Kōami
Resources

Ideas on running connected healthcare

Practical writing on clinical operations, workforce, imaging, supply chain and interoperability - from the team building Kōami.

The Digital Health Incentive Scheme: What ABDM Will Actually Pay a Hospital — Interoperability | KōamiInteroperability
Interoperability· 10 min read

The Digital Health Incentive Scheme: What ABDM Will Actually Pay a Hospital

Most hospitals meet ABDM as an obligation. A letter arrives from a state health authority, the word compliance appears in it, and the IT head starts pricing work that produces no revenue. That framing is incomplete, and expensively so, because there is a National Health Authority scheme that pays health facilities for the same digital records the compliance letter is asking them to create. The Digital Health Incentive Scheme is the part of ABDM that most purchase committees discover late, usually from a vendor slide rather than from the circular. It does not turn digitisation into a profit centre. For a hospital that was going to do the work anyway, it changes the payback arithmetic enough to be worth understanding properly before the budget is set. ## What is the Digital Health Incentive Scheme? The Digital Health Incentive Scheme, usually written DHIS, is a National Health Authority scheme that pays eligible health facilities and digital solution companies for creating health records and linking them to a patient's ABHA. The National Health Authority announced it to accelerate ABDM adoption, and has extended and revised it more than once since. The mechanism is transaction-based rather than a grant. A facility does not apply for a sum and receive it; it earns against volume of ABHA-linked records above a baseline calculated from its own size. That design is deliberate — it pays for the behaviour continuing, not for a one-off integration project that goes quiet after go-live. Two things follow from that shape, and both matter more than the headline number. The incentive rewards records that are actually linked, which means it rewards a registration counter that creates and links ABHA reliably every day rather than an integration that technically works. And because it is volume-linked, the same scheme is worth very different amounts to a 30-bed nursing home and a 300-bed hospital. ## Which hospitals are eligible for DHIS? Eligibility runs through the Health Facility Registry rather than through any separate application, and the published criteria have centred on facilities with ten or more beds registered on the HFR, transacting above a monthly baseline expressed per bed. In practice that gives a hospital three prerequisites before the scheme is even reachable. It must be registered on the Health Facility Registry and hold a valid facility ID. Its software must be an ABDM-certified health information provider, capable of creating and linking care contexts rather than merely generating an ABHA number. And it must be doing enough volume for the baseline to be cleared in a month, because incentives accrue on transactions above that line and not on the first ones. That third condition is the one that quietly disqualifies people. A hospital that links ABHA for the handful of patients who ask about it will never cross a per-bed monthly baseline. The scheme is designed to reward a counter where ABHA creation is the default path through registration, not the exception a clerk offers when the queue is short. If your registration workflow makes ABHA an extra screen someone can skip, you have built the version of compliance that costs money and earns none. The [HFR and HPR registration guide](/blog/hfr-hpr-registration) covers the registry step, which is the prerequisite people most often discover they have not completed. ## How much can a hospital earn? As the scheme has been published, a health facility earns a fixed amount per ABHA-linked transaction above a monthly baseline, subject to an overall ceiling that National Health Authority material has stated as up to four crore rupees. The figures that have circulated most consistently are these. Health facilities earn in the region of twenty rupees per eligible transaction above the baseline. The baseline for hospitals was originally set at fifty transactions per bed per month for facilities with ten or more beds; relaxations introduced from April 2023 reduced it, and a flat hundred-transactions-per-month baseline for health facilities has been widely reported since. Laboratories and smaller clinics have carried their own thresholds — commonly quoted at five hundred and two hundred transactions a month respectively — at lower per-transaction rates. Digital solution companies earn separately, at a lower per-transaction rate or a percentage of the facility's incentive. Treat every one of those numbers as indicative. The scheme has been revised repeatedly by corrigendum, and later corrigendum periods have been reported with materially different terms — lower per-record rates distinguishing a discharge summary or diagnostic report from other record types, a requirement that the ABHA be KYC-verified, and per-ABHA caps limiting how many transactions one patient can generate in a day or a month. Any of those changes the answer substantially. Take the operative corrigendum from the National Health Authority's own [DHIS page](https://abdm.gov.in/DHIS) before you put a number in a board paper. ## How should a hospital model it? With the arithmetic rather than with a headline figure, because the arithmetic survives the next corrigendum and the headline figure does not. The calculation has the same four terms whatever the current rates are. Take your monthly volume of records that would qualify — OPD and IPD encounters, discharge summaries, diagnostic reports — and be honest that this is the count that gets **linked**, not the count you generate. Subtract the baseline. Multiply by the current per-transaction rate for that record type. Apply the per-ABHA caps, which matter more than they look for a hospital with a large repeat-visit population, since a dialysis or oncology patient attending three times a week cannot generate three times the incentive. Run it twice: once at the current published rate, and once at half. If the business case only works at the higher number, it is not a business case, it is a hope. And run it against your **linked** volume rather than your registration volume, because the gap between those two is where most facilities discover their integration is thinner than the certificate suggested. The sensible use of DHIS in a software business case is as a reduction in the net cost of an integration you had already decided to do. A hospital that buys a system because of the incentive has the reasoning backwards; a hospital that ignores the incentive while budgeting the same purchase is leaving a recurring credit uncounted. ## Does the scheme pay for insurance claims too? There is a separate incentive on the claims side, and it is commonly misread as money the hospital receives. National Health Authority material has described an incentive of five hundred rupees per claim, or ten per cent of the claim amount, whichever is lower — but that arrangement accrues to the payer, the insurer or TPA processing the claim, rather than to the hospital submitting it. Hospitals reading a vendor slide about "five hundred rupees per claim" and modelling it as revenue are modelling somebody else's incentive. What the claims side does for a hospital is indirect and still worth having: payers with an incentive to process digitally are payers with a reason to onboard to [NHCX](/blog/nhcx-claims-exchange) and to accept your structured submissions. The benefit reaches you as faster settlement rather than as a payment. ## What has to be true in the software? The scheme pays for linked records, so the software has to make linking a by-product of ordinary work rather than a separate task somebody remembers to do. Concretely, ask a vendor to demonstrate the following on live ABDM sandbox or production endpoints, not on slides. - ABHA creation and verification at registration, including the Aadhaar and mobile routes, with the failure paths shown - ABHA address linking for a patient who already has one, without creating a duplicate - Care context linking on OPD registration, IPD admission, and diagnostic report publication - Consent request handling, including a denied and an expired consent - The facility's own DHIS-relevant transaction count, visible to the hospital rather than only to the vendor - Retry behaviour when the ABDM gateway is unavailable mid-registration That last two are what separate a certified integration from a system that will actually earn. If the hospital cannot see its own linked-record count without asking the vendor, nobody in the hospital can tell whether this month cleared the baseline, and a scheme nobody can measure is a scheme nobody manages. If a gateway timeout loses the link silently, the counter clerk moves on and the record is never linked — and no error was raised, so no one investigates. The [ABDM milestone certification guide](/blog/abdm-certification-milestones) sets out what M1, M2 and M3 each require, and [ABHA at the registration counter](/blog/abha-integration-hospital-software) covers what the workflow has to survive when there are eleven people waiting. ## Does DHIS change the business case for new software? It changes the arithmetic at the margin, and it changes the sequencing more than the decision. A hospital already replacing its HMS should require ABDM certification and self-visible transaction counts as contract terms; a hospital not replacing anything should not start a procurement because of an incentive. The more useful reframe is that DHIS, [NHCX](/blog/nhcx-claims-exchange) and PM-JAY now point the same direction. All three reward a hospital whose records are structured, whose identity resolution is clean, and whose transactions can be evidenced. A system bought for one of them tends to serve the others. A system bought for none of them will be retrofitted for all three, at a cost that never appears in the original quotation. The [five-year cost article](/blog/hospital-software-cost) works through where those retrofits land. ## What should a hospital do first? Check the registry, then check the counter, then read the current circular. In that order, because the first two are prerequisites the third assumes. Confirm the facility ID on the Health Facility Registry is current and the bed count on it is right, since the baseline is computed from it. Stand at your own registration desk for an hour and count how many patients leave with a linked ABHA — that number, not the vendor's certification certificate, is what the scheme pays on. Then take the current terms from the National Health Authority's [DHIS page](https://abdm.gov.in/DHIS) and model a conservative month. ## Where Kōami fits Kōami is built as an ABDM-aware system rather than one with an ABDM module bolted to the side: ABHA creation and verification sit inside the registration flow, care contexts are linked from OPD registration, IPD admission and report publication as those events happen, and consent artefacts are held against the patient record rather than in a separate log. The part worth asking us about directly is the measurement. A hospital should be able to see its own linked-record volume, its failure reasons and its month-to-date position against the baseline without raising a ticket, because that is the difference between an integration that is certified and one that earns. Bring a week of your registration volume to a [demo](/book-demo) and ask to see those counts, the gateway-failure path and the duplicate-ABHA case. Those three are where most ABDM integrations turn out to be thinner than the certificate suggests.

Read article
HL7 FHIR in India: The Standard Underneath Every ABDM Claim Your Vendor Makes — Interoperability | KōamiInteroperability
Interoperability· 8 min read

HL7 FHIR in India: The Standard Underneath Every ABDM Claim Your Vendor Makes

Ask a hospital software vendor whether their product is ABDM compliant and you will get a yes. Ask what FHIR resources they produce for a discharge summary and the conversation changes character, because the second question cannot be answered from a brochure. FHIR is the format underneath all of it. ABDM's health information exchange moves FHIR bundles. NHCX moves insurance claims as FHIR. The EHR Standards notified by the Ministry of Health and Family Welfare name it. Every interoperability promise a vendor makes in India resolves, eventually, to whether their system can emit and consume valid FHIR R4 — and a surprising number of systems that hold current certification do it through a translation layer that works for the certification test cases and little else. ## What is HL7 FHIR? FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is a healthcare data exchange standard built from small, individually addressable units called resources, exchanged over ordinary web APIs as JSON or XML. The word that matters is resources. Older healthcare messaging, HL7 v2 in particular, moved pipe-delimited messages describing events: a patient was admitted, a result was reported. FHIR instead defines discrete things — a Patient, an Encounter, a Condition, an Observation, a MedicationRequest, a DiagnosticReport — each with a defined structure and its own URL. A discharge summary is not a document format in FHIR; it is a Bundle that gathers a Composition and the resources it references. This is why FHIR won and why it is harder than it looks. It won because a REST API returning JSON is something any developer can consume without a healthcare integration engine. It is harder than it looks because agreeing on the resource shape is the easy half, and agreeing on what goes in the fields — which code system, which identifier, which cardinality — is the half that determines whether two systems actually understand each other. ## Why does FHIR matter specifically in India? Because ABDM chose it, and everything built on ABDM inherits that choice. India's national digital health architecture is built on FHIR R4, with a country-specific implementation guide maintained by NRCeS that constrains the general standard into the profiles Indian systems must produce. That last point is the one that gets lost. "Supports FHIR" is a much weaker claim than "conforms to the ABDM FHIR implementation guide", because the general standard leaves most fields optional and the national profile does not. A system can emit technically valid FHIR that an ABDM gateway rejects, for the same reason a technically valid English sentence can fail to be a valid legal filing. The practical consequence for a buyer is that there are two questions, not one. Does the system speak FHIR at all? And does it conform to the current ABDM implementation guide version — which moves, and has moved several times. A vendor who cannot name the implementation guide version they build against has answered the second question. The [ABDM milestone guide](/blog/abdm-certification-milestones) covers what certification tests; the [NHCX article](/blog/nhcx-claims-exchange) covers the claims side, which uses the same machinery for a completely different transaction. ## What does a hospital actually have to produce? The resources that carry the clinical record a patient consents to share, bundled into the ABDM-defined document types. For most hospitals that means being able to generate, from real transactional data rather than from a form somebody fills in afterwards: - A Patient resource with correctly formed identifiers, including the ABHA address - Encounter resources for OPD visits and IPD admissions with real timestamps - DiagnosticReport and Observation for laboratory and imaging results, with results as values rather than as a scanned PDF - Condition with coded diagnoses, which is where most Indian systems are thinnest - MedicationRequest and MedicationStatement for prescriptions - Composition-led bundles for the ABDM document types — discharge summary, OP consultation, prescription, diagnostic report, wellness record, immunisation record Read that list against your current system honestly. The uncomfortable entries are usually Condition and Observation. A hospital whose diagnoses live as free text in a consultation note, and whose lab results arrive as PDFs from the analyser, can produce a bundle — but it will be a bundle wrapping unstructured content, which satisfies a gateway and helps no one downstream. The [structured clinical record](/blog/hms-vs-emr-vs-ehr) question is the same question in different clothing. ## Is a translation layer good enough? For passing certification, often. For everything you would want interoperability for, usually not, and the difference shows up two years later rather than at go-live. A translation layer sits between a legacy database and the gateway, mapping columns to FHIR fields on the way out. It is a legitimate engineering approach and plenty of certified systems use one. The failure mode is that the mapping is only as rich as the source: if the underlying table has one free-text field where the profile expects a coded Condition, the translator must either leave it empty or stuff text into a coded field. Both pass a syntax check. Neither produces a record another hospital can use. The way to test this without reading anyone's code is to ask for output. Request the actual FHIR bundle for a real discharge — de-identified — and read it. Are diagnoses coded, or is there a `text` field carrying a sentence? Are lab results Observations with values and units, or one DocumentReference pointing at a PDF? Are the timestamps the real event times, or all identical because they were stamped at export? Fifteen minutes with one bundle tells you more than a day of demos. ## What should be in the contract? Version commitments and export rights, because the standard moves and vendors do not always follow it on your timetable. Four clauses worth insisting on. Name the ABDM FHIR implementation guide version the system conforms to today, and commit to a window for supporting future published versions. Require that the hospital can request a FHIR export of its own data on demand, in bulk, without a per-record charge — this is the single most valuable exit clause available to an Indian hospital and almost nobody asks for it. Require that gateway failures are visible to the hospital rather than swallowed. And put the conformance obligation on the vendor rather than on "the integration partner", so it does not become an argument between two suppliers while you are non-compliant. The [switching article](/blog/switching-hospital-software) covers why the export clause matters far more than it seems when you sign. ## Where Kōami fits Kōami stores the clinical record structurally — coded diagnoses, orders as orders, results as values with units — which is the part that makes FHIR output meaningful rather than merely valid. The ABDM bundles are generated from those records as events happen, not assembled by a nightly job reading free text. We would rather be tested on this than described. The useful thing to ask for at a [demo](/book-demo) is the bundle: pick a discharge, ask for the FHIR it produces, and read the Condition and Observation resources. Then ask the same of everyone else on your shortlist. It is the fastest way to sort systems that are interoperable from systems that are certified.

Read article
Agentic AI in a Hospital: Where an Agent May Act, and Where It May Only Ask — Clinical AI | KōamiClinical AI
Clinical AI· 9 min read

Agentic AI in a Hospital: Where an Agent May Act, and Where It May Only Ask

The vocabulary changed some time in the last eighteen months. Hospital software proposals that used to promise AI-assisted this and AI-powered that now promise agents: software that does not merely suggest, but plans a sequence of steps, calls systems, and completes work without a person in the loop for each step. The distinction is real and it is not marketing. A model that drafts a discharge summary for a doctor to sign is a tool. Software that reads a rejected claim, decides which document is missing, retrieves it, re-files the claim and updates the receivables ledger is something else, and it needs a different set of questions asked of it. Most hospitals are being sold the first thing under the second thing's name, which is confusing but harmless. The hospitals that are genuinely being sold the second thing are the ones who need to think carefully. ## What makes something an agent rather than a feature? An agent decides on a sequence of actions and executes them against real systems; a feature produces an output that a person then acts on. The dividing line is whether anything changes in the hospital's records without a human deciding that it should. By that test, ambient documentation is not an agent — it drafts, a clinician signs. An alert is not an agent. A model that predicts discharge readiness is not an agent. But software that autonomously re-orders stock when a reorder point is breached is an agent, and hospitals have had those for years without calling them that. So has anything that auto-posts a payment, auto-assigns a bed, or auto-cancels an unconfirmed appointment. Recognising that is useful because it deflates the novelty and sharpens the actual question. Hospitals already delegate actions to software. What is new in 2026 is the breadth of what can be delegated and the fact that the decision procedure is now a language model whose reasoning is neither fixed nor fully inspectable. The governance question is not "should we allow agents", which was answered years ago by every auto-reorder rule in your pharmacy. It is "which actions, under what authority, reversible how". ## Which agent use cases are actually working? The ones where the action is reversible, the domain is administrative rather than clinical, and there is a natural verification step downstream. Where deployments are demonstrably delivering value: - Documentation drafting, which is the most widely adopted healthcare AI use case anywhere and remains a draft-and-sign workflow - Claim status chasing and denial triage, where the agent classifies a rejection and assembles the response pack for a human to submit - Prior authorisation preparation, gathering the clinical evidence a payer will ask for before anyone asks - Coding suggestion against the clinical record, reviewed by a coder - Patient communication — appointment confirmation, preparation instructions, follow-up reminders — within scripted bounds - Scheduling optimisation, proposing a theatre list or a roster that a human approves Notice the shape. In almost every entry, the agent does the assembly and a person does the commitment. That is not timidity; it is where the economics currently are. The assembly is the expensive, tedious, error-prone part, and it is the part where being wrong costs a re-run rather than a patient. Our [broader AI article](/blog/ai-hospital-management-software) covers what is real across the wider category, and [hospital AI governance](/blog/hospital-ai-governance) covers the control framework. ## Where must an agent not act autonomously? Anywhere the action is clinical, irreversible, or financially final without a person's name attached to it. The list is short and should be written down before any pilot, not after one. No autonomous change to a medication order, a dose, a diagnosis or an allergy record. No autonomous discharge decision or triage disposition. No autonomous release of a diagnostic report. No autonomous refund, write-off, credit note or price override. No autonomous disclosure of a patient record to any external party — that one is a consent question under the [DPDP Act](/blog/dpdp-act-hospitals) before it is an AI question. And no autonomous deletion of anything, ever. Two design rules make the rest safe. Every agent action must be attributable — the audit trail records that this agent, on this version, acting under this delegated authority, did this thing, and a named human owns that delegation. And every agent action must be reversible by a person who did not need to understand the agent to reverse it. If reversing a mistake requires a support ticket to the vendor, the action should not have been delegated. ## How should a hospital pilot one? On one workflow with a measurable baseline, with the agent's output compared against human output for a defined period before anything is switched off. The failure pattern is recognisable. A pilot starts without a baseline, so at the end nobody can say whether the agent helped. It runs on a workflow chosen because it demos well rather than because it hurts. Success is reported as "staff liked it", which is a real signal but not a business case. And the agent is left running with permissions granted for the pilot that nobody revisits. A better shape: pick a workflow where you already measure cycle time — claim first-pass rate, denial turnaround, documentation lag — because [those numbers](/blog/hospital-cycle-time-kpis) are the only honest scoreboard. Run the agent in shadow mode first, producing output that nobody acts on, and compare. Then run it with human confirmation on every action. Only then consider narrowing the confirmation to exceptions, and only for the action classes on the permitted list. ## What should be in the contract and the audit trail? Model disclosure, data boundaries, action logs, and the right to turn it off without losing the workflow. Ask where inference happens and whether patient data leaves your jurisdiction — the answer determines whether this is a procurement decision or a [data residency](/blog/data-residency) decision. Ask whether your data trains anyone's model, and get the answer in the agreement rather than in an email. Require that agent actions are separable in the audit trail, so you can produce every action an agent took in a period without filtering by hand. Require a kill switch that degrades to the manual workflow rather than to nothing. And require notice before a model version changes, because a system whose behaviour changes silently cannot be validated. ## Where Kōami fits Kōami's position is that an agent is only as good as the record it acts on, and that the hospital rather than the vendor should hold the delegation. Structured clinical data, an audit trail that records the actor and the authority for every write, and role-based permissions that apply to automated actors the same way they apply to people — those are the prerequisites, and they are worth having whether or not you ever switch an agent on. Where we are deliberately conservative is the permitted-action list above. We would rather ship assembly-and-approve workflows that a hospital can audit than autonomous clinical or financial actions that demo impressively and fail quietly. If you are evaluating agentic claims from anyone, bring the question that settles it to a [demo](/book-demo): show me the audit trail for one agent action, and show me how a ward sister reverses it.

Read article
ABHA at the Registration Counter: What Integration Survives a Queue — Interoperability | KōamiInteroperability
Interoperability· 8 min read

ABHA at the Registration Counter: What Integration Survives a Queue

ABHA integration demos beautifully. A clerk types a mobile number, an OTP arrives, an ABHA address appears, and everybody in the room agrees the hospital is now digital. The demo is conducted with one patient, a good network, and nobody waiting. The registration counter at nine in the morning is a different environment. There are eleven people in the queue, the patient does not remember which mobile number their Aadhaar is linked to, the network is slow, and the clerk is measured on how fast the line moves. Whether ABHA works in your hospital is decided entirely by what the software does in that environment, and not at all by whether the integration is certified. ## What does ABHA integration actually involve? Three separate capabilities that vendors often present as one: creating an ABHA for a patient who has none, verifying and linking an existing ABHA, and linking care contexts so records become discoverable. The first is an onboarding function and the easiest to demonstrate. The second is identity resolution and is where the counter friction lives. The third is the one that matters most and gets shown least, because it is invisible — no screen changes when a care context links correctly. A system can do the first two well and the third badly, and it will still look compliant. It will also produce no value: an ABHA number with no linked records is an identifier attached to nothing. The [ABDM milestone guide](/blog/abdm-certification-milestones) sets out how M1, M2 and M3 divide these, and it is worth knowing which milestone a vendor's certificate actually covers. ## Why does ABHA creation slow the counter down? Because it inserts an identity verification step into a workflow that previously required only a name and a phone number, and identity verification fails in ways a registration clerk cannot fix. The common failures are worth naming, because a system's handling of them is what you are really buying. The patient's Aadhaar is linked to a mobile number they no longer use. The OTP does not arrive, or arrives after the clerk has moved on. The patient is a minor, or elderly, or unconscious in casualty, and the person present is not the patient. The patient already has an ABHA created at another hospital and does not know it. The demographic match is ambiguous — two records, similar names, same date of birth. A well-designed system does three things about this. It never blocks registration on ABHA: the patient is registered, seen and billed, with ABHA capture deferrable to a task somebody clears later. It makes the deferred queue visible, so the deferral does not become a black hole. And it detects the already-has-an-ABHA case before creating a second one, because duplicate ABHAs are a mess that propagates outward into every hospital that patient later visits. If a vendor's answer to "what happens when the OTP does not arrive" is that the clerk retries, ask what the clerk does on the fourth retry with eleven people waiting. The real answer is that they skip it, permanently, and your ABDM programme quietly stops. ## What is care context linking and why does it matter more? Care context linking is what makes a patient's record at your hospital discoverable and shareable through ABDM; without it, an ABHA number is an identifier with nothing behind it. Every clinically meaningful event should create a care context: an OPD registration, an IPD admission, a discharge, a diagnostic report becoming available, a prescription being issued. The link tells the network that this hospital holds a record of this type for this ABHA, so that when the patient consents at another facility, there is something to fetch. This is also the transaction the [Digital Health Incentive Scheme](/blog/digital-health-incentive-scheme) pays on, which makes it the one worth instrumenting. Ask to see the hospital's own count of linked care contexts by type and by day. If that number is only available from the vendor, nobody at the hospital can tell whether linking stopped working three weeks ago — and linking failing silently is the single most common way an ABDM programme dies without anyone noticing. ## How should consent be handled? As a first-class record with a lifecycle, not as a checkbox on the registration screen. Under ABDM, a health information user requests consent, the patient grants or denies it through their own consent manager, and the grant carries a purpose, a date range and an expiry. Your system is on the other side of that: it receives requests, checks them against what it holds, and releases data only within the granted scope. Four behaviours to test explicitly. A denied consent — what does the requesting facility see, and what does yours log? An expired consent used to fetch data — is the fetch refused? A revoked consent — does anything already fetched come back, and what does the hospital tell the patient about that? And a consent artefact retained against the patient record, retrievable a year later when someone asks under what authority a record was shared. The [DPDP Act article](/blog/dpdp-act-hospitals) covers where ABDM consent and Indian data protection obligations overlap, and where they do not. ## What should a hospital ask a vendor to demonstrate live? Six things, on production or sandbox endpoints, with the network genuinely interfered with at least once. - Register a patient with no ABHA, defer capture, and show where that patient appears in a follow-up queue - Create an ABHA by Aadhaar, then handle the case where the OTP never arrives - Verify a patient who already has an ABHA address without creating a second one - Link a care context on OPD registration, and show the hospital-visible count increment - Disconnect the network mid-registration and show what the clerk sees and what reconciles afterwards - Produce the linked-care-context count for last month, broken down by type, from a screen the hospital can open itself The fifth is the one that separates systems designed for a hospital from systems designed for a certification test. A gateway timeout must not lose the patient's registration, and it must not silently drop the link either — it should queue and retry, and the failure should be visible somewhere a human looks. ## Where Kōami fits In Kōami, ABHA sits inside registration rather than beside it: creation and verification happen in the same flow as the rest of patient identity, capture is deferrable so the counter is never blocked, and care contexts link from OPD registration, IPD admission and report publication as those events occur. The parts we would rather be judged on are the unglamorous ones — the deferred-capture queue, the duplicate check, the retry behaviour when the gateway is slow, and the hospital-visible linking counts. Bring an hour of your real registration volume and your worst-case network to a [demo](/book-demo), and ask to see the failure paths before the happy one.

Read article
Dialysis Unit Software: Chairs, Machines, Sessions and the Bill — Product | KōamiProduct
Product· 8 min read

Dialysis Unit Software: Chairs, Machines, Sessions and the Bill

A dialysis unit is the one part of a hospital that runs like a factory and is almost always managed like a clinic. The same patients return three times a week for years. Each session occupies a specific chair, a specific machine and a specific slot, consumes a dialyser and a bloodline set, and generates a bill that is frequently paid by a scheme rather than by the patient. General hospital software handles this badly, and it handles it badly in a consistent way: it models a dialysis session as an OPD visit. That single modelling decision is the origin of most of the complaints. An OPD visit is an episode; a dialysis session is one instance of a standing schedule, and the difference shows up in scheduling, in stock, in billing and in every report the nephrologist wants. ## What makes dialysis different from other outpatient care? Recurrence. A dialysis patient is not a visit, they are a slot — usually a fixed shift on fixed days of the week, held for months or years, against a finite number of chairs. That has consequences a visit-shaped system cannot express. Capacity is a grid of chairs times shifts times days, not a doctor's appointment book. A cancelled session is a hole in a recurring pattern that somebody should fill today, not a missed appointment. A new patient cannot be admitted to the programme unless a slot exists, which makes waiting-list management a real function rather than a spreadsheet. And utilisation — the number the unit is actually run on — is sessions delivered against chair-shifts available, which a system that does not model chair-shifts simply cannot compute. ## What should dialysis software track for each session? The clinical parameters, the consumables, the machine and the staff, linked to one session record that is also the billable unit. At minimum, per session: - Pre and post weight, target ultrafiltration and achieved ultrafiltration - Blood pressure at intervals through the session, not only at start and end - Dialyser type, and whether it is a first use or a reuse with the reuse count - Bloodline set, needles, heparin dose and any medication given during the session - The machine used, by asset ID, and the vascular access used - Start time, end time, and any interruption with its reason - Nurse and technician on the session, and the nephrologist responsible The dialyser reuse count is the entry that most general systems have nowhere to put, and it is not optional: reuse is protocol-governed, patient-specific and auditable, and a unit that tracks it on a card taped to the machine has no way to report on it. Tie the dialyser to the patient rather than to the stock ledger alone, and the reuse count becomes a data field instead of a discipline. ## How should a dialysis unit be scheduled? As a recurring assignment of a patient to a chair-shift, with exception handling, rather than as a stream of individual appointments. The scheduling model that works is a weekly template: this patient occupies chair 4, second shift, Monday–Wednesday–Friday, from this date. Everything else is an exception against that template. A session is cancelled, so the slot is offered. A patient is admitted as an inpatient, so their sessions move to the ward. A holiday shifts the whole grid. A machine goes down for service, so its chairs are unavailable and the patients on them need relocating — which is a [biomedical maintenance](/blog/hmis-roi) event and a scheduling event at the same time, and in most hospitals those two facts live in different systems and different heads. Isolation adds a hard constraint that scheduling must respect rather than leave to memory. Hepatitis B positive patients require dedicated machines and, in most units, a dedicated area. That is a rule the system should enforce when assigning a chair, not a convention the senior nurse holds. A scheduler that will happily assign a seropositive patient to a general machine is a scheduler that will do it on a busy Monday when the person who knows is on leave. ## How does dialysis billing differ? It is high-frequency, low-value, and mostly paid by somebody other than the patient — which inverts the usual billing design. A hospital's billing is built for episodes: admit, accumulate charges, discharge, bill. Dialysis generates a small bill three times a week, forever, often split across a scheme, a corporate panel and a cash component for consumables outside the package. The work is not in producing any one bill; it is in producing four hundred of them a month without a human touching each one, and in reconciling them against a scheme's payment file afterwards. What that requires: session completion should generate the charge automatically, with the consumables consumed on that session priced from the actual dialyser and bloodline used rather than from a standard assumption. Package rules need to know what the scheme covers per session and what falls outside. Erythropoietin and iron, often given in the unit, need to attach to the session or to a separate order without a second registration. And the receivables view a unit manager needs is per-scheme and per-month, not per-patient — the [claim settlement article](/blog/reduce-claim-settlement-time) covers where those days go. ## What reports does a nephrologist actually ask for? Adequacy, access, and the trends that change treatment — none of which come out of a system that stores sessions as visits. Kt/V or URR by patient over time, with the sessions that fell below target flagged rather than buried. Interdialytic weight gain trends, which is the number that tells you whether a dietary conversation worked. Vascular access history per patient — fistula, graft or catheter, with dates — because access failure is the dominant cause of hospitalisation in this population. Hospitalisation and mortality by cohort. Machine-level incident history, which is a quality question and a [biomedical equipment](/biomedical-equipment-management-software) question at once. Every one of those is a time series across recurring sessions. A system that records each session as an unrelated visit can produce them only by export and spreadsheet, which is why so many units run on a parallel register the software knows nothing about. ## Where Kōami fits Kōami is a hospital platform rather than a dedicated nephrology product, and the honest framing is that a large standalone dialysis chain should evaluate specialist software alongside us. What Kōami brings is the connection: the session is one record that carries the clinical parameters, consumes stock from the same [inventory](/products/inventory) the pharmacy uses, generates the charge on the same [billing](/hospital-billing-software) engine as the rest of the hospital, and sits on the same patient identity as the nephrology OPD and any admission. For a hospital running a dialysis unit inside a larger facility, that connection is usually the problem worth solving — the unit's isolation from the hospital's record is what generates the duplicate entry, the untracked consumables and the reconciliation. Bring one week of your session register and one scheme's payment file to a [demo](/book-demo), and ask to see the chair-shift grid, the reuse count and the automatic charge from a completed session.

Read article
Best Hospital Management Software in Nepal: A Buyer’s Guide — Product | KōamiProduct
Product· 8 min read

Best Hospital Management Software in Nepal: A Buyer’s Guide

The best hospital management software in Nepal is not the product with the longest module list. It is the system that can run one real patient journey — registration, consultation, admission, orders, pharmacy, billing and discharge — without staff rebuilding the record at every counter. Nepalese hospitals also have localisation questions that a generic international demo can conceal: Nepalese rupees, local invoices and fiscal periods, Health Insurance Board processes, routine HMIS reporting, connectivity outside the strongest urban networks, and support when a ward is working after normal office hours. A serious comparison puts those questions beside clinical depth and total cost. ## What should an HMS in Nepal include? At minimum, it should connect the patient-facing and back-office workflows on one identity. - Registration, appointments, OPD token and consultation - IPD admission, transfer, bed state, nursing and discharge - Structured EMR, orders, laboratory and imaging results - Pharmacy dispensing, batch and expiry, stores and procurement - NPR tariffs, packages, receipts, refunds and payer splits - Insurance worklists, document completeness and settlement tracking - Management dashboards and exportable routine reports The phrase “all-in-one” is not enough. Ask the vendor to enter a service once and show where it appears: in the clinical record, department worklist, stock ledger and bill. If four people still re-enter it, the modules are adjacent rather than integrated. ## How should a Nepalese hospital compare vendors? Score the same live scenarios across every vendor. Give each team your tariff sheet, one insurance case, one lab order, one return to pharmacy and one corrected bill. Do not accept screenshots for a workflow the hospital performs every day. Evaluate six dimensions: workflow depth, Nepal localisation, interoperability, implementation capacity, support, and five-year cost. Give localisation its own acceptance criteria. “Configurable” should mean the vendor can demonstrate the configuration, identify who maintains it and commit to it in the statement of work. Use the [hospital software in Nepal checklist](/hospital-management-software-nepal) as a starting point, then add the cases that generate the most complaints in your own hospital. ## What Nepal-specific requirements need proof? Currency is the easy part. The harder part is matching the forms, calendars, payer rules and reports people actually use. Ask for the exact NPR invoice and receipt formats finance has approved. Test the fiscal-year rollover and any Bikram Sambat date requirement in the actual output, not merely on screen. For Health Insurance Board work, trace eligibility or beneficiary details, services, supporting evidence, queries and settlement reconciliation. For routine reporting, ask the medical-records team to bring last month’s submission and identify which fields can come from transactional data. The Ministry of Health and Population is actively developing digital-health and interoperability initiatives. A vendor should therefore show open APIs, structured exports and standards awareness, not claim that today’s interface will never change. Nepal’s [Digital Health platform](https://digitalhealth.mohp.gov.np/digital-health-platform/) explicitly describes links among HMIS, EHR systems and the Health Facility Registry. ## Is cloud or on-premise better in Nepal? Neither is automatically better. The decision depends on measured connectivity and the hospital’s ability to maintain infrastructure. Cloud removes server-room maintenance, simplifies multi-site access and makes geographic recovery easier. On-premise can be defensible where connectivity is genuinely unreliable and the hospital has people who patch, monitor, back up and test restores. The dangerous choice is cloud without a downtime process or on-premise without an IT operating discipline. During the demo, disconnect the network. Ask what registration, pharmacy and billing staff do for the next two hours, how temporary records are reconciled and when the continuity process was last rehearsed. Read the detailed [cloud versus on-premise guide for Nepal](/blog/cloud-vs-on-premise-hms-nepal) before deciding. ## Where does Kōami fit? Kōami connects hospital operations, workforce, inventory, PACS, fertility and biomedical equipment on one identity and data model. That makes it relevant to hospitals and groups trying to replace disconnected departmental systems. The platform is India-first today, so Nepal-specific statutory, payer, payroll and reporting requirements should be scoped and accepted before go-live rather than assumed. That is a more useful starting point than a “fully localised” claim nobody has tested. Bring your forms and one complete patient journey to a [Nepal discovery call](/book-demo); the outcome should be a written map of what is ready, what is configuration and what requires localisation.

Read article
Hospital Management Software Cost in Nepal: A Five-Year View — Product | KōamiProduct
Product· 7 min read

Hospital Management Software Cost in Nepal: A Five-Year View

A quotation for hospital management software in Nepal is rarely the cost of the system. It is the visible first line of a five-year operating commitment that also includes implementation, migration, interfaces, training, infrastructure, support and change requests. Comparing only licence prices rewards the proposal that moved the most work out of the licence line. A fair comparison converts every bid into the same five-year model and attaches deliverables to every amount. ## What determines HMS cost in Nepal? Scope determines cost more than bed count alone. A 40-bed surgical hospital with an operating theatre, implants, package billing and insurance can require more configuration than a larger hospital with simpler flows. The main cost drivers are sites, simultaneous users, modules, data volume, interfaces, payer complexity, local reporting, custom documents and the support window. Ask vendors to state what their metric means. “Per bed” may mean sanctioned, operational or occupied beds. “Per user” may mean named or concurrent users. “Unlimited” may exclude mobile apps, storage, reports or future branches. Put the definition in the commercial schedule. ## Which costs are usually missing from the quote? The missing work is usually the work that decides whether the project succeeds. - Data profiling, cleanup, mapping and repeated trial migrations - Lab analyser, PACS, payment, SMS and other interfaces - Nepal-specific invoices, fiscal calendars, reports and payer workflows - Devices, printers, barcode scanners, labels, networking and backup links - Staff time for process decisions, master-data approval and training - Go-live floor support, after-hours coverage and later refresher training - Report changes and integrations requested after users see the live system - Data export, archive access and transition support at contract exit A proposal that says “migration included” should name the source systems, historical period, objects, trial cycles and reconciliation reports. Otherwise it is a promise without a boundary. ## How should hospitals compare cloud and on-premise cost? Use total cost, not subscription against server purchase. For cloud, include subscription escalation, storage growth, interfaces, backup connectivity and premium support. For on-premise, include servers, database licences, power, cooling, monitoring, backup media, off-site recovery, hardware refresh and the staff who maintain all of it. Add the cost of planned downtime and the cost of an unplanned outage to both models. Cloud usually makes costs more predictable and removes the refresh cliff. On-premise may use recent hardware the hospital already owns. The correct answer can change by facility, which is why the assumptions belong next to the total. ## What payment milestones protect the hospital? Tie payment to evidence the hospital can accept. A practical sequence is a mobilisation payment, configuration sign-off, first trial migration, interface testing, user-acceptance completion, go-live and a stability holdback released after agreed measures are met. Define those measures: reconciliation balances, critical scenarios passed, response times, open severity-one defects and user coverage. Avoid paying most of the project before the first real data appears. Configuration screens are easy to demonstrate; a reconciled pharmacy stock ledger, patient balance and opening receivable are the work. ## How is return on investment measured? Measure the few operational changes the system can actually influence. Establish baselines before implementation: registration time, discharge-to-final-bill time, rejected insurance claims, pharmacy expiry loss, stock-outs, duplicate registrations, manual report hours and days to close the month. Give each measure an owner and compare it at 30, 90 and 180 days after go-live. Software does not create the return by being installed. It creates the conditions for a new process, and management creates the return by enforcing that process. A [phased implementation plan](/blog/hmis-implementation-nepal) should therefore sit beside the financial model. For Kōami, pricing is quotation-based because scope, localisation and integration drive the work. A useful [demo](/book-demo) should end with assumptions written down clearly enough that another vendor can price the same scope. That makes the comparison better even if Kōami is not selected.

Read article
A Practical HMIS Implementation Plan for Hospitals in Nepal — Operations | KōamiOperations
Operations· 8 min read

A Practical HMIS Implementation Plan for Hospitals in Nepal

An HMIS implementation fails long before go-live if the project is treated as a software installation. The difficult work is agreeing how the hospital will register patients, name services, move stock, document care, close bills and produce reports when every department currently has its own answer. For hospitals in Nepal, the implementation also has to test local finance, insurance, government reporting and connectivity requirements. Those belong in the first design workshops, not in a localisation sprint after the system is otherwise complete. ## What should happen before configuration begins? Map the current patient and data journeys, then name the future owner of each decision. Follow five real cases from entry to closure: cash OPD, insured OPD, cash admission, insured admission and an emergency case. Record every register, form, spreadsheet, approval, label and handoff. Then list the master data underneath them — services, tariffs, packages, doctors, beds, stores, medicines, tests and users. The output is not a long requirements document. It is a decision register: what will remain, what will change, who approves it and by when. Unresolved decisions should be visible to the steering group every week. ## Which modules should go live first? Choose a sequence that creates one complete flow. For most hospitals, registration, appointments, OPD, billing and pharmacy form the first useful release. IPD, nursing, discharge and insurance follow once identity, tariffs and stock are stable. Laboratory and imaging interfaces should be prepared early because external vendors and device testing make their timelines less predictable. Do not launch fifteen half-trained modules on one date. A phased go-live is not less ambitious; it creates a reliable base before more clinical risk is placed on it. - Phase 1: patient master, OPD, cash billing and pharmacy - Phase 2: IPD, beds, nursing, discharge and payer workflows - Phase 3: laboratory, imaging, theatre and deeper clinical documentation - Phase 4: procurement, management analytics and advanced integrations ## How should legacy data be migrated? Profile it before promising to move it. Count duplicate patients, missing identifiers, inactive items, negative stock, unclosed admissions and balances that do not reconcile. Decide what must be transactional in the new system and what can remain in a searchable archive. Most hospitals need active patients, allergies, current medications, open balances, stock and recent reports more urgently than every old click. Run at least three trial migrations. Each one needs a signed reconciliation: patient counts, opening receivables, pharmacy quantity and value, deposits, open admissions and key clinical histories. Migration is complete when these balances are understood, not when an import command finishes. ## How should staff training work? Train by role on real shifts and real exceptions. A front-desk user needs twenty repetitions of registration, correction, refund and duplicate handling. A nurse needs admission, medication, transfer and downtime practice. A doctor needs the shortest safe path through notes, orders and discharge. Department super-users should train early, help test, and own local reinforcement after the vendor leaves. Measure competence with scenarios rather than attendance sheets. Keep the sandbox available, schedule refresher sessions after two weeks, and put floor support where demand peaks — often registration, pharmacy, wards and billing. ## What proves the implementation is stable? Agree the measures before go-live. Track unresolved critical defects, transaction response time, duplicate registrations, bills requiring manual correction, stock reconciliation variance, unposted services, help requests by department and downtime events. Compare core operating measures with the baseline: registration time, discharge billing time, insurance query rate and report preparation hours. The project can close only when owners have accepted the workflows, reconciliations balance, support routes work and the hospital has exercised downtime and restore procedures. The system should also be ready for evolving national interoperability: Nepal’s [Standards and Interoperability Lab](https://digitalhealth.mohp.gov.np/sil-nepal/) exists specifically to advance testing and interoperable digital-health systems. [Kōami Hospital](/products/hmis) supplies the connected clinical and operational backbone. Nepal-specific gaps should appear openly in the implementation backlog with an owner and acceptance test. Bring the project team, not only the procurement team, to the [discovery call](/book-demo).

Read article
Connecting Hospital Records to Nepal’s HMIS Reporting — Interoperability | KōamiInteroperability
Interoperability· 7 min read

Connecting Hospital Records to Nepal’s HMIS Reporting

A hospital information system and Nepal’s national HMIS do different jobs. The hospital system records individual patients, orders, services, stock and bills so care can be delivered. National HMIS reporting aggregates selected activity so health services can be monitored and planned. Confusing the two creates duplicate entry. Staff run the hospital in one system, then rebuild monthly totals in another because the local fields and national indicators were never mapped. The better design treats reporting as an output of care data, with human validation where definitions require judgement. ## What is the difference between hospital HMIS and national HMIS? In procurement, HMIS often means the application that runs a hospital. In government reporting, HMIS means the routine reporting framework and platform used by health authorities. The operational system is patient-level and transactional. National reporting is generally indicator-level and aggregate. One evolves with hospital workflows; the other evolves with policy and programme definitions. A vendor saying “we support HMIS” should specify which meaning, which forms or interfaces, and for which reporting period. ## Which data can be generated automatically? Counts built from consistently recorded events are the best candidates. Visits, admissions, discharges, diagnoses, procedures, tests, births, deaths and service utilisation can often be derived if source fields are structured and definitions are mapped. Free-text notes are a weak source because two clinicians can describe the same event differently. A dropdown with the wrong code is not better, so the mapping requires medical-records and clinical review. Every indicator should have a small specification: numerator, denominator where relevant, source event, inclusion and exclusion rules, reporting period, facility and responsible reviewer. Keep versions. If a definition changes, the hospital must still explain why the same query produced a different number this year. ## How should data quality be checked? Validate close to the source and before submission. Create exception worklists for missing age or sex, invalid dates, discharge without outcome, diagnosis without code, procedure without department and totals that differ from a related register. Give the department that creates the data ownership of the correction. A medical-records officer should not be expected to guess what happened in theatre. Then reconcile aggregate reports to operational controls: visits to registration, admissions to ADT, lab tests to the LIS and pharmacy issues to stock movement. Preserve the submitted version, reviewer, timestamp and any correction. An audit trail turns a monthly spreadsheet into a defensible reporting process. ## What integration design will survive change? Use open interfaces and a mapping layer rather than hard-coding a report into clinical screens. The Ministry’s current digital-health direction emphasizes standards and interoperability. Its [digital platform plan](https://digitalhealth.mohp.gov.np/digital-health-platform/) envisages links among HMIS, EHR systems and the Health Facility Registry, while [SIL-Nepal](https://digitalhealth.mohp.gov.np/sil-nepal/) supports standards-based design and testing. That makes five capabilities important: stable patient and facility identifiers, coded clinical data, APIs, versioned indicator mappings and export in usable structured formats. The exact exchange mechanism may change; clean source data and an open integration boundary remain valuable. ## What should a hospital ask an HMS vendor to demonstrate? Bring one report the facility submitted last month. Ask the vendor to trace five totals back to the underlying patients, show missing-data exceptions, apply a correction, regenerate the report and preserve both versions. Ask who updates mappings when government definitions change, how fast changes are tested, and whether the facility can export the source data independently. Do not accept a static PDF template as integration. The value is the lineage from a reported figure to the events that produced it. ## How does Kōami approach Nepal reporting? Kōami captures registration, encounters, ADT, diagnoses, orders, results, pharmacy, billing and other operational events on one record. That creates a strong source for routine indicators and management reporting. Nepal-specific HMIS forms, indicator mappings and live exchange requirements still need discovery and acceptance with the facility’s medical-records team. They should be treated as maintained interfaces, not as a one-time checkbox. A [Nepal HMS discovery call](/book-demo) should begin with the actual forms and submission workflow, and end with a written integration scope.

Read article
Health Insurance Board Claims: What a Hospital HMIS Must Track — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 7 min read

Health Insurance Board Claims: What a Hospital HMIS Must Track

A health-insurance claim is not created at discharge. It begins when the beneficiary is identified and the planned service is checked, continues through every documented service, and succeeds only when the evidence, submission, query and settlement all refer to the same episode. When the insurance desk keeps a separate register from registration, pharmacy, diagnostics and billing, staff spend the claim reconstructing care that the hospital has already delivered. A connected HMIS should make the claim a view of the patient episode rather than a second version of it. ## Where does a Health Insurance Board claim begin? At patient identification and eligibility, before avoidable financial assumptions are made. The hospital needs to associate the beneficiary and relevant insurance details with its own MRN without creating a duplicate patient. Staff then need a visible record of the applicable benefit, referral or authorization requirement and facility-specific process. Rules and benefit packages change, so the live Health Insurance Board source must outrank a software default. The Board publishes current documents and benefit information on its official site. Its [benefit package](https://hib.gov.np/public/uploads/shares/Benefit_Package_Updated_Final_2081_Jul10_2024.pdf) notes mandatory IMIS documentation for claim reimbursement in covered contexts; hospitals should confirm the current version and operational guidance directly with HIB. ## What evidence should the HMIS collect? Evidence should be captured as care happens and attached to the episode it supports. That can include registration and beneficiary details, referral or authorization records, clinical notes, diagnoses, orders and results, procedure notes, medicines, itemized services, discharge summary and required attachments. The exact set depends on current HIB rules and the service. The system should show missing evidence before discharge, not after submission. A checklist is useful only if each item links to the real document or structured event and records who completed it. Uploading everything into one undifferentiated folder simply moves the search from paper to a screen. ## How should queries and rejected claims be managed? As a named work queue with deadlines and root causes. Every claim needs a status, owner, last action, next action and ageing. Queries should record the question, due date, response and attachments. Rejections need categories such as eligibility, referral, benefit, coding, missing documentation, inconsistency or submission error. Without categories, management sees a backlog; with them, it sees which upstream process to fix. The [openIMIS manual used by Nepal’s HIB implementation](https://imis.hib.gov.np/Manual/IMIS_manual.pdf) shows the importance of correctly classifying claims and care settings inside the insurance system. An HMS interface should therefore preserve the identifiers and meanings needed for reconciliation rather than flattening everything into a generic payer bill. ## How should settlements be reconciled? At claim and adjustment level, not only as one bank receipt. A batch payment can cover many claims, with some fully paid, some adjusted and some excluded. Finance needs to match the receipt to individual claims, post deductions with reasons, reopen unresolved balances and produce ageing by status. Otherwise the ledger can show money received while the claims team cannot explain what remains due. Track four intervals: discharge to submission, query received to response, submission to decision, and decision to settlement. These identify delays the hospital controls separately from time spent with the payer. ## What should a vendor demonstrate? Use one completed and one queried case from your facility, with identifying data removed. Ask the vendor to register the beneficiary, record covered services, show missing evidence, assemble the claim view, receive a query, attach a response and reconcile a partial settlement. Confirm how current HIB or IMIS rules are updated and who owns interface failures. Do not accept “insurance module available” as evidence. Ask to see the claim move. ## How does Kōami support the workflow? [Kōami Hospital](/products/hmis) connects registration, clinical documentation, orders, pharmacy, billing and discharge, so the evidence originates on one episode. It can support insurance worklists, documents, query tracking and settlement reconciliation. The exact HIB electronic interface and the currently applicable claim rules require verification during a Nepal implementation. That boundary belongs in the proposal, along with test cases and responsibility for future changes. Bring a real de-identified claim to a [workflow demo](/book-demo).

Read article
Hospital Billing Software for Nepal: What to Test Before You Buy — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 7 min read

Hospital Billing Software for Nepal: What to Test Before You Buy

Hospital billing software in Nepal has to do more than print a receipt in Nepalese rupees. It must price the care recorded across OPD, wards, theatre, laboratory, imaging and pharmacy, apply the right tariff or package, preserve every correction and produce outputs that finance, patients and payers can trust. Most billing delays are not typing delays. They are waiting for departments to post services, resolve package boundaries, return medicines or approve discounts. The best billing design removes those handoffs by making a charge part of the clinical or stock event that created it. ## What should hospital billing software in Nepal include? It should cover cash, credit, sponsor and insurance episodes without maintaining separate patient bills. - NPR tariffs by service, department, payer, sponsor and effective date - OPD invoices, deposits, interim IPD bills and final settlement - Packages with defined inclusions, exclusions and overstay rules - Split responsibility between patient, insurer, employer or other sponsor - Pharmacy, consumable, laboratory and imaging charges from source events - Refunds, reversals, credit notes and discounts with approval and audit trails - Daily collection, cashier closure, receivables, adjustments and settlement reports Ask the vendor to show a correction after payment. The reversal should update the patient balance, cashier record and any linked stock movement without deleting history. ## How should local invoice and fiscal requirements be tested? With documents approved by the hospital’s Nepal finance adviser, not a generic country template. Bring the exact invoice, receipt, credit note and fiscal-period reports used today. Confirm NPR rounding, numbering, taxpayer and facility details, the treatment of taxable and exempt lines where applicable, and the required date formats. If the hospital uses Bikram Sambat dates operationally, test entry, display, print, sorting and fiscal rollover rather than assuming a translated label is enough. Tax and electronic-billing rules can change. The contract should say who monitors Inland Revenue Department requirements, who configures a change, how it is tested and how quickly it reaches production. Software is not tax advice; the accepted format should come from the hospital’s finance and legal owners. ## How does connected billing reduce leakage? By capturing a charge when the service or item moves. A lab order can create the applicable charge; a pharmacy dispense can reduce stock and post to the bill; theatre consumption can attach to the procedure; a cancelled service can reverse through the same chain. The alternative is a billing clerk phoning six departments at discharge and asking what happened. Track late postings — charges entered after the discharge decision — by department and reason. That count is a direct measure of billing leakage and discharge delay. The methods in [cutting hospital billing time](/blog/reduce-billing-time) apply regardless of country. ## How should insurance and package billing work? The system should separate clinical truth, price and payer responsibility. The patient record says what care occurred. The tariff or package prices it. The payer rules determine who owes which portion and what evidence is needed. Keeping those layers separate lets a hospital change a tariff without changing an old clinical record, and reconcile a payer adjustment without rewriting the bill. For Nepal’s Health Insurance Board, validate the current beneficiary, service, evidence, claim and settlement workflow with HIB and the facility. Read the detailed [HIB claims HMIS guide](/blog/nepal-health-insurance-claims-hmis) before accepting an “insurance-ready” claim. ## What should a billing demo include? Ask for the difficult cases, not the clean cash OPD bill. Run an admission with a package, an excluded medicine, a mid-stay transfer, a deposit, a sponsor contribution, a returned pharmacy item, an approved discount and a partial payer settlement. Then produce the patient bill, payer claim view, cashier close, receivable and audit trail. Time the common counter path at realistic concurrency. A feature-rich system that makes every cashier wait two seconds between fields will create a queue at 9 a.m. ## Where does Kōami fit? [Kōami Hospital](/products/hmis) ties billing to registration, orders, pharmacy, stores, wards and discharge. [Kōami Inventory](/products/inventory) supplies the batch and stock ledger behind medicines and consumables. Nepal invoice, tax, fiscal and payer configuration must be confirmed during discovery and acceptance. Bring the real documents to a [billing workflow demo](/book-demo); the output should be a gap list, not a promise that every local rule is already covered.

Read article
Pharmacy Management Software in Nepal: Stock, Expiry and Billing — Pharmacy | KōamiPharmacy
Pharmacy· 7 min read

Pharmacy Management Software in Nepal: Stock, Expiry and Billing

A hospital pharmacy in Nepal is simultaneously a clinical service, a store and a billing counter. Software that handles only sales misses inpatient indents, ward returns, batch recall, near-expiry stock, formulary control and the link between what was dispensed and what the patient was charged. The central design principle is simple: one medicine movement should create one stock event and, where appropriate, one patient charge. Separate pharmacy and hospital systems turn that into reconciliation work at the end of every shift. ## What should pharmacy software for a Nepal hospital include? It should track medicines from purchase to patient with batch-level evidence. - Item, generic, brand, strength, form and pack configuration - Supplier, purchase order, receipt, batch, expiry and landed cost - Multiple stores, sub-stores, wards and pharmacy counters - FEFO suggestions, minimum levels and near-expiry worklists - OPD sale, IPD dispense, indent, return, transfer and adjustment - Prescription checks, substitutions and controlled approval where configured - Patient billing, sponsor rules, cashier close and receivables - Stock, valuation, consumption, margin, expiry and stock-out reporting The vendor should show the ledger for one batch from receipt through transfer, dispense, return and adjustment. A current balance without that movement history is not an auditable inventory. ## How does FEFO reduce expiry loss? First-expiry-first-out helps only when the batch suggested by software is the batch physically picked. Receiving must capture reliable expiry data; shelves should follow the same location logic; dispensing should suggest the earliest suitable batch; exceptions should be recorded. Near-expiry reports need action bands — return to supplier, transfer to a higher-use branch, prioritize where clinically appropriate, or write off with approval. Measure expiry loss by value and reason, not just by item count. A few high-value medicines matter more than a box of low-cost supplies. The [batch and expiry guide](/blog/batch-expiry) explains the operating discipline behind the screen. ## How should wards and the pharmacy share stock? Through indents, issues, consumption and returns on one ledger. A ward request should be approved, issued against a batch and received by a named user. Patient-specific consumption should reduce the ward balance and post the applicable bill. Unused medicines should return through a recorded path that reverses the patient charge where policy permits. Emergency floor stock needs replenishment rules and periodic counts, not invisibility. This is where standalone retail pharmacy software usually breaks. It can sell at a counter but cannot explain what is sitting in a ward cupboard or why an inpatient bill contains a medicine that came back. ## What local configuration should be tested in Nepal? Test NPR pricing, local purchase and sales documents, fiscal periods, supplier rules and the facility’s payer arrangements. Hospitals should have finance and pharmacy owners approve invoice fields and tax treatment. Confirm how changes in maximum retail price, purchase cost and selling price affect existing batches. If dates are shown in Bikram Sambat for users or documents, test expiry sorting and alerts against the underlying date, because a formatting error must never change clinical stock rotation. For insured patients, show how covered, excluded and patient-pay medicines are separated without keeping a second dispensing record. ## Which pharmacy reports actually change decisions? Start with reports that lead to a named action. Near-expiry value by action window, stock-outs with lost-demand reason, days of stock, fast and slow movers, purchase-price variance, negative stock attempts, unbilled dispenses and gross margin are more useful than a hundred-page stock statement. Segment by store and branch so transfers can happen before new purchasing. Reorder suggestions should be recommendations, not automatic orders. They need lead time, recent consumption, seasonality, minimum order quantities and clinical judgment. ## What should a vendor demonstrate? Use one medicine with two batches and different expiry dates. Receive both, transfer one to a ward, dispense to an inpatient, return part, sell another at OPD, adjust a damaged unit and show the final stock, patient bills and audit trail. Then locate every patient who received a selected batch, which is the real recall test. [Kōami Inventory](/products/inventory) and [Kōami Hospital](/products/hmis) share the stock and patient transaction rather than synchronizing two ledgers later. Nepal-specific documents and finance rules remain acceptance items for a local deployment. Bring a stock ledger and real labels to the [demo](/book-demo).

Read article
Laboratory Information System in Nepal: A Practical Buyer’s Guide — Interoperability | KōamiInteroperability
Interoperability· 7 min read

Laboratory Information System in Nepal: A Practical Buyer’s Guide

A laboratory information system earns its place between the order and the clinical decision. It should preserve patient identity, label the specimen, manage the analyser work, verify the result, escalate critical values and deliver a signed report while keeping a complete amendment history. For hospitals and diagnostic centres in Nepal, the buying decision also includes local report formats, collection centres, referral pricing, connectivity, device support and whether the LIS can exchange data with the hospital system rather than creating another patient master. ## What should an LIS in Nepal include? The core workflow is order to acknowledged result, not only result entry. - Patient and order received directly from HMS or registration - Barcode labels, specimen type, collector, time and rejection reason - Accessioning, worklists, routing and priority targets - Unidirectional and bidirectional analyser interfaces where supported - Reference ranges by method, age, sex and other relevant context - Delta checks, panic values, technical review and clinical authorization - Critical-result notification with named acknowledgement - Corrected reports with reason, version and audit trail - Patient, clinician and referring-centre delivery controls - Turnaround, quality, workload and referral reports Ask to see a corrected potassium result. The original value must remain visible to authorized reviewers, the new report must be clearly versioned, and the clinician’s acknowledgement must not disappear. ## Why do analyser interfaces matter? They remove transcription and identify exactly where the sample sits. A unidirectional interface brings results from the analyser to the LIS. A bidirectional interface can also send the patient, test and sample identifier to the instrument, reducing manual selection and mismatch risk. Every interface still needs mapping, validation, monitoring and a reconciliation count; a silent interface failure is more dangerous than a visible error. Test with the exact analyser model and firmware used by the laboratory. “HL7 supported” is not a completed interface. It is the beginning of a technical conversation. ## How should turnaround time be measured? In segments and at percentiles. Track order to collection, collection to receipt, receipt to result, result to verification and verification to delivery. The median shows the typical case; the ninetieth percentile shows the delayed tail clinicians remember. Segment by test, priority, shift, collection centre and analyser. A live worklist should warn before a target is breached. A monthly report can explain last month but cannot rescue today’s sample. Read [turnaround time, the metric that runs a lab](/blog/tat-turnaround) for the operating model. ## What should Nepal diagnostic centres test? Test collection-centre identity, referral pricing, consolidated reporting and low-connectivity recovery. A sample collected outside the main lab needs a barcode, collector, collection time, transport status and receipt time. The centre and main lab must see the same patient and order. Referrer and corporate rate cards should price automatically, and approved reports should reach authorized recipients without sharing permanent public links. Disconnect a collection centre during the demo. Ask how orders are queued, identifiers stay unique, labels are produced and records reconcile when the link returns. ## How should an LIS prepare for Nepal interoperability? Use coded tests, structured results and open standards. Nepal’s Ministry of Health and Population describes HL7 and FHIR as important tools for interoperable health information, and its [HL7 overview](https://digitalhealth.mohp.gov.np/blog/hl7-standards/) specifically names laboratory results among the data exchanged. DICOM matters on the imaging side; APIs and versioned mappings matter across both. Ask who owns the interface specification, whether the facility can export results with codes and units, and how mappings are tested when the national or local target changes. ## Where does Kōami fit? [Kōami Hospital](/products/hmis) connects orders, billing and the patient record to the laboratory workflow, while [Kōami PACS](/products/pacs) handles the imaging side. The value is one identity and one order rather than matching reports after the fact. Nepal-specific report, invoice and external exchange requirements need validation with the facility. Bring an actual report, analyser list and collection-centre flow to a [technical demo](/book-demo), so the interface scope is explicit before purchase.

Read article
EMR, EHR and Interoperability in Nepal: What Hospitals Should Build For — Interoperability | KōamiInteroperability
Interoperability· 8 min read

EMR, EHR and Interoperability in Nepal: What Hospitals Should Build For

An EMR is what one hospital knows about a patient. An EHR is the longitudinal record designed to follow that patient across organizations. The distinction matters in Nepal because a hospital can buy an EMR, but an EHR emerges only when identity, consent, terminology and exchange standards work across many institutions. The practical buying question is therefore not “does this vendor sell an EHR?” It is “will the record we create today be structured, governed and open enough to participate in Nepal’s evolving digital-health ecosystem tomorrow?” ## What is the difference between EMR and EHR? An EMR supports care inside a facility or group; an EHR supports continuity across facilities. The EMR contains consultations, diagnoses, allergies, medicines, orders, results, procedures, nursing records and discharge summaries. It needs roles, audit trails, clinical safety and usable workflows. Cross-organization exchange adds patient and facility identity, consent, standardized meaning, discovery and trust between systems. A PDF discharge summary is useful to a person but limited for computation. Structured allergies, medicines and results can be searched, checked and exchanged while still producing a readable document. ## What direction is Nepal taking? Toward a connected platform, standards and national identity building blocks, while implementation continues to evolve. The Ministry’s [Digital Health platform plan](https://digitalhealth.mohp.gov.np/digital-health-platform/) describes a national platform linked to HMIS, EHR systems and the Health Facility Registry. SIL-Nepal focuses on standards-based design and testing. In 2025 the Ministry also announced work on a [National Health ID Development Committee](https://digitalhealth.mohp.gov.np/event/national-health-id-development-committee-opening-meeting/) to support interoperability between health institutions. These initiatives are reasons to preserve flexibility, not reasons for vendors to claim completed compliance with a future architecture. Hospitals should ask for current evidence and contractual support for change. ## Which standards should hospital software support? Support the standard appropriate to each exchange and keep the data clean underneath it. HL7 v2 remains common for admissions, orders and results. FHIR provides modern web resources and APIs. DICOM is the foundation for medical imaging. Standard clinical codes and units reduce ambiguity. The Ministry’s [HL7 guidance](https://digitalhealth.mohp.gov.np/blog/hl7-standards/) explicitly discusses HL7 v2, FHIR and CDA, and its interoperability resources also identify DICOM. “FHIR-ready” should mean more than a logo. Ask the vendor to expose a patient, encounter, observation and diagnostic report in a test environment, show authentication and document which profile and version it implements. ## How should consent and access be designed? As enforceable data and events, not a paper form scanned into a folder. Every user should have an individual account and role-based access. Sensitive access should be logged. Consent should record purpose, scope, source, time, status and withdrawal where applicable. Emergency access needs a clear break-glass path with review. Before exchanging data externally, the hospital must know which identifier is used, what is sent, who requested it, under what authority, and how the event is audited. Legal and policy requirements should be confirmed from current Nepal authorities and counsel; software should make the agreed rule enforceable. ## What should a hospital test before buying? Test portability and a real exchange, not only the EMR screen. Create an allergy, diagnosis, lab result, prescription and discharge summary. Export them in structured form. Correct the result and show both versions. Give a second authorized role access and show the audit trail. Then ask for the complete patient export and the contract’s exit timeline. The hospital should own usable data, not merely database files that require the former vendor to interpret. ## How does Kōami prepare for interoperability? Kōami uses one patient identity across [hospital operations](/products/hmis), inventory and [PACS imaging](/products/pacs), with open APIs and webhooks at the platform boundary. That reduces internal fragmentation before external exchange begins. Nepal’s eventual national profiles, identifiers, consent rules and certification expectations must be implemented against authoritative specifications as they mature. A [technical discovery session](/book-demo) should separate existing APIs from future interface work and put both in writing.

Read article
Cloud or On-Premise HMS in Nepal: A Hospital Decision Guide — Data Security | KōamiData Security
Data Security· 8 min read

Cloud or On-Premise HMS in Nepal: A Hospital Decision Guide

The cloud-versus-on-premise decision for a Nepal hospital is not modern against old. It is a choice about who operates the infrastructure, how the hospital works through a network failure, how quickly it can recover from a serious incident and what the full five-year commitment costs. Both models can be secure and reliable. Both can fail badly. The useful comparison replaces slogans with dates, measurements and named owners. ## When does cloud HMS make sense in Nepal? Cloud is compelling when the hospital wants predictable access without running a server room. The provider handles infrastructure patching, redundancy and platform backups; upgrades reach all sites together; a hospital group can use one patient and stock identity across Kathmandu and satellite locations; recovery does not depend on equipment in the same building as the incident. Cloud still requires the hospital to manage user accounts, roles, endpoint devices, local networks and downtime. It also requires diverse connectivity. Two internet contracts are not true redundancy if both use the same last-mile path, power source or upstream dependency. ## When is on-premise defensible? When connectivity is genuinely limiting and the hospital has the capacity to operate infrastructure as a clinical service. That means named staff, monitoring, patch schedules, secure remote support, off-site backups, tested restores, spare parts, power and cooling. Recent hardware already owned by the facility can change the economics. Local analyser and device connections may also be simpler. Physical possession is not security by itself. An unpatched server with shared administrator credentials and an untested backup is less controlled than a well-run cloud service, even if it sits behind a locked door. ## What should happen when connectivity fails? The hospital should follow a rehearsed continuity procedure with safe reconciliation. Identify the clinical minimum for registration, emergency care, medication, orders, results and billing. Define temporary identifiers, paper or local fallback forms, who declares downtime, how duplicates are prevented, how urgent results are communicated and who enters and checks the backlog later. Test the procedure on a normal shift before an outage tests it at 2 a.m. Measure recovery point and recovery time: how much data could be lost, and how long until safe service is restored? “Offline capable” needs a precise scope; ask which screens, data and devices work, and how conflicts resolve. ## How should security and recovery be compared? Ask each option for evidence against the same controls. - Individual accounts, MFA for privileged access and role review - Encryption in transit and at rest - Logging, monitoring, alerting and incident response - Patch and vulnerability management - Backup frequency, immutability and geographic separation - Restore test date, result and measured recovery time - Sub-processors, remote-access controls and breach notification - Data export, retention and secure deletion at exit The restore test is decisive. A backup nobody has restored is a belief, not a recovery capability. ## How should five-year cost be calculated? Include every resource required to keep the service safe and available. Cloud cost includes subscription, storage, interfaces, support, connectivity and escalation. On-premise includes hardware, database and operating licences, power, cooling, monitoring, backup, off-site recovery, staff and refresh. Both include devices, training, migration, downtime planning and exit. Use the same patient volume, sites, storage growth, support hours and interfaces in both cases. The detailed [Nepal HMS cost guide](/blog/hospital-management-software-cost-nepal) provides the wider model. ## What is a sensible hybrid approach? Hybrid can mean cloud application with resilient local networks and documented manual continuity, or selected local services for devices and caching while the authoritative record remains cloud-hosted. It should not mean two uncontrolled databases that staff reconcile by hand. Define the source of truth, synchronization boundary, conflict rules and security owner. Complexity is justified only when it solves a measured failure mode. [Kōami](/hospital-management-software-nepal) is cloud-native, so a Nepal proposal should include a connectivity assessment, continuity design and recovery commitments rather than assuming urban connectivity everywhere. Bring network history, site locations and the last outage report to a [discovery call](/book-demo); those facts are more useful than a preference stated in the boardroom.

Read article
The Twelve Cycle Times That Actually Run a Hospital — Analytics | KōamiAnalytics
Analytics· 9 min read

The Twelve Cycle Times That Actually Run a Hospital

Hospitals measure a great deal and act on very little of it. Part of the reason is that most hospital reporting is composed of counts and averages — patients seen, revenue booked, occupancy percentage — and counts tell you what happened without telling you where to intervene. Cycle times are different. A cycle time is an interval with a start, an end and an owner, which means that when it moves in the wrong direction there is a specific person who can do something about it. This is a list of the twelve worth running a hospital on, what each one is really telling you, and where to look when it degrades. ## Why measure intervals instead of counts? Because an interval has an owner and a cause, and a count has neither. Occupancy at eighty-four percent is a fact you cannot act on. Time from discharge decision to bed ready at four hours and ten minutes is a fact with three named owners — the ward, billing and housekeeping — and a set of handoffs you can go and watch. Two rules make the difference between a dashboard that changes behaviour and one that gets ignored. Report the ninetieth percentile alongside the median, because queues are created by the tail rather than the typical case. And report by hour or by day of week rather than as a monthly average, because the failure is almost always concentrated in specific hours. ## The patient-flow cycle times **1. Door to triage, and door to doctor in casualty.** The purest waiting interval in the hospital and the leading indicator for everything downstream. When it lengthens, look at registration policy first and at boarding second. See [door-to-doctor time in casualty](/blog/emergency-door-to-doctor-time). **2. OPD appointment time to consultation start.** The gap between the time you promised and the time you delivered. Track it against scheduled slot rather than arrival, otherwise early arrivals flatter the number. See [cutting the OPD wait with token and queue](/blog/opd-queue). **3. Admission decision to bed occupancy.** Measures how well bed state, housekeeping and admissions coordinate. A long interval here nearly always means bed status is maintained by phone. See [live bed management](/blog/bed-management). **4. Discharge decision to bed vacated.** The most valuable interval in the hospital, because every hour recovered is an hour of bed capacity created at no cost. Owned jointly by the ward, pharmacy and billing. See [admission to discharge](/blog/admission-to-discharge-time). **5. Bed vacated to bed ready.** Housekeeping's interval, and the one most often invisible because nobody records the two timestamps. > A hospital that can state its median and ninetieth-percentile discharge-decision-to-bed-ready time, by ward, already runs better than one that cannot, regardless of what the number is. ## The diagnostic and clinical cycle times **6. Lab order to result available.** Split it: order to collection, collection to receipt, receipt to result, result to verification. The step that fails is usually collection rounds not matching ward round timing. See [turnaround time, the metric that runs a lab](/blog/tat-turnaround). **7. Imaging order to signed report available.** Measure to availability to the ordering clinician, not to signature. Segment it, because the front end and the back end fail for different reasons. See [radiology report turnaround](/blog/radiology-report-turnaround). **8. Critical result identified to acknowledged.** Not sent — acknowledged, by a named person. This is a patient safety measure before it is an efficiency one, and NABH will ask for it. See [closing the loop on critical results](/blog/critical-results). **9. Theatre list start delay and turnaround between cases.** First-case start delay is a discipline measure; inter-case turnaround is a coordination measure. They have different fixes and should not be averaged together. See [scheduling the operating theatre without collisions](/blog/ot-scheduling). ## The revenue cycle times **10. Discharge decision to final bill.** Almost entirely determined by whether charges were captured as care happened. Watch the count of charge postings made after the discharge decision — that is the real number. See [cutting hospital billing time](/blog/reduce-billing-time). **11. Discharge to claim submission, and query to resubmission.** Two intervals, both owned by the hospital, and together usually a larger share of receivables ageing than payer processing. See [cutting claim settlement time](/blog/reduce-claim-settlement-time). **12. Prescription to dispense at the pharmacy counter.** The last impression a patient takes home, and mostly a prescribing and stock design problem rather than a staffing one. See [the pharmacy counter queue](/blog/pharmacy-counter-wait-time). ## What targets should a hospital set? Set your first target from your own ninetieth percentile, not from a published benchmark. Benchmarks from other health systems are interesting and rarely applicable: case mix, staffing models, payer structures and physical layouts differ too much. What works is to measure your own distribution for a month, take the ninetieth percentile, and aim to bring it toward your current median. That is a target derived from what your own hospital already achieves on a good day, which makes it both credible to staff and demonstrably achievable. Then re-baseline. A target that has been met and held for a quarter should be replaced. ## Which of the twelve should a hospital start with? Discharge decision to bed vacated, because it improves capacity, revenue and patient experience at once, and because fixing it forces you to fix several others. The chain it depends on runs through pharmacy reconciliation, ward consumption, billing, payer approval and housekeeping. A hospital that genuinely shortens this interval has necessarily improved charge capture, pharmacy returns, insurance handling and bed state along the way. No other single interval has that reach. Second, whichever of the twelve your staff complain about most. The complaint is data, and fixing something people already find painful buys the credibility needed for the rest. ## How Kōami produces these numbers The reason most hospitals cannot report these intervals is not that the software lacks a dashboard. It is that the two timestamps that define an interval live in different systems, or one of them is never recorded at all. [Kōami Hospital](/products/hmis) records both ends of most of these intervals as part of the workflow rather than as an extra step: - Registration, triage, ADT, orders, results, billing and discharge are events on one record, so patient-flow intervals are read rather than reconstructed. - Lab order, sample collection, result entry and approval are tracked with TAT reporting built into the laboratory module, and analyser interfacing removes the manual result-entry step that distorts it. - [Kōami PACS](/products/pacs) reports study volume, turnaround, modality mix and radiologist productivity, with a critical-results queue that tracks acknowledgement rather than dispatch. - Charges captured at the point of care mean the discharge-to-bill interval is short by construction, and the count of late postings is visible rather than anecdotal. - [Kōami Inventory](/products/inventory) supplies consumption, stock-out and wastage data behind the pharmacy and ward intervals. - [Kōami Workforce](/products/hrms) supplies roster coverage, overtime and time-to-fill, which is what explains an interval that degrades at a particular hour. - [Kōami Field Service](/products/field-service) tracks equipment downtime and SLA breaches, which is frequently the hidden cause behind a theatre or imaging delay nobody could account for. Start by choosing three of the twelve and measuring them honestly for a month, before changing anything. If the timestamps do not exist in your current systems, that is itself the finding, and it is worth bringing to a [demo](/book-demo).

Read article
Best Hospital Management Software in India (2026): How to Compare Them Properly — Product | KōamiProduct
Product· 9 min read

Best Hospital Management Software in India (2026): How to Compare Them Properly

Search for the best hospital management software in India and you will get a dozen ranked lists, most of them written by vendors who placed themselves at number one. They are not useless. They tell you who is actively marketing. They tell you almost nothing about which system will still be serving your hospital in year six. There is no single best HMS, and any list that claims otherwise is selling something. What exists is a best fit for a particular hospital: its size, its specialities, its appetite for change, and the compliance load it carries. This article is the comparison method rather than the ranking, because the method is what survives contact with your own shortlist. ## What does "best hospital management software" actually mean for a buyer? It means the system that fits your hospital's size, speciality mix and compliance obligations, and that your staff will still be using correctly two years after go-live. Those two clauses do different work. The first is a matching problem you can assess in a demo. The second is an adoption problem you can only assess by talking to reference sites that went live eighteen months ago and asking what they stopped using. A useful reframing: you are not buying features, you are buying the vendor's next five years of attention. The feature list is a snapshot. The roadmap, the support model and the implementation team are the thing you actually live with. ## What are the main types of HMS vendor in India? The Indian market has four recognisable categories, and knowing which one you are talking to explains most of what happens next. - Enterprise international suites. Deep, standards-mature, expensive, and usually sold to large corporate chains. Strong clinical depth; localisation for Indian statutory registers and PM-JAY workflows varies and should be verified rather than assumed. - Established Indian HIS vendors. Fifteen to twenty-five years in the market, heavily localised, often on-premise by origin with a cloud offering added later. Excellent at Indian billing and regulatory reality; user interfaces frequently show their age. - Modern cloud-native Indian platforms. Built in the last decade, subscription-priced, ABDM-aware from the start, better interfaces. Range enormously in depth: some are genuinely full HIS platforms, some are clinic software with a hospital label. - Custom builds and system integrators. A development shop building to your specification. Fits exactly, until you need it changed and the two engineers who understood it have left. None of these categories is wrong. They fail in different ways, which is the useful part. Enterprise suites fail on cost and configuration time. Legacy Indian vendors fail on usability and API access. Cloud-native platforms fail on depth in the corners: blood bank, NDPS register, complex package billing. Custom builds fail on continuity. ## Which capabilities actually separate systems, rather than brochures? Every proposal will claim registration, OPD, IPD, billing, pharmacy, lab and reports. Those are table stakes and tell you nothing. The differences show up in the places nobody demos. - Billing depth. Package billing against open billing, mid-stay tariff changes, insurance and cash split on one bill, credit notes, partial refunds, and how a corporate rate card is applied without manual intervention. - The clinical record. Genuinely structured data with coded diagnoses and orders, or free text in a rich editor. The second one demos beautifully and reports on nothing. - Multi-branch behaviour. One patient identity across sites, consolidated financials, per-site tariffs, and stock visible across stores. - Statutory registers. NDPS, blood bank, birth and death, biomedical waste. Ask to see them generated from live data, not as a report template. - Concurrency and print. What happens at nine in the morning when forty terminals are billing at once, and whether the pharmacy label prints in under two seconds. - Downtime behaviour. What the hospital does when the link drops. Any vendor without a real answer has not run a hospital through an outage. > The features that decide a deployment are almost never the ones on the comparison table. They are billing edge cases, print speed, and what happens when the network fails. ## What should an Indian hospital check on compliance in 2026? Four things, and all four are now answerable with a yes or a no rather than a roadmap promise. ABDM. The mission has moved from pilot to infrastructure. India crossed one hundred crore health records linked to ABHA accounts, with more than four hundred and fifty health technology solutions integrated into the ecosystem. Ask whether the vendor holds current M1, M2 and M3 milestone certification, and ask to see the certificate rather than a claim. DPDP. The Digital Personal Data Protection framework reaches hospitals as consent capture, purpose limitation, breach notification timelines and the ability to honour a data principal request. Ask how consent is recorded and how a patient's data would be produced or erased on request. NABH. If you are accredited or intend to be, the digital clauses in the current edition are specific about access control, audit trails, and the completeness of the medical record. A system that cannot show who viewed a record will cost you at audit. PM-JAY and insurance. If a meaningful share of your revenue is scheme or TPA driven, claim preparation, document attachment and rejection handling are not a module, they are the revenue cycle. ## How much should it cost, and what makes the number move? Expect the licence or subscription to be somewhere between a third and a half of the five-year cost, with implementation, migration, training, integrations and hardware making up the rest. Per-bed subscription pricing is the commonest Indian metric, and it needs defining in the contract: sanctioned, operational and occupied beds are three different numbers. Perpetual licences carry an annual maintenance charge, typically fifteen to twenty-two percent of licence value. Neither model is inherently cheaper; they distribute risk differently. What actually drives the number is scope, site count, integration count and how bad your legacy data is. Bed count is the metric everyone quotes and the weakest predictor of the three. ## What questions expose a weak system inside a demo? Ask for the ugly cases. A scripted demo is designed to avoid them, so requesting them by name changes what you learn. - Admit a patient, change the tariff mid-stay, add a package after two days, then discharge and produce the bill. - Show me a partially rejected PM-JAY claim and what the team does next. - Create an ABHA number at registration and link a care context, live. - Show the audit trail for a record that was viewed but not edited. - Cancel a dispensed medicine, reverse the stock, and show the ledger. - Take the network away and tell me what the front office does for the next two hours. - Export my data. Show me the format. The last one matters more than it looks. A vendor with a clean, documented export has told you they expect to be judged on merit rather than lock-in. ## How do you run a shortlist in two weeks? Write the process down before you see a single demo, because the demos are designed to reset your criteria. Start by listing your ten non-negotiables, agreed with the people who will use the system rather than only the people signing for it. Score every vendor against the same ten. Then insist on three things: a demo using your own tariff sheet and two of your real workflows, a reference call with a hospital of your size that went live at least a year ago, and a written five-year total cost including everything in the paragraph above. Anything a vendor will not put in writing during the sales cycle will not improve after the contract is signed. ## Where Kōami fits, stated plainly Kōami is a cloud-native Indian platform in the third category above, built as one connected system rather than a hospital product with satellite tools bolted on: hospital management, workforce, inventory, imaging, fertility and biomedical equipment share one identity and one data model. That design suits hospitals and multi-site groups tired of re-keying the same patient and stock data between disconnected systems, and it suits organisations that want ABDM and DPDP handled as platform behaviour rather than a project. It suits less well a hospital that wants a single narrow module and nothing else, where a focused point product will be cheaper and simpler. That is the honest shape of the fit. Judge it, and everyone else on your shortlist, against your own ten non-negotiables rather than against anybody's ranked list.

Read article
Admission to Discharge: Where the Hours Actually Go — Operations | KōamiOperations
Operations· 8 min read

Admission to Discharge: Where the Hours Actually Go

A hospital that shortens its average length of stay by half a day has, in effect, built new beds. No construction, no equipment, no additional staff. It is the cheapest capacity a hospital can create, and most hospitals leave a great deal of it on the table. The reason they leave it there is that length of stay gets treated as a clinical variable, which it partly is, and therefore as something administrators should not touch. But the clinical component is not where the slack is. The slack is in waiting, and waiting is an operations problem. ## What actually determines length of stay? Clinical need sets the floor. Almost everything above that floor is waiting for something or someone. Break a typical surgical admission into its parts and the pattern is obvious. There is time spent receiving treatment, and there is time spent waiting for a bed to be cleaned, waiting for a pre-operative investigation to come back, waiting for a theatre slot, waiting for a consultant to round, waiting for a report to be reported, waiting for a physiotherapy assessment, waiting for the discharge decision to become a discharge. In most Indian hospitals the treatment time is a minority of the stay. That is not a criticism of the clinicians; it is the arithmetic of any system where multiple specialised resources have to be sequenced. ## Where does the admission itself lose time? At the front door, in the gap between the decision to admit and the patient physically occupying a bed. The common failures are all coordination failures: - The bed is nominally free but has not been cleaned, and nobody told housekeeping - The bed is allocated by a phone call, so two people allocate the same one - The admission paperwork and the payer approval run in sequence rather than in parallel - A planned admission arrives without its pre-operative investigations, which then happen as an inpatient at full cost in time and money The fix for the first two is a live bed state that everyone reads from, where a discharge automatically raises a cleaning task and the bed becomes bookable only when housekeeping closes it. We covered the mechanics in [live bed management from ADT to discharge](/blog/bed-management). The fix for the fourth is doing the work-up as an outpatient. A planned surgical admission whose investigations, anaesthetic assessment and payer approval are complete before arrival can go to theatre the next morning instead of losing a day. > Most of the length of stay a hospital can actually control is at the two ends. The middle belongs to the clinicians. The admission day and the discharge day belong to operations. ## Which delays inside the stay are worth attacking first? The ones that block a decision, because a delayed decision costs a whole day rather than a few hours. A report that arrives at four in the afternoon rather than eleven in the morning does not cost five hours. It costs a day, because the consultant who would have acted on it has already rounded and will next see the patient tomorrow. The same is true of a specialist opinion requested in the afternoon, a theatre slot missed by an hour, and a physiotherapy assessment that happens on day three because that is when the request reached the department. This is why turnaround time on diagnostics is a length-of-stay lever and not merely a laboratory metric. If your ward rounds happen between nine and eleven, then any investigation whose result lands after eleven has effectively lost a day. Getting routine morning bloods reported before the round is worth more than shaving an hour off the average. The distinction between the median and the tail is set out in [turnaround time, the metric that runs a lab](/blog/tat-turnaround), and the imaging equivalent in [radiology report turnaround](/blog/radiology-report-turnaround). ## How do you fix the discharge day? Decide the day before, prepare in parallel, and stop treating discharge as an event that begins when the consultant says so. The single highest-yield change available to most hospitals is the expected date of discharge, set at admission and revised daily. It sounds trivial. It changes everything downstream, because it lets pharmacy prepare the take-home medication, billing prepare a provisional bill, the insurance desk seek final approval, and the family arrange transport, all before the morning of discharge rather than during it. The second change is making the discharge decision a system event rather than a verbal one. When the consultant marks the patient for discharge on the round, the ward, pharmacy, billing, housekeeping and the insurance desk should all learn simultaneously and begin their part concurrently. Sequential handoffs are what turn a ninety-minute discharge into a five-hour one. [Why discharge takes so long](/blog/discharge-time) goes through this in detail, and the billing half of it is in [cutting hospital billing time](/blog/reduce-billing-time). The third is the discharge summary. If it is written from scratch at discharge, it is a bottleneck and it is worse quality. If it accumulates through the stay from the notes already recorded, it is a review task that takes minutes. ## What should a hospital measure, and how? Six numbers, and the interval measures matter more than the averages. - Average length of stay, case-mix adjusted, by speciality and by consultant - Time from admission decision to bed occupancy - Time from discharge decision to bed vacated - Time from bed vacated to bed ready - Proportion of discharges completed before noon - Number of patients medically fit but not discharged, counted daily The last one is the most honest number in the list, and the one most hospitals do not collect. A daily count of patients who are clinically ready to leave but are still in a bed tells you exactly how much capacity your processes are consuming. ## How Kōami compresses admission to discharge [Kōami Hospital](/products/hmis) puts admission, bed state, clinical orders, pharmacy, diagnostics, billing and discharge on one record, which removes most of the handoffs where the hours are lost. - IPD, beds and ADT are live. Admission, transfer and discharge update ward and bed occupancy as they happen, and a vacated bed raises its own cleaning task rather than waiting for a phone call. - An "Initiate Discharge" action on the round is the trigger. Pharmacy reconciliation, ward consumption confirmation, provisional billing and payer approval start together instead of in sequence. - Orders placed from the chart reach the lab and the modality worklist directly, and results and turnaround post back automatically, so the diagnostics that gate a decision are visible to the person who has to make it. - Discharge summaries build from the consultation and nursing notes already in the chart, so the summary is reviewed rather than composed. - Nursing charting, vitals and clinical scores live in the same record, so the information a consultant needs on the round is on one screen rather than in three places. - Because [inventory](/products/inventory) and pharmacy share the same stock backbone, take-home medication and unused returns reconcile without a separate posting step. Length of stay is the one operational metric that improves capacity, revenue and patient experience simultaneously. If you want to see where your own hours are going, bring a month of admission and discharge timestamps to a [demo](/book-demo) and we will map them against the flow above.

Read article
Best IVF Software in India (2026): How Fertility Clinics Should Compare ART Systems — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 8 min read

Best IVF Software in India (2026): How Fertility Clinics Should Compare ART Systems

Most fertility clinics in India start on a general clinic EMR, because that is what was available when they opened. It works until the first ART audit, or the first time somebody has to reconstruct which straw in which goblet in which tank belongs to a couple who moved cities four years ago. At that point the clinic discovers that a system built for consultations is not a system built for cycles. The market for IVF software is small, noisy and full of general EMRs describing themselves as fertility platforms. Telling them apart is not difficult once you know what to ask for. ## What makes IVF software different from a clinic EMR? An IVF system is organised around the cycle and the specimen, not around the visit. That single structural difference cascades through everything. A clinic EMR records encounters: the patient came, this was noted, this was prescribed. An ART system records a treatment cycle with a defined start, a stimulation protocol, a monitoring series, a retrieval event, a laboratory phase in which biological material is handled and tracked, a transfer, and an outcome that may arrive nine months later and must attach back to the cycle that produced it. If the software cannot represent a cycle as a first-class object, everything downstream is spreadsheets. Your success rates will be counted by hand, your registry submission will be assembled by hand, and your chain of custody will live in a register that nobody can query. ## Which capabilities are genuinely ART-specific? Seven, and a general EMR will usually be missing five of them. - Cycle management across modalities. IVF, ICSI, IUI, frozen embryo transfer and donor cycles each have different steps and different denominators. One generic pathway does not cover them. - Stimulation monitoring. Day-wise dosing, follicular measurements recorded as structured values, and a chart that lets the clinician see the response rather than read it in prose. - The embryology worksheet. Fertilisation check, cleavage stage, day-wise grading, blastocyst scoring, biopsy and vitrification events, all recorded against a specific specimen rather than against a patient in general. - Electronic witnessing. Every point at which gametes or embryos are handled, recorded as a timestamped event with two identities attached, not a signature in a book. - Cryostorage inventory. Tank, canister, goblet, cane, straw. Location down to the position, with movement history, consent status and storage expiry on the same record. - Consents under the ART Act and ICMR framework. Versioned templates, the specific consents each cycle type requires, and evidence of when each was taken. - Outcomes and registry. Clinical pregnancy, ongoing pregnancy, live birth, linked back to the cycle, with National ART Registry submission produced from live data rather than compiled. > If the demo cannot show you a specific straw in a specific position with its full movement history and consent status on one screen, it is a clinic EMR with an IVF label. ## What does the ART Act require the software to hold? The ART (Regulation) Act and the ICMR framework turn record keeping from good practice into a licensing condition, and the records are specific. Clinics and banks must maintain records of donors, commissioning couples, cycles performed, gametes and embryos handled and stored, and outcomes, retained for the period the regulations specify and produced on demand to the registering authority. Donor identity handling, the limits on donor use, and the consent chain are all evidenced by what your records show. The practical test for software is not whether it can store this. Anything can store it. The test is whether it can produce it: a defensible, timestamped, queryable record set for a named couple or a named donor, generated in minutes rather than assembled over a fortnight before an inspection. Ask any vendor to demonstrate exactly that, with a search rather than a report request to their support team. ## How should a clinic compare success-rate and KPI reporting? Insist on seeing the denominator, and insist on being able to change it. Fertility KPIs are the most misused numbers in the sector, and the misuse is almost always denominator selection. Clinical pregnancy rate per transfer, per retrieval and per cycle started are three different figures from the same clinic, and the gap between them can be very large. A system that reports one hard-coded rate is not giving you a KPI, it is giving you a marketing number. What a clinic actually needs is the ability to slice outcomes by cycle type, by age band, by fresh against frozen, by own gametes against donor, and by clinician, with the denominator visible on the face of the report. That is also what the KPI frameworks used in accreditation expect, and what an honest patient conversation requires. ## Does the clinic need a full HMS as well? Usually yes, and this is where most fertility software decisions go wrong. A fertility centre is still a healthcare facility. It registers patients, bills them, runs a pharmacy that dispenses expensive gonadotropins with batch and expiry tracking, orders and receives laboratory work, may run day-care theatre lists for retrievals, employs staff whose credentials expire, and answers to the same data protection and accreditation regimes as anyone else. Clinics that buy a specialist ART module and keep a separate billing system end up reconciling two patient identities forever. Clinics that buy a general HMS and try to run embryology inside it end up with the spreadsheets described earlier. The workable answers are a single platform that genuinely covers both, or two systems with a real, tested integration on patient identity and billing events. What does not work is two systems with a promise of integration and a shared login page. ## What should a fertility clinic ask in a vendor demo? Ask for the awkward operations, because the routine ones all look the same. - Show me a couple with two failed fresh cycles and one frozen transfer, and give me their complete history on one screen. - Locate straw number 1188 and show its movement, consent and expiry history. - Witness a fertilisation step, then show me the event log entry it produced. - Change the denominator on the clinical pregnancy rate report from per transfer to per cycle started. - Generate the National ART Registry submission for last quarter. - Show me the consent set for a donor oocyte cycle and the version of each template used. - A patient asks for all their data under the DPDP framework. Produce it. ## What does it cost, and what should the contract say? Fertility software in India spans a wide range, from low tens of thousands of rupees a year for a small single-site clinic to several lakhs annually for a multi-branch network with embryology, cryostorage and integrated billing. The variables that move it are branch count, whether embryology and cryobank are included or priced separately, whether witnessing hardware is involved, and the depth of the billing side. As with any healthcare system, ask for a five-year total including implementation, migration of existing cycle history, training and support, not a per-year headline. Two contract clauses matter more here than in general hospital software. First, data export: cryostorage and cycle history are records you may need to hold for years and produce to a regulator, so the format and cost of getting them out must be written down. Second, retention: the software must let you keep records for the statutory period even for patients who have long since finished treatment. ## Where Kōami Fertility sits Kōami Fertility is the ART product inside a broader connected platform, which is the specific trade-off worth understanding. It covers couple and cycle records, stimulation, retrieval, the embryology worksheet with grading, electronic witnessing, cryobank chain of custody down to the straw, transfer, pregnancy outcome, ART KPIs with visible denominators, and registry export. Because it shares identity, billing, pharmacy and workforce with the rest of the platform, a clinic does not run two patient masters. For a single-site clinic that already has billing it is happy with and wants only an embryology tool, a narrower product may be the better buy. For a fertility network that is tired of reconciling systems, the integrated shape is the point. Either way, take the demo list above into every conversation you have, including ours.

Read article
Cutting Hospital Billing Time: Where the Forty Minutes Actually Go — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 8 min read

Cutting Hospital Billing Time: Where the Forty Minutes Actually Go

Stand at a discharge billing counter for one afternoon and you will stop believing that billing is slow because the software is slow. The clerk is not typing slowly. They are waiting. Waiting for the ward to confirm what was consumed, for pharmacy to post the last dispense, for a consultant to finalise a charge, for someone to find out whether the implant used yesterday was billed. The keystrokes take four minutes. The bill takes forty. That distinction is the whole problem, and it is why hospitals that buy faster software and change nothing else get a faster version of the same wait. ## Why does hospital billing take so long? Because most charges are recorded after the care happened, so the bill has to be assembled at the end instead of simply being read. A bill in a hospital is not a transaction, it is a reconciliation. Between admission and discharge, dozens of chargeable events occur in six or seven different places: the ward, the pharmacy, the lab, radiology, the operating theatre, the stores. If each of those places records what it did in its own register, on its own timetable, then at discharge somebody has to go and collect them. The time is spent in three places, in roughly this proportion: - Waiting for departments to post charges that already happened, which is most of it - Resolving disputes about tariff, package inclusion, discount authority and payer split - Actual data entry and printing, which is the smallest part by a wide margin Any effort spent on the third while ignoring the first is wasted. ## What is the single biggest cause of billing delay? Charges captured after the fact rather than at the point of care. This is the root of it. When a nurse administers a drug and writes it in a register for pharmacy to enter later, the charge exists in the hospital before it exists in the billing system, and the gap between those two moments is dead time that surfaces at discharge. Multiply by every consumable, every implant, every investigation and every procedure. The fix is structural rather than procedural. The dispense should create the charge. The theatre consumable scanned as it is opened should create the charge. The lab order fulfilled should create the charge. When capture and care are the same event, the bill is never assembled, because it was always complete. We wrote about this at length in [capturing charges as care happens](/blog/charge-capture). > A hospital that can produce a correct interim bill for any inpatient at any moment has already solved discharge billing. One that cannot has a reconciliation problem, not a printing problem. ## How do you cut billing time at the OPD counter? Separate registration from payment, price from a tariff engine rather than a memory, and let patients pay before they reach the counter. Outpatient billing is a different problem from inpatient. The volume is high, the value per transaction is low, and the queue is visible to everyone in the waiting area. Four things move the needle: - Pre-registration and online appointments, so the patient arrives already in the system with a record number rather than being created at the window - A tariff and package engine that prices the consultation, the procedure and the corporate or scheme rate automatically, so the clerk selects rather than calculates - Digital payment at the point of service, including a link sent to the patient's phone, so the counter is not also a cash desk - Splitting the registration desk from the payment desk at peak hours, because they have different service times and queueing them together makes both slower The measurement that matters is not average counter time. It is the ninetieth percentile, because the queue is created by the slow cases, not the typical ones. ## Where do the hours go in inpatient discharge billing? Between the clinical decision to discharge and the moment the last department posts its charges, and that gap is usually three to five hours. The sequence in most hospitals runs: the consultant decides on the round at ten, the ward informs billing at some point, billing requests final postings, pharmacy returns unused medicines and reverses those charges, the ward confirms consumables, any pending investigation is chased, insurance approval for the final amount is sought if applicable, and only then is the bill raised. Almost every step in that chain is a handoff between people, and every handoff waits for someone to be free. What compresses it is starting the process at the decision rather than at the paperwork. An "initiate discharge" action taken by the consultant on the round should immediately notify pharmacy to reconcile returns, prompt the ward to confirm consumption, alert billing to prepare a provisional bill, and trigger the insurance desk to seek final approval — all in parallel rather than in sequence. That is the difference between a five-hour discharge and a ninety-minute one, and it is covered in more detail in [why discharge takes so long](/blog/discharge-time). ## What about insurance and TPA patients, where the delay is worst? Start the payer conversation at admission, keep an approximate bill live throughout the stay, and never let the final approval request be the first the payer has heard of the actual amount. The classic failure is a cashless patient whose pre-authorisation was taken for an estimated amount at admission, whose stay extended, and whose final bill exceeds the approval. The enhancement request goes at discharge, and the patient waits in a bed that the hospital needs. The working pattern is to treat the approximate bill as a living document that updates as charges accrue, with a threshold that automatically flags when the accrued amount approaches the sanctioned limit, so the enhancement request goes at hour thirty rather than at discharge. The related mechanics are in [pre-auth and TPA claims without the back-and-forth](/blog/tpa-preauth). ## What should a hospital measure? Five numbers, tracked weekly, broken down by ward and by payer. - Time from discharge decision to final bill, at median and at the ninetieth percentile - Time from final bill to patient departure - Number of charge postings made after the discharge decision, which is the direct measure of late capture - Value of charges written off at discharge because they could not be substantiated - OPD counter service time at peak hour, ninetieth percentile The third one is the leading indicator. Drive late postings toward zero and the other four improve without being addressed directly. ## How Kōami shortens hospital billing time [Kōami Hospital](/products/hmis) is built so that the bill is a by-product of care rather than a task performed after it. - Charges are captured where care happens. Pharmacy dispensing, ward indents and consumption, theatre consumables, lab and imaging orders all post to the patient's bill as the event occurs, so there is nothing to collect at discharge. - A tariff and package engine prices automatically across package and open billing, sponsor, TPA and corporate rate cards, so counter staff select rather than compute, and discount authority is enforced by role rather than by convention. - Admission to "Initiate Discharge" is a single flow. The decision on the round triggers pharmacy reconciliation, ward confirmation and billing preparation in parallel instead of one after another. - Approximate and pre-authorisation bills stay live through the stay, so an enhancement request goes when the number moves, not when the patient wants to leave. - Because pharmacy, [inventory](/products/inventory), lab and [imaging](/products/pacs) sit on the same record rather than in separate systems, there is no interface waiting to post and no reconciliation between two versions of the same stay. - Audit-ready GST invoices and payer-specific formats come out of the same engine, so the finance team is not reformatting anything afterwards. If billing time is the number your board is asking about, the useful next step is to bring one week of your own discharge data to a [demo](/book-demo) and ask to see where those hours would have gone. That conversation is more informative than any feature list, including this one.

Read article
Best HRMS for Hospitals in India (2026): Why Generic HR Software Breaks on a Rotational Roster — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 8 min read

Best HRMS for Hospitals in India (2026): Why Generic HR Software Breaks on a Rotational Roster

Hospitals usually buy their HR software the way every other business does. Somebody compares three well-known Indian HRMS platforms, picks the one with the cleanest payroll and the nicest app, and rolls it out. Six months later the HR team is running the nursing roster in a spreadsheet again, because the system that handles a nine-to-six office cannot handle a ward. Nothing about that failure is unusual. Generic HRMS platforms are good products built for a work pattern hospitals do not have. ## Why does generic HR software fail in a hospital? Because it assumes a fixed shift, a fixed location and a fixed skill, and a hospital has none of those. Consider a single week in a 200-bed hospital. Nurses rotate across morning, evening and night in patterns that must respect rest rules. Someone calls in sick at half past five in the morning and a replacement has to be found who is credentialed for high dependency. A consultant is on call rather than on shift, and on-call is paid differently. Housekeeping is outsourced but must still be tracked on site. Attendance is captured at three gates and two ward stations. Overtime is generated by clinical events, not by schedules. Generic HRMS handles the payroll end of that reasonably well. It handles the front end, which is rostering against skill and acuity, either badly or not at all. So the roster leaves the system, and once the roster is outside the system the attendance and overtime data feeding payroll is reconstructed rather than recorded. ## What does a hospital actually need that generic HRMS lacks? Six capabilities, and the first three are where most deployments fail. - Rotational rostering with rules. Shift patterns, weekly-off entitlements, minimum rest between shifts, night-shift limits, and the ability to publish a roster and then modify it without republishing everything. - Skill and credential awareness in the roster itself. The system should refuse, or at least warn, when a shift is filled by someone whose licence expired last week or who is not credentialed for that unit. - Shift swap and open-shift filling. Staff-initiated swaps with supervisor approval, and open shifts offered to eligible staff on their phones rather than through a WhatsApp group. - Attendance that survives a hospital campus. Multiple capture points, geofencing for field and home-care staff, biometric where it exists, and a sane exception workflow for the inevitable failures. - Indian statutory payroll, done properly. PF, ESI, professional tax, TDS, gratuity, bonus, and the returns that go with them, with hospital-specific earnings like night allowance, on-call and shift differential handled as first-class components rather than manual adjustments. - Credential and compliance tracking. Registration renewals, immunisation status, background verification, mandatory training. NABH will ask for this and the answer needs to be a report, not a cupboard. > The test for a hospital HRMS is simple: can the charge nurse fill tomorrow morning's sick-leave gap inside the system, on a phone, in under two minutes? If not, the roster will leave the system, and the payroll data will follow it. ## How should attendance and payroll actually connect? Attendance should generate payroll inputs automatically, with exceptions raised rather than corrections applied. The common failure is a monthly reconciliation ritual: HR exports attendance, compares it against the roster, chases departments for approvals, adjusts for the exceptions, and then runs payroll under time pressure with a spreadsheet of manual entries. Every step in that chain is a place where a night allowance goes missing and a nurse loses trust in the system. What good looks like is a chain that holds end to end. The roster defines the expected shift. Attendance records the actual. The difference is an exception with a defined owner and a deadline. Approved exceptions become payroll components with an audit trail. By the time payroll runs, there is nothing to reconstruct. Ask any vendor to walk that chain with a real example, including a nurse who worked a double, swapped a shift, and had a biometric failure on one of the days. ## What about doctors, who are not employees in the usual sense? Consultants need a different model, and a hospital HRMS that only understands salaried staff will push them into a spreadsheet too. Visiting and consulting arrangements in Indian hospitals include revenue share on OPD and procedures, fixed retainers plus share, per-session payments, on-call allowances, and combinations of all of these that vary by department. The calculation depends on clinical activity captured in the HMS, not on attendance. This is the strongest argument for keeping workforce and hospital systems on one data model. A consultant payout that depends on procedures performed requires the procedure data. When the two systems are separate, someone exports, someone reconciles, and the payout is late. ## What should a hospital ask in an HRMS demo? Bring your own roster. A demo on the vendor's sample data will show you a roster that has never had a bad week. - Build next week's roster for a 30-bed ward with three shifts, using our actual shift patterns and rest rules. - Now a nurse calls in sick for tomorrow morning. Fill the gap, on a phone, with someone credentialed and rested. - Show me what happens when I try to roster a nurse whose registration expires on Thursday. - Run a swap between two staff, with approval, and show the effect on both payslips. - Process payroll for a month containing a double shift, a night allowance, an unapproved absence and a biometric failure. - Generate the PF and ESI returns for that month. - Show me every staff member with a credential expiring in the next sixty days. - Calculate a consultant payout that depends on procedures done in the hospital system. The last one is the question that separates a hospital HRMS from an HRMS being sold to a hospital. ## How do you evaluate the vendors on the market? There are three groups, and they fail predictably. Large Indian HRMS platforms are excellent at payroll and compliance, with mature statutory handling and good employee self-service. Rostering is usually shift-based rather than skill-based, and credential compliance is a custom field. Suitable for a hospital's administrative staff; usually supplemented for nursing. Global workforce management suites do have real acuity-based scheduling, and they are built for exactly this problem in large health systems. Cost and Indian statutory localisation are the questions to press hard on. Healthcare-specific Indian platforms sit between the two. Rostering and credentialing are built in, statutory payroll is local. Depth of the payroll engine varies, so test it against your most complicated month rather than a clean one. ## Where Kōami Workforce fits Kōami Workforce is the healthcare-specific option, and it exists because the alternative in most hospitals is a spreadsheet sitting between two good systems. It covers rotational rostering with rest and skill rules, geofenced and multi-point attendance, shift bidding and swaps, Indian statutory payroll, and credential expiry tracking. Because it sits on the same platform as the hospital system, consultant payouts that depend on clinical activity are calculated from that activity rather than from an export, and a credential that lapses is visible to the person building the roster. If your hospital's HR pain is purely payroll, a mainstream Indian HRMS will serve you well and cost less. If it is the roster, and the reconciliation the roster causes, that is a different problem and it needs a different tool.

Read article
Getting Paid Faster: Cutting Claim Settlement Time — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 8 min read

Getting Paid Faster: Cutting Claim Settlement Time

A hospital's receivables ageing report tells a story that most boards read incorrectly. The story they read is that payers are slow. The story in the data is usually that a large share of the delay happened inside the hospital, before the claim was ever submitted, and a further share happened because the claim was submitted incomplete and came back. Payer processing time is real and it is largely outside your control. Everything either side of it is not. ## What does claim settlement time actually consist of? Four intervals, and only one of them belongs to the payer. - Discharge to claim submission. The hospital's own preparation time. - Payer processing to first response. The payer's clock. - Query or rejection to resubmission. The hospital's again, and usually the worst of the four. - Approval to money received and reconciled. Shared, and frequently untracked. Hospitals that measure only the total, or only "days in receivables", cannot tell which of these is hurting them. The first step is always to split the number. In most hospitals the first interval is several days and the third is several weeks, because a rejected claim goes into a pile that nobody owns. ## Why do claims take days to leave the hospital after discharge? Because the claim needs documents that were created during the stay but were not collected as they were created. A scheme or insurance claim typically needs the discharge summary, investigation reports, the itemised bill, the pre-authorisation and any enhancements, implant stickers and invoices where relevant, operative notes, and in some schemes photographs at defined stages. Every one of those existed before discharge. Almost none of them is assembled before discharge. So a clerk spends two days after discharge collecting documents from the ward, the theatre, the lab and the medical records department. This is not a claims problem. It is a document-capture problem wearing a claims costume. The fix is to make the claim file assemble itself during the stay: each required document attached to the admission as it is produced, with a checklist showing what is still missing while the patient is still in the building and the people who created the documents are still available. > The cheapest week you can take out of your receivables cycle is the week between discharge and submission, and you take it out by collecting documents during the stay rather than after it. ## Why do so many claims come back? Because the error was made at registration or at the point of clinical documentation, and nobody checked before submission. The recurring causes are consistent across payers and schemes: - Identity and eligibility errors made at the counter: a mismatched name, an unverified card, a policy that had lapsed - The wrong package selected, or a package whose inclusions do not match what was actually done - Missing pre-authorisation, or a final bill exceeding the sanctioned amount with no enhancement on record - Documentation that does not support the claim: a discharge summary that omits the procedure, missing implant invoices, absent photographs where the scheme requires them - Submission after the payer's time limit, which converts a valid claim into nothing Every one of these is detectable before submission by a rules check. Most hospitals do the check after rejection instead. The specific mechanics for scheme claims are in [why PM-JAY claims get rejected](/blog/ayushman-bharat-claims), and the first-pass discipline in [raising first-pass claim rates](/blog/claims-first-pass). ## What happens to rejected claims, and why is that the biggest leak? They sit in a queue that has no owner, and a meaningful share of them are eventually written off unworked. This is the least glamorous and most expensive failure in hospital revenue. A rejection is not a loss; it is a task. But a task without an owner, a due date and a visible queue becomes a loss by default, usually silently, and usually discovered at the year-end audit. What fixes it is unremarkable and effective: every rejection or query becomes a work item with an owner, a reason code, an age and an escalation. Reason codes are the important part, because they turn a pile of individual failures into a pattern. When forty percent of your rejections share one reason code, you have found a process to fix rather than forty claims to chase. ## What should the hospital measure? Seven numbers, split by payer and by scheme, because the payers behave differently and an aggregate hides that. - Days from discharge to claim submission - First-pass acceptance rate - Days from submission to first payer response - Days from query to resubmission - Rejection reasons, ranked by count and by value - Claims approaching the payer's submission deadline, as a live list - Days in receivables, split by payer and by age bucket The sixth is the one to build first. A live list of claims about to time out prevents the most avoidable loss in the entire cycle. ## How Kōami shortens claim settlement time [Kōami Hospital](/products/hmis) treats the claim as something that accumulates during the admission rather than something assembled after it. - Billing, TPA and insurance run on the same record as the care. The tariff and package engine prices against the payer's rate card, and sponsor, TPA and corporate arrangements are configured rather than remembered. - Approximate and pre-authorisation bills stay live as charges accrue, so an enhancement request goes when the amount moves past the sanctioned limit rather than at discharge. - Clinical documents produced during the stay — discharge summary, investigation reports, operative notes, implant and consumable records from theatre — are attached to the admission as they are created, because they are created in the same system. - Charges are captured at the point of care through pharmacy, [inventory](/products/inventory), lab and [imaging](/products/pacs), so the itemised bill supporting the claim matches what actually happened without a reconciliation step. - Audit-ready invoices come out of the billing engine in the format the payer expects, so nothing is reformatted by hand. - Because it is one system, the claim file, the clinical record and the bill cannot disagree with each other, which removes an entire category of rejection. If you want to know where your own days are going, the exercise worth running before you talk to any vendor is to split your receivables into the four intervals at the top of this article. Bring that split to a [demo](/book-demo) and the conversation will be about your numbers rather than anyone's features.

Read article
Best PACS Software in India (2026): Cloud, On-Premise and What to Ask Every Vendor — Radiology | KōamiRadiology
Radiology· 8 min read

Best PACS Software in India (2026): Cloud, On-Premise and What to Ask Every Vendor

A radiologist's opinion of a PACS forms in the first ten minutes and rarely changes. Either the study opens fast and the tools land where the hands expect them, or it does not, and no amount of feature depth recovers from that. Buyers, meanwhile, are comparing storage tiers and licence counts. The two conversations barely touch, which is why so many imaging deployments are technically successful and clinically resented. The Indian PACS market now spans everything from a free viewer on a workstation to enterprise imaging suites, with home-grown vendors, global platforms and cloud-first newcomers in between. Comparing them properly means separating three things buyers routinely conflate: the archive, the viewer and the workflow. ## What is the difference between PACS, RIS and a DICOM viewer? They are three separate things, and most confusion in an imaging purchase comes from treating them as one. - A DICOM viewer displays images. It is a client. It can be free, it can be excellent, and on its own it stores nothing and schedules nothing. - PACS is the archive and distribution layer. It receives studies from modalities, stores them, and serves them to viewers. It is where retention, redundancy and access control live. - RIS is the workflow: orders, scheduling, the worklist, the report, and the billing hooks. It is what turns an image into a completed clinical event. Some products cover all three, some cover two, and many proposals are ambiguous about which they cover. Ask explicitly. A hospital that buys PACS believing it includes RIS discovers on go-live that nobody knows which studies are unreported. ## Should an Indian hospital choose cloud or on-premise PACS? Cloud for most hospitals now, on-premise where imaging volume is very high or connectivity is genuinely unreliable. The calculation has shifted. Imaging is the largest data set a hospital produces, and on-premise means buying storage for peak growth, running redundancy, managing backups, and refreshing hardware every few years. Cloud converts that into a recurring cost and removes a class of failure most hospitals were never staffed to handle. What still argues for on-premise, or for hybrid, is throughput and bandwidth. A high-volume centre pushing large studies, particularly thin-slice CT and MR, needs to move a lot of data before a radiologist can read. If the site's upstream link cannot sustain that, the cloud archive will be correct and slow, which in practice means unused. The pragmatic middle is common and worth asking about: a local cache or gateway holding recent studies for fast reading, with the cloud as the archive of record. Ask any cloud vendor how they handle a site with a weak link, because the answer tells you whether they have deployed in Indian conditions. > Radiologists do not evaluate a PACS on storage architecture. They evaluate it on how long a 900-slice CT takes to become readable, and whether the window presets are where they left them. ## What separates a good viewer from a bad one? Speed to first image, and whether the tools match how the reader actually works. The technical mechanism that matters most is progressive, server-side rendering. A viewer that downloads an entire study before displaying anything will feel slow no matter how fast the network is. A viewer that streams slices on demand, rendering server-side and sending only what the reader is looking at, feels instant even on modest bandwidth. When comparing, ask specifically whether the viewer downloads studies or streams them. After that, the things readers care about: - Zero-footprint browser operation, with no installed client and no browser plug-in, so a study can be read from any machine including at home. - Window and level presets per modality and body part, remembered per user. - Hanging protocols that lay out prior and current studies the way that reader wants them. - Measurement, MPR and basic 3D where the speciality needs it. - Prior study retrieval that is automatic rather than a search. - Mobile viewing that is honest about its limits, for reference rather than primary diagnosis. ## What should the reporting side do? It should produce structured reports and close the loop on critical findings. Dictation into free text is still the default in much of the market, and it is the reason radiology data is nearly impossible to analyse afterwards. Structured reporting with templates by modality and indication takes discipline to adopt, but it makes reports consistent, faster to produce for routine studies, and actually queryable. The second thing to insist on is critical results handling. When a radiologist finds something urgent, the system should record the notification, who received it, when, and the acknowledgement. NABH will ask, and more importantly a missed critical finding is the most serious failure mode radiology has. ## What integration and compliance questions should be on the list? Six, and they are the ones most likely to be answered vaguely. - Modality integration. DICOM worklist to every modality, including the older ones. Ask specifically about your oldest machine, by model. - HIS and RIS integration. Orders in, reports out, status visible in the hospital system, and billing triggered by study completion rather than by a person remembering. - Standards. DICOMweb interfaces, HL7 or FHIR for orders and results. A private API instead of a standard is a lock-in signal. - ABDM. Whether imaging reports can be linked as a care context so the record is discoverable to the patient, and whether the vendor holds current milestone certification. - Data residency and DPDP. Where the archive physically sits, who can access it, and how access is logged. Imaging data is health data. - Retention and exit. How long studies are kept, at what cost, and what it costs to get the whole archive back in standard DICOM if you leave. Imaging is the hardest data to migrate; the exit clause is not theoretical. ## What does PACS cost in India? The honest answer is that the licence is usually the smaller part of the number. Vendors price by study volume, by concurrent user, by modality connection, by storage tier, or by some combination. The costs buyers forget are modality integration work charged per machine, migration of the existing archive, the local gateway hardware if one is needed, the network upgrade the deployment exposes, and archive egress at the end of the contract. Ask for a five-year total against your actual annual study volume with a stated growth rate, including storage growth. A quote that does not model storage growth is not a quote for an imaging system. ## What should you ask in a PACS demo? Use your own studies. A vendor's demo data set is chosen because it opens quickly. - Open a large multi-slice CT from our archive on this connection, and time it. - Show the same study in a browser with nothing installed. - Bring up the prior study automatically alongside it. - Apply my window preset and show me that it persists next session. - Report it using a structured template, then show me the report in the hospital system. - Flag a critical finding and show the notification and acknowledgement trail. - Show me the audit log for a study that was viewed but not reported. - Export the last thirty days of studies as standard DICOM. ## Where Kōami PACS fits Kōami PACS is a browser-first, streaming-based imaging platform, built on the view that the viewer is the product and everything else is plumbing that should be invisible. It does zero-footprint DICOM viewing with server-side rendering rather than whole-study download, window and level presets that follow the reader, structured reporting, critical results workflow, and secure external sharing. Because it sits on the same platform as the hospital system, an order placed in OPD reaches the modality worklist and the finished report reaches the patient record without an interface engine in between. If you are a standalone imaging centre with no hospital system, a dedicated RIS-PACS vendor is a perfectly sensible choice and you should evaluate several. If you are a hospital tired of imaging being an island with its own patient identity, that is the problem Kōami PACS was built to remove.

Read article
Door-to-Doctor Time in Casualty, and How to Shorten It — Operations | KōamiOperations
Operations· 7 min read

Door-to-Doctor Time in Casualty, and How to Shorten It

In an emergency department, the first number that matters is how long a patient waits between walking through the door and being seen by a clinician. Everything else — time to investigation, time to decision, time to admission or discharge — sits downstream of it. A department that fixes door-to-doctor time usually finds the rest improves without being attacked separately. It is also the number most often measured badly, because the clock is started when somebody remembers to start it. ## What is door-to-doctor time and why does it matter more than the others? It is the interval between a patient's arrival and their first assessment by a doctor, and it matters because it is the only interval during which nobody is doing anything for the patient. Every other emergency interval contains work. Time to CT includes the scan. Time to admission includes the decision. Door-to-doctor is pure waiting, and for a proportion of arrivals it is the interval in which a deteriorating patient is unattended. It is also a leading indicator. When door-to-doctor lengthens, it is almost always because something downstream has blocked: no cubicle free because admitted patients are boarding, no doctor free because one is tied up in resuscitation, or registration has become a bottleneck. ## Where do the minutes actually go in an Indian casualty? Four places, and registration is usually the largest and the most fixable. - Registration and payment before assessment. In many hospitals a patient cannot be seen until they are registered, and registration includes payment or payer verification. For a genuine emergency this is both a clinical risk and an operational bottleneck. - Triage that is a queue rather than a sort. If arrivals are seen in order of arrival, the sickest patient waits behind six minor complaints. - Cubicle availability. Space occupied by patients who have been decided upon but not moved. - Doctor availability at the specific hour. Emergency arrivals are not uniform through the day, and rosters frequently are. The first is the one to attack first, because it is entirely within the hospital's control and it costs nothing to change. ## How should registration work in an emergency? Assessment first, registration in parallel, with a provisional identity created in seconds. The workable pattern is a rapid registration that captures the minimum needed to create a record — an approximate age, a sex, a presenting complaint and a system-generated temporary identifier — and lets the patient be seen immediately. Full demographics, payer details and payment follow while care is under way, and the temporary record merges into the permanent one once identity is established. This matters for the unidentified patient too. A road traffic casualty brought in by a passer-by needs a record before anyone knows their name, and that record has to be capable of receiving orders, results and charges, then merging cleanly later without losing anything. > If your emergency department cannot create a working patient record for an unidentified, unaccompanied patient in under thirty seconds, registration is part of your clinical risk, not just your queue. ## What does triage have to do to be worth the time it takes? Sort by acuity in under two minutes, and make the sort visible to everyone who acts on it. A triage that takes eight minutes has consumed a meaningful fraction of the interval it exists to protect. A triage whose output lives on a paper slip is invisible to the doctor scanning the department for who to see next. What works is a short structured assessment producing a category, recorded once, and immediately visible on a live emergency board that everybody reads: who is waiting, in what category, for how long, and what has been ordered. When a category-one patient has been waiting four minutes, that fact should be on a screen, not in someone's memory. The same principle applies to re-triage. A patient who has waited forty minutes is not the patient who arrived; their category should be revisited, and the system should prompt it. ## How do you stop the department blocking from downstream? Measure boarding time separately, and treat it as an inpatient problem rather than an emergency one. Boarding — patients who have been admitted but remain in emergency because no ward bed is available — is the single largest cause of emergency overcrowding in most hospitals, and it is not caused by the emergency department. It is caused by discharge timing on the wards. If your wards discharge in the late afternoon and your emergency admissions peak in the evening, the two curves guarantee boarding. Moving ward discharges earlier in the day is an emergency department intervention, even though nothing about it happens in the emergency department. This is one more reason the discharge process matters beyond its own metric, as set out in [admission to discharge](/blog/admission-to-discharge-time) and [why discharge takes so long](/blog/discharge-time). ## What should an emergency department measure? Six intervals, reported by hour of day rather than as daily averages, because the whole point is to find the hours that fail. - Door to triage - Door to doctor, at median and ninetieth percentile - Door to first investigation ordered, and to result available - Decision to admit, and decision to admission on a ward bed, which is boarding time - Total time in department, split by admitted and discharged - Left without being seen, counted rather than estimated Reporting these as a daily average hides the problem. Reporting them by hour shows you that the department fails between six and ten in the evening, which is a rostering conversation rather than a process one. ## How Kōami shortens door-to-doctor time [Kōami Hospital](/products/hmis) treats the emergency arrival as a record that can exist before identity, payment or payer are known, so nothing clinical waits on administration. - Rapid registration creates a working UMR immediately, capable of carrying orders, results and charges, and merging into the permanent record once identity is confirmed without losing the history attached to it. - Triage category is recorded once and drives a live view of the department, so the next patient to be seen is decided by acuity and waiting time rather than by whoever is loudest at the counter. - Orders placed from the chart go straight to the lab and to the imaging [modality worklist](/products/pacs), and results and turnaround times post back automatically, so the clock on an investigation is visible rather than inferred. - Live bed and ward occupancy means the decision to admit can be matched to an actual available bed, and boarding time becomes a number on a screen rather than an argument between two departments. - Because [Kōami Workforce](/products/hrms) holds the roster, staffing can be matched to arrival patterns by hour, and the credential rules that decide who can staff which area are enforced when the roster is built rather than discovered on the shift. - Charges accrue as care happens, so an emergency patient who is admitted, discharged or transferred does not generate a separate billing reconciliation afterwards. If your emergency department's numbers are collected on paper or not at all, that is the place to start, and it is worth doing before any software decision. If you already have the timestamps, bring a month of them to a [demo](/book-demo).

Read article
Best Hospital Inventory and Pharmacy Software in India (2026) — Supply Chain | KōamiSupply Chain
Supply Chain· 8 min read

Best Hospital Inventory and Pharmacy Software in India (2026)

Ask a hospital finance head where the money leaks and they will name consumables before they name anything else. Ask the pharmacy in the same hospital and they will describe a different problem: not leakage, but firefighting. Stock-outs of things that should never run out, expiry write-offs of things that were over-ordered, and a ward indent process that consumes half of somebody's day. Both descriptions are of the same failure. The hospital is running its supply chain on records that are updated after the fact rather than as events happen. Software fixes that only if it is chosen for the right reasons, and hospital inventory has a few that general-purpose inventory software does not cover. ## Why can't a hospital use ordinary inventory or ERP software? Because hospital stock is regulated, batch-controlled, expiry-bound and dispensed against a patient, and general inventory software treats it as quantity on hand. Four differences matter. - Batch and expiry are not optional attributes. A hospital must know which batch was dispensed to which patient, because that is what a recall depends on and what a drug authority will ask for. - Consumption is clinical. Stock moves when a nurse administers a dose or a theatre opens an implant, not when a storekeeper issues it. If the system only records store issues, ward stock becomes invisible. - Some categories are legally controlled. Narcotic and psychotropic substances carry register obligations under the NDPS rules. Blood products, vaccines and reagents carry their own conditions, including cold chain. - Charges are attached. In most Indian hospitals a consumable used on a patient must reach the bill. An inventory system that does not connect to billing creates revenue leakage that nobody can quantify. > Every hospital that cannot say which ward is holding how much stock right now is over-ordering somewhere and stocking out somewhere else, usually at the same time. ## What should a hospital inventory system actually do? Nine things. The first four are where most systems are weak. - Multi-store, multi-branch structure. Main store, sub-stores, pharmacy counters, ward floor stock, theatre, and each branch, with stock visible across all of them. - Ward-level consumption. Indents raised from the ward, issued against the indent, consumed against a patient, and reconciled without a monthly stock-take being the only truth. - FEFO enforcement. First expiry, first out, applied at the point of issue by the system rather than by the storekeeper's judgement. - Reorder logic that reflects reality. Reorder levels calculated from consumption history and lead time, differentiated by criticality, rather than a static minimum somebody typed in three years ago. - Procure to pay. Indent, purchase requisition, approval, purchase order, goods receipt with batch capture, quality check, invoice matching and vendor payment, with the three-way match enforced. - Statutory registers. NDPS register generated from live transactions, not maintained separately. - Charge capture. Consumables and implants used on a patient reaching that patient's bill automatically. - Vendor and rate management. Rate contracts, comparison at purchase, and vendor performance on delivery time and rejection rate. - Expiry management ahead of time. Alerts early enough to return goods under the vendor's return terms, not a write-off report afterwards. ## How do you tell a real hospital pharmacy module from a retail one? Look at what happens between the prescription and the bill. Retail pharmacy software sells a product to a walk-in customer. A hospital pharmacy dispenses against an inpatient order, from a ward stock or a counter, sometimes with the drug returned unused, sometimes with the charge going to a package rather than to the patient, sometimes against a scheme that pays differently. The behaviours to test are the returns and reversals. Dispense a medicine to an inpatient, then cancel it because the order changed. A good system reverses the stock, reverses the charge, keeps both in the audit trail, and leaves the batch record correct. A weak system leaves you with a manual adjustment and a discrepancy at month end. Also test substitution. When the prescribed brand is unavailable and an equivalent is dispensed, the system should record what was actually given, because that is the record that matters clinically and legally. ## What questions should be in the demo? Bring a real ward and a real drug list. - Raise an indent from a ward, issue against it, and show me the ward's current holding. - Dispense a controlled substance and show me the NDPS register entry it produced. - Dispense a medicine to an inpatient, then cancel it. Show the stock ledger and the bill. - Receive a purchase order with two batches and different expiry dates, then issue and show me which batch went out. - Show me every item expiring in ninety days, by store, with the vendor return terms. - Show me consumption for a theatre implant reaching a patient bill. - Recalculate reorder levels from the last six months of consumption. - Transfer stock between two branches and show both ledgers. - A batch is recalled. List every patient who received it. That last one is the question that most clearly separates systems built for hospitals from systems adapted to them. ## What does it cost, and where do hospitals overspend? Inventory is usually priced as a module of a hospital system or as a standalone supply chain product, and the standalone route is where the cost surprises live. A standalone system needs integration with billing for charge capture, with the HMS for patient identity, and often with accounting for vendor payment. Each is a project. The integrated route trades some depth for the absence of those interfaces, which for most hospitals under three hundred beds is the better trade. Where hospitals genuinely overspend is on scanning hardware bought before the process is agreed, and on barcode projects that stall halfway. Barcoding at receipt and at dispensing is transformative, but only if the whole chain is barcoded. Half a chain is more work than none. ## How does this connect to the rest of the hospital? Inventory touches billing, clinical orders, theatre, biomedical equipment and finance, and every one of those connections is a place where separate systems leak. The clearest example is charge capture. When pharmacy and billing are the same system, a dispense creates a charge. When they are separate, a dispense creates a file that somebody imports, and the difference between the two shows up in the annual accounts as consumables consumed but not billed. The second is theatre. Implants and high-value consumables opened in an operating theatre are the single largest source of untracked expenditure in most hospitals, because the recording happens in a register during a procedure. A system that lets theatre staff record consumption at the point of use, on a screen that takes seconds, recovers more money than any procurement negotiation. ## Where Kōami Inventory fits Kōami Inventory is the supply chain product inside the wider platform: indents, procurement, batch and expiry tracking with FEFO, multi-store and multi-branch stock, and vendor management. The reason it exists as part of a platform rather than a standalone product is the connection described above. Dispensing creates the charge. Theatre consumption reaches the bill. The NDPS register comes from the transactions rather than from a parallel book. Ward stock is visible because the ward is in the same system. If you run a large distribution operation across many sites and need deep procurement analytics, a dedicated supply chain platform will go further than any hospital system's module. If your problem is that stock, billing and the wards do not agree with each other, that gap is the thing worth closing first.

Read article
Radiology Report Turnaround: From Scan to Signed Report — Radiology | KōamiRadiology
Radiology· 7 min read

Radiology Report Turnaround: From Scan to Signed Report

Ask a hospital why its radiology reports are slow and you will usually be told there are not enough radiologists. Sometimes that is true. More often, the radiologist is reading steadily all day while the report sits unsigned for reasons that have nothing to do with reading speed: the study did not appear on the worklist, the prior study could not be found, the report was dictated and is waiting to be typed, or it was signed hours ago and nobody told the ward. Turnaround is an end-to-end interval. Reading is one segment of it, and rarely the longest. ## What should radiology turnaround time actually measure? The interval from the study being acquired to the report being available to the person who ordered it, not from when the radiologist opened it. This definition matters because the shorter definitions are the ones that let a department report good numbers while clinicians experience bad ones. If the clock starts when the study reaches the worklist, every delay in getting it there is invisible. If it stops at signature rather than at availability, the last hop is invisible too. Measure it in segments, because the segments have different owners: - Order placed to scan performed - Scan performed to study available on the worklist - Study available to radiologist opening it - Opened to report drafted - Drafted to signed - Signed to visible in the patient record and to the ordering clinician ## Where do the hours usually go? Between the scan completing and the report reaching the person who has to act on it — the two ends, not the middle. At the front end, studies that do not reach the worklist promptly, or reach it unmatched because the accession number or patient identity was entered differently at the modality than at the order. An unmatched study waits for a person to notice it. At the back end, the reporting chain. Dictation transcribed by a typist, returned for correction, corrected, returned, signed. Each hop is a queue. And then the last hop, which in many hospitals is a printout carried to a ward, or a report visible only in the radiology system that the treating team does not open. In the middle, the delays are usually about context rather than speed: a prior study that has to be requested, a clinical history that is not attached, a protocol question that requires a phone call. > A report signed at eleven that reaches the ward at four has a turnaround time of five hours, whatever the radiology system says. ## Why does the missing prior study cost so much? Because comparison is often the whole diagnostic question, and a radiologist who cannot find the prior either waits or reports without it. For oncology follow-up, chest imaging and anything being monitored over time, the prior is not a nice-to-have. If retrieving it means a request to another department, a CD, or a phone call to another hospital, the study stops. If the prior appears automatically alongside the current study, that delay disappears entirely. This is one of the strongest arguments for a single archive across sites in a multi-branch group. A patient scanned at the satellite unit in March and at the main hospital in September should present as one imaging history, not two. ## How much does structured reporting actually help? It shortens routine reports substantially and makes them consistent, at the cost of discipline in setting up templates. The gain is largest where volume is highest and variation is lowest: screening studies, routine radiographs, standard follow-ups. A templated report for a normal chest radiograph is a matter of confirming a structure rather than composing prose. The radiologist's time is then concentrated on the studies that need thought. The secondary gain is that structured reports are queryable, which is what makes departmental analytics and any downstream automation possible at all. A decade of free-text reports is a decade of data you cannot count. The trade-offs are set out in [from dictation to structured reports](/blog/structured-reporting). ## What about the last hop, which nobody measures? Automate it, and measure separately whether a critical finding was acknowledged rather than merely sent. A signed report should appear in the patient's record immediately and be visible to the ordering clinician without anyone carrying anything. For routine findings that is sufficient. For critical findings it is not: the requirement is a closed loop, where the notification is recorded, the recipient is identified, and the acknowledgement is captured. NABH will ask for this, and it is the failure mode with the most serious consequences. [Closing the loop on critical results](/blog/critical-results) covers it. Turnaround also has a length-of-stay consequence. A report that lands after the morning ward round costs an inpatient a day, not an hour, which is why radiology turnaround belongs in the operations conversation and not only the radiology one. See [admission to discharge](/blog/admission-to-discharge-time). ## How Kōami shortens scan-to-report time [Kōami PACS](/products/pacs) is browser-first and streams rather than downloads, which removes the delay that most often makes a radiologist wait before reading. - Studies land in the archive and appear on the worklist automatically, de-duplicated by SOP UID, so unmatched studies do not sit waiting for someone to notice them. - The worklist is triaged rather than chronological, with red, amber and green badges, modality and status filters and an "assigned to me" view, so the urgent study is read first by design. - The zero-footprint DICOM viewer opens in the browser with no install, streaming slices over WADO-RS rather than downloading the study, with window and level presets, measurement, multi-viewport, MPR and cine. A radiologist can read from any machine, including at home on call. - Priors are part of the same archive, so comparison does not begin with a search. - Structured reporting with RadReport templates, AI-assisted drafting and dictation runs inside the study, with a clean draft, final and addendum sign-off producing both DICOM SR and a branded PDF. - AI findings are presented as ranked cards with heatmap overlays and the ability to navigate to a finding, positioned as assistance to the radiologist rather than a replacement, in line with [AI findings as a second reader](/blog/ai-second-reader). - Because imaging sits inside [Kōami Hospital](/products/hmis), the order reaches the modality worklist and the signed report reaches the patient record and the ordering clinician without an interface engine in between, and a critical-results queue tracks acknowledgement rather than assuming it. - Imaging analytics report study volume, turnaround, modality mix and radiologist productivity, so the segments above are numbers rather than impressions. If your department reports good turnaround numbers and your clinicians disagree, the definition is almost certainly the problem. Measure the six segments above for a fortnight and bring them to a [demo](/book-demo).

Read article
Biomedical Equipment Management Software: Choosing a Hospital CMMS in India — Operations | KōamiOperations
Operations· 7 min read

Biomedical Equipment Management Software: Choosing a Hospital CMMS in India

Every hospital knows roughly what it spent on medical equipment. Very few can say what any single machine has cost them since it arrived, how much of the last year it spent out of service, or whether the annual maintenance contract renewed last month was worth its price. The information exists. It exists in service reports in a file, warranty documents in a drawer, and the biomedical engineer's memory. A computerised maintenance management system, a CMMS, is the software that turns that into a record. For a hospital it also happens to be an accreditation requirement, which is usually what finally triggers the purchase. ## What does biomedical equipment management software do? It maintains an asset register, schedules preventive maintenance, manages breakdown calls, records every service event against the machine, and tracks calibration and contracts. Put more usefully, it answers questions the hospital currently cannot answer: - Which equipment is due for preventive maintenance this month, and which is overdue? - How many hours has this ventilator been out of service this year? - Which vendor consistently misses its response time commitment? - Which machines are out of warranty and not under contract? - Which calibrations expire before the next NABH audit? - Is it now cheaper to replace this machine than to keep repairing it? ## Why does NABH make this a purchase rather than a nice-to-have? Because accreditation asks the hospital to demonstrate a documented equipment management programme, and demonstration means records. The clauses concerned expect an inventory of equipment, planned preventive maintenance carried out to schedule with evidence, breakdown maintenance recorded, calibration of measuring equipment against traceable standards, and evidence that critical equipment availability is managed. An assessor asking for the last four preventive maintenance records for a specific ventilator is asking a question a filing cabinet answers slowly and a system answers immediately. Hospitals that fail this section rarely fail because maintenance was not done. They fail because it cannot be shown. > A maintenance programme that cannot be produced on demand is, for accreditation purposes, a maintenance programme that did not happen. ## What should a hospital CMMS include? Eight things, and the ones hospitals underestimate are the last three. - Asset register with real depth. Make, model, serial, location, department, purchase date and value, warranty expiry, contract status, criticality classification, and the responsible department. - Preventive maintenance scheduling. Frequency by asset class or by manufacturer recommendation, checklists per equipment type, automatic work order generation, and escalation when a schedule slips. - Breakdown and work order management. Fault logged from the ward, assigned to an engineer or a vendor, tracked to closure, with downtime measured from report to restoration rather than from when someone opened a ticket. - Contract and warranty tracking. AMC and CMC coverage, what each covers, renewal dates with lead time, and whether a given breakdown falls inside coverage. This single feature usually pays for the system. - Calibration management. Due dates, certificates stored against the asset, traceability to standards. - Spares and consumables. What is held, what is consumed per repair, and reorder for critical spares. - Vendor SLA performance. Response and resolution times measured against commitments, per vendor, over time. Without this, contract renewal is a negotiation with no evidence. - Cost history per asset. Every rupee spent on a machine, so the replace-or-repair decision has a number behind it. ## How is this different from general asset management software? Three ways, and each one matters at audit. General asset software is built for finance: what the hospital owns and what it is worth. A CMMS is built for uptime: what is working right now. Depreciation schedules and maintenance schedules are different data with different owners. Medical equipment has regulatory obligations that generic tools do not model: calibration traceability, manufacturer-specified maintenance intervals, and in some categories, event reporting. A field labelled "next service date" is not the same as a calibration record with a certificate attached. And medical equipment failure is clinically consequential. Criticality classification, so that a failed infusion pump in the ICU is routed differently from a failed printer, needs to be built into the workflow rather than added as a priority flag. ## Should biomedical maintenance sit inside the hospital system? It should at least share the hospital's location and department structure, and ideally its inventory and procurement. The argument for integration is practical. Equipment lives in wards and theatres that already exist as entities in the hospital system. Spares are inventory. Purchase of a replacement is procurement. Downtime on a theatre machine affects the surgical list. When these are separate systems, the biomedical department maintains a parallel map of the hospital, and the two maps drift. The argument for a standalone specialist CMMS is depth, particularly for large multi-site organisations with hundreds of engineers and complex contract portfolios. That is a real argument at scale. Below it, the integration cost usually outweighs the extra depth. ## What should be in the demo? Use your own equipment list, including the awkward items. - Import our asset register and show me every item out of warranty and not under contract. - Generate this month's preventive maintenance schedule and show the checklist for an anaesthesia workstation. - Log a breakdown from a ward, on a phone, with a photograph. - Assign it to an external vendor and show me the SLA clock. - Close it, record the spare used, and show the cost added to that asset's history. - Show me total downtime for the CT this year. - Show me each vendor's average response time against its contracted commitment. - Produce the last four PM records and the current calibration certificate for a named ventilator. That final request is the accreditation question. If it takes more than a few seconds, the system has not solved the problem you are buying it for. ## What does it cost? CMMS is usually priced per asset under management or per engineer user, and it is one of the cheaper systems a hospital buys relative to what it protects. The cost that matters is not the licence. It is building the asset register accurately in the first place: walking the hospital, tagging equipment, capturing serials and contract details, and classifying criticality. Budget for that as a project with a named owner, because a CMMS on top of an incomplete register produces confident reports about a fiction. Ask whether the vendor helps with the initial asset capture, whether tagging hardware is included, and how the register is kept current when equipment moves between departments, which it does constantly. ## Where Kōami Field Service fits Kōami Field Service covers biomedical equipment upkeep as part of the wider platform: preventive maintenance scheduling, engineer dispatch, SLA tracking against vendors and internal teams, and full asset service history. Because it shares the hospital's structure, a fault raised from a ward is raised against a real location, spares consumed come out of the same inventory the pharmacy and stores use, and a machine's cost history includes what was actually spent through procurement rather than what somebody typed into a maintenance note. For a hospital group running a large in-house biomedical department across many sites, evaluate dedicated CMMS platforms too; they go deeper. For most hospitals, the reason equipment records are poor is not that the available software lacked features. It is that the system sat outside everything else, so nobody kept it current.

Read article
The Pharmacy Counter Queue: The Last Wait Before a Patient Goes Home — Pharmacy | KōamiPharmacy
Pharmacy· 7 min read

The Pharmacy Counter Queue: The Last Wait Before a Patient Goes Home

A patient can have an excellent consultation, a fast investigation and a smooth billing experience, and still leave the hospital annoyed, because the last thirty-five minutes of their visit were spent standing at the pharmacy counter. It is the final interaction, which means it is disproportionately what they remember and what they describe to other people. It is also, unusually for a hospital queue, mostly a design problem rather than a resourcing one. ## Why is the hospital pharmacy queue so slow? Because each transaction contains several small delays that compound, and the counter is the only place where all of them become visible. Watch a single dispense and count the pauses. The pharmacist deciphers or re-keys the prescription. Searches for each item by name, from a list where three brands look similar. Discovers one item is out of stock and consults about substitution. Checks whether the patient is an inpatient, an outpatient or a scheme patient, because that changes the price and the payer. Enters batch details. Bills. Takes payment. Prints. Explains the dosage. Nine steps, each thirty to ninety seconds. The queue is not caused by any one of them. ## Which of those steps can actually be removed? Four, and together they account for most of the time. - Re-keying the prescription. If prescribing is electronic, the dispense screen opens with the items already on it. This single change is usually worth more than the other three combined. - Searching for the item. The prescription should carry the item identity, not a printed name to be matched by eye. - Discovering a stock-out at the counter. The prescriber should see availability while prescribing, and the counter should know before the patient arrives. - Recomputing price and payer. The tariff, the scheme rate and the payer split should be applied automatically from the patient's record. What remains — the clinical check, the batch selection, the payment, and the counselling — is work that should take time. The goal is not a fast pharmacist. It is a pharmacist who spends their minutes on the parts that need a pharmacist. > A pharmacy queue is usually a prescribing problem observed thirty metres downstream. Fix what arrives at the counter and the counter stops being the bottleneck. ## What does electronic prescribing change in practice? It removes the transcription step, the legibility risk and the search, and it lets availability be known before the patient walks over. When a consultation ends with an electronic prescription tied to the patient's record, the pharmacy has the order before the patient has left the consulting room. For outpatients that means the dispense can be prepared while the patient walks the corridor. For inpatients it means the ward's requirement reaches pharmacy without a runner and a register. It also removes an entire class of error. A handwritten prescription misread at the counter is one of the most common medication incidents in any hospital, and it is eliminated rather than reduced by not having a handwritten prescription. The substitution case is worth designing deliberately. When the prescribed brand is unavailable, the pharmacist should be able to record what was actually dispensed against what was prescribed, so the clinical record shows the truth rather than the intention. ## How does stock design affect the queue? A stock-out discovered at the counter costs far more time than one prevented in the store, because it stops a queue rather than a shelf. Three things prevent it: - Reorder points calculated from actual consumption and lead time, rather than a static minimum typed in years ago, so fast-moving items are reordered before they run out - Visibility of stock at the point of prescribing, so a clinician can be told at the moment of writing rather than the patient being told at the counter - Batch and expiry handled by the system rather than by the pharmacist's judgement, with first-expiry-first-out applied automatically at issue The reorder mechanics are in [reorder points that prevent stock-outs](/blog/reorder-automation) and the expiry discipline in [FEFO](/blog/batch-expiry). ## What about inpatient pharmacy, which is a different problem? Inpatient dispensing should never involve the patient's family standing at a counter at all. In many hospitals a relative is sent to the pharmacy to buy medicines for an admitted patient, several times a day. This is a queue the hospital created and can remove. Ward stock, indents issued against the ward, and consumption recorded against the patient at administration take the family out of the loop entirely and produce a more accurate medication record as a by-product. It also fixes the discharge delay caused by returning unused medicines, because if consumption was recorded as it happened there is very little to return and reconcile. The mechanics are in [ward indents that reconcile themselves](/blog/ward-indents), and the discharge consequence in [cutting hospital billing time](/blog/reduce-billing-time). ## What should a pharmacy measure? Five numbers, at peak hour rather than as a daily average. - Counter service time, median and ninetieth percentile - Queue length by hour of day - Stock-outs at the point of dispensing, counted as events - Substitutions made, and whether they were recorded against the prescription - Time from prescription written to dispense completed, for outpatients The third is the one that most directly explains a bad afternoon, and it is the one most hospitals do not record because it happens verbally. ## How Kōami removes the wait at the counter Pharmacy in [Kōami Hospital](/products/hmis) sits on the same record as prescribing, billing and stock, which is what removes the re-keying, the searching and the recomputing. - Electronic prescribing means the dispense screen opens with the prescribed items already on it, tied to the patient's UMR, so there is nothing to transcribe and nothing to search for. - OP, IP, OT and central pharmacy run on one stock backbone, so availability is a single truth rather than four registers, and a ward indent, a theatre issue and a counter sale all deduct from the same stock. - Batch and expiry control with first-expiry-first-out is applied at issue by the system, and the NDPS register is generated from the transactions rather than maintained separately. - Point-of-sale billing and returns run inside the same flow, with the tariff, scheme rate and payer split applied from the patient's record instead of being recomputed at the window. - [Kōami Inventory](/products/inventory) drives reorder points from real consumption with automatic purchase orders and shortage alerts, so the stock-out is prevented in the store rather than discovered at the counter. - Ward indents and consumption are recorded against the patient as care happens, which takes the family out of the queue and makes the discharge reconciliation nearly empty. The pharmacy queue is the cheapest patient-experience win available to most hospitals, because almost all of it is removable without hiring anyone. If you want to see where your own minutes go, a [demo](/book-demo) against one of your real prescriptions is the fastest way to find out.

Read article
The Complete Hospital Management System Module List, and Which Ones You Actually Need — Product | KōamiProduct
Product· 9 min read

The Complete Hospital Management System Module List, and Which Ones You Actually Need

Every HMS proposal contains a module list. It is usually the longest page in the document, it usually has thirty or forty entries, and it is usually the least useful page for making a decision, because two vendors can list the same module name and mean wildly different things by it. This is the module list explained: what each one is, what it must contain to be real, and which ones a hospital of your size actually needs on day one. Read it as a checklist to hold up against any proposal. ## What are the core modules every hospital management system must have? Six. Without all six you do not have an HMS, you have a department tool. - Patient registration and master index. One identity per patient, with duplicate detection, ABHA creation and linkage, and demographic capture. Everything else hangs off this. A weak patient master produces a decade of merged-record problems. - OPD management. Appointments, queue and token, consultation recording, prescriptions, and follow-up scheduling. - IPD management. Admission, bed allocation, transfer, daily care recording, discharge summary, and the ADT event stream that the rest of the hospital depends on. - Billing and revenue. Tariffs, package and open billing, advances, interim bills, insurance and cash splits, credit notes, and the final bill. - Pharmacy. Dispensing against orders, batch and expiry, stock, and the charge reaching the bill. - Reports and MIS. Census, revenue, department productivity, and the statutory returns. ## Which clinical modules matter, and what makes them real? The clinical layer is where proposals are vaguest, because "EMR" is a word rather than a specification. Electronic medical record. The test is whether data is structured. Coded diagnoses, structured orders, results as values rather than as scanned images, and templates by speciality. A rich-text editor with a spell-checker is not an EMR; it is a word processor inside a hospital system, and nothing it holds can be reported on. Nursing and clinical charting. Vitals, intake and output, medication administration records, care plans, and assessment forms. This is the module most often bought and least often used, because it is the one that adds work at the bedside unless it is genuinely fast. Order management. Orders placed once, reaching the lab, radiology and pharmacy without re-entry, with status visible to the person who ordered. Laboratory information system. Sample collection with barcoding, analyser interfacing so results arrive electronically rather than typed, validation rules, and turnaround time measurement. Analyser interfacing is frequently a separate charge per instrument. Ask. Radiology and imaging. Order to modality worklist, reporting, and the images accessible from the patient record. Whether PACS is included or integrated is a question that must be answered explicitly. Operating theatre. Scheduling with conflict detection across surgeon, theatre and equipment, pre-operative checklist, intra-operative notes, implant and consumable recording, and the link to billing. Emergency. Triage category on arrival, rapid registration for unidentified patients, and the handover to inpatient care. > The modules a hospital regrets buying are rarely the ones it did not need. They are the ones it needed and bought in a version too shallow to use. ## Which modules are driven by Indian regulation? Five, and each is a licensing or accreditation obligation rather than a convenience. - Blood bank. Donor registration, screening, component preparation, crossmatch, issue and the statutory registers. A blood bank is a separately licensed establishment; the software has to reflect that. - NDPS register. Narcotic and psychotropic stock and dispensing, with the register generated from live transactions. - Biomedical waste. Category-wise generation, handover records, and the annual return. - Birth and death registration. Statutory records and the certificates. - Insurance, TPA and PM-JAY. Pre-authorisation, claim assembly with documents, rejection handling and resubmission. If schemes are a meaningful share of revenue, this is not a module, it is the revenue cycle. ## Which administrative modules are worth having in the same system? Four, and the argument for each is that they share data with clinical operations rather than sitting beside them. Inventory and procurement. Indents, purchase orders, goods receipt with batch capture, multi-store stock. Shares batch and expiry with pharmacy and consumption with theatre. Human resources and payroll. Rostering, attendance, statutory payroll, credential expiry. Shares clinical activity with consultant payouts. Accounts and finance. At minimum, a clean export to the accounting system with a defined chart of accounts mapping. Full financial accounting inside the HMS is less common and rarely necessary. Biomedical equipment maintenance. Asset register, preventive maintenance, breakdown, calibration. Shares hospital structure and spares inventory. ## What does a hospital of my size actually need on day one? Fewer modules than the proposal contains, implemented properly, rather than everything implemented thinly. A clinic or nursing home under thirty beds needs registration, OPD, IPD basics, billing, pharmacy and reports. Add lab if the lab is in-house. Everything else can wait, and buying it early means paying maintenance on unused software. A hospital between thirty and a hundred beds adds a real lab module with analyser interfacing, EMR with structured orders, theatre scheduling, inventory, and insurance handling if schemes matter. This is the size at which the patient master and billing depth start to hurt if they were chosen carelessly. Between one hundred and three hundred beds, nursing charting, radiology integration, blood bank if licensed, HR and rostering, biomedical maintenance, and proper MIS become necessary rather than optional. Multi-store inventory is no longer a convenience. Above three hundred beds, or across multiple branches, the questions change shape entirely: consolidated identity and reporting across sites, per-site configuration, integration architecture, and performance under concurrency matter more than any individual module's feature depth. ## How should the module list be used in a negotiation? As a scope definition, not as a score. Three habits protect a hospital here. First, ask for each module to be priced individually even if you buy a bundle, so you know what you are paying maintenance on. Second, ask which modules are included in the implementation scope and which are licensed but not configured, because those are different things and the gap is where go-live delays live. Third, ask what is on the roadmap rather than shipped, and get the distinction in writing. A bundle discount on modules you will not use for three years is not a discount. It is three years of maintenance on shelfware. ## What is the module list missing? The things that decide whether the system works, none of which appear as a module. - The patient master's duplicate handling - Print speed at the billing counter - What happens during a network outage - Concurrency at peak OPD - Whether the API is documented and open - What the data export looks like - Who implements it, and how many hospitals they have done Kōami is built as one connected system across hospital management, workforce, inventory, imaging, fertility and biomedical equipment, which means most of the list above shares one patient identity and one data model rather than being stitched together. That design decision matters more, in practice, than the length of anybody's module list, including ours.

Read article
Hospital Staff Productivity: The Hours Lost Before Anyone Touches a Patient — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 8 min read

Hospital Staff Productivity: The Hours Lost Before Anyone Touches a Patient

Productivity is an uncomfortable word in a hospital, because it sounds like a demand that people work harder. In most hospitals the staff are already working extremely hard. The hours being lost are not lost to slowness. They are lost to coordination: finding things, chasing people, re-entering data that already exists somewhere, and covering for a roster that did not match the day. That distinction changes what you do about it. You cannot fix coordination loss by asking for more effort. ## Where do nursing hours actually go? A substantial share goes to documentation, hunting for supplies and equipment, and communication that exists only because two systems do not talk to each other. Studies of nursing time across health systems consistently find that direct patient care is a minority of the shift. The remainder is documentation, medication administration logistics, handover, coordination calls, and searching. The proportions vary; the shape does not. The searching is the part hospitals underestimate. A nurse who cannot see ward stock on a screen walks to the store. A nurse who does not know whether the pharmacy has dispensed walks to the pharmacy. A nurse who needs the consultant's decision waits for the round because there is no other channel. None of these is visible in any report, and together they are a large number. ## Which of those hours are actually recoverable? Three categories, and they are recoverable by design rather than by discipline. - Duplicate entry. The same observation, order or consumption recorded in a register and again in a system, or in two systems. Every duplicate is pure loss. - Physical search. Walking to find stock, equipment, a chart, a person or a result that could have been on a screen. - Waiting on a handoff. Time spent unable to proceed because another department has not done something and there is no way to see whether they have. What is not recoverable, and should not be targeted, is time spent with patients, time spent thinking, and the handover conversation. Hospitals that squeeze those create a different and worse problem. > If a ward keeps a paper register alongside the system, the register is telling you something the system failed to do. Find out what, before you ban the register. ## How does the roster itself destroy productivity? By staffing to headcount rather than to workload, and by being fragile enough that every absence becomes a scramble. A roster built on the assumption of a fixed number of nurses per ward ignores that thirty beds holding stable post-operative patients and thirty beds holding high-dependency cases are entirely different amounts of work. When the mismatch happens, the ward absorbs it, and absorbing it is what burnout is made of. The fragility is the second half. When someone calls in sick at half past five in the morning, the typical hospital response is a series of phone calls made by whoever is on duty, which consumes the first hour of a senior nurse's shift and frequently ends with an unfilled gap or an inappropriate fill. The mechanics of doing this properly are in [overcoming nursing shortages with dynamic shift allocation](/blog/nursing-shortage) and [letting nurses swap shifts without chaos](/blog/shift-swaps). ## Where do administrative hours go? Into reconciliation between systems, and into month-end. The reconciliation is continuous and invisible: attendance against roster, dispensing against stock, charges against care, claims against documents, consultant activity against payouts. Each of these is somebody's recurring task, and each exists only because two records of the same fact are kept in two places. Month-end concentrates it. Payroll month-end in a hospital with attendance in one system and the roster in a spreadsheet is a week of work that could be a day. The chain that removes it is described in [getting PF, ESI, PT and TDS right](/blog/statutory-payroll). Consultant payouts deserve their own mention, because they are the clearest case of a calculation that requires data from two systems. A share on procedures performed needs the procedure data. If the clinical system and the payroll system are separate, somebody exports, somebody reconciles, and somebody queries the result every month. ## What should a hospital measure? Six numbers, and the first is the one that changes the conversation. - Proportion of nursing time in direct patient care, sampled rather than surveyed - Overtime hours, by ward and by cause - Unfilled shifts and time to fill a gap - Roster changes made after publication - Number of duplicate registers maintained alongside the system, counted honestly - Month-end payroll cycle time Sampling the first is worth doing properly. An observer following a nurse for a shift and timing categories will tell you more about your hospital than any survey, and it will tell you which of the three recoverable categories dominates in your building. ## How Kōami gives the hours back The recoverable losses above are all consequences of separate systems, so the mechanism is a shared record rather than any single feature. [Kōami Workforce](/products/hrms) addresses the roster and the administrative chain: - Rotational rostering with skill and ratio rules, edited on an employee-by-day grid, so a roster reflects who is qualified for what rather than only how many bodies are on the floor. - Shift-swap and on-call handled as approvals inside the system rather than as phone calls, so a gap is filled from a pool of eligible, rested staff. - Geofenced, face-verified mobile check-in, biometric and kiosk options, with regularisation and overtime as workflows rather than as exception forms. - Statutory payroll running from that attendance directly, with PF, ESI, PT and TDS, shift differentials and LOP handled, so month-end is a review rather than a reconstruction. - Credential compliance tracked against the roster, so a lapsed registration is caught when the shift is built rather than at an audit. - Workforce analytics on headcount, overtime, attrition and cost, so the numbers above are produced rather than assembled. [Kōami Hospital](/products/hmis) addresses the ward-level losses: - Nursing charting at the bedside with vitals, intake and output, clinical scores and shift handover in the record, so the observation is written once. - Orders placed from the chart reach pharmacy, the lab and the [imaging worklist](/products/pacs) directly, and status comes back, so a nurse can see whether something has happened rather than walking to find out. - Ward stock and indents run on the same backbone as [Kōami Inventory](/products/inventory), so what the ward holds is on a screen and consumption recorded at administration is also the charge and the stock movement. - Consultant activity recorded in the clinical record is the same data the payout calculation reads, which removes the monthly export entirely. Productivity work in hospitals goes wrong when it starts with people and ends with targets. It goes right when it starts by counting duplicate entry, physical search and blocked handoffs, and then removes them. If you want to see what that would look like in your wards, bring a shift observation to a [demo](/book-demo).

Read article
Clinic and Polyclinic Management Software in India: What a Small Practice Actually Needs — Product | KōamiProduct
Product· 7 min read

Clinic and Polyclinic Management Software in India: What a Small Practice Actually Needs

A ten-doctor polyclinic and a two-hundred-bed hospital are often sold the same software, and the mismatch runs in both directions. Some clinics buy a full hospital system and use eight percent of it, paying for the rest and navigating around it. Others buy an appointment app, discover at the first tax filing or insurance query that it holds nothing they need, and start again. Clinics are not small hospitals. The differences are structural, and knowing them makes the purchase straightforward. ## How is clinic software different from a hospital system? A clinic's work is a sequence of visits. A hospital's work is a stay. Almost everything follows from that. A hospital system is organised around admission, bed, length of stay and a bill assembled over days. It needs ward management, nursing charting, theatre scheduling, inpatient pharmacy and an interim billing model. A clinic needs none of these, and carrying them costs money and clutters every screen. What a clinic needs instead, and needs to be genuinely good, is the outpatient flow: getting patients booked, seen on time, recorded quickly, billed correctly and brought back. The hospital equivalent of that flow is one module among thirty. In a clinic it is the entire business. ## What should clinic management software actually include? Eight things, and only eight for most practices. - Appointments and scheduling. Multi-doctor calendars, online booking, reminders by SMS or WhatsApp, walk-in handling, and a queue display that keeps the waiting area calm. - Patient records. One identity per patient, demographics, history, allergies, and previous visits accessible in seconds rather than searched for. - Consultation and prescription. Fast note capture with speciality templates, a drug database with interaction and allergy checks, and a printed or digital prescription that meets the requirements for a valid prescription. - Billing and receipts. Consultation and procedure charges, packages, discounts with a control on who can give them, GST where applicable, and daily collection reconciliation. - Pharmacy, if you dispense. Stock with batch and expiry, dispensing against the prescription, and the charge on the same bill. - Diagnostics, if you have a lab or imaging on site. Orders, results attached to the visit, and results shared with the patient. - Reports that a practice owner reads. Daily collection, doctor-wise revenue, new against repeat patients, no-show rate, and outstanding. - Compliance basics. Consent records, an audit trail of who saw what, ABHA creation and linkage, and teleconsultation records if you consult remotely. > If a clinic system cannot register a walk-in, get them to the right doctor, record the consultation and print the bill in under three minutes total, nothing else about it matters. ## What do clinics buy that they do not need? Four things, consistently. Inpatient modules. Wards, beds, nursing charting and theatre, licensed because they came in the bundle. Maintenance is paid on all of them. Deep insurance and TPA workflows, in a practice that is ninety-five percent cash. Useful if you take insurance; expensive complexity if you do not. Elaborate role hierarchies designed for a hospital's departmental structure, imposed on a team of twelve people who all know each other. Full financial accounting inside the clinic system. A clean export to whichever accounting package your chartered accountant already uses is almost always the better arrangement. ## What do clinics under-buy? Three things, and each one costs more than the modules they overbought. Patient recall and follow-up. A clinic's economics depend on repeat visits, and most systems treat recall as an afterthought. The ability to define a follow-up interval at the consultation and have it turn into a reminder automatically is worth more than any clinical feature on the list. Online presence and booking. Patients increasingly find a clinic through search and expect to book without ringing. A booking link that is a form which emails somebody is not online booking. A real data export. Small practices change software more often than hospitals do, and the ones that get stuck are the ones whose records live in a system with no export. Ask on day one, not in year four. ## What about polyclinics, day-care centres and chains? They sit between the two, and the questions that matter are multi-site identity, multi-doctor economics and revenue sharing. A polyclinic with visiting consultants has a payout problem before it has a clinical software problem. Each consultant may work on a different arrangement: revenue share on consultations, a different share on procedures, a fixed session fee, or a combination. If the system cannot calculate this from recorded activity, someone does it monthly in a spreadsheet, and consultants query it. A small chain adds the requirement that a patient registered at one branch is recognised at another, that stock can move between sites, and that the owner sees consolidated numbers without three exports. These are not hospital features; they are the specific things that break when a single-site clinic system is used across four locations. Day-care and short-stay centres need a limited version of admission: a patient occupying a chair or bed for hours, with charges accruing, discharged the same day. Confirm the system models this, because clinic software often does not and hospital software often makes it heavy. ## What does clinic software cost in India? Considerably less than hospital software, and the market spans from a few thousand rupees a month to a few tens of thousands for a multi-site practice. Pricing is usually per doctor or per user per month, sometimes with a cap. The variables are the number of doctors, the number of locations, whether pharmacy and diagnostics are included, and whether patient communication by SMS or WhatsApp is bundled or metered. Messaging costs are the item most often left out of the comparison and the one most likely to grow. At this end of the market, the questions that protect you are simple: what is the price at twice our current size, what does data export cost, and is there a contractual minimum term. ## What should a clinic ask in a demo? Time the routine things rather than admiring the unusual ones. - Register a walk-in patient and get them into the right doctor's queue. - Record a consultation using our speciality's template and print the prescription. - Bill it, apply a discount, and print the receipt. - Show me the same patient's previous three visits. - Set a follow-up for six weeks and show me the reminder it will send. - Show me today's collection, split by doctor and payment mode. - Dispense a medicine from our stock against this prescription. - Book an appointment as a patient would, from a phone. - Export all our patient data. If any of the first three takes longer than a minute in the vendor's own hands, it will take longer in yours. ## Where Kōami fits, honestly Kōami is built for hospitals and multi-site healthcare groups, and it is used by clinics that expect to become one of those. That is a real distinction and worth stating plainly. A single-site practice with four doctors, no pharmacy and no plans to expand will be well served by a focused clinic product and will pay less for it. Where Kōami earns its place is the practice that is adding locations, running a pharmacy and diagnostics on site, managing consultant payouts against recorded activity, or moving toward day-care and short-stay work, because those are the points at which clinic software runs out and stitching a second system alongside it begins. Buy for the size you are, with one honest look at the size you intend to be in three years. Those two answers, more than any feature comparison, decide which end of this market you should be shopping in.

Read article
One Platform or Best-of-Breed? The Integration Bill Nobody Puts in the Quote — Interoperability | KōamiInteroperability
Interoperability· 8 min read

One Platform or Best-of-Breed? The Integration Bill Nobody Puts in the Quote

There are two ways to build a hospital's software estate and both have serious people arguing for them. Buy one platform that does everything adequately, or buy the best system in each category and connect them. The debate is old, it is not settled, and it is usually conducted with the wrong evidence. The wrong evidence is feature comparison. Of course the specialist laboratory system has more depth than an HMS lab module; that is what specialisation means. The question was never whether it has more features. The question is what the connections cost, who maintains them, and what happens when one of them silently stops working on a Tuesday afternoon. ## What is the actual difference between the two approaches? An integrated platform shares one data model. A best-of-breed estate shares messages between separate data models. That is the whole thing, and everything else follows from it. In an integrated system, a patient exists once. When they are admitted, every part of the system knows, because there is nothing to tell. A dispense creates a charge because dispensing and charging are operations on the same data. There is no synchronisation because there is nothing to synchronise. In a best-of-breed estate, a patient exists several times, once per system, and the copies are kept in agreement by messages. When the messages flow correctly, the experience is similar. When they do not, the copies diverge, and divergence in healthcare data is not a cosmetic problem. ## Where does best-of-breed genuinely win? Depth in a specialised domain, and negotiating leverage. Some hospital functions are deep enough to sustain a serious independent software industry: laboratory, imaging, cardiology, oncology, pharmacy automation, operating theatre. A dedicated LIS from a vendor who does nothing else will handle analyser interfacing, quality control, reflex testing rules and NABL evidence in ways a general HMS lab module usually will not. If a function is your hospital's primary business, buy the best system for it. A standalone diagnostic chain should own the best LIS it can afford. A dedicated imaging centre should own the best RIS-PACS. The specialisation is the business. The second advantage is commercial. Multiple vendors means no single one owns your entire estate, and renewal conversations are different when the alternative is replacing one system rather than all of them. ## Where does the integrated platform win? Everywhere the data has to cross a boundary, which is most of a hospital's day. The workflows that break in a best-of-breed estate are the boring ones that happen thousands of times a week: - A consumable used in theatre reaching the patient's bill - A discharge that has to wait for pharmacy, lab and billing to agree the patient is done - A lab result that must be visible to a doctor who ordered it from a different system - A consultant payout calculated from procedures recorded elsewhere - A patient's complete record produced for a data request under DPDP - An ABDM care context linkage that requires records from four systems Each of these is solvable with integration. Each of them is also a place where, once a year, somebody discovers that a message queue stopped three days ago. > The cost of best-of-breed is not the interfaces you build. It is that you now own an integration estate, permanently, and integration estates need a named owner or they rot. ## What does integration actually cost? More than the quote, and the shape of the cost is predictable. Every interface has a build cost, which is the part that gets quoted. It also has a test cost, which is larger than expected because the interesting cases are the exceptions: cancelled orders, merged patients, amended results, reversed charges. And it has a permanent operating cost: monitoring, reconciliation, and a person who understands it. Then there is version drift. System A upgrades. The interface to system B was built against the old behaviour. Nobody notices until a report is wrong. Multiply by the number of interfaces and by the number of upgrades per year, and the reason hospitals with many systems employ integration engineers becomes obvious. A rough planning assumption: budget for each interface roughly as an ongoing commitment rather than a one-time project, and count the interfaces before deciding. Six systems fully connected is fifteen possible pairs, which is why serious best-of-breed estates use an integration engine rather than point-to-point links. ## How do you decide for your own hospital? Four questions, in this order. What is your core business? Specialise there, integrate the rest. A multi-speciality hospital's core is the hospital, not the lab. What is your IT capacity? Best-of-breed with no integration owner is not a strategy, it is a deferred failure. If you cannot name the person who will monitor the interfaces, you have answered the question. How many boundaries does your daily workflow cross? Count the cross-system steps in your ten most common workflows. If the count is high, integration is your dominant cost regardless of which systems you pick. What is your migration position? An estate of separate systems can be replaced one at a time, which is genuinely lower risk. A platform is replaced all at once. If you are unsure about a vendor, the modular estate hedges better. ## What if the decision is already made for you? Most hospitals are not choosing from scratch. They have a system, some satellites, and a spreadsheet. The useful move in that situation is not to pick a side but to reduce the number of boundaries where it hurts most. Identify the two or three cross-system workflows that consume the most staff time or leak the most revenue, usually charge capture and discharge, and close those. Consolidating three systems into one for a specific workflow is worth more than a strategy document about platform philosophy. The other useful move is to insist that every new system, whatever it is, arrives with standards-based interfaces: HL7 or FHIR, DICOMweb for imaging, a documented API, and a real data export. A best-of-breed estate built on standards is manageable. One built on private integrations is a trap that took several years to build. ## Where Kōami sits, and where it does not Kōami is the integrated position, deliberately: hospital management, workforce, inventory, imaging, fertility and biomedical equipment on one identity and one data model, because the cross-boundary workflows above are where most hospitals lose time and money. It is also built to be integrated with, not only integrated within, because no hospital estate is ever only one vendor. Standards-based interfaces, documented APIs and a clean export exist for the systems that will stay. If your hospital's core business is a single specialised function, buy the best system for that function and connect it. If your hospital's problem is that six systems each hold a version of the same patient and none of them agree, that is the problem worth solving first, and it is not solved by adding a seventh.

Read article
Free and Open-Source Hospital Management Software: What It Actually Costs — Operations | KōamiOperations
Operations· 7 min read

Free and Open-Source Hospital Management Software: What It Actually Costs

Somewhere in the evaluation of every hospital system, usually late in the process and usually from the finance side, someone asks whether there is a free option. There is. Several, in fact, some of them serious pieces of engineering with hospitals running on them worldwide. The question is worth taking seriously rather than dismissing, because the honest answer is not no. It is that free software has a cost structure rather than no cost, and that structure suits some hospitals very well and others not at all. ## Is there genuinely free hospital management software? Yes. There is mature open-source software in this category, used in real hospitals, and the licence genuinely costs nothing. The established projects have been developed over years, often with support from global health organisations and deployments in resource-constrained settings. There are open-source electronic medical record platforms with substantial clinical depth, open-source laboratory systems, open-source imaging archives that are widely used even inside commercial deployments, and general-purpose ERP systems with healthcare modules. None of this is vapourware, and dismissing it as unserious is a vendor reflex rather than an argument. ## So what does free actually cost? The licence is zero. The deployment is not, and the ongoing operation is where the real number lives. - Hosting and infrastructure. Servers or cloud capacity, redundancy, backups, and someone monitoring them. - Implementation. Configuration, master data, tariffs, forms, roles, and workflow design. Identical work whether the software was free or not. - Localisation. Indian statutory registers, GST-compliant billing, PM-JAY and TPA claim formats, ABDM integration. Most international open-source projects do not include these, and building them is a development project, not a configuration exercise. - Development capacity. Someone who can read the codebase, fix what breaks, and build what is missing. This is a salaried role or a retained agency, permanently. - Upgrades. Community releases are not backwards-compatible with your customisations by default. Every upgrade is a merge exercise. - Support at three in the morning. There is no number to ring. There is a forum. > Free software transfers cost from a licence line to a payroll line. For a hospital with the payroll line already in place, that is a good trade. For one without it, it is not a trade at all. ## Which hospitals does open source genuinely suit? Three kinds, and they have something in common. Institutions with real internal IT capacity. Teaching hospitals, large trusts, government programmes and health networks with a development team already on staff. They can absorb the maintenance burden, and in exchange they get complete control and no per-bed fee across a large estate. Organisations with unusual requirements. Research institutions, public health programmes, and anyone whose workflow is far enough from commercial assumptions that they would be paying for heavy customisation anyway. Deployments where the licence cost is genuinely prohibitive. Low-resource settings and large-scale public deployments where a per-bed subscription across thousands of beds is simply not fundable. What these share is that the marginal cost of maintaining the software is spread across a large deployment or an existing team. Where that is not true, the arithmetic reverses. ## Which hospitals should not choose it? A hospital with no IT department, or one person who also handles the printers. This is the most common Indian case and it deserves plain speaking. A fifty-bed hospital where the systems are looked after by one capable generalist cannot run open-source HMS successfully. Not because the software is bad, but because the operating model assumes engineering capacity that the hospital does not have and would find expensive to acquire. The failure mode is predictable and slow. The system goes in with enthusiasm and an implementation partner. The partner's engagement ends. Something breaks during an upgrade. The one person who understood the deployment takes another job. Two years later the hospital is running an unpatched version nobody dares touch, with a security exposure it cannot assess and a data set it cannot easily move. That is a worse outcome than any subscription. ## What about the middle path? There are two, and both are more common than pure open source in Indian hospitals. Commercially supported open source. A vendor takes an open-source core, localises it, hosts it and supports it, for a fee. You get the open licence and an escape route, plus somebody to ring. The fee is real and often comparable to commercial software, but the exit position is better because the core is not proprietary. Open components inside a commercial system. This is quietly the most common arrangement in healthcare software of any kind. Open-source DICOM libraries, terminology services, database engines and interface tooling sit inside commercial products everywhere. It is a reason to ask about licences and dependencies, not a reason to worry. ## What questions settle the decision? Five, answered honestly rather than aspirationally. - Who, by name, will maintain this in eighteen months? If the answer is a role that does not currently exist, the answer is nobody. - What will it cost to build Indian statutory compliance, and who owns it when the regulations change? - What is the upgrade path, and who does the merge? - What happens at three in the morning during a go-live weekend? - If this fails, what is the exit? Which is the one question where open source usually answers best, because the data model is documented and yours. ## What does this mean for how you evaluate commercial vendors? Use the open-source option as a measuring stick rather than as a threat. The genuine advantages of open source, which are control, transparency and no lock-in, are things you can demand from a commercial vendor in contract form. Ask for a documented data model. Ask for standards-based APIs rather than a private integration. Ask what a complete data export looks like, in what format, at what cost, on what timeline. Ask what happens to your data if the vendor is acquired or ceases trading, and whether source escrow is available. A commercial vendor who answers those well has given you most of what open source offers, with a support contract attached. One who deflects has told you exactly why the open-source question was worth asking. Kōami is commercial software, and we would rather be chosen for the reasons above than because the alternative was dismissed. If your hospital has real engineering capacity and unusual requirements, open source may well be the better answer for you. If it does not, the honest comparison is not free against paid. It is paid against paid, with one of the payments hidden in a job description that has not been written yet.

Read article
Switching Hospital Management Software Without Losing a Day of Billing — Operations | KōamiOperations
Operations· 8 min read

Switching Hospital Management Software Without Losing a Day of Billing

Hospitals stay on software they dislike for years, and the reason is almost never that they cannot find a better one. It is that the current system holds twelve years of patient records, every outstanding balance, the stock on hand, and forty admitted patients, and nobody can see how to move all of that without the hospital stopping. The hospital cannot stop. That constraint is real and it is the whole design problem. But it is a solved design problem, and the hospitals that switch badly usually did so by treating a migration as an installation. ## When is switching actually worth it? When the current system is costing you more than the switch will, and you can name the cost. Dissatisfaction is not a business case. These are: - Revenue leakage you can measure. Charges not captured, claims rejected for reasons the system should prevent, consumables consumed and not billed. - Compliance exposure. The system cannot produce audit trails, statutory registers, or the ABDM and DPDP behaviour now expected of it, and the vendor has no dated plan. - Staff time spent on workarounds. Count the hours in registers, spreadsheets and re-keying. In most hospitals this is the largest number and the least measured. - Vendor risk. The product is no longer developed, support has degraded, or the people who knew your deployment have left. - Growth you cannot serve. A new branch, a new speciality, or a bed count the system was never designed for. If none of these apply and the complaint is that the interface looks dated, the switch will probably cost more than it returns. Interfaces are the most visible thing about software and among the least consequential. ## What actually has to move? Six data sets, and they have very different difficulty levels. - Patient master. Every patient identity, deduplicated. This is the foundation and the one most worth spending time on. - Financial position. Outstanding balances, advances held, credit notes, and unbilled charges on current admissions. This must be exact; there is no acceptable rounding. - Clinical history. Consultations, diagnoses, results, prescriptions, discharge summaries. Usually the largest volume and the most variable in structure. - Stock. Current holdings by store and batch, with expiry, plus open purchase orders. - Masters and configuration. Tariffs, packages, rate contracts, doctors, departments, users and roles. Rarely migrated; usually rebuilt, and rebuilding is often the right call. - Open transactions. Admitted patients, pending orders, undelivered lab results, unclosed claims. The hardest category, because it is live at the moment of cutover. > The clinical history can arrive over the following month. The financial position and the admitted patients cannot. Design the cutover around the second group. ## How do you handle the patients who are admitted on cutover day? You bring them across as open admissions, with their charges to date, and you accept that the discharge bill is assembled from two sources. There are three workable patterns and the right one depends on your admission volume. Full migration of open cases. Every admitted patient is created in the new system with their admission date, bed, and accrued charges. Clean afterwards, expensive on the night, and requires the old system to produce an accurate charge position at a frozen point in time. Run-out. New admissions go into the new system from cutover; existing admissions are discharged from the old one. Both systems run for a period equal to your longest length of stay. Simplest technically, and it means two systems, two counters and a confused front office for two or three weeks. Hybrid, which is what most hospitals end up doing. Long-stay and critical care patients run out in the old system; everything else migrates. Requires a clear rule agreed in advance and a person on each ward who knows which patients are in which system. Whichever you choose, decide it early. This is the single decision that most affects how the cutover feels to staff. ## What does the timeline look like? For a mid-sized hospital, three to six months from contract to cutover, and the data work starts far earlier than most people expect. A workable sequence: Weeks one to three: data audit. Extract everything from the old system and look at it honestly. Duplicate patients, blank fields, free-text where codes should be, balances that do not reconcile. Every migration is delayed by the discovery that the source data was worse than assumed, so make the discovery first. Weeks two to eight: configuration in parallel. Tariffs, packages, departments, roles, document templates, and the workflow decisions. This is where the new system is actually built, and it is the work most often underestimated. Weeks six to ten: data cleanup at source. Merge duplicates, close what should be closed, reconcile balances. Doing this in the old system rather than during migration is much cheaper. Weeks eight to fourteen: trial migrations. At least three. Each one produces a reconciliation report, and the report has to balance before you go further. Weeks twelve to sixteen: parallel run and training. Selected departments enter data in both systems for a defined period, and every difference is investigated. Cutover: a low-volume window, usually a weekend, with the final delta migration, a reconciliation sign-off, and both systems available in read-only for a defined period afterwards. ## What goes wrong, and how is it prevented? Five failures account for most bad migrations. Migrating dirty data because cleaning it felt like a delay. The mess arrives intact and is more expensive to fix live. No reconciliation gate. Every trial migration must produce a report that ties: patient counts, total outstanding, stock value, by department. If it does not tie, you do not proceed. Hospitals that skip this discover the gap during the first month-end close. Losing read access to the old system. Negotiate continued read-only access, in writing, before you sign with the new vendor. You will need it for at least a year for queries, disputes and audits, and once the relationship has ended the price of access goes up. Training as an event. Staff trained six weeks before cutover have forgotten. Train close to go-live, train by role rather than by module, and plan refresher sessions for the second and fourth weeks when the real questions appear. Nobody owning the decisions. A migration generates a hundred small judgement calls a week. Without a named internal owner with authority, they queue. ## What should the contract say? Four clauses that are much easier to negotiate before you sign than after. Migration scope and responsibility, stated in data sets, with the new vendor's obligations and yours written separately. "Data migration included" is not a scope. Reconciliation criteria and a sign-off gate, with an agreed definition of what a successful migration looks like numerically. Rollback. What happens if the cutover fails at two in the morning, who decides, and how the hospital operates the next day. Exit. The one you are exercising against your current vendor is the one you will one day exercise against the new one. Ask for the export format and cost in writing now, while you have leverage. ## The part nobody plans for The month after go-live is harder than the cutover, and it is the part that determines whether staff conclude the switch was worth it. Expect billing queries, reports that do not match the old ones because the old ones were calculated differently, and a fortnight of slower throughput at the counters. Staff the first month deliberately: extra hands at billing and registration, a visible support presence on the floor, and a daily issues meeting at a fixed time that ends when the list is empty. Kōami's implementations follow the sequence above, with reconciliation gates and read-only access to the outgoing system as standing requirements rather than negotiable extras. That is not a differentiator so much as the minimum any hospital should demand from any vendor it is considering, including the one it already has.

Read article
AI in Hospital Management Software: What Is Real in 2026 and What Is Still a Demo — Clinical AI | KōamiClinical AI
Clinical AI· 8 min read

AI in Hospital Management Software: What Is Real in 2026 and What Is Still a Demo

Every hospital software proposal in 2026 contains the word AI, usually on the cover. Some of what it describes is genuinely working in Indian hospitals today and paying for itself. Some of it works in a controlled demonstration and falls over on real data. And some of it is a feature that existed for a decade being renamed. Sorting the three is not hard, but it does require asking a specific question of each claim: what does this do when it is wrong, and how would we know? ## What AI features are genuinely working in hospitals today? Five, in roughly descending order of how reliably they deliver. Ambient documentation. A microphone in the consultation room, a transcript, and a structured note the clinician edits and signs. This is the clearest win available right now, because the task is language, the output is reviewed before it counts, and the time saved is directly measurable in minutes per consultation. Accuracy on Indian English, code-switching between languages, and drug names is the thing to test, not the demo video. Imaging triage and second read. Algorithms that flag likely abnormalities on chest radiographs, CT head studies and screening mammography, reordering the worklist so urgent studies are read first. Several such tools have regulatory clearances and real deployments. They work as a second reader and a prioritiser, not as a replacement. Coding and claim assistance. Suggesting diagnosis and procedure codes from the clinical note, and flagging claims likely to be rejected before submission. Unglamorous, easy to measure, and one of the fastest payback items in the list. Deterioration and early warning scores. Models that watch vitals and lab trends and raise a flag before a patient crashes. These genuinely help, and they genuinely produce false alarms. The deployment succeeds or fails on the escalation protocol, not on the model. Operational forecasting. Bed occupancy, OPD volume, theatre utilisation and stock demand. Mature, uncontroversial, and the least likely to be called AI on a brochure because it looks like statistics. ## What is still mostly a demo? Three categories, and each fails in a way worth understanding. Autonomous clinical decision-making. Systems that propose diagnoses or treatment without a clinician in the loop. The technology is impressive and the accountability structure does not exist. Every serious deployment keeps a human decision-maker, and the ones that do not are not being run in a hospital. Conversational interfaces to the whole record. Asking the system a free-form question about a patient and trusting the answer. Genuinely useful for summarising and searching, genuinely unreliable when it needs to be complete. The failure mode is confident omission, which is the worst possible failure mode in a clinical record. Fully automated revenue cycle. Claims from note to payment with no human review. Works on the clean majority, and the clean majority was never the problem. > The useful question about any AI feature is not how accurate it is. It is what happens when it is wrong, who notices, and how fast. ## How should a hospital evaluate an AI claim in a proposal? Six questions, and vague answers to any of them are informative. - What exactly is the model doing, in one sentence, without the word AI? - What data was it trained on, and does that population resemble ours? - Is it regulated as a medical device anywhere, and what is its status here? - What is its performance on our kind of case mix, and can we test it on our data before committing? - Where does the data go? If inference happens outside the hospital, that is a data protection question with DPDP consequences. - Who is accountable for a decision influenced by the output, and what does the audit trail record? The last one is where most conversations end abruptly. If a model contributed to a clinical decision, the record should show that it did, what it said, and who acted on it. A system that cannot show this has not been designed for use in a hospital. ## What governance does an Indian hospital need before deploying AI? A named owner, an inventory, a review cycle and a documented escalation path. None of it is exotic and all of it is missing in most deployments. Practically, this means the hospital knows which AI tools are in use and where, each has a clinical owner who is accountable for it, each has a defined performance review at a stated interval, and each has a rule for what staff do when they disagree with it. Add the data protection position: what data leaves the hospital, under what consent, to whom, and where it is stored. This is also the point where the DPDP framework and NABH expectations converge. Consent for processing, purpose limitation, access logging and the ability to explain what happened to a patient's data are obligations regardless of whether a model is involved, and models make them harder to satisfy, not easier. ## Does AI change how hospital software should be built? Yes, in one specific way: it raises the value of structured data enormously. Every AI capability in the working list above depends on data that can be read by a machine. Coded diagnoses, structured orders, results as values, medication records with actual administration times. A hospital whose clinical record is free text in a rich editor cannot use most of this, and no amount of model quality compensates. This is the most practical AI-related decision a hospital will make, and it happens years before any model is bought. Choosing a system that captures structured data, and configuring it so staff actually produce structured data rather than pasting paragraphs into a notes field, is what makes the later options possible. The second implication is API access. AI tools change faster than hospital systems do, and the ones you will want in three years do not exist yet. A platform with documented, standards-based interfaces can adopt them. A closed one cannot, whatever its own roadmap promises. ## What changed when everyone started saying "agents"? The word moved from describing a model that produces an output to describing software that plans a sequence of steps and executes them against real systems without a person confirming each one. That is a genuine distinction, and it is the one to hold on to while reading any 2026 proposal. Most of what is sold as agentic is still assemble-and-approve: the software gathers a denial pack, drafts a summary, proposes a theatre list, and a human commits it. That is valuable and it is not autonomy. Actual autonomy — an action written to the hospital's records with no human in the loop — is a much smaller set, and hospitals have quietly run some of it for years in the form of auto-reorder rules and auto-posting. So the governance question is not whether to allow agents. It is which action classes may be delegated, under whose named authority, logged how, and reversible by whom. [Agentic AI in hospital operations](/blog/agentic-ai-hospital-operations) works through the permitted and forbidden lists and how to run a pilot that produces a decision rather than an anecdote. One market observation worth carrying into a vendor meeting: ambient documentation is the one healthcare AI use case with essentially universal adoption activity, while autonomous clinical action remains rare in production anywhere. If a proposal reverses that ordering — light on documentation, heavy on autonomous decisions — it is describing a roadmap, not a product. ## How should a hospital start? With one use case, measured, in a department that wants it. Pick something with a clear metric and a low blast radius. Ambient documentation in one outpatient department, measured in consultation minutes and clinician satisfaction. Claim rejection prediction, measured in first-pass rate. Imaging triage, measured in time to report for urgent studies. Run it for a defined period against a defined question, keep the human decision first, record the disagreements, and be willing to conclude that it did not help. The hospitals that get value from AI are not the ones that bought the most of it. They are the ones that measured. Kōami's position is that AI belongs inside the workflow rather than beside it, and that the platform's job is to make the data structured, the access governed and the audit trail complete, so that whatever tools a hospital chooses can be adopted and, when necessary, removed. The model is not the hard part. The record it reads from, and the accountability around what it says, is.

Read article
Opening an IVF Centre: The Systems Checklist — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 7 min read

Opening an IVF Centre: The Systems Checklist

The clinical plan for a new fertility centre is usually excellent. There is a consultant with a following, an embryologist being recruited, a quotation for incubators and a workstation, and a lease on a floor with the right air handling. What is almost never in the plan, at the point the money is committed, is how the centre will record what it does — and that decision gets made eight weeks before opening, under time pressure, by whoever is least busy. It is a strange omission, because the record is the one part of a fertility centre that regulators, patients and your own future self will all interrogate. ## What has to be in place before the first cycle? Registration under the ART legislation, the physical and staffing standards that go with it, and a record system capable of producing what the law asks for. The clinical and regulatory prerequisites are the obvious half: - Registration of the clinic, and of the bank if you are operating one, at the level of service you intend to provide. - Premises and equipment meeting the prescribed standards, including the lab environment. - Qualified staff in the roles the rules specify, with their credentials documented. - Consent forms in the prescribed formats. - A relationship with a registered ART bank if you will use donor gametes. Work from the Act, the rules and your state authority's requirements directly. What follows is the half that gets forgotten. ## The four identifiers, decided on day one A fertility centre needs to identify four things, and retrofitting the fourth is painful. - The patient: one person, one permanent record. - The couple: both partners linked as a treatment party without their individual records being merged. - The cycle: every IUI, IVF, ICSI, frozen transfer, donor or preservation attempt, with its own identity and outcome. - The specimen: every semen sample, oocyte, embryo, biopsy and straw. The first three exist in most systems in some form. The fourth is what makes witnessing, cryostorage traceability and any future lineage question possible, and a centre that opens without it will be adding it later, with material already in the tanks and cycles already completed. > Everything expensive to fix later comes from the same source: a record designed around the bill instead of around the cycle and the specimen. ## Consent, before the first patient rather than after the first problem Consent has to be versioned and it has to gate procedures, and both are cheap to build at the start. Versioned means the exact text a couple signed is stored as a snapshot, not as a pointer to a document that will be revised next year. Gating means the system refuses to record a procedure whose consent is missing or withdrawn, and says why. Withdrawal has to be modelled, because it happens and because it has immediate consequences for stored material. A new centre has the advantage here. There is no backlog of scanned forms in inconsistent formats and no legacy vocabulary to reconcile. Getting this right on day one costs a configuration decision; getting it right in year three costs a migration and a legal review. ## The cryobank you have not filled yet Structured storage addresses and an insert-only movement log are trivial to adopt when there is nothing in the tanks, and expensive once there is. Decide now that location is tank, canister, cane and goblet rather than three free-text fields, that every straw has a permanent identifier, and that moving material is recorded as a new event rather than by editing the old one. Add the consent linkage, the storage term, the renewal reminder and the disposition instruction while the table is empty. Also decide the unglamorous operational half: who monitors nitrogen, how alarms are acknowledged and recorded, what the escalation is at two in the morning, and what happens on the day a tank has to be evacuated. Cryostorage incidents are overwhelmingly equipment failures, and they give warning in consumption data that nobody was reviewing. ## What to record from cycle one, because you cannot recreate it A centre that records outcomes properly from the beginning can report honestly in year two. One that does not will spend year two reconstructing. The minimum set is small and non-negotiable: cycle type and protocol, age at treatment, oocytes retrieved and mature, fertilisation, embryo development and grading, what was transferred and what was frozen, and the outcome through to birth including multiples. Each with a denominator you defined in advance and wrote down. The tempting shortcut is free text, because at fifteen cycles a month it feels sufficient and it is faster at the bench. It is also the decision that makes your first registry submission a manual reconstruction and your first honest look at your own results impossible. ## The systems checklist - Patient, couple, cycle and specimen identifiers, all four, from the first registration. - Cycle types configured so an IUI cycle does not expose embryo transfer fields. - Versioned consent that blocks the procedure it covers. - Pre-cycle readiness check enforced where records are written, not only in the interface. - Structured embryology grading, not notes. - Witnessing as an authenticated event with an immutable record, including at transfer. - Structured cryo addresses with an insert-only movement log, and a witness on freeze, thaw, transport and discard. - Per-sac and per-baby outcome, because twins are common in ART. - Registry fields captured as fields, so the annual return is an export. - Donor identity in an access-controlled compartment, with linkage still provable. - Billing that understands cycle packages, since a cycle is not an admission. - Backups that have been restored at least once, with the time written down. ## The one thing worth spending on early Of everything on that list, specimen identity and witnessing are the items to insist on before opening. They are the hardest to add later, they are what an inspection and an incident both turn on, and they are the difference between a centre that can explain what happened and one that can only apologise. Everything else on the list can be improved incrementally. Those two are foundations, and foundations are poured before the building goes up.

Read article
AI Embryo Grading: What It Can and Cannot Tell You — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 6 min read

AI Embryo Grading: What It Can and Cannot Tell You

Two embryologists grade the same blastocyst. One calls it 4AA, the other 4AB. Both are experienced, both are looking at the same image, and both are right in the sense that the grading scheme they are applying has a subjective component that training reduces but does not remove. Multiply that across a lab, across a year, and the grading data a clinic uses to make transfer decisions and to measure itself carries a variability nobody quite quantifies. This is the honest case for algorithmic grading, and it is a better case than the one usually made. ## What does AI embryo grading actually do? It scores embryo images or time-lapse video against patterns learnt from historical embryos whose outcomes are known, and returns a ranking or a probability. What it produces is a consistent number. The same embryo, assessed twice, gets the same score, which is not true of human assessment. Depending on the system it may work from a single static image at a defined time point, or from continuous time-lapse imaging that captures the timing of divisions — information a human observer cannot see without watching continuously. What it does not produce is a new kind of knowledge. It is learning correlations between appearance and outcome in the data it was trained on, which means its usefulness is bounded by how much appearance predicts outcome in the first place, and by how much its training population resembles yours. ## What it is genuinely good at Consistency and ranking, which happen to be what the transfer decision needs most. - Deselection. Identifying embryos unlikely to be viable is easier than identifying which one will implant, and it is clinically useful on its own. - Ranking within a cohort. When a couple has six blastocysts, the practical question is which to transfer first, and a consistent ordering is worth having. - Standardising the record. A score that does not drift with who was on shift makes the lab's own data usable for the first time. - Surfacing timing. Time-lapse systems capture division timings that correlate with development and that nobody was recording before. That last point deserves emphasis. A clinic that adopts algorithmic scoring often finds the largest immediate benefit is not the score at all. It is that grading finally became structured data, so fertilisation rates, blastocyst conversion and implantation per grade can be computed without a manual audit. ## What it cannot tell you It cannot tell you an embryo is chromosomally normal, and it cannot tell you a transfer will succeed. The first is the misunderstanding that causes real harm in a consultation room. Morphology and ploidy are related but not equivalent. A high-scoring embryo can be aneuploid and a lower-scoring one euploid. Any system presented as a substitute for genetic testing is being oversold, and the counselling implication is direct: a patient told their embryo scored well may hear a promise that was not made. The second is a matter of what implantation depends on. Endometrial receptivity, the transfer itself, and factors nobody has characterised all sit between a good embryo and a pregnancy. A model scoring the embryo is scoring one input to a multi-factor outcome. > A grading model ranks embryos. It does not predict babies, and a clinic that lets the distinction blur in its counselling will regret it. ## The questions to ask a vendor Most of the difference between systems is in the answers to five questions, and none of them is about the headline accuracy figure. - What population was it trained on, in terms of age distribution, clinic geography and time period? A model built on a different population may transfer poorly to yours. - What is the outcome label? Implantation, clinical pregnancy and live birth are different targets, and a model trained on one should not be described using another. - Has it been validated prospectively, and independently of the developer? - What exactly does the score mean? A number between one and ten is not a probability unless the vendor says it is and shows the calibration. - How does it handle images it has not seen the like of before? A model that returns a confident score for an out-of-distribution image is more dangerous than one that declines. Ask also, plainly, whether the vendor considers it a medical device and what regulatory position it holds. The answer tells you something about the vendor regardless of what it is. ## How to introduce it without disrupting the lab Run it alongside human grading before it influences anything, and keep the embryologist's assessment first. The pattern that preserves clinical judgement is the same one that works for AI elsewhere in medicine: the embryologist grades, records their grade, and then sees the score. That order matters. Reversed, the human grade quietly becomes an endorsement of the machine's, and within a few months the lab has lost the independent assessment it would need to detect a problem. Record both. The disagreements are the most valuable data the deployment produces — they show where the model diverges from your lab's practice, and over enough cycles, with outcomes attached, they show which of the two was closer. Set a review point before you start, with a defined question: after this many cycles, does the score add information beyond our own grading in our own patients. Then answer it honestly, including the possibility that the answer is no. ## What it means for the patient conversation Consistency is easier to explain than a black box, and patients ask better questions than clinics expect. Be able to say what the tool does, that it assists the embryologist rather than replacing them, that a score is a ranking and not a guarantee, and that it does not assess chromosomes. Where a score influenced which embryo was transferred, that is worth being able to explain afterwards, particularly if the cycle fails. Algorithmic grading is a genuine improvement to a genuinely subjective task. It earns its place by making the lab's assessments consistent and its data countable — not by knowing something about an embryo that nobody else does.

Read article
ABDM Milestones M1, M2 and M3: What Certification Actually Requires — Interoperability | KōamiInteroperability
Interoperability· 8 min read

ABDM Milestones M1, M2 and M3: What Certification Actually Requires

A hospital IT head gets an email from a state health authority mentioning ABDM compliance, forwards it to the software vendor, and gets back a reply saying the product is ABDM certified. Everyone relaxes. Six weeks later the empanelment paperwork asks for the facility's HFR ID and a demonstration that records are actually being linked, and it turns out that certified software and a compliant facility are two different things, only one of which anybody has. The distinction is the single most useful thing to understand about ABDM, so it is worth starting there. ## What does ABDM certification actually certify? Certification applies to the software, not to your hospital. A vendor takes their product through the National Health Authority's sandbox, demonstrates that it correctly implements a set of APIs, and exits with certification for that product. That certification is theirs, once, and it covers every hospital that uses the product. Your facility then has to do its own part: register in the Health Facility Registry, get an HFR ID, register your clinicians in the Healthcare Professionals Registry, and configure the certified software to act on your behalf. The vendor cannot do that for you, and their certificate does not substitute for it. So the correct question to a vendor is not "are you ABDM certified" but "which milestones is your certification for, and what do we have to do at our end". ## What are the ABDM milestones? The milestones describe increasing levels of participation, and each builds on the one before it. - Milestone 1: ABHA creation and verification. Your registration counter can create an ABHA number for a patient who does not have one, and verify an existing one. This is the entry point and the easiest to reach. - Milestone 2: linking records. Clinical records created in your system are linked to the patient's ABHA as care contexts, so the patient can see that a record exists at your facility and can share it. This is where a hospital becomes a Health Information Provider. - Milestone 3: exchange. Your system can request records from other facilities, with the patient's consent, and display them to a clinician. This is where you become a Health Information User, and it is where the clinical value finally shows up. Treat the exact milestone definitions and any further levels as things to verify against the current NHA documentation rather than against a vendor's slide, because the programme has evolved since it launched and will continue to. ## Why milestone 1 alone is not worth much Creating ABHA numbers without linking records is data entry with no payoff. It is easy to reach, so it is where most implementations stop, and it produces a hospital that has generated thousands of ABHA numbers and shared nothing. The patient sees no records. Other facilities see nothing. The clinical benefit that justified the work never arrives. Linking is the milestone that changes anything, and it is harder for a reason worth understanding: it forces the question of what counts as a record. A care context has to point at something real and retrievable. If your discharge summaries are unindexed scans on a shared drive, there is nothing coherent to link. > Milestone 1 tests your registration counter. Milestone 2 tests whether your records are actually records. ## What consent means here, and why it is not a checkbox ABDM consent is a scoped, time-bound, revocable artefact managed outside your system, not a signature you collect once. A patient grants consent for a specific purpose, for a defined set of record types, for a defined period, through a consent manager. Your system receives the granted consent and must honour its boundaries: only the record types covered, only within the window, and only for the stated purpose. When consent expires or is revoked, access ends. This is unlike anything in a traditional hospital system, where access is governed by staff roles and nothing else. It means your software has to hold a concept it probably did not have before, and it means the audit trail has to record not just who accessed a record but under which consent. ## What has to be true inside your hospital before any of this works Most ABDM projects stall on data quality rather than on APIs, and the failures are predictable. - One patient, one identity. If a returning patient gets registered afresh because searching was slow, you have two records and only one of them will carry the ABHA link. Duplicate management is a prerequisite, not a follow-up task. - Records that exist as records. A care context should resolve to a retrievable document. Scans in a folder named by date do not qualify. - Structured data where the standard expects it. Exchange uses FHIR resources, and a diagnosis recorded as free text cannot become a coded condition without somebody making a judgement call. - Mobile numbers captured accurately. ABHA creation and consent both depend on reaching the patient. A counter that types the number wrong once has broken the chain. - Clinicians registered in HPR, because records need an author with a verifiable identity. None of this is ABDM-specific work. It is the same data hygiene that makes a hospital system worth having. ABDM simply makes the absence of it visible outside your building. ## What it takes at the counter The part everyone underestimates is the twenty seconds at registration. Creating an ABHA takes a patient interaction: an identifier, a mobile number, an OTP, a moment of explanation. At a counter with a queue of forty on a Monday morning, twenty seconds is not free, and the clerk will skip it if skipping is possible. What works is making it the default path rather than an extra step, capturing existing ABHA numbers when patients already have them, and giving the counter a script for the question patients actually ask, which is some version of what this is and whether it is compulsory. What does not work is a target on a dashboard and no change to the workflow. ## Is there any money in it? Yes, and hospitals routinely budget ABDM work as pure cost because nobody tells them otherwise. The National Health Authority's [Digital Health Incentive Scheme](/blog/digital-health-incentive-scheme) pays eligible facilities for health records created and linked to a patient's ABHA, accruing on transaction volume above a baseline derived from bed count. The eligibility gate runs through the Health Facility Registry, so the [HFR registration](/blog/hfr-hpr-registration) step is a prerequisite rather than a parallel task. The rates and the ceiling have been revised across the scheme's extensions, so model conservatively from the current NHA circular rather than from a vendor slide. The reason to know this before procurement rather than after is that it changes what belongs in the contract. If linked-record volume earns, then the hospital needs to see its own linked-record volume — by day, by type, and with failure reasons — without asking the vendor for a report. That is a requirement worth writing down while you still have negotiating leverage. ## What is the format underneath the milestones? FHIR R4, constrained by the ABDM implementation guide that NRCeS maintains, and the version your vendor builds against is a fair question to ask. Certification tests conformance at a point in time against a published guide version. That guide moves. A vendor who can name the version they conform to today and describe how they track new ones is telling you something a certificate cannot. The [FHIR article](/blog/hl7-fhir-india) covers how to test the claim without reading anyone's code — ask for one real de-identified bundle and read the Condition and Observation resources. ## A sequence that does not stall - Register the facility in HFR and get the ID. Nothing else is possible first. - Register clinicians in HPR, starting with the ones who sign records. - Confirm with your vendor which milestones their certification covers and what configuration you need. Get it in writing. - Fix duplicate patient identity before turning on linking, not after. - Reach milestone 1 at one counter, not all of them, and watch what it does to the queue. - Move to linking as soon as ABHA creation is routine, because that is where the value is. - Only then plan for consent-based retrieval, and decide in advance where a fetched record will be shown to a clinician and who is allowed to fetch it. The hospitals that find ABDM painful are usually the ones that treated it as a compliance box to be ticked by the vendor. The ones that find it manageable treated it as the identity and records project it actually is, and got a cleaner patient master out of it either way.

Read article
The Blood Bank Is a Licensed Establishment, Not a Module — Operations | KōamiOperations
Operations· 6 min read

The Blood Bank Is a Licensed Establishment, Not a Module

Most hospital software treats the blood bank as a stores problem with unusual units. Items come in, items go out, keep track of expiry. It is an understandable model and it is wrong in a way that only shows up under inspection, or on the night a transfusion reaction has to be traced back through three donations. A blood centre is a separately licensed establishment operating under drug law. The unit of stock is a human donation, and the record has to survive scrutiny years later. ## What makes a blood bank different from any other inventory? Every unit has an origin that must remain traceable to a named donor, and every unit is released only after tests that are legally mandated. That produces requirements ordinary inventory never has: - A donor record, with eligibility screening at each donation and a deferral history that must be honoured at the next visit. - Mandatory transmissible-infection testing before any unit is released, with results recorded against the specific unit. - Component separation, where one donation becomes several products with different shelf lives and storage conditions. - Cold chain that is monitored and recorded, not assumed. - Traceability that runs in both directions: from donor to every recipient of every component, and from a recipient back to the donation. - Retention of records for the period the rules specify, long after the unit itself is gone. An inventory module that models units as fungible stock cannot express most of that. ## Where the licensing sits Blood centres operate under the Drugs and Cosmetics Act and its rules, with separate licences for whole blood and for component preparation, and with defined requirements for premises, equipment and technical staff. The practical consequence for software is that the licence conditions describe records the establishment must maintain, and an inspection tests whether those records exist and agree with each other. Registers that agree with each other are exactly what software should be good at and what parallel paper systems are bad at. Apheresis, component preparation and storage centres each carry their own conditions. Verify what your establishment is licensed for against the current rules and your own licence, rather than assuming a general answer applies. ## The donor is a longitudinal record, not a form Treating each donation as an isolated event is the design error that causes the most trouble later. A donor has a history: previous donations with dates, which matters because minimum intervals apply; deferrals, temporary or permanent, with the reason; adverse reactions during donation; and test results from previous visits. When the same person returns eight months later, the system should recognise them and apply what it already knows, rather than starting a blank form. This matters most for deferrals. A permanent deferral recorded on paper in a register at one desk, in an establishment where the donor can present at a camp instead, is a deferral that will not be honoured. The registry has to be one registry. ## Testing, release and the quarantine that must be enforced No unit should be issuable before its mandatory tests are complete and recorded, and that has to be enforced by the system rather than by convention. The pattern to build is a quarantine state that is the default: a unit enters quarantine on collection, testing results attach to the unit, and release requires a complete and negative set plus an authorised person's sign-off. Anything not released cannot be crossmatched or issued, and the block is at the point of issue, not a warning on a screen somebody can dismiss. Where a test is reactive, the workflow branches into discard and donor notification, and both need recording — the notification especially, because informing a donor of a reactive result is a clinical and ethical obligation, and evidence that it was done is part of the record. > The most dangerous unit in a blood bank is one that is physically in the fridge and administratively in limbo. Software's job is to make sure the fridge and the record agree on which units exist. ## Crossmatch to bedside, which is where identity fails Transfusion errors are overwhelmingly identity errors, and they happen at the two ends: sample collection and administration. The sample drawn for grouping and crossmatch has to be provably from the patient it is labelled for, which argues for labelling at the bedside from the patient's own wristband rather than from pre-printed labels carried to the ward. The unit issued has to be provably matched to the patient at the moment of administration, which is where a second check by a second person, or a scan of both wristband and unit, does the work. Everything in between — the crossmatch itself, the issue register, the transport — matters, but the two identity checks at the ends are where the catastrophic errors are prevented. The transfusion event itself belongs in the patient's clinical record: which unit, at what time, given by whom, with observations during and after, and any reaction. A blood bank register that records issue but not administration cannot answer what happened to a unit after it left the counter. ## Reactions and traceability, both directions When a transfusion reaction is reported, the system has to answer two questions quickly, and it should answer them without anyone opening a register. The first is what this patient received: every unit, its donation, its components, its test results. The second is the reverse lookup — this donation produced these components, which went to these patients, so who else needs to be considered. That second query is the one paper systems cannot do in useful time, and it is the one that matters when a look-back is triggered. Build the reaction workflow as a first-class record: reported by whom, clinical features, samples sent, investigation findings, conclusion, and any action on the donor. It is a reportable event, and the investigation is a record in its own right. ## What to check in your current system - Can you produce, in one query, every recipient of every component of a given donation? - Can a unit be issued before its test results are complete? Try it. - Does a permanent deferral recorded at a camp block that donor at the main centre? - Is the transfusion administration recorded in the patient's chart, or only the issue in the bank's register? - Are storage temperatures logged automatically, with alarms and acknowledgements recorded? - Does the discard record say why, and who authorised it? - Can you reconcile physical stock in a refrigerator against the system, and has anyone done it recently? A blood bank that answers those cleanly is running a licensed establishment. One that cannot is running an inventory module with red bags in it, and the difference becomes apparent at the worst possible moment.

Read article
HFR and HPR Registration: The Step Before Everything Else — Interoperability | KōamiInteroperability
Interoperability· 6 min read

HFR and HPR Registration: The Step Before Everything Else

A nursing home in a district town gets told it needs to be on the Health Facility Registry before its empanelment renewal goes through. The administrator opens the portal, gets as far as the facility type dropdown, and stops, because the options do not obviously describe a twelve-bed establishment that does deliveries and minor surgery and has a pharmacy at the front. The application sits half-finished for three weeks. This is the commonest way HFR registration fails. Not a technical barrier, just a form asking questions nobody has decided the answer to. ## What is HFR, and what is HPR? HFR is the national register of health facilities. HPR is the national register of health professionals. - The Health Facility Registry lists hospitals, clinics, labs, pharmacies and diagnostic centres, public and private, each with a unique facility ID. - The Healthcare Professionals Registry lists doctors, nurses and other practitioners with verified credentials, each with a unique identifier. Together they answer the two questions any health information exchange has to answer before it can move a record: which facility is this, and who is the person who wrote it. Everything else in ABDM sits on top of them. ## Why registration comes before anything else Without an HFR ID your facility cannot become a Health Information Provider, so no record you create can be linked or shared. It has also stopped being optional in practice. Accreditation processes and insurance empanelment, including government schemes, increasingly ask for it, which means a facility without an HFR ID is not merely outside the digital network — it may be outside a payer's list. The requirement arrives through the commercial door rather than the technical one, and usually with less notice than anyone would like. ## What you need before you open the portal Gathering these first turns a three-week stall into an afternoon. - The facility's legal name, exactly as it appears on its registration or licence, not the name on the signboard. - Ownership and facility type, decided in advance. If your establishment does not fit neatly, pick the closest match and be consistent everywhere else. - Address with the correct district and sub-district, and the geolocation. - Registration or licence numbers for the establishment, and for the pharmacy and lab if they are separately licensed. - The services you actually offer, and specialities, which will later determine what other facilities and payers understand about you. - Bed count, and whether you are in-patient capable. - A responsible person with a working mobile number and an ABHA, because verification runs through them. - The system uses email and mobile as contact points; use an address that outlives the person currently in the job. ## The decisions people get wrong Three fields cause most of the corrections later, and all three are decisions rather than facts to look up. Facility name. Use the licensed legal name. Hospitals routinely register the brand name, then find it does not match the name on the empanelment paperwork or the pharmacy licence, and every downstream verification asks about the discrepancy. Facility type and ownership. Get it right the first time. Changing it later is possible and tedious, and in the meantime everything that references your facility carries the wrong classification. The contact person. Registering under a doctor's personal mobile is convenient and creates a dependency that surfaces the day they leave. Use a role-based contact where the system allows it, and record who holds it. ## What HPR registration involves HPR is per-person, and it is the clinician's own registration, not the hospital's. A doctor registers with their identity, their council registration details and their qualification, and the record is verified against the relevant council. The hospital's role is to make it happen: explain why it matters, help with the process, and keep track of who has done it. That last part is the hospital's real work. Records created in an ABDM context need an author with a verifiable identity, so a hospital whose consultants are not on HPR will find gaps in exactly the records it most wants to share. Visiting consultants and part-time specialists are the ones who slip, because nobody in the hospital owns their paperwork. > HFR is a form. HPR is a change-management problem wearing a form. ## After registration, what actually changes Registration by itself changes nothing clinically, and it is worth being honest about that internally so nobody expects otherwise. What it does is unlock the next steps: your certified software can be configured against your facility ID, ABHA numbers can be created and linked at your counters, records can become discoverable to patients, and payers and accreditation bodies can find you where they expect to. It also puts your facility's details into a national directory, which means the accuracy of what you entered now has consequences beyond your own records. A practical follow-up that most facilities skip: check your own listing a month later. Details entered under time pressure are frequently wrong in small ways, and a wrong district or a missing service is easier to fix before anything depends on it. ## A short sequence for a facility starting from zero - Decide facility type, ownership and legal name. Write them down and use them consistently everywhere. - Collect licence and registration numbers, including pharmacy and lab. - Ensure the responsible person has an ABHA and a mobile number they will keep. - Complete HFR registration and note the facility ID somewhere your billing and compliance teams can find it. - Get your regularly practising clinicians onto HPR, starting with whoever signs discharge summaries. - Give your software vendor the facility ID and ask what they need to configure, and what they need from you. - Verify your public listing, and correct it. None of this is difficult. It is administrative work that stalls because it needs decisions rather than effort, and the hospitals that finish it quickly are the ones where somebody was made responsible for making those decisions rather than for filling in the form.

Read article
HMS, HIS, HIMS, EMR, EHR: The Acronyms, Settled — Product | KōamiProduct
Product· 7 min read

HMS, HIS, HIMS, EMR, EHR: The Acronyms, Settled

Two vendors are sitting in front of a hospital's purchase committee. One says their product is a complete HIS. The other says theirs is an HMS with an integrated EMR. A board member asks whether the hospital needs an EHR as well. Nobody in the room is being dishonest, and nobody is quite sure whether the two products do the same thing. They mostly do. The acronyms are a mixture of genuine distinctions and marketing habit, and the distinctions that are real are worth knowing before you sign anything. ## What is an HMS, and is it different from an HIS or a HIMS? In practice, HMS, HIS and HIMS all describe the same category of software: the system that runs a hospital's day-to-day operations. - HMS: Hospital Management System - HIS: Hospital Information System - HIMS: Hospital Information Management System - Occasionally, hospital ERP Buyers use them interchangeably, and so do most vendors. If a proposal uses one and a competing proposal uses another, that tells you nothing about scope. Ask for the module list instead. If you want to be pedantic there is a shade of difference in the origins. HIS came from an information-systems tradition and leans clinical. HMS came from an administrative tradition and leans operational: registration, billing, pharmacy, stores. In India today the terms have converged so completely that the shade is not worth acting on. ## What is an EMR, and how is it different from an EHR? An EMR is the clinical record held by one organisation. An EHR is a record designed to follow the patient across organisations. That is the one distinction in this whole list that carries real consequences. An EMR holds what your hospital knows about a patient: consultations, diagnoses, orders, results, prescriptions, discharge summaries. It is complete within your walls and stops at them. If the patient goes to a different hospital, your EMR does not travel with them. An EHR is the longitudinal record. The same patient, seen anywhere, with their history available to whoever is treating them now, subject to consent. In India this is what the Ayushman Bharat Digital Mission is building: an ABHA number as the identity, health records held by the facilities that created them, and a consent-driven exchange that lets a record move when the patient permits it. The practical consequence for a buyer: every serious HMS contains an EMR. Almost none contains an EHR, because an EHR is not a product you buy, it is a network you join. What you should actually ask is whether the EMR can participate in that network. ## So what should a hospital actually ask for? Ask for the module list and the integration list, and ignore the acronym on the cover. - Which modules are included at the quoted price, named individually - Whether the clinical record is genuinely structured, or free text with a search box - Whether it can create and verify ABHA numbers at registration - Whether it can link care contexts, so records become discoverable to the patient - Whether it exposes standards-based interfaces rather than a private export A vendor who answers those five clearly is offering something specific. A vendor who answers by restating that they are a complete HIS is offering a word. ## Where do LIS, RIS and PACS fit? They are departmental systems, and the question is not whether you have them but whether they are separate. - LIS, the Laboratory Information System, runs the lab: order to sample to result to approval, with analyser interfacing and turnaround tracking. - RIS, the Radiology Information System, runs imaging orders, scheduling and reporting. - PACS stores and displays the images themselves, in DICOM. In an integrated suite these are modules that share the patient record, so a lab order placed in the chart appears on the lab worklist and the result posts back without anybody re-keying it. Bought separately, each needs an interface, and each interface is a small project with its own failure modes. Neither approach is wrong. The mistake is buying separately while assuming integration is free. ## What about HRMS, ERP and the rest? An HRMS manages people, not patients, and a hospital HRMS is not the same as an office one. Hospitals run rotational shifts around the clock, with statutory staffing ratios, night and on-call differentials, and professional registrations that expire. Generic HR software models none of that. When a hospital says it needs an HRMS, it usually means rostering, attendance across wards, statutory payroll, and credential-expiry tracking. ERP in a hospital context usually means the finance and supply chain layer: purchasing, stores, fixed assets, general ledger. Some HMS products include it. Some hospitals run a separate ERP and interface it. The decision hinges on whether your finance team already lives in something they will not leave. ## The question the acronyms are hiding Whether a product is called an HMS or an HIS tells you nothing. What separates products is narrower and easier to test. - Does a patient have one identity across every department, or one per system? - Is clinical data structured enough to be counted, or only readable? - Do charges attach to care as it happens, or get assembled at discharge? - Can the record leave the building when the patient consents, using a standard rather than a spreadsheet? - When something goes wrong, is there an audit trail that shows who did what, including who merely looked? A product that answers those five well is worth buying under any acronym. One that answers them badly is not worth buying under all of them. ## A short glossary to keep in the room - HMS / HIS / HIMS: the hospital operations and clinical system. Same thing. - EMR: your organisation's clinical record for a patient. - EHR: a record that follows the patient across organisations. - ABHA: the health account number that identifies a patient in India's digital health network. - ABDM: the national programme that defines how records are identified, linked and exchanged. - HIP: a Health Information Provider, meaning a facility that creates records others may request. - HIU: a Health Information User, meaning a facility that requests them. - LIS / RIS / PACS: lab, radiology workflow, and imaging storage and display. - HRMS: workforce, rostering, attendance and payroll. - TPA: the third party that administers insurance claims between the hospital and the insurer. Print it, put it on the table, and spend the meeting on the module list instead.

Read article
Putting AI in a Hospital Without Losing Control of It — Clinical AI | KōamiClinical AI
Clinical AI· 7 min read

Putting AI in a Hospital Without Losing Control of It

The first AI tool arrives in a hospital without a decision being made. A radiologist trials a free reading assistant. A resident starts drafting discharge summaries with a chatbot because it saves forty minutes. Somebody in finance uploads a spreadsheet of claim data to get a summary. None of it went through procurement, IT or the ethics committee, and by the time anyone notices, three different tools are handling patient data and nobody can say which. This is how AI actually enters healthcare organisations. Governance that assumes a formal adoption decision is governing something that already happened. ## What does AI governance in a hospital actually mean? It means knowing which tools touch patient data, who is accountable for each decision they influence, and being able to show both. It is not an ethics statement and it is not a ban. A ban produces exactly the shadow usage described above, with the added problem that nobody will tell you about it. The workable version is narrower and more practical: - An inventory of AI tools in use, including the unofficial ones. - A named clinical owner for each tool that touches care. - A clear statement, per tool, of what it does and what it must not be relied on for. - A record of what the tool said and what the human did about it. - A review that actually happens, on a schedule, using the hospital's own data. ## Where the accountability sits With the clinician who acts, always — and a tool that blurs this is a tool to reject. This is the load-bearing principle. A model that flags a finding is offering an input, exactly like a prior study or a lab result. The report carries a radiologist's name. The prescription carries a prescriber's. The discharge summary carries the signature of whoever signed it, and signing means having read it. Two failure modes threaten this from opposite directions. Automation bias is the first: the human stops reading carefully because the machine has already looked. The second is the alibi, where a clinician defends a decision on the grounds that the system suggested it. Both are prevented by the same design choice — the human commits to their own assessment before seeing the model's, and the record shows they did. > The safe question is never "is the model right often enough". It is "when the model is wrong, who catches it, and how". ## Which uses are low-risk and which are not Sort tools by what happens when they are wrong, not by how impressive they are. - Low risk: scheduling suggestions, queue forecasting, stock reorder proposals, coding assistance that a coder reviews. A wrong answer costs efficiency and is caught in the ordinary course of work. - Medium risk: documentation drafting, triage ordering, summarisation of a record for a clinician who will also read the source. A wrong answer wastes time or misleads briefly, and the human is positioned to notice. - High risk: anything producing a finding, a diagnosis, a dose, or a prioritisation that determines who is seen first. A wrong answer can reach a patient. The governance effort should be concentrated on the third category, and the second category deserves more attention than it usually gets — a fluent, confidently wrong summary is more dangerous than an obviously broken one, because nothing about it invites checking. ## The data question, which is now a legal one Any tool that receives patient data is a processor acting on the hospital's behalf, and the hospital remains responsible for what happens to it. That has consequences that are easy to state and frequently ignored. A free web tool with no contract is not an acceptable destination for patient data, regardless of how useful it is. Where a tool is contracted, the terms need to say what may be done with the data, whether it is used for training, where it is stored and for how long, and what happens at termination. Under India's data protection framework, purpose limitation applies: data collected for care is not automatically available for training somebody's model. De-identification helps and is not a magic word. Free-text clinical notes carry identifying detail in ways that automated redaction misses, and small populations re-identify easily. Treat de-identified as reduced risk, not absent risk. Where a tool makes a claim about clinical purpose, there is also a regulatory question about whether it is a medical device and what approvals apply. Ask the vendor directly and get the answer in writing. ## Monitoring, because performance is not a fixed property A model that performed well on the vendor's validation set may perform differently on your patients, and the only way to know is to measure it on your own. Drift is normal and has mundane causes: a new scanner, a change in case mix, a different referral pattern, a software update on the model side. So the tool needs a baseline established locally at deployment, a metric that is checked on a schedule, and a person whose job it is to look. The most informative signal is usually free and rarely collected: what clinicians do with the output. Override and dismissal rates, tracked over time, tell you more than any accuracy figure. A flag that is dismissed almost every time has become noise, and noise trains people to ignore the next flag too. A tool nobody overrides may be trusted, or may be being rubber-stamped, and the two look identical on a dashboard. ## What a small hospital can do without a committee Governance does not require a large programme, and treating it as one is why it never starts. - Write down every AI tool in use. Ask the departments; the list will be longer than IT's. - For each, name an owner and write one line on what it may and may not be used for. - Rule that no patient data goes to any tool without a contract. Give people a compliant alternative in the same breath, or the rule creates shadow usage. - Ensure high-risk tools log the suggestion, the human's action, and the identity of the human. - Pick one metric per high-risk tool and review it quarterly, using your own cases. - Tell patients, in your privacy notice, that AI tools assist in care — and be able to explain how if asked. The hospitals that get value from AI are not the ones that adopted earliest. They are the ones that can say, a year later, which tools are actually being used, what they changed, and who is answerable — and that can therefore keep the ones that work and drop the ones that do not.

Read article
NABH 6th Edition: The Digital Clauses Hospitals Keep Missing — Operations | KōamiOperations
Operations· 7 min read

NABH 6th Edition: The Digital Clauses Hospitals Keep Missing

A quality manager who has been through three NABH cycles opens the 6th edition expecting to recognise most of it, and mostly does. The chapters are familiar, the structure is familiar, the discipline is the same discipline. What is different is quieter and shows up in the wording: a steady shift from asking whether a hospital has a policy to asking whether the hospital can demonstrate what happened, and an assumption running underneath the whole document that the demonstrating will be done from systems rather than from files. That shift is easy to miss on a first read and expensive to miss on an assessment. ## What changed in the 6th edition? The direction of travel is towards digital records, measurable quality indicators and demonstrable data security, rather than towards new clinical requirements. Work from the published standard rather than from anyone's summary, this one included, because the objective elements are what an assessor actually scores. But the themes are consistent enough to plan against. - Greater emphasis on electronic records and on digital health, including alignment with the national digital health framework. - More weight on quality indicators: not just collecting them, but showing that they were reviewed and acted on. - Explicit attention to data security and patient privacy, which used to be treated as an IT concern and is now a clinical governance one. - The same underlying demand as always, sharpened: evidence, contemporaneously created. ## Why the digital emphasis changes preparation A hospital on paper can prepare for an assessment in six weeks. A hospital being assessed on data cannot. This is the practical consequence, and it is worth stating plainly. Retrospective documentation is detectable — an assessor who asks for three months of a quality indicator and receives a spreadsheet created last Tuesday has learnt something. When the standard leans on digital records, the timestamps come along with them, and a record created at the point of care looks nothing like one entered in a batch the week before the visit. That cuts both ways, and the favourable direction is the one worth planning for: if your system captures the evidence as a by-product of the work, preparation stops being a project. The file is already there because the work created it. ## Which quality indicators cause the most trouble The ones nobody owns, and the ones whose denominator was never defined. - Indicators collected by a department for its own use, in its own format, so nothing aggregates. - Indicators with a numerator everyone agrees on and a denominator nobody wrote down, which means this quarter's figure is not comparable to last quarter's. - Indicators that are collected faithfully and never reviewed, so there is no record of anyone having acted on them. - Incident and near-miss reporting, which is under-reported everywhere and where a suspiciously low number invites more scrutiny than an honest one. An assessor's follow-up question is almost never whether you collect the indicator. It is what you did when it moved. That answer lives in minutes of a meeting, in a corrective action recorded against the finding, and in the next quarter's number — and all three should be findable without a search party. ## What the data security clauses actually ask for They ask a hospital to show that access to patient data is controlled, recorded and reviewed, which is a configuration question more than a policy one. A privacy policy has no effect on who can open a record. What decides that is role configuration, and in most hospitals it has drifted: a single clinical role that sees every patient, shared counter logins during busy hours, vendor support accounts left active from a go-live two years ago, and ex-employees whose accounts outlived their employment because offboarding never reached the HIS. The specific things worth checking before an assessment, because they are the specific things that get asked about: - Are user accounts individual, or shared at any point in the day? - Does the audit trail record reads, not just writes? The commonest privacy complaint is that somebody looked at a record they had no business seeing, and a write-only log cannot answer it. - Is there a documented access review, and has it happened? - Are backups tested by restoring them, with the elapsed time recorded? - Does the DPDP work you have already started line up with this, or are they two separate projects producing two separate binders? That last point is the free win. The data protection work a hospital has to do anyway covers a large part of what the accreditation standard is asking about, and running them as one programme halves the effort. ## Where the 6th edition and ABDM meet Alignment with the national digital health framework appears in both, and the overlap is real work you only need to do once. A facility on the Health Facility Registry, with clinicians on the Healthcare Professionals Registry, creating structured records linked to patient identities, is simultaneously making progress against the digital expectations of the standard and against empanelment requirements. Hospitals that run these as three separate initiatives, with three owners and three timelines, do the same work three times and finish none of it. > The overlap between accreditation, data protection and the digital health mission is not a coincidence. They are three regulators asking for the same underlying capability: know what you hold, control who touches it, and be able to show what happened. ## A preparation plan that does not end in a scramble - Read the actual standard and map each objective element to where its evidence will come from. The ones with no source are your gaps. - Define every quality indicator once, with its denominator written down, and stop letting departments keep private versions. - Record corrective actions against the finding that triggered them, so the link survives the meeting. - Put every expiring record — competency, calibration, licence, credential — on an automatic reminder with an escalation. - Review user roles and disable dormant and vendor accounts. Confirm the audit trail covers reads. - Run one restore test and write down how long it took. - A quarter before the assessment, pull the reports an assessor would ask for, on an ordinary week. Whatever takes two days to produce is the finding, and you have found it yourself. The hospitals that find accreditation easy are not the ones with better documentation. They are the ones whose systems produce the documentation without anybody being asked to.

Read article
Getting PM-JAY Empanelled, and Staying That Way — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 7 min read

Getting PM-JAY Empanelled, and Staying That Way

Empanelment is treated as a finish line. The application goes in, the inspection happens, the hospital appears on the list, and everybody moves on to the next thing. Then the claims start, and within two quarters the hospital discovers that being empanelled and being paid are separate achievements, and that the second one depends on operational discipline nobody costed for during the application. The hospitals that do well under the scheme are not the ones with the best application. They are the ones whose systems were ready for what came after it. ## What does PM-JAY empanelment actually require? Empanelment is a state-administered process against national criteria: you apply, you are assessed on infrastructure and staffing against the specialities you want to offer, and you are approved for a defined set of packages. The application itself is mostly documentary, and the parts that delay hospitals are consistent. - Registration and licences current, including the establishment registration, pharmacy licence, biomedical waste authorisation and fire clearance. - Staffing evidence for the specialities applied for, with qualifications and registrations that can be verified. - Infrastructure appropriate to those specialities, including ICU and theatre where the packages require it. - Bank account and PAN details in the hospital's legal name, matched exactly. - Increasingly, digital health prerequisites: registration on the Health Facility Registry, and the ability to create and link ABHA numbers. Speciality selection is the decision that matters most and gets the least thought. Apply for what you genuinely staff and can document. A hospital approved for a speciality it cannot consistently deliver ends up with rejected claims and awkward questions rather than revenue. ## What changes operationally on day one The moment you are empanelled, three things become daily work that were previously occasional. Pre-authorisation. Most packages need approval before the procedure, with clinical justification and supporting documents. That is a queue, it has a turnaround time, and it sits directly in front of a patient waiting for a decision. Somebody has to own it by name. Package discipline. Care is billed against defined packages with defined inclusions. A hospital used to itemised billing has to learn what falls inside the package and what genuinely does not, and the learning is expensive if it happens through rejections. Documentation at a different standard. Scheme claims need evidence that the procedure happened as claimed: notes, investigation reports, implant details where applicable, and photographs where the package specifies them. Documentation that was adequate for an insurer may not be adequate here. ## Why claims get rejected, and what actually fixes it Most rejections are administrative, not clinical, which is good news because administrative causes are fixable with system configuration rather than with argument. - Beneficiary identity mismatch. The name, the card and the record do not agree. This is the cheapest rejection to eliminate and one of the commonest. - Missing pre-authorisation, or a procedure that drifted from what was authorised. - Package selected incorrectly, or unbundled into components that the scheme expects as one package. - Documents missing at submission: a report, an implant sticker, a required photograph. - Late submission, past the window. - Clinical documentation that does not support the package claimed. The fix for almost all of these is the same and unglamorous: capture at the point of care, validation before submission, and a checklist enforced by the system rather than remembered by a person. A billing screen that will not let a scheme claim be submitted without its required attachments prevents more revenue loss than any amount of follow-up afterwards. > A rejection queue is a system telling you what your workflow forgot to capture. Read it as a defect list, not as a collections problem. ## The part hospitals underestimate: the money takes time Scheme rates are fixed and payment cycles are longer than private insurance, so empanelment changes your working capital, not just your patient mix. Model it before you commit. Volume at scheme rates against your actual cost per case, with a realistic assumption about how long payment takes and what proportion is queried on the first pass. A hospital that plans on gross claim value and receives it two quarters later, minus deductions, has a cash flow problem that has nothing to do with clinical quality. This is also why the receivables view matters more here than anywhere else. You need to know, at any moment, how much is submitted, queried, approved and paid, by age. If assembling that takes a day of somebody's time, you will not do it monthly, and you will find out about a problem a quarter late. ## Staying empanelled De-empanelment and penalties usually follow from patterns rather than from single mistakes, and the patterns are visible in your own data first. Scheme administrators run analytics for exactly this: unusual package mixes, procedures at implausible volumes, admissions that look avoidable, readmissions inside a suspicious window, claims for specialities that are thinly staffed. A hospital acting in good faith can still show an odd pattern — a genuinely high-volume speciality, a seasonal surge, one surgeon whose case mix is unusual — and the time to understand it is before somebody asks. The defensive posture is straightforward. Run the same analysis on yourself, quarterly. Keep clinical documentation that would justify each claim to a reviewer who was not there. Make sure the beneficiary verification step is real and recorded, since identity fraud committed by others still lands on your hospital's record. And keep the empanelment paperwork current, because licences expire and a lapsed fire clearance is a needless way to lose a listing. ## A checklist worth running before you apply - Licences and clearances current, with expiry dates on a reminder rather than in a drawer. - Specialities chosen against what you actually staff, documented. - HFR registration done, ABHA creation working at your counters. - Named owner for pre-authorisation, with a defined turnaround target. - Package master loaded in your system with inclusions, so billing is not interpreting them case by case. - Required-document rules enforced at submission, not checked afterwards. - A receivables view by payer, stage and age that you can produce in a minute. - A cash flow model that assumes queries and delay, not gross claim value. Empanelment is worth having. It is a volume decision with a working capital consequence and an administrative overhead, and hospitals that treat it that way from the start do considerably better than the ones who treat it as an approval to be obtained.

Read article
Teleconsultation in India: What the Guidelines Ask of Your Software — Patient Experience | KōamiPatient Experience
Patient Experience· 7 min read

Teleconsultation in India: What the Guidelines Ask of Your Software

A consultant takes a follow-up call on a Sunday evening. The patient describes a rash, sends two photographs on WhatsApp, and asks whether the medicine should continue. The consultant says yes, adds a second drug, and types the dose into the chat. It takes four minutes and it is good medicine. It is also, as a record, almost nothing: no identity check that anyone could later verify, no consent, no note in the chart, and a prescription that exists only in a message thread on two phones. Nobody set out to practise badly. The consultation simply happened somewhere the hospital's systems were not. ## Is teleconsultation legal in India, and under what rules? Yes. Telemedicine has been formally permitted since the Telemedicine Practice Guidelines were issued in 2020, and they remain the operative framework. The essentials, in the form they matter to a hospital: - Only practitioners registered with the National Medical Commission or a State Medical Council may consult. - The same professional standards apply as in person. A teleconsultation is a consultation, not a lesser thing. - The practitioner must identify the patient and be identifiable themselves. - Patient consent is required, and in many situations it is implied by the patient initiating the consultation — but it must be recorded. - The practitioner exercises professional judgement on whether the case can be handled remotely at all, and must decline when a physical examination is essential. - Records must be maintained as for any other consultation. Read the guidelines themselves rather than a summary, including any subsequent clarifications, since they interact with medical council conduct rules and with state-level requirements. ## What can and cannot be prescribed remotely? Most medicines can be prescribed after a teleconsultation, with defined exclusions that the software should enforce rather than leave to memory. The exclusions are the part worth building into the system: drugs listed in Schedule X of the Drugs and Cosmetics Rules, and substances under the Narcotic Drugs and Psychotropic Substances Act, are outside the scope of a teleconsultation prescription. The guidelines also distinguish between what may be prescribed on a first remote consultation and what is appropriate on follow-up. A prescribing screen that knows which drugs are restricted, and refuses rather than warns, converts a rule somebody has to remember into a rule the system keeps. That matters most on a Sunday evening, which is exactly when nobody is checking. ## What the record has to contain A teleconsultation record should be indistinguishable in completeness from an in-person one, and it needs three things the in-person visit gets for free. - Identity. Who the patient was, and how you established it. In person this is the person standing there; remotely it is a deliberate step that has to be recorded. - Mode and consent. Whether it was video, audio or text, and that the patient consented, captured at the time rather than reconstructed. - The clinical content itself. History, assessment, advice, prescription, and the decision about whether remote management was appropriate. Anything shared during the consultation — photographs, reports, previous prescriptions — belongs in the record, attached to the encounter. This is the single largest gap in practice. Images sent over a messaging app are clinical data sitting on two personal phones, outside the record, outside your access controls and outside any retention policy. Under data protection law they are also personal data your hospital is responsible for and cannot account for. > If the consultation happened on a platform your hospital does not control, then clinically it happened and administratively it did not. ## Why the messaging-app habit is hard to break It persists because it is faster than anything the hospital has offered instead, and that is a design problem rather than a discipline problem. Any replacement has to beat a chat window on effort. In practice that means the consultation opens from the patient's existing record rather than as a separate application, the previous encounter is visible without searching, images attach in one action, the prescription generates from the same screen and reaches the patient without being retyped, and the whole thing works on a phone on a weak connection. If the compliant route takes ninety seconds longer than the non-compliant one, clinicians will use the fast one, and no policy will change that. The hospitals that have moved teleconsultation into their systems did it by making the system faster, not by circulating a memo. ## Where the money and the identity go A teleconsultation that is not billed and not registered is a patient interaction your hospital has no record of. The workflow needs the same skeleton as an OPD visit: the patient is identified against their existing UMR so the encounter joins their history, payment is handled before or at the consultation, the encounter is recorded as an encounter, and a follow-up can be booked from it. Hospitals that bolt a video tool onto the side end up with a parallel stream of clinical activity that never reaches the patient record or the revenue cycle, and they usually discover it when someone asks how many teleconsultations were done last month. Where teleconsultation is offered under a scheme or an insurer's programme, the documentation standard is the payer's, not the platform's — another reason for the encounter to live in the hospital's system rather than in a vendor's dashboard. ## Data protection applies with full force A remote consultation generates the same category of personal data as an in-person one, plus a recording risk that does not exist in a consulting room. Decide in advance whether consultations are recorded at all, and if they are, on what basis, for how long, who can access them, and how the patient is told. A recording made for clinical reasons and kept indefinitely on a cloud service in a jurisdiction nobody has checked is a liability accumulating quietly. The rest is the ordinary discipline: encrypted in transit and at rest, access limited to the care relationship, read access logged as well as writes, and a contract with the platform vendor that says what they may do with what passes through them. ## A short readiness check - Can a clinician start a teleconsultation from the patient's existing record, in one action? - Does the system record identity verification, mode and consent, without extra typing? - Do restricted drug categories get blocked at prescribing, not flagged in a policy document? - Do images and reports shared during the consultation land in the record automatically? - Does the prescription reach the patient from the system, rather than being retyped into a chat? - Is the encounter billed and counted like any other? - Do you know where recordings, if any, are stored and for how long? Teleconsultation is not a separate product a hospital buys. It is a consultation that happens over a wire, and everything that makes an in-person consultation a proper clinical event applies to it unchanged.

Read article
The DPDP Act Reaches the Hospital Floor — Data Security | KōamiData Security
Data Security· 7 min read

The DPDP Act Reaches the Hospital Floor

The registration counter asks for a phone number, an address and, quite often, an Aadhaar number. The number goes into the system, and from there into the SMS gateway that sends appointment reminders, into the spreadsheet the marketing team uses for health-camp follow-ups, into the WhatsApp group where the ward coordinates discharges, and into a backup on a drive in the IT room. Nobody decided this. It accreted, one reasonable step at a time, over a decade. India's Digital Personal Data Protection Act, 2023 turns that accretion into a question a hospital has to answer: on what basis do you hold this, and who told the patient? ## What changes, in plain terms The Act is short by the standards of privacy law, and its core is a small number of ideas. - A hospital that decides why and how personal data is processed is a data fiduciary. The patient is a data principal. - Processing generally requires consent, and the consent has to be preceded by a clear notice in plain language saying what data, for what purpose. - Purpose limitation. Data collected for one purpose is not automatically available for another. The phone number given for appointment reminders is not, by default, a marketing list. - Data minimisation. Collect what the purpose needs, not what the form has always asked for. - Patient rights: to access, to correct, to erasure, and to nominate someone to exercise those rights on their behalf. - Breach notification, to the regulator and to affected individuals. - Processors, meaning the vendors who handle data on the hospital's behalf, are bound by contract, and the obligation does not transfer away from the hospital. - Penalties are significant enough that this is a board-level matter rather than an IT one. Exact timelines, thresholds and the finer points of the Rules move, and you should work from the current notified text and qualified advice rather than a summary. What is not going to change is the shape: a hospital must know what it holds, why, and be able to act on a patient's request about it. ## The inventory nobody has The first exercise is unglamorous and always revealing: write down every place patient data sits. Not the systems on the architecture diagram — every place. - The HIS or HMS database, and its backups, and where those backups physically are. - The PACS archive, which is larger than everything else combined and often has the loosest access control. - The lab analyser interface, which frequently keeps its own local copy. - Spreadsheets on individual machines: camp registrations, corporate check-up lists, TPA follow-ups, the pending-discharge tracker. - The SMS and WhatsApp gateways, which are third parties holding a patient's name, number and often their appointment details. - Scanned consent forms and discharge summaries on a shared drive. - CCTV, biometric attendance, and the visitor register at the gate. - Whatever the analytics or marketing agency was given for the last campaign. Every hospital that does this exercise finds at least two copies it had forgotten and one vendor relationship with no contract governing data. Those are the findings. The exercise is worth doing purely for them. ## Consent notices, and the trap of consenting to everything The instinct is to add a paragraph to the registration form covering every conceivable use, and have everyone sign it. This is the approach the law is specifically designed to defeat, and it fails at the point that matters, which is when a patient objects and the hospital has to show that the consent was informed and specific. The workable version separates the purposes. Care delivery is the core purpose, and the notice for it can be short and clear. Statutory and regulatory reporting is a separate basis and should be described as such rather than bundled into consent. Insurance and TPA processing involves disclosure to third parties and needs to say so. Appointment reminders and clinical follow-up are operational. Marketing, health camps, newsletters and feedback surveys are a genuinely separate purpose, and the patient should be able to decline them without declining treatment. That last point is the one that changes behaviour inside a hospital. Once marketing consent is separate and recorded, the marketing list stops being "everyone who ever registered" and becomes a subset. This is inconvenient and it is the entire point. > If declining a purpose would stop the patient receiving care, it is not a consent. It is a condition of entry, and it will not stand. ## Access control is where policy becomes real A privacy policy has no effect on who can actually open a record. That is decided by role configuration, and in most hospitals the roles have drifted a long way from the org chart. The pattern is familiar. A single Doctor role that can see every patient in the hospital, because it was easier to configure. Front-office staff with access to clinical notes they have no use for. Shared logins at the counter during busy hours. Vendor support accounts, created for a go-live two years ago, still active and still privileged. Ex-employees whose accounts were never disabled because offboarding runs through HR and never reaches the HIS. Least privilege is the principle, and the practical version is narrower than most hospitals implement: access follows the care relationship, so a clinician sees the patients they are treating; sensitive categories such as psychiatry, HIV status and fertility records sit in their own compartments with explicit grants; every access to a record is logged with enough detail to answer who looked and when; and break-glass access exists for emergencies, is generously granted, and is reviewed afterwards without exception. The audit log deserves particular attention, because it is what converts a policy into something provable. A log that records only writes cannot answer the most common privacy complaint, which is that somebody read a record they had no business reading. ## Rights requests need an owner and a route A patient writes in asking what data the hospital holds about them, or asks for a correction, or asks for erasure. The Act gives them that right and expects a response. Most hospitals have no route for this at all. The letter arrives at the front desk, is passed to medical records, then to IT, and stalls because nobody can assemble the answer across nine systems and a shared drive. Deciding this in advance is inexpensive. Name the person who owns rights requests. Define the intake channel and publish it. Write down which systems have to be queried, which is precisely the inventory from earlier. Agree what erasure means in a clinical context, where retention obligations for medical records constrain what can actually be deleted, and be able to explain that constraint to the patient rather than simply refusing. ## Breaches, and the twenty-four hours that matter Breach handling is where preparation shows most starkly, because it happens under time pressure and in public. Have a definition of what constitutes a reportable breach and who decides. Have the contact points ready, both regulatory and internal. Know in advance what your logs can actually tell you about scope, because the first question is always how many records, and a hospital that cannot answer it will guess badly. Rehearse it once. A tabletop exercise on a Thursday afternoon costs three hours and finds most of the gaps. Note that CERT-In's incident reporting directions already impose their own tight timelines for cyber incidents, separately from the DPDP obligations. Hospitals need one process that satisfies both, not two competing ones discovered mid-incident. ## A first ninety days that is actually achievable - Build the data inventory, including spreadsheets and messaging apps. Nothing else works without it. - Separate the consent purposes on the registration form, especially marketing. - Review roles in the HIS and PACS, and disable dormant and vendor accounts. - Confirm that read access is logged, not just writes. - Get data processing terms in writing with the SMS gateway, the cloud provider, the billing vendor and the analytics agency. - Name the person who owns rights requests, and publish the route. - Run one breach tabletop. None of this is exotic. It is mostly hygiene that a hospital would want in place regardless. What the Act adds is a deadline and a consequence — and, usefully, a reason for the conversation about that spreadsheet on the marketing laptop to finally happen.

Read article
ART Success Rates: Always Ask for the Denominator — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 7 min read

ART Success Rates: Always Ask for the Denominator

A hoarding near the highway advertises a fertility centre with a seventy-eight percent success rate. Down the road, another claims sixty-five. A couple sitting in a consultation room has seen both. They ask the obvious question, which is why anyone would choose the second clinic, and the honest answer is that the two numbers are not measuring the same thing and neither of them has told you what they divided by. This is not mainly a marketing problem. It is a measurement problem, and it starts inside the clinic, where the same ambiguity makes it impossible to tell whether this year was better than last. ## Every rate is a fraction, and the argument is always about the bottom A success rate is a numerator over a denominator. In ART the numerator is usually clear enough. The denominator is where the disagreement lives, and moving it changes the answer dramatically without anybody stating an untruth. Take clinical pregnancy. Per embryo transfer, the denominator excludes every cycle that was cancelled, every retrieval that produced nothing to transfer, and every freeze-all that has not come back yet. Per oocyte retrieval, it includes the failed fertilisations. Per cycle started, it includes the cancellations. The same clinic, the same year, the same patients: three quite different percentages, all correct. - Per transfer flatters clinics that cancel freely and transfer selectively. - Per retrieval is harder, and closer to what a patient going through a retrieval experiences. - Per cycle started is hardest, and closest to the question a couple is actually asking. - Cumulative live birth per retrieval, counting the fresh transfer and every subsequent frozen transfer from that cohort, is the most honest of all and the slowest to compute, because it needs the follow-up to be complete. > A rate without its denominator is not a statistic. It is a claim. ## The indicators worth watching inside the clinic Headline pregnancy rates are for the outside world. The numbers that tell a clinic something it can act on are further up the chain, because they isolate a step. - Cycle cancellation rate, split by reason: poor response, over-response and risk of hyperstimulation, personal reasons. - Oocyte yield against the antral follicle count that was expected, which tests both stimulation and the honesty of the counting. - Maturity rate: mature oocytes as a share of those retrieved. - Fertilisation rate, calculated on mature oocytes for ICSI and on inseminated oocytes for conventional IVF. Conflating the two makes the number meaningless. - Blastocyst conversion, as a share of normally fertilised embryos. - Usable embryo rate per retrieval, which is what determines whether a couple gets more than one attempt from one stimulation. - Implantation rate, sacs per embryo transferred, which is the closest thing to a measure of embryo quality. - Miscarriage rate, because a pregnancy rate uncorrected by this can hide a real problem. - Freeze-thaw survival, which is a direct measure of laboratory technique. A shift in any one of these localises the issue. Fertilisation down while maturity holds points at the andrology side or the injection technique. Blastocyst conversion down while fertilisation holds points at culture conditions. Implantation down while grading is unchanged points at the transfer, or at grading that has quietly drifted. ## Small numbers lie, confidently A clinic doing forty retrievals a month is looking at small samples the moment you segment by age band, protocol and clinician. Nine cycles in a cell is not a trend, but it will render as a percentage that looks exactly as authoritative as one computed from nine hundred. The discipline that fixes this is simple and rarely implemented: set a minimum denominator, and have the system decline to report below it. Not display zero, not display a dash — say plainly that there are too few records to report, and show the count. It feels like a loss of functionality. It is the opposite: it stops the monthly meeting spending twenty minutes on a swing that was two patients. The same applies to comparisons between clinicians. Case mix differs, referral patterns differ, and the doctor who takes the difficult cases will look worse on every raw measure. Comparison without adjustment for age and reserve is not analysis; it is a way of making colleagues defensive. ## Data quality is the number nobody puts on the dashboard Every rate above assumes the underlying data exists. In practice a clinic's dashboard is quietly built on whatever was recorded, and the gaps do not announce themselves. The cycles that disappear are always the same kind. Cancelled cycles that were never closed in the system and sit as active forever. Couples who went elsewhere after a failure, so no outcome was ever recorded. Freeze-alls whose subsequent transfers were entered as fresh cycles. Beta hCG results that came back to a phone and were never entered. Each of these biases the result in the same direction, because the missing cases are disproportionately the failures. A clinic with poor follow-up capture will always look better than it is, and will never know by how much. So the first panel on a KPI dashboard should not be a success rate. It should be completeness: how many cycles in this period have a recorded outcome, how many are still open past their expected close, how many are missing a fertilisation check. A clinic reporting a pregnancy rate on sixty percent outcome capture is reporting on a sample it did not choose. ## Building something people actually use The dashboards that get used share a few properties, and they are mostly about trust rather than visualisation. Every figure states its numerator and denominator on the face of it, not in a tooltip. Every figure is clickable through to the underlying cycles, because the first reaction of any clinician to a surprising number is to want to see the cases, and a dashboard that cannot show them gets dismissed once and never revisited. Definitions are written down and visible, so that "clinical pregnancy" means the same thing in March as it did in January. Filters cover age band, cycle type, protocol, fresh versus frozen, and clinician, because the aggregate is rarely the interesting view. And the whole thing refuses to invent a number. If the denominator is below the threshold, it says so. ## What to do with the numbers once you have them The point of measuring is to change something, and the change is usually less dramatic than expected. Look at the step, not the headline. Compare cohorts, not months, since seasonal variation in a small clinic is mostly noise. Change one thing at a time, because two simultaneous changes to the lab protocol produce an uninterpretable result. Give it enough cycles to mean something before deciding. And when a number improves, check the completeness panel first, because the commonest cause of a sudden improvement is a change in what got recorded rather than in what happened. The clinics that improve fastest are not the ones with the most sophisticated analytics. They are the ones that record outcomes completely, define their terms once, and are willing to look at a number that is worse than last quarter without immediately explaining it away.

Read article
What an IVF Clinic Actually Needs From Its Software — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 8 min read

What an IVF Clinic Actually Needs From Its Software

A couple walks into a fertility centre for the second time in three years. The first attempt was at another clinic in another city. She remembers the protocol was "the one with the injections in the evening" and that they got to day three. He remembers nothing except the cost. Somewhere in a cardboard folder at home there is a discharge summary and a photograph of an embryo with a number printed under it. The consultant now has to decide whether to repeat what failed. This is the problem fertility software exists to solve, and it is not the problem most hospital systems are built for. ## A hospital system tracks one person. Fertility tracks four things at once A hospital information system is built around an episode: one patient, one admission, one bill. That model breaks the moment you walk into an ART unit, because fertility care is not one patient having one episode. It is four identities that all have to hold at the same time. - The patient. One person, one permanent record, whichever partner they are. - The couple, or treatment party. Two people who must be linked without their records being merged, because each keeps their own history, their own serology and their own consent. - The cycle. Every IUI, IVF, ICSI, frozen transfer, donor or fertility-preservation attempt, with its own protocol, its own drugs and its own outcome. - The specimen. Every semen sample, every oocyte, every embryo, every biopsy, every straw in a tank. Miss the fourth and the whole edifice wobbles. You cannot witness a transfer if the embryo has no identity. You cannot prove a chain of custody for a straw that is described as "second cane, blue top". You cannot answer, five years later, which gametes a child came from. Clinics that run fertility on a general hospital module usually have the first three in some form and the fourth almost never. > The specimen identifier is the one most systems skip, and it is the one every serious safety and traceability question depends on. ## The cycle is the unit of work, and it is not a bill The commonest structural mistake is hanging clinical events off a billing number. It happens because the billing number is what exists first and what the counter staff already know. Then a couple takes a break, comes back four months later, and a second bill is raised for the same stimulation that was never completed. Now there are two cycle records for one cycle, or one cycle record split across two bills, and the outcome cannot be attributed to either. A cycle needs its own identity, created deliberately, with a guard against duplicates. It carries the cycle type and sub-type, and that distinction is not cosmetic. A natural-cycle IUI and a stimulated IUI are different treatments with different costs and different expectations, and if the software cannot record which one happened, the clinic cannot report its own results honestly. The cycle type should also drive what the chart shows. An IUI cycle has no embryo transfer step. A frozen transfer starts at the thaw, not at day two of stimulation. Software that shows every step for every cycle type is inviting somebody to file embryo data against an IUI, and one day somebody will. ## Where paper actually survives Ask a clinic which parts are still on paper and the answer is rarely "the whole thing". It is specific, and the same list comes up everywhere. - Consent forms, signed and scanned, findable only by date. - The embryology day sheet, filled in at the bench and typed up later, if at all. - The cryo register, which is often a physical book near the tanks because that is where the work happens. - The witness signature, which is a name and a squiggle in a column. - Follow-up, which lives in a WhatsApp thread and a nurse's memory. These survive because the software asked people to walk away from the work to use it. The embryologist is at a hood with gloved hands. The nurse is on the phone. The counter is busy. Any system that wants those five things off paper has to be usable at the exact moment the work happens, which usually means the record follows the workflow rather than the workflow bending to the record. ## Consent has to be a gate, not a document Most systems treat consent as an attachment. The form is signed, scanned, uploaded, and nothing in the software behaves differently afterwards. That is a filing cabinet with a search box. Consent in ART is a precondition for a procedure. The versioned text that was signed matters, because consent text changes and you must be able to show what this couple actually agreed to, not what the current version says. The identity of each signer matters. Withdrawal matters. And the system should be able to refuse: if the consent covering embryo freezing is missing or withdrawn, the freeze should not be recordable, and the refusal should say why. The same logic applies to the pre-cycle checklist. Serology within validity, screening complete, consents in place, counselling done. A checklist that only prints is decoration. A checklist that blocks cycle creation until it passes, or until a named person overrides it with a reason that is stored, is a control. And it has to be enforced where the record is written, not in the browser, or the first workaround someone finds becomes the new normal. ## The lab is where software usually gives up Everything upstream of the embryology lab is recognisably clinical software: appointments, scans, drugs, procedures. Inside the lab, the requirements change shape. Grading is structured, not free text: oocyte maturity, fertilisation check at the right hour, day-three cell counts and fragmentation, blastocyst expansion with inner cell mass and trophectoderm grades. Free-text notes here feel faster and cost the clinic its own data, because nothing that follows can be counted. Timings are clinical facts. The interval from trigger to retrieval, the hour of the fertilisation check, the day of transfer. These should be configurable per clinic rather than baked into the code as a constant, because protocols differ and they change. And every step where material could be confused needs a witness. Which brings us to the part that is easiest to fake. ## Witnessing, cryostorage and the things you only need once A witness typed as a name into a text box proves nothing. Anybody can type any name, the field is often not required in the first place, and it can be edited afterwards. A witness needs to be an event: an authenticated second person, at a recorded time, against a specific specimen, in a record that cannot later be altered or deleted. The system should also refuse to accept the operator as their own witness, which sounds obvious and is frequently not enforced. Cryostorage has the same character. "Straw 12, blue, second position" is three free-text fields, and the moment a straw is moved, the old position is usually overwritten. The address should be structured, down to tank, canister, cane and goblet, and every movement should be an insert, never an update. A cryobank whose history can be overwritten cannot answer where material was in March, which is exactly the question an inspection, an incident review or a distressed patient will ask. You will not need this most days. You will need it completely on the day something goes wrong, and on that day you cannot build it retrospectively. ## Outcome, and the honesty of denominators Fertility software that stops at the transfer has stopped one step early. The outcome is the point: beta hCG, the scan series, the number of sacs, and the eventual birth. Systems that model a single baby cannot represent twins, and twins are not rare in ART. Per-sac and per-baby outcome is not an edge case; it is the normal case often enough to matter. Once outcomes are structured, the clinic can finally do arithmetic on itself: fertilisation rate, blastocyst conversion, clinical pregnancy per transfer, cumulative live birth per retrieval, broken down by age band and protocol. Those numbers should always carry their denominator, and a good system refuses to publish a rate computed from a handful of cycles rather than printing a flattering percentage with nothing behind it. ## The practical test If you are evaluating a system, the demo will look fine. Ask instead for the six things that separate a fertility system from a hospital module wearing a fertility badge. - Show me a couple record where both partners keep their own history. - Create a second active cycle for the same couple and show me what stops you. - Freeze an embryo without the consent that covers freezing. - Show me every place straw ST-1188 has been since the day it was frozen. - Edit a witness record from last week. - Show me the clinical pregnancy rate for women under 35 on an antagonist protocol, with the denominator on the screen. A system built for this work answers all six in a few minutes. One that was adapted for it will manage two or three, and the gaps will be exactly the places where the clinic is still running on paper, memory and trust.

Read article
NABL for a Hospital Lab: What the Software Has to Prove — Operations | KōamiOperations
Operations· 6 min read

NABL for a Hospital Lab: What the Software Has to Prove

Six weeks before the assessment, the lab in-charge starts a spreadsheet. It has tabs for equipment calibration, internal quality control, competency records, and a list of every result that went out amended. Most of the data exists somewhere. Some of it is in the analyser, some in a register on the bench, some in a WhatsApp thread where a technologist reported an out-of-range control at eleven at night. The spreadsheet is an act of archaeology, and it will be redone from scratch before the next assessment. NABL accreditation for a medical laboratory is built on ISO 15189, and the standard's demand is not that a lab be excellent on the day of the assessment. It is that the lab can demonstrate it was in control on any day. That is a records question, and it is where laboratory software either helps or quietly gets in the way. ## The evidence a lab has to produce Strip away the vocabulary and an assessment asks a lab to demonstrate a handful of things, repeatedly, across different tests and different days. - That the sample which produced this result is the sample that was collected from this patient. - That the instrument was in control when the result was produced. - That the person who performed and released it was competent to do so. - That the result reached the right clinician in the right time, and that critical results reached them faster. - That when something went wrong, it was recorded, investigated and closed. - That the reference intervals, methods and units on the report are the ones the lab validated. Each of these is a chain of evidence. Where a link lives on paper or in an analyser's local memory, assembling the chain is manual, and manual assembly is what turns preparation into a six-week project. ## The pre-analytical phase, where most errors actually happen Laboratory quality literature is consistent on this: the majority of errors occur before the sample reaches the analyser. Wrong patient, wrong tube, insufficient volume, haemolysis, delay in transport, wrong preservative. Software earns its place here more than anywhere else. Positive identification at collection, with the label printed at the patient's side rather than pre-printed and carried, closes the most dangerous gap in the process. A pre-printed label that travels to a bedside is an accident with a delay built in. Sample lifecycle timestamps — collected, received, accepted or rejected, run, verified, reported — turn turnaround time from an estimate into a measurement, and turnaround is one of the things a lab must monitor. Structured rejection reasons matter more than they look. If rejections are recorded as free text, the lab cannot tell whether haemolysis is rising in one ward, which is exactly the kind of finding that leads to a real improvement. > The lab that can say "twelve percent of our rejections come from one ward, and here is what we did about it" is demonstrating a quality system. The lab with a rejection register nobody totals is demonstrating a register. ## Quality control that is recorded when it happens Internal quality control is the heart of an assessment and the commonest place preparation falls apart. Control results should be captured as data, with the lot number, the level, the analyser, the operator and the time. Levey-Jennings charts should be drawn from that data rather than maintained separately, because a chart maintained by hand is a chart drawn after the fact. Westgard rule violations need to be flagged, and, crucially, what happened next needs to be recorded against the violation: what was investigated, what corrective action was taken, whether patient results in the affected window were reviewed and recalled. An assessor's follow-up question is almost never "do you run controls". It is "show me a violation and what you did about it". External quality assessment participation, results and any corrective actions belong in the same place, along with the evidence that unsatisfactory performance was investigated rather than filed. The pattern across all of this is the same: it is not the doing that is hard, it is the proving. Labs run controls diligently. They struggle to show, two years later, what happened on the day one failed. ## Competency, calibration and the records that expire Two categories of record share a property that makes them ideal for software: they expire. Staff competency records include initial training, assessment, periodic reassessment, and authorisation to release results for particular tests. A technologist authorised to release biochemistry is not automatically authorised to release histopathology, and the system should know the difference rather than relying on a role called Lab. Equipment records cover calibration, maintenance, service history, temperature monitoring for storage, and validation after repair. Each has a due date. Anything with an expiry date should generate a reminder before it expires and an escalation when it lapses. This is unglamorous automation and it removes an entire class of assessment finding, because most lapses are not negligence. They are a date nobody was tracking. ## Reporting, amendments and the honest audit trail The report is the lab's product, and it carries requirements that are easy to get wrong. It has to identify the patient unambiguously, state the method where the method matters, carry reference intervals appropriate to the patient's age and sex, use the units the lab validated, and be released by an authorised person whose identity is recorded. Amendments are where the audit trail earns its keep. When a result is corrected after release, the original must remain visible, the amendment must be marked as such, the reason must be recorded, and there must be evidence that the clinician who received the original was informed. A system that lets a result be silently overwritten has destroyed exactly the record an assessment wants to see, and has created a clinical risk on the way. Critical result communication needs the same treatment: the value, who was called, when, who took the call, and what was read back. A note saying "informed" is not evidence. It is a claim. ## Preparing without the six-week scramble The lab that finds assessment easy is the one where the evidence is a by-product of the work rather than a separate exercise. - Capture control data in the system as it is run, not on a sheet to be entered later. - Record corrective actions against the violation that triggered them, so the two are permanently linked. - Put every expiring record — competency, calibration, reagent lot, service — on a reminder with an escalation. - Structure sample rejection reasons and review the totals monthly. - Log critical result communication as a structured event with the read-back. - Make amendments additive, never destructive, with a mandatory reason. - Run the reports an assessor would ask for, once a quarter, on an ordinary week. If a report takes two days to produce, that is the finding, and you have found it yourself. Accreditation is often described as a burden, and the paperwork is real. But almost every item on the list above is something a lab wants anyway: knowing which ward sends haemolysed samples, which analyser drifts, which reagent lot underperformed, which results were amended and why. The accreditation just insists you write it down.

Read article
Witnessing in the Embryology Lab: From a Name to an Event — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 6 min read

Witnessing in the Embryology Lab: From a Name to an Event

There is a column on the embryology worksheet headed Witness. Under it, in most labs, is a name written in the same hand as everything else on the page, because the person filling in the sheet wrote both. Nobody involved is dishonest. The second embryologist was standing right there, watched the dish move, and went back to work while a colleague completed the paperwork. The witness happened. The evidence that it happened does not exist. Witnessing is the control that stops the worst thing an ART lab can do, which is give the wrong material to the wrong person. It deserves better than a text field. ## What witnessing is for The lab handles material that is anonymous to the naked eye. A dish of oocytes looks like any other dish of oocytes. A straw looks like a straw. Identity travels entirely on labels, and labels are applied, read and transcribed by tired humans working under time pressure at a heated stage. So at every point where material could be confused, a second person independently confirms identity before the step proceeds. The steps are well known: at retrieval, when oocytes are received from theatre; at insemination or injection, when eggs meet sperm; at denudation; at every change of dish; at freezing and at thawing; and above all at transfer, when material leaves the lab and enters a patient. The last one deserves emphasis because it is where systems most often fall short. Embryo transfer is the highest-consequence identity step in the whole workflow, and it is the one where the witness record is most likely to be missing entirely rather than merely weak. ## The four ways a witness field fails A typed name fails predictably, and each failure has been found in real systems. - It is not required. The field exists, the red asterisk is drawn in the markup, and the client-side check can be bypassed by anything that posts directly to the endpoint. The record saves with no witness at all. - It is not authenticated. Any string is accepted. There is no check that the name belongs to a real person, still works there, or was anywhere near the lab that day. - It permits self-witnessing. Nothing stops the operator entering their own name, and under pressure somebody eventually does. - It can be edited afterwards. If the row can be updated, then what it says today is not evidence of what happened then. There is a fifth, subtler failure. Some systems capture the witness properly at the interface, resolving the typed name to a real staff record with an identifier, and then save only the display text. The identity was in the browser's hands and was thrown away on the way to the database. > A witness you cannot authenticate, cannot verify was a second person, and can edit later is documentation, not a control. ## Witnessing as an event The alternative is to stop treating the witness as an attribute of a record and start treating it as an event in its own right. An event has a subject: which specimen, identified by its own permanent identifier rather than by a description. It has a step: what was being done at that moment. It has two identities: the operator and the witness, both authenticated by whatever the lab uses to establish identity, which means a login or a badge scan and not a keyboard. It has a time, generated by the system rather than typed. And it is written once. Write-once is the property that makes the rest worth having. If the witness event can be updated, everything above it is only as strong as the weakest person with edit rights. Labs that get this right enforce immutability in the database itself, so that no application path, no admin screen and no support script can quietly rewrite history. Corrections are made by adding a further event that says a correction was made, and by whom, which is how every other serious record-keeping discipline handles the same problem. ## Electronic witnessing, and its honest limits Barcode and RFID witnessing systems take the idea further. Every dish, tube and straw carries a machine-readable identity. A reader at the workstation knows what is present. If two items belonging to different patients are on the stage at once, the system stops the step rather than recording that it happened. That hard stop is the real advance. A human witness confirms that the labels match; an electronic system can refuse to let the work proceed when they do not. Removing the possibility beats detecting the error. The limits are worth stating plainly, because vendors rarely do. - It witnesses labels, not biology. If the wrong label went on at the start, the system faithfully confirms the wrong thing all the way through. - It only covers steps where readers are actually deployed. Coverage in the andrology room and at the tanks is commonly thinner than in the main lab. - It is only as good as its exception path. Every lab has moments when the reader fails, and how the system handles a manual override, whether it demands a reason, and whether it flags the override for review, determines whether the control survives a busy Monday. - It generates data nobody reads unless somebody looks. Override rates and refused steps are the most useful quality signal the lab produces, and in most labs nobody has ever run that report. Electronic witnessing is a strong control. It is not a reason to stop thinking about identity. ## What it costs and what it buys The objection is always time. Two people, at every step, in a lab that is already stretched on a heavy retrieval morning. That objection is legitimate and should be answered honestly: witnessing does cost time, and a design that pretends otherwise gets circumvented. What it buys is the ability to answer questions that cannot be answered any other way. Who was present when this embryo was frozen. Whether the transfer on the fourteenth was independently confirmed. Whether the same two people witness for each other every single time, which is a rota problem worth knowing about. And, in the worst case, whether the clinic can demonstrate that its controls were operating on the day something went wrong. That last point is what makes this a management question rather than a lab question. A clinic with immutable witness events can investigate an incident. A clinic with a name column can only apologise. ## A short audit you can run this week You do not need a project to find out where you stand. - Take last month's freezes and transfers. For each, is there a witness record, and does it name somebody other than the operator? - Post a record directly to the endpoint with the witness field empty. Does the server accept it? - Change a witness name on a record from six months ago. Can you? Does anything notice? - Count how often each pair of staff witnesses for each other. If two names account for most of the lab, that is a single point of failure wearing the appearance of a control. - Ask the lab what they do when the barcode reader fails, and compare the answer to what the system actually permits. Most labs already do the witnessing. What they lack is proof, and proof is the part that only matters once.

Read article
What Hospital Management Software Actually Costs in India — Operations | KōamiOperations
Operations· 8 min read

What Hospital Management Software Actually Costs in India

The question arrives in the first meeting, usually within ten minutes, and it is always the same: what will this cost. The honest answer annoys everybody, because it is that nobody can tell you yet. Two 150-bed hospitals in the same city can pay amounts that differ by a factor of four, and both can be getting fair value. What can be explained is where the money goes, which parts are negotiable, and which costs are systematically left out of the first quotation. ## The three shapes of a price Almost every proposal you will receive is one of three structures, and the structure matters more than the headline number. Perpetual licence with annual maintenance. You pay a large sum once for the right to use the software, then an annual maintenance charge — usually somewhere between fifteen and twenty-two percent of the licence value — for support and updates. Heavy capital expenditure, lower ongoing cost, and the software is yours to keep running even if the relationship ends. Common with on-premise deployments and with hospitals that have capital budgets but tight operating ones. Subscription, priced per bed or per user per month. Lower entry cost, everything bundled, and the vendor carries the infrastructure. Over five to seven years the total often exceeds the perpetual route, but the risk profile is different and the hospital is not left maintaining its own servers. Hybrid. A smaller licence fee plus a subscription for the hosted components. Increasingly the default, and the one that most needs reading carefully, because it is easiest to hide a growth term in. Per-bed pricing is the commonest metric in the Indian market, and it needs a definition in the contract. Sanctioned beds, operational beds, or occupied beds are three quite different numbers, and hospitals that agree to per-bed pricing without defining which one have handed the vendor a lever. ## What the first quotation usually leaves out The gap between the quoted figure and what the project actually costs is rarely the vendor being dishonest. It is that the quotation covers software and the project involves a hospital. - Implementation and configuration. Master data, tariffs, packages, user roles, department structures, document templates. This is real work, usually costs between a quarter and a half of the licence value, and is the single biggest determinant of whether the system succeeds. - Data migration. Bringing over patient master records, outstanding balances, stock on hand and open admissions. Priced by how bad the old data is, which nobody knows until they look. - Training. Not one session. Initial training, refresher training after go-live, training for the next intake of staff, and material that survives the trainer leaving. - Go-live support. On-site presence for the first week or two. Some vendors include it, some price it separately, and the difference in the quotation can be substantial. - Hardware and network. Servers or cloud capacity, workstations, label and barcode printers, scanners, tablets for wards, uninterruptible power, and the wireless coverage that ward-side use depends on. Wi-Fi in older buildings with thick walls is a recurring surprise. - Third-party components. Database licences if the platform needs commercial ones, SMS and WhatsApp gateways, payment gateway charges, digital signature certificates, analyser interfacing licences that are often charged per instrument. - Integrations. PACS, lab analysers, ABDM and ABHA, insurance and claims connectivity, accounting systems, biometric devices. Frequently quoted as "included" in the sales conversation and as a line item in the contract. - Customisation. Every hospital has processes it will not change. The first year of change requests is a predictable cost that no first quotation contains. - Internal cost. The staff time given to the project. This is real money and never appears in any document, but it is often the largest number of all. > Ask for the total cost over five years, including implementation, migration, training, hardware, integrations and annual maintenance. A vendor who cannot produce that has not thought about your project. ## What actually drives the number Bed count is the metric everyone uses and it is a weak predictor. The things that genuinely move the price are these. Scope. A registration, billing and pharmacy deployment costs a fraction of one that includes EMR, nursing charting, theatre, lab, radiology, blood bank and specialist modules. Most cost surprises are scope creep in disguise. Number of sites. Multi-branch adds consolidated reporting, cross-site master data, per-site configuration and considerably more testing. Integration count. Each interface is a small project. Ten of them is not ten times a little; it is a programme. Data migration difficulty. Twelve years of inconsistent records with duplicate patient identities and free-text diagnoses costs far more to migrate than three years of clean data. Deployment model. On-premise means servers, redundancy, backup infrastructure and somebody to run it. Cloud shifts that into a recurring line and into somebody else's competence. Customisation appetite. The hospitals that spend most are the ones that ask the software to reproduce their existing forms exactly rather than adopting a workable standard. Compliance requirements. NABH, NABL, statutory registers and regulatory reporting each imply configuration and validation work. ## Where hospitals genuinely waste money Some patterns repeat often enough to be worth naming. Buying modules that will not be used for three years, because the bundle was discounted. The discount is real; the maintenance you pay on unused modules for three years is also real. Under-investing in implementation to protect the licence budget. This is the most expensive saving available. A well-implemented mid-range system beats a badly implemented premium one, every time and by a wide margin. Skipping the data cleanup and migrating the mess. The mess follows you, and it is more expensive to fix once it is live. Treating training as a one-off. Staff turnover in Indian hospitals is high enough that a system trained once is a system half-used within eighteen months. Signing without an exit clause. Ask what happens to your data if you leave: in what format, at what cost, over what timeline. A vendor who has not thought about this has told you something important. ## What are the actual price bands in India? Published 2026 pricing across the Indian market clusters into recognisable bands, and it is more useful to know the bands than to be told that it depends. Cloud subscriptions quoted per facility commonly run from a few thousand rupees a month for a small clinic to the mid five figures a month for a hospital, while per-user pricing typically sits in the low hundreds of rupees per user per month. Per-user looks cheaper on the first page and frequently is not: at fifty users, a few hundred rupees a month each becomes a materially larger annual number than a flat facility plan, and hospitals rarely model it at the headcount they will actually have in year three. Perpetual licences with annual maintenance still exist, mostly from on-premise-origin vendors, and are usually quoted as a large first-year number with maintenance at a percentage of licence value each year afterwards. Custom builds occupy their own range entirely and should be compared against the sections above on continuity risk rather than on price. Treat all of these as the shape of the market rather than as a quotation. The band a specific hospital lands in is set by the drivers in the previous section — bed count, module scope, sites, integrations and migration — and any vendor quoting from a rate card without asking about those has not scoped your project. ## What should a small hospital expect to pay? Less than the enterprise band and on a simpler shape, and the shape matters more than the number. A 10-to-80 bed hospital or nursing home should be looking for flat, predictable pricing, a go-live measured in days rather than quarters, and OPD, IPD, billing and pharmacy without the configuration overhead of an enterprise deployment. The trap at this end of the market is a low monthly figure attached to a system that cannot do package billing, statutory registers or a second branch — the price is real and so is the ceiling you will hit in year two. The [small hospital guide](/hospital-management-software-for-small-hospitals) covers what to insist on without paying for what you do not need. One credit that belongs in a small hospital's model and almost never appears: facilities on the Health Facility Registry with ten or more beds may be eligible under the [Digital Health Incentive Scheme](/blog/digital-health-incentive-scheme) for ABHA-linked records they were going to create anyway. ## A workable way to compare quotations Reduce every proposal to the same shape before comparing. - Total five-year cost, all lines included, no exceptions. - What is in scope at that price, module by module, in writing. - What each additional module, site and integration costs, with the numbers in the contract rather than in a conversation. - Annual escalation on maintenance and subscription. An uncapped escalation clause is worth more than most negotiated discounts. - Support terms: hours, response times, whether on-site support is included, and what happens at 2am on a Sunday. - Implementation timeline with payment milestones tied to delivered outcomes, not to elapsed calendar time. - Data exit terms. Then, before signing anything, run a paid pilot in one department with your own data and your own staff. It costs a little and reveals more than any demonstration, because a demo shows the software working on the vendor's data with the vendor driving. The number that matters is not what the system costs. It is what it costs you when it does not work.

Read article
NHCX and What It Changes About Getting Paid — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 7 min read

NHCX and What It Changes About Getting Paid

The insurance desk of a mid-sized hospital runs on portals. One for each insurer, one for each TPA, each with its own login, its own document naming convention, its own idea of what a pre-authorisation form should contain, and its own habit of timing out at four in the afternoon. A senior executive spends her day switching between fourteen browser tabs, uploading the same discharge summary in three different formats, and telephoning to ask why a query was raised on a claim that was already answered. The National Health Claims Exchange is an attempt to replace that with one road. ## What it is NHCX is a gateway, built under the National Health Authority alongside the insurance regulator, through which claims-related information moves between hospitals, insurers and TPAs in a standard, machine-readable form. It sits inside the wider ABDM framework and uses the same health data standards, which in practice means FHIR resources rather than PDFs and portal forms. The important word is exchange. NHCX does not adjudicate claims or decide what is payable. Insurers still make those decisions using their own policies and rules. What changes is the transport and the format: instead of every hospital integrating separately with every payer, both sides connect to a common exchange and speak a common language. - One integration for the hospital, rather than one per payer. - Structured data instead of documents that have to be read by a human. - Defined message types for pre-authorisation, claim submission, queries and responses. - A traceable path, so both sides can see where a claim actually is. ## Why the current process is expensive The cost of the portal-per-payer world is easy to underestimate because it is spread across people rather than concentrated in a line item. Re-keying is the obvious part. Data that already exists in the hospital system is typed again into a portal, and every re-keying is an opportunity for a mismatch between what the claim says and what the record says. Those mismatches are a leading cause of queries. Then there is the waiting. A pre-authorisation that takes a day is a patient occupying a bed while the family waits for a decision. Discharge planning that depends on a portal response arriving is discharge planning that cannot be planned. And there is the invisible cost: nobody can tell you, at any given moment, how much money is sitting in claims, at what stage, with which payer, and how long it has been there. The answer exists across fourteen portals and one spreadsheet that is updated when somebody has time. > The real cost of the portal era is not the effort. It is that a hospital cannot see its own receivables without assembling them by hand. ## What has to be true inside the hospital first This is the part that gets skipped. Connecting to an exchange does not fix a claims process; it exposes it. Structured claims demand structured source data, and most hospitals discover their gaps at exactly the wrong moment. - Coding. Diagnoses and procedures must be coded consistently, not written as free text. A claim that says "fever, r/o dengue" cannot be structured, and the coder downstream is guessing. - Charge capture. If consumables and procedures are added to the bill hours or days after they happen, the claim assembled at discharge is incomplete, and the shortfall becomes a query or a write-off. - Package and tariff mastery. Package definitions, exclusions and payer-specific rates have to be current in the system. A tariff master that is six months stale produces claims that are wrong before they are sent. - Documents. Discharge summaries, investigation reports and implant stickers need to be attached to the claim from the record rather than scanned and hunted for. - Patient identity. Name, policy number and identifiers must match what the payer holds. A large share of rejections is nothing more than a mismatched name or an incorrect policy number. A hospital with these in order gets most of NHCX's benefit almost immediately. A hospital without them gets a faster route to the same rejections. ## What actually improves Assuming the groundwork, the changes are concrete. Pre-authorisation turnaround falls, because the request is structured and machine-readable and the payer's system can act on it without a person reading a PDF first. Not every case, and not instantly, but the routine ones stop waiting behind the difficult ones. Queries become specific. A structured query points at a field, rather than arriving as a line of text asking for clarification, and can be answered from the record rather than by composing an email. Status becomes visible. Because messages are exchanged rather than uploaded, the hospital's own system knows where each claim is. That single change is what makes a genuine receivables dashboard possible: how much is submitted, queried, approved, rejected and paid, by payer and by age, without anybody assembling it manually. And first-pass rates improve, for the unglamorous reason that structured submissions carry fewer transcription errors than re-keyed ones. ## What does not change It is worth being blunt about the limits, because expectations that outrun reality produce disappointment and then disengagement. Insurers still decide. Adjudication rules, exclusions, waiting periods and medical necessity assessments remain entirely with the payer, and a well-formed claim for something the policy excludes is still declined. Coverage builds gradually. Not every insurer and TPA arrives at the same time, so hospitals run the exchange alongside existing portals during the transition, and the transition is longer than anyone plans for. Bad data is still bad. The exchange transports what it is given. A claim built on stale tariffs and late charge capture arrives faster and is rejected on schedule. And clinical documentation still has to justify the claim. Structuring the envelope does not improve the letter inside it. ## Where NHCX has actually got to The exchange moved from announcement to operation, and the useful question is no longer whether it will happen but whether your payers are on it yet. Payer and provider onboarding has continued steadily, with published National Health Authority figures running to tens of thousands of registered provider facilities and claims processed in the tens of millions. Take the current numbers from the NHA's own dashboards rather than from any comparison article, including this one — adoption reporting in this area moves faster than the articles describing it. The distinction that matters when you read those figures is between registration and transaction. A payer being onboarded to the exchange is not the same as that payer processing your claims through it at volume, and a hospital that plans on the first number will be disappointed by the second. Ask each of your major insurers and TPAs a narrow question: are you accepting pre-authorisation and claim submission for our facility over NHCX today, and if not, when. The answers will vary by payer and will decide how long you run the exchange and the portals in parallel. There is also now money attached. Claims routed through the exchange fall under the National Health Authority's incentive arrangements, and the wider [Digital Health Incentive Scheme](/blog/digital-health-incentive-scheme) pays health facilities for ABHA-linked records — the same records a well-formed NHCX claim depends on. Neither is large enough to justify a software purchase by itself. Both are large enough that a hospital doing the work anyway should be counting them, and most are not. ## What FHIR has to do with any of this Everything, and it is the part hospitals discover last. NHCX moves claims as [FHIR resources](/blog/hl7-fhir-india), which means the exchange inherits whatever structure your clinical record does or does not have. A hospital whose diagnoses are free text and whose reports are scanned PDFs can technically submit over NHCX. What it submits is a structured envelope wrapped around unstructured content, which passes transport validation and then generates exactly the queries the portal era generated. The exchange rewards the preparation described below; it does not perform it. ## Preparing without waiting The useful thing about NHCX readiness is that almost every step is worth doing on its own merits, whether or not the exchange arrives on your timeline. - Measure first-pass claim rate and query rate by payer. If you cannot, that is the first finding. - Age your receivables by payer and by stage, once, manually. It will be uncomfortable and it will tell you where the money is stuck. - Fix charge capture at the point of care, so the bill is complete when the patient leaves. - Get the tariff and package masters current, and put a review cycle on them. - Move diagnoses and procedures to coded fields. - Ask your HIS vendor a direct question: are you building NHCX and ABDM connectivity, on what timeline, and at what cost. - Sort out ABHA linking and patient identity capture at registration, because identity errors are the cheapest rejections to eliminate. The hospitals that will benefit most from a claims exchange are the ones whose data was already clean enough to send. The exchange rewards the preparation; it does not substitute for it.

Read article
The Cryobank Question: Where Exactly Is Straw 1188? — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 6 min read

The Cryobank Question: Where Exactly Is Straw 1188?

A patient who froze embryos four years ago has moved cities and wants them transferred to a clinic near her new home. The request arrives by email on a Tuesday. The embryologist goes to the register, finds her name, and reads the entry: straw 12, blue, second position. Two of the three tanks have been reorganised since then. The person who did the reorganising left last year. It takes most of an afternoon, two people and a nitrogen top-up to establish, with reasonable confidence, that the material is where they now think it is. Everybody involved is competent. The record was simply never designed to answer the question being asked. ## Free text is the root of it Cryo location, in most systems, is two or three free-text fields. Straw number. Colour. Position. There is no pattern, no picklist, nothing mandatory, and the fields carry whatever convention the person on duty was using at the time. Over a few years a single tank accumulates several vocabularies, and they are all valid to the software. A storage address is a hierarchy, and it should be recorded as one. - Tank, which is a physical vessel with an identity of its own. - Canister within the tank. - Cane within the canister. - Goblet within the cane, where the clinic uses them. - Straw or vial, which carries its own permanent identifier. The point is not tidiness. It is that a structured address can be validated, searched, counted and reconciled against what is physically in the tank. A free-text address can only be read and interpreted, which is a job for a person who was there. ## The update that erases the past The more serious problem is what happens when material moves, and it moves more than people expect: a tank is decommissioned, a canister is consolidated, material is transferred to another clinic, straws are moved to make room. In most systems the move is an update. The record is edited to show the new position, and the previous one is gone. All that survives is a modified-by and a modified-on, which tells you somebody changed something at some point and nothing at all about what it was before. That single design decision destroys the chain of custody. Chain of custody is not knowing where something is. It is being able to show every place it has been and who moved it, without gaps. An update-in-place record can never demonstrate that, because the evidence is overwritten by the act of recording. > If relocating a straw erases where it used to be, you do not have a cryobank record. You have a current guess with a timestamp. The fix is structural and cheap: movements are inserts, never updates. Every event — frozen in, relocated, thawed, transported out, discarded — is a new row carrying the specimen, the source address, the destination address, the reason, the person, the witness and the time. Current location is derived from the latest event rather than stored as a mutable field. Nothing is ever overwritten, so nothing can be lost. Clinics often discover this at the worst moment: when they want to introduce it, and the tanks are already full. The best time to put a structured, insert-only model in place is before there is anything in the table to migrate, and the second best time is now, because the volume only grows. ## What a cryobank record has to carry beyond location Location is the obvious part. The rest is what turns a location log into something a clinic can actually run on. - Ownership and consent. Whose material this is, what they consented to, and what happens at the end of the agreed storage period. This is the field that generates every difficult conversation, and it is frequently absent. - Storage term and renewal. When the current term expires, who was notified, when, and how they responded. Renewal reminders that live in somebody's calendar are not a system. - Disposition. What is to be done at expiry or on withdrawal of consent, recorded in advance rather than decided under pressure. - Witness. Cryo steps often have no witness field at all, not even the weak typed-name kind. Freezing and thawing are identity-critical steps and need the same treatment as any other. - Transport. When material leaves the building, who released it, to whom, under what conditions, with what acknowledgement of receipt. - Discard. The most consequential action in the whole module, and the one that most deserves a two-person authorisation and an immutable record. ## The tank has its own record Software people think about the data. The people who run the lab think about the vessel, and the vessel needs a record too. Nitrogen levels and top-up history. Temperature monitoring and alarm events, including who acknowledged each alarm and how quickly. Service history. Age of the tank, because vacuum-jacketed vessels do fail, and they usually give warning in the form of rising consumption that nobody was tracking. A cryobank inventory that knows exactly where every straw is, in a tank whose nitrogen history nobody has looked at in eight months, is only half a system. The most consequential cryostorage incidents are equipment failures, not clerical ones, and the warning signs are usually visible in consumption data that was collected and never reviewed. ## Reconciliation is the test Everything above can be true in the software and false in the tank. The only way to know is to reconcile: take a canister, list what the system says is in it, and check physically. Do it on a schedule, do it on a sample rather than everything at once, and record the result including the discrepancies. Every clinic finds discrepancies the first time. The number matters less than the trend, and than whether the reconciliation itself is recorded, because an unrecorded reconciliation has the same evidentiary weight as one that never happened. A first pass usually surfaces the same handful of causes: material moved in an emergency and recorded later, if at all; straws consolidated during a reorganisation with the register updated in bulk; entries where the straw number was recorded but not the position, because the field was optional; and material belonging to couples who stopped responding years ago, whose disposition nobody has been willing to decide. That last group is the real backlog in most Indian clinics, and it does not shrink on its own. It needs a policy, a documented attempt to make contact, and a decision recorded against each specimen — which is only possible if each specimen has an identity in the first place. ## Where to start If your cryo record is three text fields, you do not need to fix everything at once. - Give every straw a permanent identifier, and stop describing material by colour and position. - Make the address structured, with tank, canister, cane and goblet as separate validated fields. - Make movement insert-only. This is the single highest-value change, and it is a schema decision, not a workflow one. - Add a witness to freeze, thaw, transport and discard. - Run one reconciliation on one canister, and record the result honestly. The clinics that handle this well are not the ones with the newest tanks. They are the ones that can answer, in under a minute and without walking to the lab, where straw 1188 is and every place it has been.

Read article
The ART Act and the Records a Fertility Clinic Has to Keep — Fertility & IVF | KōamiFertility & IVF
Fertility & IVF· 7 min read

The ART Act and the Records a Fertility Clinic Has to Keep

The inspection question that catches clinics out is never the difficult one. It is not about culture media or air quality. It is somebody asking to see the consent that a specific couple signed before a specific procedure, on a specific date, in the version that was current at the time. The clinic has the consent. It is in a folder, or a scan named by date, or in a cupboard behind the counter. Producing it takes forty minutes, and the forty minutes is the finding. India's Assisted Reproductive Technology (Regulation) Act, 2021 and its companion surrogacy legislation moved fertility practice from professional convention to statutory obligation. Most of what the law asks for is not clinically new. What changed is that a clinic now has to be able to prove it, on demand, years later. ## What the law is actually asking of a clinic The specifics belong in the bare Act, the Rules and whatever your state authority has issued, and you should read the current text rather than a summary. But the shape of the obligations is stable, and it is worth being clear about what that shape demands of a record system. - Registration. ART clinics and ART banks are registered entities, listed on the national registry, with the level of service they are registered to provide. - Reporting. Clinics report cycle-level information to the national registry rather than keeping results as a private matter. - Consent. Written, informed consent in the prescribed form from the commissioning couple and, separately, from donors. - Donor governance. Donors come through registered ART banks, with screening, and with limits on how donor gametes may be used. - Eligibility. Age limits apply to the commissioning couple, and a clinic is expected to have verified them. - Records. Retained for a defined period and available to the authority on request. Nothing in that list is unreasonable. All of it is nearly impossible to satisfy reliably if the underlying record is a mixture of a hospital billing module, a spreadsheet and a stack of scans. ## The registry submission is a data problem, not a paperwork problem Registry reporting is where the gap between a clinic that records structured data and one that does not becomes financial. If cycle type, protocol, age at treatment, number of oocytes retrieved, number fertilised, embryos transferred, and the pregnancy outcome exist as fields, the submission is an export. If any of them lives in free text, in a consultant's notes, or only in the embryologist's day sheet, the submission is a project: three people, two weeks, reconstructing a year from memory and paper. The reconstruction is where errors enter. Nobody misreports deliberately. They misreport because the only surviving record of what happened on a Thursday in March is ambiguous, and somebody has to make a call under deadline pressure. > A registry return assembled at the deadline reflects what could be found, not what happened. Those are different numbers, and only one of them is defensible. There is a second-order point that clinics discover late. The export itself should be logged: who ran it, for which period, with what row count, and what was included. When a discrepancy surfaces two years later, the difference between an awkward conversation and a serious one is being able to show exactly what was submitted and when. ## Consent, in the only form that survives a challenge Consent is the obligation that most often exists on paper and fails in practice, and the reasons are mundane. The form changes. A clinic updates its consent text after legal review, and now there are three versions in circulation. A couple who signed in 2024 signed something different from what the current form says. If the system stores only the current text, the clinic can no longer show what was actually agreed. The signature is separated from what it covers. A scanned page in a folder proves somebody signed something. It does not prove which procedure it authorised, or that it preceded the procedure. Withdrawal is not modelled. Consent can be withdrawn, and in ART that withdrawal has immediate consequences for stored material. A system with no concept of withdrawal will happily let a procedure proceed against material the couple no longer consents to. What a defensible consent record looks like is not complicated: the exact text that was signed, captured as a snapshot rather than a pointer to a document that will later change; each signer identified, with their role and the time; the procedure it covers named; and a withdrawal path that takes effect where it matters, which is at the point the procedure is attempted. ## Donors, and the compartment nobody plans for Donor records carry an obligation ordinary clinical records do not: the identity is confidential, but the screening, the consent and the link to the recipient cycle all have to be provable. Those two requirements pull in opposite directions, and the resolution is access control rather than omission. In practice that means donor identity sits in its own compartment, with permission to view it granted narrowly and every view logged, while the screening results, the consent status and the linkage remain visible to the people who need to act on them. Clinics that instead handle this by keeping donor details in a separate offline register end up with the worst of both: the identity is less secure, not more, and the linkage is unprovable. The screening itself has a failure mode worth naming. If the screening form has no mandatory fields on the server side, records get saved with the infection screening blank, because the person filling it in was interrupted and meant to come back. A screening record without a result is not a record of a negative result. It is a record of nothing, and it is indistinguishable from one at inspection. ## Retention means the record has to still be readable Retention periods are the part of compliance that gets agreed in a meeting and then quietly ignored, because the deadline is years away and nothing enforces it. But retention has practical consequences for how the record is built. - Data on a workstation's local storage is not retained. Browser storage is not a record; it survives until somebody clears a cache or replaces a machine. - Scans on a shared drive with no index are retained but not retrievable, which for an inspection is the same thing. - Records that can be silently edited are retained but not trustworthy. If a clinical entry can be changed without a trace, its evidentiary value at year five is close to zero. - Signed records need an amendment model. The correct behaviour is an addendum that leaves the original visible, not an overwrite. The general principle is that a record you can amend without trace is not a record; it is a current opinion about the past. ## What to do before the next inspection If you want a practical sequence rather than a compliance programme, this order works because each step is verifiable on its own. - Pick five completed cycles at random and try to assemble the full file for each: consent versions, screening, cycle detail, lab records, witness entries, outcome. Time yourself. The ones that take longest tell you where the record is actually broken. - Make the consent snapshot real. Store the text that was signed, not a reference to a document that changes. - Make screening fields mandatory where the server writes them, not only in the form. - Give every specimen an identity, and make witnessing an event with an authenticated second person. - Structure the fields the registry asks for, so the annual return is an export rather than an archaeology project. None of this is about the law being demanding. The law asks a clinic to be able to show what it did. The clinics that struggle are not the ones practising badly; they are the ones whose records were built to run today's list rather than to answer a question in 2031.

Read article
Ransomware in a Hospital: The First Six Hours — Data Security | KōamiData Security
Data Security· 7 min read

Ransomware in a Hospital: The First Six Hours

It starts at 02:40 with the night duty technician noticing that a report will not print. By 03:15 the registration counter cannot open a patient record and the error is the same on every terminal. By 04:00 somebody finds a text file on a shared folder explaining, in confident English, what has happened and where to send payment. The casualty officer is still admitting patients, because casualty does not stop, and there is now no system to admit them into. Every hospital IT head has imagined this. Fewer have decided, in advance, what happens next. ## The hospital-specific part Ransomware in a hospital differs from ransomware in a factory in one respect that changes every decision: the operation cannot pause. Patients in beds still need drugs, ventilated patients still need monitoring, and the theatre list has people already fasting. That reality drives three constraints most incident plans ignore. - Clinical continuity comes first and is not a technology decision. It belongs to the medical superintendent, not to IT. - Systems cannot simply be switched off wholesale to contain the spread, because some of them are keeping people alive. - The organisation cannot go quiet while it investigates. Patients keep arriving at the gate. The plan therefore has to be written by clinical leadership and IT together, or it will be a plan for a business that can close for a day. ## The first six hours The sequence below is deliberately mundane. Under pressure, at four in the morning, people execute what is written down and little else. Contain, but selectively. Isolate the network segments that are spreading rather than pulling every cable. Disconnect from the internet and between sites. Preserve the ability of clinical monitoring to keep monitoring. Declare, and say the word. Somebody has to say "this is a ransomware incident" out loud, because until it is declared, everyone is still troubleshooting a printer problem. Name in advance who has the authority to declare it, and make sure that person is reachable at night. Go to downtime procedures. This only works if they exist on paper, physically, and staff have used them. More on this below, because it is where hospitals live or die. Preserve evidence. Do not wipe and rebuild the first affected machine. It holds what you need to understand how far this went. Take images before anyone starts fixing. Notify. CERT-In's directions require reporting cyber incidents within a tight window, measured in hours, not days. Have the contact details and the reporting format ready in advance, because finding them at 05:00 wastes the window. If personal data is involved, data protection obligations run in parallel and need their own clock. Assess the backups, carefully. The first question is not whether backups exist but whether they are reachable from the compromised network. Modern ransomware looks for backups first, and a backup server on the same domain is usually already encrypted. Communicate internally. Wards need to know what is down and what to do. A single message from a named person beats twenty versions circulating on WhatsApp. ## Downtime procedures are the actual control Every hospital has a folder called Downtime Procedures. In most, it was written for a two-hour power cut, printed once, and filed somewhere nobody can now find. A downtime procedure that works for a multi-day outage looks different. - Paper forms exist, physically, in the departments that need them: registration, OPD, casualty, pharmacy, lab, radiology, billing. Printed, in a labelled box, in a location every shift knows. - A manual numbering scheme for registrations and admissions is defined in advance, so records created during downtime can be reconciled afterwards without collisions. - A read-only copy of critical data is available offline. Current inpatient list with diagnoses and drug charts, allergies, and the theatre schedule. Some hospitals print this nightly for exactly this reason, and it looks wasteful right up until the night it is the only patient list in the building. - The pharmacy knows how to dispense and record without the system, including narcotics, where the register is a statutory obligation that does not pause. - The lab knows how to receive requests and issue results on paper, with a plan for how those results get back into the system later. - Everybody knows the back-entry plan: who types the backlog in, in what order, and by when. This is the phase that takes longest and gets least attention. Staff should have practised at least once. A drill during a quiet afternoon, with the systems deliberately made unavailable for an hour, teaches more than any document. > The measure of readiness is not whether you have a downtime folder. It is whether the ward clerk on night duty knows where it is. ## Backups, and the only question that matters Every hospital says it has backups. The question is narrower: when did you last restore one, and how long did it take? A backup that has never been restored is a hypothesis. The failure modes are boringly consistent — the job had been failing silently for weeks, the backup was on a share the ransomware also encrypted, the restore worked but took four days because nobody had measured, or the database restored while the document store did not and half the record came back. What survives a serious incident is offline or immutable copies that cannot be modified even with domain administrator credentials, kept separate from the production environment, and tested by an actual restore on a schedule with the elapsed time written down. The recovery time you can prove is the only one you have. ## The prevention that pays None of the above prevents anything. Prevention is unglamorous and mostly known. Multi-factor authentication on every remote access path, especially the vendor support routes that exist on almost every hospital network and are rarely inventoried. Patching, particularly of internet-facing systems. Network segmentation, so that biomedical equipment and administrative desktops are not on the same flat network as clinical servers. Removing local administrator rights from ordinary workstations. Email filtering and phishing awareness, which is where most intrusions still begin. Biomedical devices deserve a paragraph of their own. Many run operating systems that cannot be patched without voiding a service contract, and they sit on the network because they must exchange data. They cannot be secured like a laptop, so they need to be isolated: their own segment, tightly controlled traffic, and monitoring that notices when one starts behaving unlike a monitor. ## The question that reveals everything Ask the hospital's IT head one question: if the primary database were encrypted right now, when was the last successful restore test, and how long did it take? An answer with a date and a duration means somebody has done the work. Anything vaguer means the recovery plan is a hope, and the first time it is tested will be the night it is needed.

Read article
How to Choose the Right Hospital Management System (HMS) in 2026 — Product | KōamiProduct
Product· 8 min read

How to Choose the Right Hospital Management System (HMS) in 2026

Picking a hospital management system is one of those decisions that shapes how an entire organisation works for the next decade. Get it right and the software disappears into the background, quietly making every department a little faster and a little more accurate. Get it wrong and you spend years working around the system instead of through it, re-entering data, chasing reports, and wondering why the thing that was supposed to simplify everything became the thing everyone complains about. This is a practical guide for hospital administrators, IT leads, and clinical directors who are evaluating HMS platforms in 2026. It does not rank vendors. It lays out the questions that actually separate a good choice from an expensive regret. ## Start with the problem, not the feature list The first mistake most hospitals make is starting the evaluation with a vendor demo. The demo is designed to impress, and it usually does, but it answers the wrong question. It shows what the software can do. It does not show whether the software solves the problems your hospital actually has. Before you see a single demo, get clarity on what is broken today. - Where do staff re-enter data that already exists somewhere else in the hospital? - Which reports take days to compile because the data lives in separate systems? - Where are the revenue leaks: unbilled services, rejected claims, missed charges? - Which workflows depend on phone calls and WhatsApp messages because the systems do not talk to each other? - What keeps your IT team up at night: security gaps, downtime, data migration risks? Once you have that list, you have your evaluation criteria. Every vendor demo should be measured against it. A feature that is not solving one of your real problems is a feature you will never use. ## Unified vs best-of-breed: the decision that shapes everything else This is the strategic fork in the road, and most hospitals do not frame it as a deliberate choice. They drift into best-of-breed by buying point solutions one at a time, a lab system here, a billing module there, and an EMR from a third vendor. Each solves its own problem well enough, but together they create the integration burden that becomes the hospital's biggest operational drag. The alternative is a unified platform where clinical, financial, workforce, and supply chain modules share a single patient identity, a single data model, and a single login. The trade-off is real: a unified platform may not have the deepest feature in every vertical, but it eliminates the data silos that cost you more than any missing feature. Ask yourself honestly: - Can your IT team maintain integrations between five or six different vendors indefinitely? - Can you afford the reconciliation effort when patient data lives in three databases? - Do you have the middleware budget and the staff to keep HL7 or FHIR bridges running reliably? - Will your clinicians tolerate logging into four different systems during a single patient encounter? For most hospitals in India, especially those between fifty and five hundred beds, a unified platform is the pragmatic choice. The integration effort of best-of-breed is a hidden tax that scales with volume, and it rarely gets cheaper. > The best HMS is not the one with the longest feature list. It is the one where every module already knows what the others know. ## Cloud-native or on-premise: where the industry has moved Five years ago this was a genuine debate. In 2026, the question is less whether to go cloud and more how to go cloud responsibly. A cloud-native HMS eliminates the capital cost of server hardware, removes the burden of patching and backups from your IT team, and enables access from anywhere, which matters enormously for multi-branch hospital chains and remote consultations. The concerns that remain are legitimate and deserve straight answers, not vendor hand-waving. - Data residency: where exactly does the data sit, and does the vendor support hosting within India? - Uptime: what is the SLA, and what happens during an outage? Is there a local fallback? - Security: is data encrypted at rest and in transit, and who manages the encryption keys? - Exit: if you leave the vendor, can you export your data in a standard format, and how long does it take? A vendor that cannot answer these clearly is not ready for your hospital. A vendor that answers them well makes on-premise hard to justify for most organisations. ## Clinical depth matters more than clinical breadth Many HMS platforms advertise dozens of modules. The number of modules is not the metric. The depth of each module is. A billing module that handles only cash billing and cannot process TPA pre-authorisations, package billing, or CGHS and ECHS claims is not saving your billing team any work. An EMR that stores notes as unstructured text but cannot generate a structured discharge summary is creating data, not clinical value. The areas to probe deeply during evaluation: - OPD and IPD workflows: does the system handle your actual patient journey, from token to billing to discharge, or does it force your processes to fit its design? - Pharmacy: does it support batch and expiry tracking, FEFO dispensing, NDPS registers, and drug interaction alerts? - Laboratory: does it interface with your analysers, or does the lab tech re-type results from a printout? - Radiology and imaging: is there a built-in PACS viewer, or does the system hand off to a separate application with a separate login? - Billing and revenue cycle: does it handle the Indian payer landscape, TPA, CGHS, ECHS, Ayushman Bharat, package deals, and the back-and-forth of pre-authorisation? The answer to all of these should be a live demonstration on realistic data, not a slide deck with screenshots. ## Indian compliance is not optional An HMS built for a global market will not handle the specifics of Indian healthcare operations without significant customisation, and customisation is where budgets go to die. The compliance requirements you need out of the box include: - ABDM and ABHA integration for the national health stack - GST-compliant invoicing with proper HSN codes for medical consumables - Statutory payroll if the workforce module is included: PF, ESI, professional tax, TDS - NABH documentation support for hospitals pursuing or maintaining accreditation - Drug schedule compliance, including Schedule H, H1, and NDPS tracking If the vendor treats these as roadmap items rather than current capabilities, you will be the one filling the gap manually. ## Interoperability is the feature nobody sees but everybody needs A hospital does not exist in isolation. It sends lab reports to referring physicians, receives referrals from primary care centres, files claims with insurers, reports data to government portals, and exchanges imaging with external radiologists. An HMS that cannot interoperate is an island, and islands create manual workarounds. The baseline you should expect: - Open REST APIs for integration with existing systems: ERP, finance, or legacy modules you are not replacing immediately - HL7 or FHIR support for clinical data exchange - ABDM integration for consent-based health record sharing - Webhook support so external systems can react to events in real time - Export capabilities in standard formats so you are never locked in Interoperability is also insurance. The vendor you choose today may not be the vendor you use forever. A system that lets data flow in and out cleanly is a system you can leave without a crisis. ## Mobile access is no longer a nice-to-have A hospital runs around the clock. Clinicians do ward rounds away from desktops. Administrators need dashboards while they are between meetings. Attendance is captured at entry points, not at desk workstations. If the HMS is only usable on a desktop browser, it is already behind. What to look for: - A responsive web application that works well on tablets at the bedside - A native mobile app for clinical workflows like ward rounds, vitals entry, and approvals - Geofenced attendance and check-in for workforce management - Push notifications for critical alerts, escalations, and approvals - Offline capability or graceful degradation if connectivity drops in remote areas The mobile experience should not be a stripped-down afterthought. It should be the same system, with the same data, adapted for a smaller screen and a moving user. ## The total cost is never the license fee Every hospital asks about price, and every vendor quotes a number that is smaller than the real cost. The total cost of ownership includes: - Implementation and data migration: how long, how much hand-holding, and who does the heavy lifting? - Training: how many hours, for how many staff, and what happens when new people join? - Customisation: will the vendor adapt to your workflows, or will you adapt to theirs? - Integration: if you are connecting to existing systems, who builds and maintains those bridges? - Ongoing support: what is included, what is billable, and what are the response times? - Scaling: as your bed count or branch count grows, does the pricing grow linearly or does it jump? A system that costs less upfront but requires six months of parallel running, three rounds of customisation, and a dedicated integration engineer is not cheaper. It is just cheaper on the first invoice. ## Run a pilot before you commit No amount of demos, reference calls, or RFP responses will tell you what a system actually feels like in your hospital. The best predictor is a pilot: a contained, time-bound deployment in one department or one branch, with real staff using real data. A good pilot answers the questions a demo cannot: - How long does it take a nurse to complete a task they do fifty times a day? - Does the billing team actually find the system faster than their current process? - How responsive is the vendor when something breaks at 11pm? - Does the data entry feel natural, or are staff constantly fighting the interface? A vendor confident in their product will welcome a pilot. A vendor that insists on a full commitment before you have touched the system is asking you to take a very expensive bet. ## The checklist that actually matters After evaluating dozens of implementations, here is what separates the hospitals that are happy with their HMS from the ones that are not: - They chose a system that solved their specific problems, not the system with the most features - They prioritised a unified platform over a patchwork of best-of-breed modules - They verified Indian compliance capabilities before signing, not after - They ran a pilot with real users before committing to a full rollout - They evaluated total cost of ownership, not just the license fee - They confirmed interoperability so the system connects to their existing world - They checked that mobile access works for the workflows that happen away from desks Choosing an HMS is not a technology decision. It is an operations decision with technology implications. The right system does not just digitise your hospital. It connects the people, data, and workflows that were always supposed to work together but never had a shared language. That connection, more than any single feature, is what makes the investment worth it.

Read article
Digitising a 30-Bed Hospital Without an IT Department — Product | KōamiProduct
Product· 6 min read

Digitising a 30-Bed Hospital Without an IT Department

A 30-bed nursing home in a tier-2 district town runs on three things: a hardbound register at the front counter, a billing package installed sometime around 2011 that only one person knows how to close properly at day end, and the owner's nephew, who is good with computers. He sets up the printer. He reinstalls Windows when the machine gets slow. When the software throws an error at nine on a Saturday night, he is the one who gets the call. That is the IT department. This is where a very large share of India's inpatient care actually happens — nursing homes, single-speciality units, small general hospitals in district towns. It is also the segment that enterprise hospital information systems fail most reliably, and the reasons are not technical. ## Why enterprise deployments fail at thirty beds Start with the money. The licence is quoted per bed and sounds reasonable. Then comes implementation: discovery, tariff master configuration, data migration, on-site training, consultant travel, integration charges, a change request or two. A 300-bed corporate hospital absorbs that across hundreds of users and several years. A 30-bed hospital can find it exceeds the entire annual software spend, sometimes by a multiple. Nobody collecting a few lakh a month can underwrite a project that costs more to install than to run. Then the calendar. Enterprise deployments assume a hospital-side project owner who convenes workshops, chases sign-offs and escalates slipped milestones. In a 30-bed hospital that person is the medical superintendent, who is also running the OPD, or the owner, who is also a practising surgeon. Workshops get rescheduled. Go-live moves from March to June. By month five the enthusiasm has gone and the counter staff have quietly returned to the register, because the new system slows them down at exactly the hour they cannot afford to be slow. Then the implementation team rotates off to the next project and support becomes a portal, a ticket number and a reply measured in business days. Ask around and the pattern repeats everywhere: registration in the software, billing half in the software and half in Tally, discharge summaries in Word, and the ward on paper. ## Cloud, because there is no server room The single most useful decision a small hospital can make is to not own a server. On paper an on-premise deployment looks cheaper over five years. In practice the "server" is a desktop under the reception counter, sharing a power board with the printer, in a town with four-hour outages and a monsoon that does unkind things to electronics. Nobody sizes the UPS. Nobody tests the backup. The first time anyone discovers the backup has been failing for eleven months is the day the disk dies. Cloud removes the whole category — no patching, no backup regime, no antivirus licence, no annual maintenance contract for hardware. Kōami runs this way for exactly that reason: the hospital's only infrastructure is a browser. The honest trade-off is connectivity. Going cloud means a wired line, a 4G failover, and knowing what happens at the billing counter when both are down. The answer should be a documented fallback — printed receipts, reconciliation the next morning — not a shrug. Any vendor who tells you the internet never goes down in a district town has not spent much time in one. ## Registration and billing first. Everything else waits. Phasing is not a compromise, it is the whole strategy. Start with two things. - Registration. One patient, one MRN, for life. Nothing else works if the same person exists four times under four spellings. This alone repays the project. - Billing. OPD receipts, IPD interim bills, cash and card, and one day-end summary the owner can actually read. Run only that for eight to ten weeks. Let the counter staff get fast. Let the day-end tally match without a manual recount. Only then add pharmacy and stores, then IPD orders and nursing charges, then discharge summaries, then TPA and scheme claims. Going live with everything at once feels efficient and is the most common way these projects die. Fifteen half-learned modules is a worse outcome than two that people trust. ## Sensible defaults, and a number that gets answered Configuration is a tax, and the customer pays it. A discovery workshop that asks a 30-bed hospital to define its bed transfer policy, its ward hierarchy and its charge posting rules is asking questions the hospital has never needed to answer formally. The honest answer is "we do whatever makes sense", which is not a specification. What works is arriving with defaults already in place: a tariff master that can be edited rather than built, ready OPD, IPD and casualty workflows, NABH-shaped documentation templates, standard receipt and bill formats. The hospital changes the ten things genuinely specific to it — consultant list, room categories, package rates — and goes live in days rather than quarters. Kōami ships opinionated for this reason. > If a small hospital needs a consultant to explain its own software, the software has already failed. The same realism applies to support. At eleven at night the ward sister cannot print a discharge bill and the family is waiting to leave. She is not going to raise a ticket on a portal; she is going to photograph the screen and send it to whoever helped her last time. Meeting that is not unprofessional. Refusing to is. Behind the scenes it still gets logged, categorised and fixed properly, but the hospital's entry point stays the channel it already uses at midnight. For a hospital with no IT staff, responsive support is not an add-on to the product. It is most of the product. ## What not to digitise in year one Being honest about scope is the cheapest thing a vendor can do. - Consultant clinical notes. A visiting consultant who spends twenty minutes in the ward will not type. Keep paper notes, scan them against the episode, revisit in year two. - Point-of-care vitals and nursing charts. Tablets at the bedside are a fine idea and a poor second-year priority. - Consumable-level inventory. Start with pharmacy sales and high-value items. Batch and expiry tracking on every gauze roll can wait. - Analytics dashboards. Get six months of clean registration and billing data first. A dashboard built over bad data is worse than none. - Biomedical asset registers and payroll integration. Real value, wrong year. The exception worth doing early is identity. Capturing ABHA at registration and getting the facility and practitioner registrations in order under ABDM costs very little and saves a scramble later. Do the identity groundwork; leave the rest of the health-record linkage until the basics are steady. ## The test at twelve months Not how many modules are live. Not whether the dashboard impresses a visitor. The test is whether the register at the front counter has actually disappeared, whether the day-end collection figure is trusted without a recount, and whether the owner's nephew has got his Saturday nights back. A 30-bed hospital does not need a digital transformation programme. It needs two or three things that work every single day, and someone who picks up the phone when they don't.

Read article
The Day the Fibre Line Was Cut — Operations | KōamiOperations
Operations· 6 min read

The Day the Fibre Line Was Cut

A JCB widening the road outside the gate goes through the fibre at ten past eleven on a Monday. Nobody inside the building knows that yet. What they know is that the registration screen has stopped responding, the OPD display is frozen on token eighty-four, and the pharmacy counter shows a spinner that will never resolve. Four minutes later there are twenty-odd people at the front desk and one clerk telling all of them the same thing: system down hai. Fibre cuts, dead switches, failed transformers, upgrades that go sideways. Ask any hospital IT manager in a tier-2 city for their last three outages and they will give you dates. What varies is not whether this happens. It is whether anybody rehearsed for it. ## The protocol exists. Nobody has read it. Most NABH-accredited hospitals have a downtime policy. It is a document, written for the assessment, produced when asked for, initialled and filed. The distance between owning that document and owning a reflex is the whole story of a bad Monday. A protocol that works fits on a laminated card at every counter and answers four questions inside two minutes: - Who declares downtime? Not IT. The duty manager, because IT is busy diagnosing and someone must call it while they do. - How is it announced? Phone tree, WhatsApp group, a runner with legs. Keep all three, because the one you rely on may be down. - Which forms come out, and from where? A sealed downtime box at registration, casualty, every ward, pharmacy and lab. - How long is it expected to last, and who updates that estimate every thirty minutes? Staff can cope with two hours of paper. They cannot cope with not knowing. ## Registration and billing have to keep moving The instinct is to stop registering patients. It is the wrong instinct. The queue does not stop, it moves outside into the sun and doubles. Paper registration needs three things prepared long in advance. Pre-printed, pre-numbered downtime slips, because the pre-numbering is what makes reconciliation possible later. A rule for the MRN: existing patients keep the number on their old card, new patients take a temporary identifier from a reserved block, never a guessed number and never a series invented at the counter. And a printed tariff sheet for the sixty commonest items, because otherwise the counter starts estimating prices, and estimates become disputes at discharge. Billing moves to a pre-numbered receipt book, tallied against cash each shift. The TPA does not care that your fibre is cut, so keep a paper pre-authorisation pack ready with the insurer helplines, and note the time of every call and the name at the other end. When the query lands three weeks later, that time-stamped scribble is the entire defence. ## The orders that go quiet Lab and imaging are where downtime does real clinical damage, because the failure is silent. A consultant writes an order on paper and assumes it has travelled. Nothing travels. The sample is never collected. Nobody notices for six hours. During downtime, an order becomes a physical object a human being carries. Duplicate requisition slips, one to the lab with the sample and one retained in the file. A logbook at lab reception recording time in, time out, and whoever carried the report back to the ward. Radiology keeps working, since a CT does not need the HIS to scan, but images sit on the modality and the report is handwritten. Critical values go to the ward sister by phone, read back, recorded at both ends. > During downtime, your audit trail is a person with a pen. Treat it as seriously as the database you have lost. ## Back-capture is where the errors are born The link comes back at half past four and everyone relaxes. That is precisely the wrong moment. The outage cost you five hours. A careless back-capture will cost you a month of quiet damage, and it fails in familiar ways. Two clerks enter the same slip and the patient is billed twice. A slip disappears between counter and data-entry desk, and a lakh of legitimate billing is never captured. Temporary identifiers get merged into the wrong permanent record, the worst outcome here, because a bad merge puts one patient's allergy into another patient's chart. Timestamps get keyed as the time of typing rather than of the event, so a discharge summary claims a patient was seen at 5pm when they were seen at noon. Back-capture has to be run, not merely done: - One named owner per department on the day itself, not a vague instruction to catch up. - Reconcile against the pre-numbered slips. If the pad ran 1041 to 1096 and only fifty-two records exist, four patients are unaccounted for and somebody goes looking. - Enter the event time, not the entry time, and flag every record from that window as retrospective, so an audit finds the gap explained rather than discovers it. - Merge temporary identifiers deliberately, by one trained person, with a second pair of eyes on anything ambiguous. Kōami can flag retrospective entries and hold a temporary-to-permanent merge as a reviewable step, but reconciliation stays a human discipline. No software knows about a slip that never reached the desk. ## Redundancy is a set of choices, not a purchase Nobody buys five-nines uptime on a hospital budget. The question is which failure you are protecting against, and at what price. - Two ISPs on genuinely different physical paths. Two providers sharing one conduit under one road are a single connection with two invoices, which is exactly what the JCB found. - A 4G or 5G failover router that switches without a human. Test the SIM quarterly. It is usually the SIM. - Local caching or an on-premise node, so a WAN outage still leaves the ward holding today's admitted list, active orders and drug charts. Kōami can be deployed either way, but that is an architecture decision taken long before you need it, never on the afternoon of the outage. - UPS and generator cover on the network switches, not only the servers. A running server behind a dead switch is a dead system. ## Rehearse it, or you do not have it A written evacuation plan has never evacuated anybody, which is why fire drills exist. Downtime is identical, and almost nobody drills it. Take a low-volume window, a Wednesday afternoon rather than a Monday morning, and go offline for ninety minutes with department heads informed and counters not. Then watch. The ward's downtime box will be locked and the key will be with someone on leave. The forms will carry a field for a charge you dropped last year, and clerks hired since the last outage will never have seen a receipt book. Two of the three escalation numbers will belong to people who resigned. Then run the drill's back-capture properly, because that is the half everyone skips and the half that costs money. A hospital that has drilled downtime does not have a better day when the fibre is cut. It has an ordinary one. Busier, slower, more paper, but ordinary. Patients notice the longer queue. What they do not notice is a hospital losing control, because it has not.

Read article
What Actually Happens on HMIS Go-Live Weekend — Operations | KōamiOperations
Operations· 6 min read

What Actually Happens on HMIS Go-Live Weekend

The last bill on the old system goes through at 11:40 on a Saturday night. Casualty is still open, there is a caesarean running upstairs, and in a server room behind the pharmacy a database holding twelve years of a hospital's memory is about to be set to read-only. Nobody claps. The IT head looks at the clock, looks at the general manager, and says the word everyone has been circling all week: freeze. That is what a go-live actually is. Not a launch. A controlled handover between two systems, carried out while the hospital keeps running, because a hospital cannot be switched off for a weekend. ## The cutover plan is a timetable, not a strategy By the time the weekend arrives, the strategy is finished. What you need now is a timetable with names against it, hour by hour, and a phone number beside every name. For a 200-bed hospital in a tier-2 city it reads roughly like this: - Friday 18:00 — final master data sign-off. Tariff master, TPA package rates, consultant list, service codes, room categories. After this, nothing changes. - Saturday 23:00 — last transaction on the legacy system. Billing counters close, casualty moves to manual slips. - Sunday 00:30 to 06:00 — final delta migration. Open IPD admissions, unpaid bills, advance deposits, stock on hand, unclosed lab orders. - Sunday 06:00 to 14:00 — reconciliation. Admitted patients on the floor counted against admitted patients in the system, twice, by two different people. - Sunday 14:00 — every counter verified physically, by a person standing at it. - Monday 08:00 — OPD opens on the new system. What separates a calm weekend from a bad one is the open-items list: patients currently admitted, bills raised but unpaid, TPA cases awaiting pre-authorisation, samples collected but not reported, indents raised but not issued. Everything else is history and can follow later. ## The parallel-run decision Somebody will suggest running both systems together for two weeks. It sounds prudent. It is usually the most dangerous option on the table. Every registration, every bill, every lab order gets entered twice, by the same tired staff, at the same counters — and within four days they quietly pick one and neglect the other, usually abandoning the new one because the old one is faster. Now there are two half-true records and no way of telling which is authoritative. > A parallel run does not halve your risk. It doubles your data entry and hides which system is telling the truth. The one defensible use is the first month-end close, where finance re-runs a frozen period in both systems and compares totals. Everywhere else, a clean cutover with rehearsed rollback criteria beats a fortnight of ambiguity. ## The first OPD morning Eight o'clock on Monday is the only test that counts. Registration opens, and by ten past eight there are forty people in the queue, several waving OPD cards printed in the old MRN format. Two questions decide the morning: - Can a returning patient be found in under fifteen seconds? By phone number, by old MRN, by name and age. If a clerk has to search three ways before finding someone, the queue builds faster than it clears. - Does the OPD slip print, correctly, first time, at that counter? Not at the test terminal in the IT room. At counter three, on that printer, on the actual stationery. Staff the counters at roughly double normal strength on day one. Put your trained super-users at the counters and the vendor engineers behind them, never the other way round. The moment an engineer sits down and does the clerk's job, the clerk stops learning and the hospital has bought a dependency lasting months. ## The war room, and what always breaks The command centre should be a real room with a whiteboard, close enough to OPD and billing to walk there in ninety seconds. Three columns: blocked, being worked on, resolved. One person, usually the IT head or the operations manager, decides what counts as blocked. Everything else is noise. Physically present, not on call: two people who know the application configuration, one who owns network and printers, a senior person from billing, a ward sister with authority, and one consultant other consultants respect. That last one is not decoration. When a senior consultant declares the system unusable, the fix is usually five minutes of orientation, and it lands better from a peer. Then there is the list that repeats at every hospital, regardless of which system is going in: - Printer mappings. Label printers, OPD slip printers and pharmacy bill printers assigned to the wrong counter, or dropping off after a workstation restart. The commonest day-one complaint, and almost never the application. - Tariff master gaps. A service exists but carries no rate, or has a general-category rate and nothing for the TPA or scheme tariff. Billing stops mid-queue. Every uncosted service found on Monday should have surfaced in the dry run. - User logins and rights. Relief staff, visiting consultants, the third shift, the person on leave during training week. Somebody will need an account at 08:20 with the correct role and department mapping. - Barcode scanners. Configured for the old system's prefix and suffix characters, now producing sample IDs with a stray character on the end. A system like Kōami narrows the surface area — masters validated before the switch, roles templated by department, failed transactions logged with enough context to be fixed rather than guessed at. None of it survives counter three's printer unless somebody has stood at counter three and printed something. ## Rollback is a decision, not a feeling Write the rollback criteria before the weekend, get them signed, put them on the wall. Make them specific enough that nobody can argue: registration down for more than thirty minutes, billing unable to raise bills for more than an hour, any patient safety event traceable to the system. Name the one person who can call it, and set a deadline — usually end of day Monday — after which rollback is off the table, because unwinding three days of clinical and financial data is a larger risk than pushing through. The value of written criteria is not that you will use them. It is that on Monday morning, when a consultant is angry and the queue is forty deep and somebody says go back, you can look at the wall and answer honestly. None of these have happened. This is friction, not failure. ## The quiet Tuesday Almost nobody remembers go-live weekend as the hard part. The hard part is the third week, when the vendor team has thinned out, the novelty has worn off, and the workarounds invented on day two have hardened into habits. The clerk who registers every follow-up as a walk-in because it is quicker. The ward quietly keeping a parallel register in a notebook. Go-live is the day the software starts running. It is not the day the hospital changes. That takes another two months, and it is done by ward sisters and billing supervisors who keep insisting on the new way long after the war room has been dismantled.

Read article
The Board Asked What the HMS Actually Saved Us — Analytics | KōamiAnalytics
Analytics· 6 min read

The Board Asked What the HMS Actually Saved Us

Ninety days after go-live, someone at the board table asks it plainly. Fine. We spent the better part of half a crore and six months of everybody's patience. What did the HMS actually save us? Whoever sponsored the project reaches for the same sentence, and it is the wrong one. ## "We are more efficient" is not an answer It fails for a simple reason. Nobody in the room can disagree with it, which means nobody can be persuaded by it either. A board that signs off a CT scanner is used to being told what the machine returns per year in rupees. Efficiency, with no line under it, reads as an apology. The second reflex is worse: screenshots. A dashboard of thirty tiles, none corresponding to a line in the P&L. Utilisation graphs prove the system is used. They do not prove it paid for itself. An honest answer has three parts. Where money genuinely moved. Where you believe it moved but cannot yet prove it. And where nothing moved and never would. Boards trust the third part most, and it is what makes them believe the first. ## The lines you can actually defend Charge capture is the big one. The largest quiet leak in most hospitals is not fraud, it is items consumed and never billed. A dressing set used in casualty at 2am. Oxygen hours on a ward. A dose pulled from floor stock. A consultant's second visit on discharge day. When the charge is raised by the order and the dispense event rather than from memory at discharge, that leak closes. Compare what stores issued to a ward against what was billed from it. The gap is your number, before and after. First-pass claim rate is the cleanest metric here, because your billing team already knows it in their bones. What moves it is structured documentation, a tariff master matching what the TPA contract actually says, and pre-authorisation attached to the encounter rather than living in a WhatsApp thread. Every query avoided is a few weeks of cash. Days in AR follows, later and more slowly, and is hard to fake. Pharmacy shrinkage and expiry write-offs respond to batch tracking, near-expiry alerts, and a reconciled issue-and-return cycle between main store and ward floor stock. Write-offs already sit as a rupee figure in the pharmacy's register. Compare last year's to this year's and there is no argument to have. Overtime and agency spend responds to rosters built against ward acuity rather than habit, and a leave calendar visible before the shift rather than after. Locum cost is a payroll line, so before-and-after is not a matter of opinion. Discharge turnaround converts into bed-days. If the discharge summary, final bill, pharmacy return and TPA clearance run in parallel instead of in a queue, discharge shifts from late afternoon to late morning. At high occupancy that is not a comfort metric. It is a bed released for another admission, and a bed-day carries a known contribution margin in your books. Registration-to-consult time belongs here too, the line patients rate you on. ## A worked example, with your numbers instead of mine What follows is a template, not a result. Every figure below is invented to show the arithmetic. Substitute your own or the exercise is worthless. Take a 200-bed hospital in a tier-2 city turning over ₹60 crore a year. - Charge capture: assume 1% of billable consumables and services were escaping the bill, half of it now caught. Thirty lakh. - Claims: assume two hundred queried claims a month, falling by a quarter. Fifty fewer queries at half an hour each, plus the working-capital effect of a shorter cycle. - Pharmacy expiry: assume eighteen lakh written off last year, a third avoidable with batch-level visibility. Six lakh. - Agency and overtime: assume forty lakh a year, cut by a tenth. Four lakh. - Bed-days: assume fifteen discharges a day and a two-hour improvement, yielding two extra admissions a week at your own contribution per admission. Then do the two things that make a case credible. First, halve every assumption and see if it still stands. If it only works at the optimistic end, you have a hope, not a case. Second, subtract the real cost: licence, implementation, hardware, network, the AMC, and the several hundred hours your consultants, ward sisters and billing staff spent on the project instead of their jobs. That last item is genuine money, and leaving it out is the commonest dishonesty in these presentations. > A board can live with a modest number honestly derived. It cannot live with a large number it cannot interrogate. ## What an HMS does not save Say this part early, and out loud. It does not reduce headcount. Registration clerks do not become unnecessary, they stop retyping and start handling the queue. If the business case was sold on staff reduction, it was sold wrong, and month three is when that shows. It does not fix a tariff master that is wrong. Kōami, or anything else, will bill an incorrect rate faster and far more consistently than any human managed. It does not improve documentation quality by itself. A consultant who wrote three lines on paper writes three lines on a screen. What changes is that they are legible, timestamped and retrievable, which matters enormously for NABH and for an audit, but it is not clinical richness appearing from nowhere. It does not shorten a queue caused by a consultant arriving ninety minutes late. And in the first six to ten weeks it costs you. Throughput dips, staff are slower, tempers shorter. Had the board asked at day thirty, the honest answer would have been negative, and should have been given as such. ## The baseline you did not capture Here is the uncomfortable part. These questions are hard to answer not because data is missing now, but because it was missing then. Nobody recorded average registration-to-consult time in the month before go-live. Nobody has a clean first-pass claim figure for the previous quarter. Discharge timing exists only as "usually by evening". So the comparison becomes a new precise number set against an old remembered one, and remembered numbers always flatter whoever is remembering. If you are still pre-go-live, spend two weeks measuring by hand. A clerk with a clipboard sampling fifty registrations and fifty discharges buys a defensible baseline for the life of the system, at a cost of nothing. If you are already live and skipped it, do not reverse-engineer one. Say which lines have a genuine before-and-after, run the rest forward from today, and return at month nine with twelve months of consistent data. Any HMS reports only on the period since it started recording. It cannot reconstruct the year before it arrived, and a vendor implying otherwise is selling you something. ## The answer worth giving The strongest thing a CFO can put before a board at ninety days is short. Three lines with real rupees and a stated method. Three more being tracked, with the date they become answerable. One paragraph on what the system was never going to fix. That answer survives the next board meeting, and the one after. "We are more efficient" does not survive the walk back to the car park.

Read article
Cloud or On-Premise: The Argument Every Hospital Board Has — Data Security | KōamiData Security
Data Security· 6 min read

Cloud or On-Premise: The Argument Every Hospital Board Has

The server room of a 220-bed hospital in a tier-2 city is usually behind the accounts department. A split AC runs all year, one rack is half empty, the whiteboard network diagram stopped being accurate in 2019, and the UPS batteries were replaced once, four years ago. The engineer who built it left for a larger group in Pune, and the current IT executive — capable, overworked, the only one — inherited a root password written inside a register cover. That room is what the board is really arguing about. The debate gets framed as modern versus old-fashioned, the least useful way to have it. Both work, both fail, and what separates them is which set of obligations the hospital is in a position to carry. For clarity: Kōami is a cloud system, which is why the next section matters most. On-premise has a real case, and a hospital talked out of it by a vendor with a hosting bill to protect has been badly served. ## The honest case for on-premise Start with money already spent. A hospital that put thirty lakh into servers and storage eighteen months ago has years of life left in that hardware. Writing it off for a monthly subscription is a real loss, not an accounting inconvenience, and no amount of capex-to-opex language makes it disappear. Then connectivity, which deserves the most respect. In many locations the primary link drops, the secondary turns out to be the same last-mile fibre under a different name, and the 4G failover depends on a tower that struggles whenever it rains hard. Registration, billing, pharmacy and the OT list cannot pause for a router, and casualty at 2am cannot wait for an ISP ticket. A hospital with genuinely unreliable connectivity is not being sentimental. It is being honest. There are others, all legitimate: - Local integrations. PACS modalities, analysers on old interfaces, biometric attendance, queue displays — simpler on a LAN, and the workarounds cost real money. - Custody. For a trust or family-owned hospital, the instinct that data should sit in the building reflects a view of accountability that has served the board well elsewhere, and some institutional tie-ups and tenders carry hosting expectations of their own. - A single-site hospital with a real IT team, a patching routine and a restore that has actually been tested is often better off on-premise, and should be told so. ## The honest case for cloud The cloud case is not about technology either. It is about who does the maintenance. No server room. No diesel-backed UPS, no AC failing in May, no hardware refresh landing the same year as the new OT block. Patching, key rotation and backups become somebody's full-time job rather than the fourth priority of an executive whose week is passwords and printers. Multi-site is where the difference turns structural. A group running a main hospital, a satellite unit and a daycare centre gets one patient index, one MRN series, one tariff master, one version of the software. The on-premise equivalent is three databases and a patient who exists twice. Disaster recovery is the uncomfortable one. Ask an on-premise hospital what happens if the building floods, and the honest answer is often a second server in the same building and a portable drive in the administrator's cupboard. That is a backup with a single point of failure. Geographic redundancy is the one thing a hospital cannot easily build for itself. ## Two claims that do not survive contact with a Tuesday The first is that on-premise is more secure. In principle, possibly. In practice security is maintenance, and maintenance is a staffing question. Ask when the operating system was last patched and whether the database port is exposed. Ask whether the remote-access tool the vendor installed so support could log in on a Sunday is still there with the same password. Ask whether accounts of staff who left are disabled. Physical custody of a box is not security; it is only the opportunity to secure it, taken every week for years. The second is that cloud moves the responsibility elsewhere. It does not. The provider secures the infrastructure. The hospital still owns what causes incidents: who holds an account, which roles can open which MRN, three billing staff sharing one login, the nursing terminal left unlocked in a corridor, the discharge summary forwarded on WhatsApp. > Almost nobody is breached because the server was in the wrong building. They are breached because nobody was watching the accounts. ## Residency, consent and what belongs in the contract Health data in India carries obligations around consent, purpose limitation, retention and residency, and the framework keeps moving. Anyone claiming to know exactly what is mandated today, in a blog post or a sales deck, deserves suspicion. Take current advice from counsel. What a board can insist on, without waiting for legal certainty, is that the answers live in the contract rather than in a conversation: - Where the data resides, and whether that can change without notice. - Which sub-processors are involved and what they can see. - Breach notification timelines, audit rights, and what evidence the vendor will produce on request. - The exit clause: on termination, in what format the data comes back, how fast, at what cost, and whether it is usable without the vendor's software. That last one applies whether the system is Kōami or anything else, and it is the clause most often left vague. NABH expects documented access control, audit trails, backup and retention policy whatever the hosting model, and ABDM participation brings consent artefacts the system must handle as data rather than paperwork. ## The questions a board should actually ask Most of the debate collapses once these are answered honestly, and if nobody can answer the first with a date, the argument is already over. - When did we last restore a backup onto a working system, and how long did it take? - If the internet is down for four hours, what still runs, and has that been rehearsed rather than assumed? - Who applies patches, on what schedule, and how would we know if that stopped? - Who holds administrator access today, including vendor engineers and people who have left? - What is the five-year total either way, including hardware refresh, power, cooling and the person who keeps it running? - If the building is unusable tomorrow morning, what do we open, and from where? ## The decision underneath the decision The board is not choosing between two technologies. It is choosing who does the unglamorous work — patching, backups, key rotation, reading logs, disabling accounts — and verifying it happened. On-premise means taking that on, defensible as long as it is staffed and funded like a real commitment rather than added to somebody's existing job. Cloud means buying it, defensible as long as the hospital audits what it bought. The failure mode is not choosing wrongly. It is choosing on-premise for control and never exercising it, or choosing cloud and assuming responsibility left with the server. Hospitals that have this right are recognisable from one detail. Somebody in the room can answer the restore question with a date.

Read article
Why PM-JAY Claims Get Rejected, and How to Stop It — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 6 min read

Why PM-JAY Claims Get Rejected, and How to Stop It

Every hospital empanelled under Ayushman Bharat has a folder — physical, or on a shared drive — that everyone calls "pending". Inside are claims that were rejected, claims queried and never answered, claims raised against the wrong package, and claims never submitted because the file was incomplete and whoever could have completed it has left. In a mid-sized hospital in a tier-2 city that folder can quietly hold several lakh, and nobody's monthly target includes it. Scheme claims fail for a small number of reasons, they fail the same way almost everywhere, and nearly all the causes sit upstream of the person who submits the claim. ## Scheme billing is not TPA billing with a different logo This is the root error, and it is organisational rather than technical. Hospitals put scheme claims on the TPA desk, staffed by people trained in TPA logic, and expect it to work. The two are different instruments. - TPA billing is itemised against your tariff master. Scheme billing is package-based at a rate the state health agency has already fixed. What you actually consumed is your problem. - A TPA claim is negotiable; someone will discuss a deduction with you. A scheme claim is adjudicated against published rules by a medical officer you will never speak to. - TPA queries arrive by email. Scheme queries sit in a portal, and they expire. - Your empanelment defines which specialities and packages you may claim at all. Treat outside that scope and there is no claim, however good the care was. The consequence is an inversion most claims desks miss: the pricing decision is made at admission by whoever selects the package, not at discharge by whoever raises the bill. ## The claim is won or lost at the registration counter Beneficiary verification is not paperwork. It is the moment the claim becomes possible. The failure mode is familiar. A patient arrives in casualty at night, is admitted as a cash case because the family did not bring the card, and on the morning of discharge someone asks whether this could go under the scheme. It usually cannot. Verification, authentication and the entitlement check belong at or before admission, in the manner the state prescribes, and retrofitting them is a losing exercise. > A claim that begins at discharge is not a claim. It is a hope. Three habits make the front desk work. - Verify before admission wherever the clinical situation allows. Emergency routes exist and differ by state; know yours and use it deliberately rather than by accident. - Tie the scheme identity to the MRN at registration. If the arogya mitra desk keeps a parallel register that never meets the hospital record, you spend the admission reconciling two versions of one patient. - Confirm the entitlement covers the intended treatment, not merely that the beneficiary exists. ## The wrong package sinks the claim Package selection is where most avoidable rejections are created. Packages are defined by procedure and speciality, often stratified by approach, implant or complexity. Choose the wrong one and the claim contradicts its own evidence. The recurring patterns: - A general medical management package claimed where a specific listed procedure was performed, or the reverse. - Unbundling — claiming separately for items the package already includes. - Claiming a package the facility is not empanelled to perform, or one implying a level of care the notes do not support. Getting this right needs the treating consultant involved, at least briefly, because in practice a claims executive picks from a dropdown using a discharge summary written in a hurry. The fix is small: the procedure note and the selected package are read together before submission, by someone competent to read both. Ten minutes per case. The other direction matters too. Claiming a higher-value package than the record supports is not clever revenue capture; claims are audited, patterns are visible across a hospital's history, and consequences run to de-empanelment. ## Documentation and photographs are part of the treatment Scheme adjudication is evidence-based in a very literal sense: the agency cannot see your patient, only what you uploaded. That means admission notes, investigation reports, the procedure note, implant details where applicable, and a discharge summary naming the same diagnosis and procedure as the pre-authorisation. Most state schemes also require photographic evidence at defined points — commonly at admission, during or after the procedure, and at discharge — in the format the state specifies. Photographs are where busy wards lose money. Nobody takes the admission photograph because casualty is full, and there is no honest way to create it three days later. That is a checklist problem rather than a technology one, though a system helps: Kōami holds the required documents and evidence against the episode itself, so an incomplete file is visible while the patient is still in the bed rather than after they have gone home. The second discipline is consistency. Auditors read the pre-authorisation, operative note, discharge summary and claimed package side by side; if the diagnosis drifts between them, the claim invites a query even where the care was appropriate. ## Pre-authorisation, queries, and the queue nobody owns A pre-authorisation request is a clinical argument, not a form. A medical officer reads it to decide whether the proposed package is justified by the presentation, and weak requests all look alike: a one-line diagnosis, no supporting investigation, no reason given for this procedure now. Emergency admissions follow a separate route with their own intimation requirement, and every one of these timelines is set by the scheme, varies between states and gets revised — work from your state health agency's current guidelines, not the note pinned above the desk. Then there is the query, where money leaves silently. The agency raises one, the hospital has a stipulated window in which to respond, and it is short. Either nobody checks the portal daily and it is found after it has expired, or the response resubmits the same file instead of answering the actual question. A rejected claim makes no noise. No patient calls, no TPA follows up, no ageing report anyone reads. It simply stops moving. What restarts it is ownership. - One named owner for scheme claims, not a responsibility split across three departments. - A daily worklist with ageing buckets: awaiting pre-authorisation, awaiting documents, query open, submitted, part-paid, rejected. - Line-item reconciliation of settlements. Payments arrive in batches against many claims at once and are frequently short-paid; without matching each receipt to a claim, a hospital does not know what it is owed. Kōami keeps that worklist, tracks the query clock and reconciles batch settlements back to individual claims. What it cannot supply is the owner. That has to be a person with a name. ## Where the money actually is Hospitals chasing scheme revenue look outward: more empanelment, more specialities, higher-value packages. The faster return is inward — the gap between what was treated and what was claimable, then between what was claimed and what was paid. Categorise a quarter's rejections and four or five causes will account for most of the volume. A verification skipped at the counter. A package chosen without reading the operative note. A missing photograph. A query that expired. None are claims-desk failures. They are front-desk and ward failures the claims desk inherits, and they are only ever fixed where they happen.

Read article
Migrating 12 Years of Patient Records Without Losing Anyone — Interoperability | KōamiInteroperability
Interoperability· 6 min read

Migrating 12 Years of Patient Records Without Losing Anyone

A woman arrives at OPD and says she was treated here about six years ago. The clerk searches her name and gets seven results. Three spellings of the same surname, two carrying an initial that may or may not be her husband's. Two records share a phone number. One shows a date of birth of 01/01/1980, which is what the old system wrote whenever the field was left blank. Upstairs, a consultant wants to know whether she has been on thyroxine since 2019, and the answer sits in one of those seven records, or in a scanned discharge summary nobody indexed. That is what a data migration actually deals with. Not a million clean rows. Twelve years of a hospital doing its best under queue pressure. ## Twelve years of good intentions Nobody sets out to build a messy database. It is 9:15, thirty people are waiting, the patient cannot remember her MRN and has no card, and it is faster to register her afresh than to hunt. Multiply that by twelve years and several lakh registrations. The patterns repeat everywhere: - The same person registered five times across a decade, spelt differently each time, because names transliterated from a regional script have no single correct English form. - Ages recorded instead of dates of birth. A record saying "45 years" entered in 2014 tells you nothing useful today. - Free-text diagnoses that were never coded. "?koch's", "CAD s/p PTCA", "fever ? viral, r/o dengue" — clear to the doctor who wrote it, invisible to any structured query. - Scanned PDFs in folders named by date, with no MRN in the filename and no metadata inside. > A migration is an archaeology exercise with a technical deliverable. ## The phone number is the only honest key Names are unreliable. Dates of birth are often invented. MRNs are duplicated by design failure rather than malice. What survives twelve years reasonably intact is the phone number, because follow-up calls, reports and TPA queries depended on it — somebody had a reason to get it right. It is still not clean. Families share one number across a husband, a wife and three children, and numbers change. So matching has to be scored, not binary. Combine phone number, name similarity, gender and an age band, then sort every candidate pair into three outcomes: auto-merge on high confidence, human review queue in the middle, leave separate by default. The default matters more than the algorithm. A duplicate is an inconvenience; a wrong merge is a clinical incident, because it puts one patient's allergy history into another patient's chart. ABDM helps forward, not backward. An ABHA number gives new registrations a clean national spine, but it does not retrospectively repair a decade of duplicates. ## Migrate, archive, or leave behind Three buckets, decided by the hospital, not the vendor. - Migrate as live structured data: demographics, the current MRN plus every old MRN as a searchable alias, allergies, active problem list, current medication, admissions and discharge summaries, lab results within a clinically useful window, outstanding balances and open TPA cases. - Archive as searchable read-only: old billing detail, lab results beyond the window, scanned documents. Openable from inside the chart, never poured into structured clinical fields. - Leave behind entirely: audit logs, system tables, abandoned drafts, and the test patients every hospital has — "Test Test", "ABC XYZ", a staff member's own name used to check a printer in 2016. A hospital that migrates everything as structured data ends up with twelve years of unreliable structure — worse than three years of reliable data beside a searchable archive. The same discipline applies to free text. Do not auto-code a decade of diagnoses into ICD. Carry it across verbatim, flagged as legacy, and start coding properly from go-live. The urge to produce a tidy coded history is what generates a chart claiming a patient has a condition they never had. ## Extract, map, validate, reconcile — then do it again The loop is unglamorous and does not get shorter. - Extract from a timestamped read-only snapshot, never from the live legacy database. Every run must be reproducible from that snapshot, or two runs cannot be compared. - Map field by field, in a document signed by somebody from the hospital, not only by IT. It must state the ugly rules: what an age-only record becomes, what happens when gender is blank, what 01/01/1980 becomes — flagged as estimated, not deleted. - Validate with rules that fail loudly. No record without an identifier. No discharge dated before its admission. No result without a patient. Counts by year and department, so a year that quietly lost half its OPD visits shows up. - Reconcile against arithmetic. Records out must equal records in, minus documented merges and exclusions. Outstanding balances must tie back to the last trial balance finance signed. Run at least three full dry runs. The first exposes schema surprises. The second exposes volume and timing, which matters when the real window is six hours on a Sunday morning. The third is a rehearsal against the clock. Publish the exception report after each; the count should fall and its shape change. If the same four thousand records fail three times running, nobody is fixing anything. This is where tooling earns its place. In Kōami a transformed record keeps a pointer to its source row and the rule that shaped it, so when a consultant queries a date six months later the answer is a lookup, not an argument. ## Proving to a clinician that nothing was lost Clinicians do not read reconciliation reports. They test a system with the patients they remember, so run the acceptance the way they will run it anyway. Ask each department to nominate thirty to fifty of their own records — the diabetic on six drugs, the oncology follow-up, the patient readmitted four times in two years — and sit with them, old screen beside new. Trust is built by a consultant seeing their own note, in their own words, against the right date. No report produces that. Then give them the archive link from inside the chart. "Everything before March 2021 is one click away, searchable by MRN" is an answer a clinician can work with. "It has all been migrated", when it visibly has not, ends confidence in the whole system. Publish the exception list openly, including duplicates deliberately left unmerged and dates of birth marked as estimated. A documented gap is a managed risk; a hidden one surfaces at the worst possible moment. And give registration a merge request button rather than merge rights, so duplicates are flagged where noticed and resolved by people holding the records. ## Nobody lost, some still doubled At the end of a good migration you will still have duplicates. That is not failure, it is an honest state. There was never a perfect database to move. What you are owed is this: nobody lost, every record traceable to where it came from, every remaining gap written down. The woman with seven records becomes one active chart with six aliases pointing at it, and when the consultant asks about thyroxine, 2019 is on the screen.

Read article
Walking Into an NABH Audit Without the Week-Before Panic — Operations | KōamiOperations
Operations· 6 min read

Walking Into an NABH Audit Without the Week-Before Panic

Three weeks before the assessment, the hospital changes shape. A store room is cleared out and becomes a documentation cell. Two staff nurses come off the roster to work through last quarter's case files. Somebody discovers that the calibration certificates for four ICU monitors expired in March. The photocopier runs all day. In medical records, a junior is filling gaps in nursing charts from six months ago, and there is a general understanding that nobody will look too closely at that. Any hospital that has been through an accreditation cycle recognises this fortnight. It is expensive, exhausting, and it produces a version of the hospital that exists in no other month of the year. ## The scramble is itself the finding An assessor is not really reading your files. She is reading your habits, and files are simply where habits leave marks. Pull ten case sheets from the assessment quarter and ten from the quarter before it. If the first set is complete and the second has blank consent columns, unsigned nursing notes and discharge summaries dated a week after the patient went home, the conclusion writes itself. Documentation here is an event, not a practice. That single observation shapes the rest of the visit, because now everything gets checked twice. The hospitals that walk through an assessment calmly are not the ones with better files. They are the ones where the files were never a separate activity. ## What an assessor actually asks for Strip away the anxiety and the questions are fairly predictable, because they follow the patient rather than the department. The assessor picks an MRN, usually not one you offered, and walks it end to end. - Consent. Taken before the procedure, by someone qualified to explain it, in a language the patient understands, with risks and alternatives actually recorded rather than implied by a pre-printed line. - The medication chart. Prescribed by whom, administered by whom, at what time, and where a dose was missed or delayed, whether anyone wrote why. - Assessment and reassessment. Within the timeframe your own policy commits to, with evidence that the patient was looked at again as their condition changed. - The discharge summary. Complete, signed, handed over, and inside the timeline the hospital has committed to in its own manual. - Incidents. Not zero, because nobody believes zero. A register with entries, investigations, and evidence that something changed as a result. - People. Credential and privileging files for consultants, with qualifications verified, registration current, and a clear record of what each clinician is permitted to do here. - Equipment. Calibration and preventive maintenance records for the devices that matter, traceable and current, not a folder of certificates with a gap in the middle. None of this is exotic. What makes it hard is that the evidence lives across seven departments, six formats and two languages, and nobody owns the whole trail until three weeks before the visit. ## Retrospective documentation announces itself Hospitals badly underestimate how visible back-filling is. An experienced assessor has read thousands of case sheets and reads them the way a radiologist reads a plate: patterns first. Ink that stays uniform across a two-week admission. Handwriting that does not change across three different nursing shifts. Vitals recorded at implausibly tidy intervals — 06:00, 10:00, 14:00, exactly — on a weekend when the ward was short-staffed. Nursing notes describing a deterioration with no corresponding entry in the doctor's notes for another eleven hours. A consent signed at 09:15 for a procedure the theatre register shows started at 09:05. > Nothing looks more suspicious than a perfect file. Electronic records do not fix this on their own, and can make it worse if the system is treated as a typing pool. If every entry for a five-day admission carries a timestamp from the afternoon before the assessor arrived, the audit trail is the confession. The value of a system is not that it produces tidy documents. It is that it records when things actually happened. ## Evidence should be a by-product of the work The shift in thinking is small and it changes everything: stop treating documentation as a task that follows care, and let it be the thing that happens while care is given. A nurse administers a drug and marks it at the bedside. That one action is the clinical record, the stock movement, the billing entry and the audit evidence at the same time. Nobody transcribes it later. A consultant closes the discharge summary before the patient leaves, and the hospital sees its compliance against its own stated timeline as a running number rather than discovering it in a file review. A monitor carries its calibration due date, so the ward knows the device in bed 6 has lapsed before an assessor does. Systems like Kōami are useful here for an unglamorous reason: they capture the user, the timestamp and the sequence as the work happens, which means the evidence trail assembles itself. This is also where ABDM work pays off in a way people do not anticipate. Clean, uniquely identified, properly linked patient records are normally pitched as an interoperability project. In practice the first thing they buy you is a complete longitudinal record for one MRN in half a minute, in front of an assessor, without anybody running to the record room. ## The files nobody owns until the week before Clinical documentation gets attention because it is visible. The findings that catch hospitals out tend to sit elsewhere, in the registers with no obvious owner. Credential files drift. A consultant's registration renewal came through eighteen months ago and the copy never reached HR. A visiting anaesthetist has been operating for two years against a file that was never completed. Calibration lapses because the biomedical engineer tracked it in a personal spreadsheet and then resigned. The incident register goes quiet for four months, not because nothing happened but because the ward sister who maintained it was transferred and nobody picked it up. Mandatory training records for fire safety, BLS and infection control exist as attendance sheets in a cupboard rather than against each employee's name. Every one of these is trivial to maintain continuously and painful to reconstruct. An HRMS that holds registration expiry against the employee record and flags it ninety days out costs the hospital almost nothing in effort and removes a whole category of finding. A 180-bed hospital in a tier-2 city might carry 240 staff files and thirty-odd consultants on visiting arrangements. That is a spreadsheet problem for exactly as long as it takes the person maintaining the spreadsheet to leave. ## The goal is a boring assessment The tell for a genuinely prepared hospital is not confidence. It is indifference. Somebody asks for the medication chart of an MRN from last April, and a staff nurse pulls it up without any change of expression, because it is the same three clicks she uses every shift. Accreditation was never designed as an examination to be revised for. It describes a hospital that already runs the way it says it runs. The week-before panic is the distance between those two things, measured in overtime. Close that distance and the assessment stops being an event, which was rather the intention.

Read article
The Consultant Who Would Not Type — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 6 min read

The Consultant Who Would Not Type

The consultant finishes his ward round at nine, walks into OPD, and by one o'clock has seen sixty patients. He writes on a prescription pad, in handwriting his junior has learned to read. Behind him a data entry operator is typing last Thursday's notes into the EMR, four days behind and falling further behind. The IT report that month puts physician adoption at forty per cent, and in that meeting a man who has practised for twenty-two years is called resistant to change. He is not resistant to change. He is doing arithmetic. ## The arithmetic of a four-hour OPD A consultant seeing sixty patients in a four-hour clinic has roughly four minutes each, and those four minutes include the greeting, the history, the examination, the explanation to an anxious relative, and the decision. Ninety seconds of form-filling per patient is not ninety seconds. Across sixty patients it is an hour and a half, an entire second clinic that does not exist in the day. That time comes out of the examination, or the explanation, or the queue in the corridor. This is why the adoption argument rarely moves. Management talks about NABH documentation and claim rejections. The consultant is thinking about the fifty-eighth patient, who travelled three hours and will be told to come back next week. Both are reasonable. Only one is being asked to absorb the cost. Clicks are the currency here, and most systems are careless with them. Count them honestly one morning: log in, search the MRN, wait, open the encounter, pick a template, dismiss a popup, type, switch to the orders tab, search a drug by generic name because the brand the patient actually takes is not mapped, set dose, frequency and duration in three dropdowns, save, confirm, return to the worklist. Twenty-two clicks for a fixed-dose antihypertensive this consultant prescribes forty times a week, and nobody has been asked to justify them. They accumulated, the way clutter does. ## Design the screen around the consultation, not the database Most EMR screens are a database schema wearing a user interface. Demographics sit in one tab because they sit in one table. Vitals in another, labs in a third, pending investigations in a fourth, previous prescriptions in a fifth. The doctor reassembles the patient out of five tabs, sixty times a morning. The clinical question is almost always the same shape: what has changed since I last saw this person? A follow-up diabetic needs the last three HbA1c values, the current drug list, the weight trend, renal function and any admission since the last visit — one screen, in the order a clinician thinks, no navigation. Put that up in two seconds when the MRN opens and the consultant will use it, because it beats the paper file the patient may not have brought. > The moment the screen is quicker than the memory of the last visit, the resistance quietly disappears. ## Templates and order sets have to be written by clinicians Every hospital has a folder of templates nobody uses. They were built by an implementation consultant, approved by a committee, and designed for the general case. General cases do not exist in clinics. An orthopaedic OPD is post-op reviews, knee pain, back pain and trauma follow-ups, and that is most of the morning. If those four are one tap each, opening pre-populated with the usual examination structure, investigations and advice — editable, never locked — the consultant writes a better note in less time than the pad took him. The rule is unglamorous. Templates and order sets get built by specialty, with the consultants who will use them, and revised after the first month once everybody has found what was wrong with them. - A paediatric clinic needs weight-based dosing that calculates, not a free-text box that invites a decimal error. - A cardiology follow-up needs the previous echo report on the same screen as the new prescription. - Casualty needs the shortest possible path to a note that is still defensible at 3am with one junior on duty. A template that gets ignored is not evidence of a stubborn doctor. It is evidence that nobody sat in that clinic for a morning before building it. ## More than one way into the record The keyboard is one door into the record, and for a consultant who never learned to touch type it is the narrowest one available. Dictation and ambient capture have become genuinely usable — good enough to speak the note while examining and then review a draft rather than compose one. Reviewing text is a different task from producing it, and far quicker. Delegation matters as much as the technology. Much of what sits in an EMR is not clinical judgement at all. Vitals, allergies, medication reconciliation, past history, the address correction, the TPA details: that work belongs to the nursing station, the ward sister, the junior resident. The consultant's irreducible contribution is the assessment, the plan and the signature. A system like Kōami earns its place here for a dull reason — several people write into the same encounter under their own roles and audit trail, the consultant countersigns, and a fuller record costs less consultant time. What cannot be delegated is the thinking, and nobody should pretend that a clerk transcribing last week's pad amounts to an electronic medical record. That is a typed archive of paper. Interaction checks, an IPD discharge summary that assembles itself, ABDM linkage: all of it depends on the note existing at the time of the encounter. ## Adoption is not a login count A dashboard reporting that eighty-two per cent of consultants logged in this month tells you nothing. Logins measure attendance. The question worth asking is whether the notes are useful to the next clinician. - Can the doctor on night duty, who has never met this patient, understand the plan from the note alone? - Does the discharge summary build itself from the record, or does somebody retype it? - Do the orders in the system match what was actually given on the ward? - When the patient returns in six months, does the previous encounter answer the question, or merely prove that a visit happened? A hospital can hit perfect login compliance and still hold a record no clinician would rely on. It can equally have a consultant signing in twice a day and writes four sentences worth more than anybody else's four paragraphs. ## What the next clinician sees The consultant who would not type was never arguing about technology. He was defending the one thing he cannot make more of, which is the minute spent looking at the patient instead of the screen. Every hospital that got this right did the same dull thing. Somebody sat in the clinic for a morning, counted the clicks, and then went and removed them. Not trained the doctors harder. Removed the clicks. The proof turns up quietly, months later, when a junior in casualty at 2am opens a record from an OPD visit eleven weeks earlier and finds precisely what she needed. That never appears in an adoption report. It was the only thing that mattered.

Read article
Training Staff Who Have Used Paper for Twenty Years — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 6 min read

Training Staff Who Have Used Paper for Twenty Years

The ward sister has a register. Hardbound, cracked spine, kept on the second shelf under the nursing station counter, and she has run a thirty-bed female medical ward out of it for nineteen years. She knows which page the handover sits on. She has her own shorthand for a patient who needs watching. She can tell you without turning a page who is due for a dressing change and who the consultant wants reviewed before evening rounds. Then a project team arrives with laptops and a go-live date, and tells her that from the fifteenth, everything goes into the system. She is not impressed by the demo. She is also not being difficult. ## Resistance is usually a rational risk assessment Hospitals talk about resistance to change as though it were a personality defect. It rarely is. Ask any nurse who has sat through two abandoned software rollouts and she will explain the arithmetic quite calmly. The register has never crashed. The register works during a power cut. The register does not log her out after four minutes of inactivity while she is holding a syringe. Against that, she is being offered something a vendor says will be better, delivered by a project team that will be gone in six weeks. There is a second, quieter calculation running underneath. She is the most competent person on that floor and everybody knows it. Juniors ask her; she does not ask them. The moment she has to hunt for the discharge screen while a first-year nurse watches, that order wobbles. Twenty years of earned authority, traded against the risk of looking slow in front of the people she trains. > Nobody resists a better system. They resist becoming a beginner in public. Once you see it that way, most of the standard playbook looks wrong. A classroom session at 3pm with a projector asks her to be a student in a room full of her own juniors. A single induction covering registration, OPD billing, IPD orders and TPA workflow teaches her mostly things she will never touch. ## Train in the ward, not in the classroom The training that works happens standing at the nursing station, with live patients on the screen. Not dummy data. Her ward, her beds, her patients, her consultant's orders. The moment the training set is fictional, the exercise turns abstract and nothing sticks. In practice: - Sessions of twenty to thirty minutes, not two hours. Attention on a working ward comes in short windows. - Timed to the shift, not to the trainer. Catch the night shift at 6am when the ward is quiet rather than asking eleven nurses to come in on an off day. - Scoped to the role. A staff nurse needs vitals, medication administration, nursing notes and handover. She does not need the tariff master. - Repeated. One pass teaches nobody. Three short passes across a fortnight, with real work in between, teaches everybody. Hospitals resist this because it is expensive in trainer hours. It is far cheaper than a rollout that quietly reverts to paper. ## Super-users carry the rollout, not the trainers External trainers leave. That is the structural flaw in the classroom model — the knowledge walks out of the building on the last day of go-live. What survives is whatever the ward can teach itself. The super-user model addresses this by picking two or three people per ward, per shift, and training them properly and early, a fortnight ahead of everyone else, with time to break things in a test environment without an audience. They are not necessarily the fastest typists. Choose them for standing: whoever the floor already goes to when something goes wrong. A few things separate a real super-user programme from a list of names on a slide: - Protected time. An hour a shift during go-live weeks, formally covered. - A direct line to the implementation team, not the general helpdesk queue. - Authority over small decisions. Which screen the ward defaults to, how the handover note is structured. Ownership converts people faster than instruction. - Public credit. In a hospital, being the person who knows is a currency. By the second month she is answering most of the questions the helpdesk would otherwise receive, and answering them better. ## The laminated card beats the training manual Somebody will produce a sixty-page user manual. It will be a PDF, it will live on a shared drive, and precisely nobody will open it at 2am in casualty. What gets used is a single laminated A5 card taped inside the nursing station cupboard door or hanging on a string beside the terminal. Admission in six steps. How to record a dose given late, and where the reason goes. How to raise an incident. Who to call when the printer will not release the discharge summary. It is written in the ward's own language, shorthand included, and reprinted whenever the workflow changes. The same logic applies to the software. If a nurse has to remember an eight-step path, the design is at fault, not the nurse. Systems like Kōami earn their place on a ward by keeping the common actions — record vitals, administer a drug, hand over the shift — a couple of taps away, and by not throwing her out of the screen when the patient in bed 12 needs both her hands for ten minutes. ## The loudest sceptic makes the best champion There is a strong temptation to route around the difficult senior: train the enthusiastic young nurses, build momentum, let the holdout come along later. This nearly always backfires, because the ward takes its cue from her, not from the project plan. If she is visibly unconvinced, the floor runs the system as a data-entry chore alongside the register — double documentation, which is worse than either system alone. Bring her in before go-live, not after. Ask her what the system gets wrong. She will tell you precisely, and she will usually be right: the handover screen does miss the thing she tracks, the medication chart does not show the allergy clearly enough. Fix two of the things she raises and tell her which two. That is the conversion moment, and it has very little to do with training. She is not being asked to accept the system. She is being asked to shape it. When she does turn, she turns hard, because she has spent twenty years being right in public and has no intention of stopping. A sceptic who has openly signed off is worth a dozen willing juniors. ## Adoption shows up in the third month Go-live week tells you almost nothing. Everyone is being watched and compliance looks excellent. The honest test comes in the third month, on a Sunday night, when the ward is two nurses short and nobody is observing. If the register has come back out of the cupboard, the rollout failed, whatever the dashboard says. The wards where it holds are the ones where the senior sister decided the system was hers. That decision is never made in a training room. It gets made the day somebody senior enough to matter asked her what was wrong with it, and then changed it.

Read article
Why We Built Kōami as One Connected Ecosystem — Product | KōamiProduct
Product· 4 min read

Why We Built Kōami as One Connected Ecosystem

We kept walking into hospitals that were running four or five systems which could not talk to each other, and watching staff re-key the same patient into every one of them. A person would be registered at the front desk, typed again into the lab system, typed a third time at the pharmacy counter, and once more into the billing software before they were discharged. Every one of those keystrokes was a chance to introduce an error, and every reconciliation between the systems was a chance to lose money, time, or trust. Kōami is our answer to that. It is a connected ecosystem of clinical-grade software - hospital operations, workforce, inventory, imaging and field service - that shares one identity and one data model, so the work flows instead of the paperwork. This piece explains the problem we set out to solve, the principles we built on, and how the pieces fit together in practice. ## The real cost of disconnected systems The bill for fragmentation rarely shows up as a single line item. It hides in the extra minutes at every counter, the duplicate records that have to be merged, the claims that bounce because a charge was captured in one system and billed from another. It shows up when a ward runs out of a consumable that the store thought it had, because the two were counting from different books. Individually, none of these is a catastrophe. Together, across thousands of patients a month, they are the difference between a hospital that runs smoothly and one that is always fighting its own tools. The staff feel it first, because they are the ones bridging the gaps by hand. > A product is only as good as the seams between its parts - so we tried not to have any. ## One identity, one data model The foundation of the ecosystem is deliberately boring: a single identity and a single data model. A patient is registered once and carries the same Unique Medical Record across every product. A staff member has one account, one set of permissions, and one place their credentials live. An item of stock is the same item whether the ward is consuming it or the store is reordering it. That shared spine is what lets the products behave like one system instead of five. When a discharge in the hospital module deducts consumables in inventory and frees a bed on the occupancy board, nobody has to reconcile anything - because there was only ever one event, seen from three angles. ## Five products, each strong on its own We did not want to force anyone to adopt everything at once. Each product stands on its own and solves a real problem the day you switch it on: - Kōami Hospital connects registration, OPD, IPD, EMR, pharmacy, lab, radiology and billing to one patient record. - Kōami Workforce handles rostering, geofenced attendance, statutory payroll and credential compliance for a round-the-clock hospital. - Kōami Inventory keeps stock, batches and expiry under control, and reorders before anything runs out. - Kōami PACS streams imaging studies to a browser-based viewer with AI-assisted findings and structured reporting. - Kōami Field Service dispatches technicians and tracks SLAs so biomedical equipment stays up. Most customers start with one - usually where the pain is loudest - and add the rest over time. Because they share the data model, each new product lights up already knowing your patients, your staff and your stock. ## Interoperability, not a walled garden A connected ecosystem is not the same as a closed one. Hospitals already run software they cannot and should not replace overnight, so Kōami is built to exchange data with the world around it through open REST APIs and webhooks. The goal is that adding Kōami never means ripping out something that already works; it means giving the pieces a common language. ## Security as a foundation, not a feature Because everything shares one identity, we could make security a property of the whole platform rather than a bolt-on per product. Single sign-on with multi-factor authentication, granular role-based access, and audit logging that spans every product mean the right people see the right data, and every access is accountable. Getting this right once, at the foundation, is far better than getting it slightly wrong five times. ## What this looks like on a normal Tuesday Consider an ordinary admission. A patient is registered once and admitted; orders, medicines and results flow through EMR, pharmacy and lab. The right clinicians are auto-rostered to the ward, their attendance captured on a geofenced check-in. Consumables are deducted from stock in real time, triggering an automatic reorder before the shelf runs low. An imaging study is read in the browser with AI findings alongside. A flagged biomedical device raises a work order, and a technician is dispatched before it fails. No one re-typed anything, and no one reconciled anything - the systems simply agreed, because they were never really separate. ## The road ahead We are early, and we are building alongside a first group of hospitals and clinics who are shaping the platform around how care actually works. That is the whole idea: start where the pain is, prove the value on real data, and let the ecosystem grow with you. If that sounds like the kind of partner you want, we would love to talk.

Read article
Live Bed Management from ADT to Discharge — Operations | KōamiOperations
Operations· 5 min read

Live Bed Management from ADT to Discharge

Ask a bed manager how many beds are free right now and you will often get a pause, a phone call, and a number that is already wrong by the time it is spoken. The bed board on the wall said one thing at eight this morning; the ward knows another; the emergency department, holding patients on trolleys, is working from a third. A bed that a system marks as occupied may have been vacated an hour ago and not yet cleaned; a bed marked free may already be promised to a transfer nobody logged. Bed management is the circulatory system of a hospital, and when the picture is stale, everything downstream - admissions, transfers, discharges, the emergency department's ability to breathe - runs on guesswork. Getting it right is less about counting beds and more about keeping the count true, minute by minute, as patients move. ## The problem is not beds, it is truth Most hospitals do not have a bed-counting problem. They have a bed-truth problem. The physical beds are there; what is missing is a single, current, trustworthy statement of their state. When the information lives in a whiteboard, a ward register, and several people's heads, it drifts out of sync the moment anyone moves. The states a bed can be in are not just "full" and "empty." A useful picture distinguishes: - Occupied - a patient is in the bed now. - Ready - clean, made up, and available to admit immediately. - Vacated but dirty - the patient has left, the bed needs turning over before reuse. - Blocked - out of service for maintenance, isolation, or infection control. - Reserved - held for a known incoming admission or transfer. A bed marked simply "free" hides all of this. The emergency department cannot tell an immediately-usable bed from one that is still dirty, so it either waits unnecessarily or sends a patient to a bed that is not actually ready. Kōami tracks these states distinctly, so "free" means genuinely ready, and the difference is visible rather than assumed. ## ADT as the single source of movement Every change in bed state comes from a patient movement, and those movements have a name: admission, discharge, and transfer - ADT. If bed status is updated separately from the ADT events that cause it, the two will always disagree. The only reliable design is to make the movement drive the status, so they cannot diverge. > A bed board is only as honest as the last movement someone remembered to log. Tie it to ADT and honesty stops depending on memory. When an admission is recorded, the bed becomes occupied automatically. When a transfer is ordered, the origin bed enters turnover and the destination is reserved. When a discharge completes, the bed moves to vacated-but-dirty and a housekeeping task is raised. Because Kōami drives bed status directly from ADT, the board reflects reality as a consequence of the movements that were going to be recorded anyway, not as a second, easily-forgotten step. The nurse does not update the bed board; the act of admitting the patient updates it. ## Closing the loop with housekeeping The gap that costs hospitals the most is the one between "patient discharged" and "bed ready." A discharged patient does not free a bed; a cleaned bed does. In many hospitals that turnover is a phone call away from happening, which means it happens late, and beds sit dirty and unusable while patients wait for them. Making the loop automatic changes the economics of the whole ward: - A completed discharge raises the cleaning task the instant it happens, not when someone calls. - Housekeeping sees the queue of beds to turn over, prioritised by demand. - When cleaning is marked done, the bed flips to ready and re-enters the live count immediately. - The admissions and emergency departments see that readiness the moment it exists. That closed loop is where the waiting-for-a-bed problem is actually solved. The bed that a discharge freed at eleven becomes a bed the emergency department can use at half past, because the turnover was triggered, tracked, and reported without a single chase-up call. Kōami connects discharge, housekeeping, and the live bed count so the handoff carries itself. ## Occupancy you can act on, not just admire Bed occupancy is one of the most quoted numbers in hospital management and one of the least useful when it arrives a day late. A monthly average occupancy figure tells the board something; a live occupancy view tells the operations team what to do in the next hour. The two are different tools, and the live one is where daily decisions get made. A real-time picture lets the bed manager act before a squeeze becomes a crisis. When occupancy in one ward crosses a threshold, it shows now, while there is still time to expedite a discharge, open a flexed bed, or redirect an admission. When the emergency department is holding patients, the bed manager can see exactly which beds are close to ready and push the turnover on those specifically. Occupancy broken down by ward, by specialty, and by bed type turns a single blunt percentage into an actionable map. Kōami keeps this view current so the number is a lever, not a postmortem. ## The whole patient journey, one connected flow Bed management does not live alone. It is the hinge between admission and discharge, and it only works when it is connected to both. The discharge that frees a bed, the OPD or emergency admission that fills one, the transfer between wards, the housekeeping turnover - these are not separate systems that need reconciling. They are one flow of the patient through the hospital, and the bed state is simply the visible trace of that flow. When they are connected in one ecosystem, the benefits compound. An earlier-initiated discharge frees a bed sooner, which the emergency department sees sooner, which shortens someone's wait on a trolley. A transfer logged properly keeps two wards' counts honest at once. The bed board stops being a thing someone maintains and becomes a thing the hospital's own movements keep true. That is the real goal of live bed management: not a perfect count for its own sake, but a hospital that always knows where its next bed is coming from - and can act on that knowledge while it still matters.

Read article
Scheduling the Operating Theatre Without Collisions — Operations | KōamiOperations
Operations· 6 min read

Scheduling the Operating Theatre Without Collisions

The operating theatre is the most expensive room in the hospital and the one least forgiving of a scheduling mistake. A collision there is not a double-booked meeting room; it is an anaesthetised patient, a scrubbed team, and a surgeon waiting because the previous case overran and nobody rebalanced the list. The OT schedule sits at the intersection of surgeons, anaesthetists, nurses, equipment, and the patient's own preparation, and every one of those has to line up in the same room at the same time. Scheduling it well is less about a prettier calendar and more about respecting the constraints that, when ignored, turn into cancellations, overtime, and a theatre that runs at a fraction of its capacity. ## Why theatre scheduling is genuinely hard People who have never built an OT list underestimate it because a calendar looks simple. The difficulty is that a single slot is not one resource but a set of resources that must all be free together, and each has its own rules: - The surgeon has to be available, and not already listed in another theatre. - The anaesthetist has to cover the case, and cannot be in two rooms at once. - The theatre itself has to be free, cleaned, and turned over from the previous case. - The specific equipment or implant set has to be present, sterilised, and not committed elsewhere. - The patient has to be prepared - fasted, consented, pre-assessed, and physically ready. Book a slot that satisfies four of these and misses the fifth, and you have a cancellation waiting to happen. A booking system that only tracks the room is not scheduling the OT; it is scheduling the furniture. Real OT scheduling checks every constraint at the moment of booking, so the collision is caught on screen rather than discovered in the corridor. ## Booking against every constraint, not just the room The core move is to make a booking impossible to confirm until all the resources it needs are actually free. When the scheduler proposes a case, Kōami checks the surgeon, the anaesthetist, the theatre, and the required equipment set against everything else already on the list, and refuses the clash instead of quietly accepting it. A double-booked surgeon is flagged where it can still be fixed. > The cheapest cancellation is the one prevented at booking. Every other kind is paid for in wasted theatre time and a patient sent home unoperated. That validation is what separates a scheduling system from a shared diary. It also lets the scheduler see the real picture - which surgeon has capacity on Thursday, which theatre has a gap, whether the implant set booked for the morning case will be back in time for the afternoon one. Estimated case durations feed the layout, so the list reflects how long procedures actually take rather than an optimistic guess, and the turnover time between cases is built in rather than assumed to be zero. ## Turnaround is where theatres win or lose time Ask why a theatre managed six cases instead of eight, and the answer is usually not the surgery. It is the gaps between cases - the turnaround, when one patient leaves, the room is cleaned, the next set is prepared, and the next patient is brought in. Those gaps are where capacity quietly evaporates, and they are almost always longer than anyone admits. Scheduling has to treat turnaround as a real, planned interval, not dead space that magically disappears. That means: - Building realistic cleaning and set-up time into the list, per procedure type. - Sequencing cases so that equipment and staff flow from one to the next without a scramble. - Having the next patient prepared and ready before the current case finishes, not after. - Watching the list live so that when one case overruns, the downstream cases are adjusted deliberately rather than colliding. When the schedule respects turnaround honestly, the theatre stops overrunning into the evening and starts finishing its planned list within the planned day. Kōami keeps the running list visible so the OT coordinator can see slippage as it happens and rebalance - move a short case forward, alert the next surgeon, adjust the afternoon - instead of finding out at handover that the day has fallen an hour behind. ## The safe-surgery checklist as part of the flow A schedule that packs the theatre efficiently but drops the safety steps has optimised the wrong thing. The safe-surgery checklist - the structured pauses before induction, before incision, and before the patient leaves the room - is not paperwork to be squeezed out when the list is tight. It is the guardrail that catches the wrong-site, wrong-patient, wrong-procedure errors that no amount of scheduling efficiency can be allowed to risk. The practical answer is to make the checklist part of the case flow rather than a separate form that competes with it for time. When the pre-operative verification, the sign-in, the time-out, and the sign-out are steps in the same record that carries the schedule, they get done because they are part of moving the case forward, not despite the pressure of the list. Kōami supports the checklist as an integral part of the OT workflow, so the drive for throughput and the discipline of safety pull in the same direction instead of against each other. ## Measuring utilisation to plan better lists You cannot improve theatre efficiency you do not measure, and the measures that matter are specific. Utilisation - the share of available theatre time actually spent operating - tells you whether the room is earning its keep. Start delays tell you whether the first case of the day is dragging the whole list. Turnaround times tell you where the hidden gaps are. Cancellation rates, and the reasons behind them, tell you which constraint keeps breaking. Those numbers turn scheduling from a daily firefight into a plannable operation. If first-case start times slip consistently, you fix the morning preparation, not the surgeon. If a particular procedure always overruns its booked slot, you adjust its estimated duration so future lists are honest. If cancellations cluster around missing equipment sets, you fix the sterilisation loop. Kōami keeps this history so the OT manager tunes the next month's lists against evidence rather than the loudest complaint from last week. Scheduling the theatre without collisions is not a scheduling trick. It is the accumulation of honest constraints checked at booking, realistic turnaround built into the list, safety kept inside the flow rather than outside it, and utilisation measured so the plan gets better each cycle. Get those right and the most expensive room in the hospital finally spends its time doing the thing it exists for - operating - instead of waiting.

Read article
Running a Multi-Branch Hospital Group on One System — Operations | KōamiOperations
Operations· 6 min read

Running a Multi-Branch Hospital Group on One System

A hospital group is not one hospital repeated. It is several hospitals, each with its own consultants, its own local suppliers, its own quirks of layout and habit, and a head office that needs to see all of them at once without flattening what makes each one work. The temptation, when a group grows, is to let every branch run its own systems and reconcile the numbers later. That works until it does not - until a patient who was seen at one branch turns up at another and their history is invisible, until central procurement cannot tell which site is overstocked while another runs dry, until the monthly board pack is three weeks of manually merging spreadsheets that never quite agree. Running a group on one system is not about central control for its own sake. It is about giving each branch autonomy where it needs it and the group visibility where it needs that. ## One patient, many branches The clearest test of a group system is what happens when a patient moves between sites. In a federated mess of separate systems, the patient is effectively a new person at each branch - re-registered, re-explained, their allergies and history left behind at the site that first recorded them. That is not just inconvenient. It is a clinical risk, repeated at every internal referral. A single patient identity across the group fixes this. The same person carries one record, one history, one set of allergies and results, wherever in the group they are seen: - A referral from a smaller branch to the group's tertiary centre arrives with the full history attached, not a scribbled note. - Results ordered at one site are visible to the treating clinician at another. - The patient does not repeat their story, or their registration, at every door. Kōami holds that shared identity while still letting each branch run its own OPD, its own wards, and its own local workflows. The record is common; the operation stays local. That balance - shared where it helps the patient, local where it helps the branch - is the whole design principle of a group system. ## Cluster structure without a straitjacket Groups are rarely flat. There are clusters - by city, by region, by tier - and the reporting and control structure has to reflect that reality rather than fighting it. A regional director wants to see their cluster rolled up; a branch administrator wants their own site's numbers without noise from the others; the board wants the whole group on one page. > Centralisation should be a dial, not a switch. Some things belong to the group; many things belong to the branch; wisdom is knowing which is which. The workable pattern is a hierarchy where the group sets the standards - the master data, the item catalogue, the chart of cost centers, the core policies - and each branch operates within them while keeping local control of the things that are genuinely local. Doctor rosters, OT schedules, ward configurations, and local vendor relationships stay with the branch. Pricing might be set centrally with room for local adjustment, or set locally within group-defined bands. Kōami supports that layered structure so the group is coherent without every branch being forced into an identical mould that fits none of them well. ## Inventory that moves across the group Stock is where a group system pays for itself fastest. Each branch running its own isolated store will, reliably, produce the same absurd situation: one site writing off expired reagents while another places an emergency order for the very same item at a premium. They simply cannot see each other. Put the branches on one inventory backbone and that waste becomes visible and fixable. Before any site raises an external purchase order, the system can check group-wide stock and suggest an inter-branch transfer from a location holding surplus. Central procurement can negotiate as a group - real volume, real leverage - while each branch still requisitions against its own cost center and receives against its own GRN. - See on-hand stock across every branch and the central store in one view. - Suggest transfers before purchases, turning one site's surplus into another's supply. - Negotiate group contracts on real aggregate volume, not per-site guesswork. - Keep reorder points local to each branch's actual consumption and lead times. Because Kōami connects inventory and procurement across the whole group, the reorder logic and the three-way match that work for a single hospital simply extend across many, with the group's scale as an added lever rather than an added headache. ## Reporting that reconciles by design The monthly grind of merging branch spreadsheets exists only because the branches were never on the same data model. When they share one system, the roll-up is not a project; it is a query. Occupancy, revenue, OPD throughput, average length of stay, stock value, procurement spend - each can be read per branch, per cluster, or for the group as a whole, using the same definitions everywhere. That last point is the quiet one that matters most. When "bed occupancy" or "average length of stay" means the same thing at every site, comparison becomes fair and useful. You can see that one branch discharges faster, ask why, and spread the practice. When every site defines its metrics slightly differently, comparison is noise and the board learns nothing. A common system enforces common definitions as a byproduct, so benchmarking across the group becomes a management tool rather than an argument about whose numbers are right. ## Rolling out without breaking the branches The risk in unifying a group is a big-bang cutover that disrupts live clinical operations across many sites at once. The saner path is to bring branches onto the shared system in sequence, prove the model at one or two sites, carry the master data and identity forward, and let each branch adopt the common core while keeping its local configuration intact. Kōami's shared-identity, layered-control structure is built for that gradual convergence rather than an all-or-nothing switch that no operating hospital can safely afford. A multi-branch group run well feels, to a patient, like one organisation that happens to have several front doors. It feels, to a branch administrator, like their own hospital with better backup. And it feels, to the group's leadership, like a single trustworthy picture instead of a monthly reconciliation. Getting there is not about imposing sameness. It is about sharing what should be shared - the patient, the standards, the visibility - and leaving to each branch the local judgement that made it worth having in the first place.

Read article
Procure-to-Pay Without the Paperwork — Supply Chain | KōamiSupply Chain
Supply Chain· 6 min read

Procure-to-Pay Without the Paperwork

Procurement is where good hospitals lose money and time in ways that never show up on a clinical audit. A single purchase can pass through a requisition, a quotation, an approval, a purchase order, a delivery, a goods receipt, an invoice, and a payment - and at every handoff there is a form, a signature, a phone call, and a chance to lose the thread. When those steps live in email, spreadsheets, and a shared drive of scanned PDFs, the finance team spends its month reconciling instead of controlling. Procure-to-pay done well is not about buying software to digitise the paperwork. It is about removing the paperwork so the control that mattered - who approved what, and does the invoice match reality - is enforced by the flow itself. ## The paper trail that quietly costs a fortune Before you can fix procurement, it helps to see honestly where the money and hours leak. In a paper-and-email process, the usual suspects are always the same: - Requisitions that sit in someone's inbox because there is no queue and no owner. - Purchase orders raised without checking an agreed price or preferred vendor, so the hospital pays retail on a contracted item. - Deliveries received against a delivery note that nobody reconciles to the PO, so short-shipments and wrong items slip through. - Invoices paid because they arrived and looked plausible, not because they were checked against what was ordered and what was received. - Duplicate payments, because the same invoice came by email and by post and nobody caught it. None of these are exotic failures. They are the ordinary friction of a manual process, and across a year they add up to real money and a finance team that is always behind. The fix is to make each step create a record that the next step is forced to check. ## One flow from requisition to purchase order The front half of procure-to-pay is getting from "a ward needs something" to "a purchase order is with the vendor" without losing days to chasing. In Kōami that path is a single connected flow. A requisition is raised against a cost center, routed to the right approver by value and category, and - once approved - turned into a purchase order that already knows the preferred vendor and the agreed price. > A purchase order is a promise. If it does not carry the agreed price and the right vendor, you are negotiating again at invoice time, when you have the least leverage. Because the requisition, the approval, and the PO are the same object moving through states rather than three documents retyped, the audit trail is a byproduct, not a chore. Anyone can see who requested, who approved, and on what terms, without opening a filing cabinet. And because inventory and procurement sit in the same ecosystem, a reorder trigger from the store can draft the requisition automatically, so routine replenishment does not wait for someone to notice. ## GRN and the three-way match The moment goods arrive is the moment control is won or lost. A goods receipt note (GRN) records what actually turned up - the quantities, the batches, the condition - against the purchase order that ordered it. That comparison is the first line of defence. If forty units were ordered and thirty-eight delivered, the GRN catches it there, at the loading dock, not six weeks later when finance is puzzling over a mismatched invoice. The real discipline is the three-way match: the purchase order, the goods receipt, and the vendor invoice all have to agree before payment is released. This is the single most effective control in procurement, and it is almost impossible to enforce by hand at volume: - The PO says what was ordered and at what price. - The GRN says what was actually received. - The invoice says what the vendor is charging. When all three line up, payment can proceed with confidence. When they do not, the exception is flagged for a human rather than paid on trust. Kōami runs this match automatically, so the finance team's attention goes to the handful of genuine discrepancies instead of the hundreds of clean transactions. Short-shipments, price creep, and duplicate invoices surface as exceptions rather than slipping through as payments. ## Vendors and cost centers you can actually see Managing vendors well is not about having their phone numbers. It is about knowing, at any moment, how each one performs and what you are actually spending with them. When every PO, GRN, and invoice is connected, the vendor record stops being a contact card and becomes a performance history: who delivers on time, who short-ships, whose lead times have quietly doubled, who keeps sending invoices that do not match. That history feeds better decisions. The lead-time data flows back to inventory so reorder points reflect the vendor's real behaviour, not their promises. The pricing data shows where a contracted rate is being honoured and where it is drifting. And because spend is tagged to a cost center, department heads can see what their unit is consuming and finance can hold budgets against reality rather than guesswork. - Track on-time delivery and fill rate per vendor, from the GRN data you already capture. - Watch price variance against agreed rates so contract leakage is visible. - Attribute every purchase to a cost center so budgets mean something. - Keep the full approval and match trail on each transaction for clean internal review. None of this requires extra data entry. It falls out of running the flow properly, because each step already recorded what it needed to. ## Paying with confidence, and paying once Payment should be the calm end of a controlled process, not the anxious moment where you hope the numbers were right. When the three-way match has already cleared, releasing payment is a decision made on evidence: this was ordered, this was received, this is the correct amount, and this invoice has not been paid before. Duplicate detection stops the same bill being settled twice. The approval chain means no single person can quietly push through a payment that nobody else saw. Procure-to-pay without the paperwork is not a promise of less work for its own sake. It is a promise that the work which remains is the work that matters - negotiating with vendors, managing budgets, resolving real exceptions - while the repetitive checking that used to eat the finance team's month is handled by a flow that never skips a step. Kōami ties requisition, PO, GRN, invoice, and payment into that one flow, so control stops depending on whether someone remembered to reconcile, and starts being simply how the process runs.

Read article
Reorder Points That Prevent Stock-Outs — Supply Chain | KōamiSupply Chain
Supply Chain· 5 min read

Reorder Points That Prevent Stock-Outs

Every hospital store has two failure modes, and they are mirror images of each other. In one, a critical item runs out at the worst possible moment - a suture size mid-procedure, a reagent the lab needs before the morning run, a drug the ward assumed was always there. In the other, a cupboard is quietly stacked with six months of something that expires in three, capital tied up in stock nobody will use in time. Both come from the same root: someone is guessing when to reorder, and human guessing does not scale across thousands of line items. Reorder points exist to replace the guess with arithmetic, and arithmetic that runs by itself does not forget, does not go on leave, and does not panic-order. ## What a reorder point actually is A reorder point (ROP) is the stock level at which you place a new order. It is not a vibe or a gut feel; it is a number you can calculate, and it rests on three inputs you already have or can measure: - Average daily consumption - how fast the item actually moves, not how fast you think it does. - Lead time - how long the vendor genuinely takes from purchase order to goods received, in practice, not on paper. - Safety stock - the buffer that absorbs the normal variation in both of the above. The core relationship is simple: ROP equals average daily usage multiplied by lead time, plus safety stock. When on-hand quantity falls to the ROP, you order enough to bring stock back up toward a defined maximum. That min/max/ROP framing is the whole discipline in one line. The hard part is not the formula. It is keeping the inputs honest and acting on the trigger every single time. ## Why min/max beats intuition at scale A charge nurse can eyeball reordering for the dozen items she touches every day. She cannot do it for the several thousand SKUs a hospital carries across pharmacy, consumables, lab reagents, and OT sets. At that scale, intuition degrades into a mix of over-ordering the familiar and under-ordering the rare-but-critical. > Stock-outs are rarely a supply problem. They are almost always a signal problem - nobody saw the level fall until it was already too late. Setting a minimum and a maximum per item turns thousands of judgement calls into thousands of rules that the system checks continuously. The minimum is your ROP; the maximum caps how much you hold so you do not swing into overstock. Kōami watches on-hand quantity against those thresholds in real time and raises the reorder the moment stock crosses the line, so the trigger does not depend on a person happening to open the right cupboard on the right day. The payoff is not just fewer stock-outs. It is fewer emergency purchases at bad prices, less expired stock written off, and a store manager who spends time on exceptions instead of on counting. ## Consumption is not constant, so the numbers must move The quiet failure of static reorder points is that they are set once and never revisited. Consumption is seasonal and situational. A dengue season spikes certain reagents and fluids. A new surgeon joining the OT changes the demand for a particular set of consumables overnight. A single high-volume month can shift the true average well away from the number someone typed in last year. Reorder points have to breathe with demand. That means recalculating average daily consumption on a rolling basis rather than freezing it, and reflecting real observed lead times rather than the vendor's optimistic quote. When a vendor who used to deliver in three days is now taking eight, the safety stock and ROP for their items should rise to match, automatically, before that slippage becomes a shortage. - Recompute average usage on a moving window so trends are captured early. - Track actual lead time per vendor and per item, and feed it back into the ROP. - Flag items whose consumption pattern is changing sharply for a human to review. - Separate steady movers from lumpy, unpredictable ones - they need different buffers. Kōami keeps this loop running so the thresholds stay tied to reality instead of drifting into fiction the moment they are set. ## From trigger to purchase order without the scramble A reorder trigger that only sends an email is half a solution. The point is to shorten the distance between "stock is low" and "replenishment is on its way." When on-hand crosses the ROP, the system should be able to draft the purchase order itself - the right item, the right quantity to reach maximum, the preferred vendor, the last agreed price - and put it in front of the person who approves it. That person is still in control. What changes is that they are approving a well-formed order rather than assembling one from scratch under time pressure. For low-value, high-frequency items, the approval can be light; for expensive or clinically critical ones, it stays deliberate. Because Kōami connects inventory to procurement, the drafted PO carries straight through to the vendor, and when the goods arrive the GRN posts back against stock, which updates on-hand, which keeps the next ROP calculation accurate. The loop closes on itself. Multi-store hospitals get an extra benefit here. Before raising an external order, the system can check whether another branch or central store is holding surplus, and suggest a transfer instead of a purchase. That turns dead stock in one location into a stock-out prevented in another. ## Getting started without boiling the ocean You do not need perfect data to begin, and waiting for it is how these projects die. Start with the items that hurt most when they run out - the critical, fast-moving, or expensive ones - and set defensible min/max levels using whatever consumption history exists. Let the system run, watch where it over- and under-corrects, and tighten from there. The numbers get better precisely because they are being used. The goal is not a warehouse that is never wrong. It is a store where the boring, repetitive vigilance is handled by arithmetic that never sleeps, so that the pharmacist and the store manager are freed to deal with the genuine exceptions - the recall, the shortage, the new procedure - that actually need a human. Reorder points that run themselves are not about clever software. They are about making sure nobody ever again discovers a stock-out by reaching for an empty shelf.

Read article
A Portal Patients Actually Use — Patient Experience | KōamiPatient Experience
Patient Experience· 6 min read

A Portal Patients Actually Use

Most patient portals fail the same way. They are built as a compliance checkbox or a marketing feature, launched with fanfare, and then quietly abandoned by the people they were meant to serve. Patients log in once, cannot find their report, hit a dead end, and never return. The clinic concludes that patients "do not want digital," which is exactly the wrong lesson. Patients want the specific things a portal can do for them. What they do not want is a second, worse version of the hospital's paperwork, dressed up in a login screen. A portal patients actually use starts from what the patient came for, not from what the IT roadmap wanted to tick off. ## Start from the three things patients actually want Walk up to someone in a waiting room and ask what they wish they could do without calling the hospital, and you will hear a short, consistent list. Not a feature matrix - a handful of real needs: - See my test results as soon as they are ready, and understand what they mean. - Book, move, or cancel an appointment without waiting on a phone line. - Get my prescription and discharge instructions in a form I can actually read later. Everything else is secondary. A portal that does these three things reliably will be used every week. A portal that does thirty things badly will be used once. The discipline is to make the common path effortless and to resist burying it under features that sound impressive in a demo and matter to almost no one. Kōami's approach is to treat the portal as the patient-facing surface of the same record the clinicians use, not a separate island that has to be manually synced. When a result is finalised in the lab, it is available to the patient. When an appointment moves, the patient sees the new time. There is no overnight batch, no re-entry, no divergence between what the front desk knows and what the patient can see. ## Results that explain themselves A lab value on its own is a source of anxiety, not information. A patient who sees "14.2" with no context will either panic or ignore it, and both are bad outcomes. The portal has to do a little of the work that a good clinician does at the bedside: show the reference range, flag whether the value is in or out of it, and where possible give a plain-language line about what the test was for. > A result the patient cannot interpret is not transparency. It is just a number that generates a phone call. There is a judgement call here, and it is worth making deliberately. Some results should reach the patient through their clinician first, not as a raw notification at eleven at night. A sensible portal lets the clinical team set the release rules - immediate for routine results, held for review on the sensitive ones - so that transparency does not come at the cost of a patient reading life-changing news alone and unsupported. Kōami supports that graduated release rather than treating every result the same way. ## Appointments the patient can actually manage Booking is where most portals quietly break. They show a calendar that is not really the clinic's calendar, so the patient books a slot that does not exist, turns up, and finds the doctor on leave. Trust, once broken that way, does not come back. The booking surface has to be the real schedule - the same slots the front desk sees, with the same holds and the same rules. Done properly, self-service booking takes load off the phone lines and gives the patient control at the same time. They can: - Book into a genuinely available slot for the right department and doctor. - Reschedule or cancel within the clinic's own policy window. - Get a reminder ahead of time, and a simple way to confirm they are coming. - See their upcoming and past visits in one place, tied to the same token and queue flow they will meet on the day. Because the portal shares the OPD scheduling and queue system, a booked appointment carries through to the token the patient receives on arrival. The online action and the physical visit are the same thread, not two systems the patient has to reconcile. ## Instructions that survive the car park Some of the most important minutes of a hospital visit happen in the last ten, when a tired patient is handed a prescription and a set of instructions and told to follow them at home. By the time they reach the car park, half of it is forgotten. This is where a portal earns its keep quietly and permanently. The discharge summary, the medication list with timing, and the follow-up plan should all land in the portal automatically, drawn from the same records the clinical team finalised. Not retyped, not a scanned photo of a handwritten note, but structured, legible, and available at two in the morning when the patient's daughter is trying to remember whether the tablet was twice a day or three times. Kōami links the portal to the discharge and prescription flow so this content appears without anyone re-keying it. That connection matters more than it first appears. When instructions live in the portal, the family can act on them, the patient is more likely to actually take the medication correctly, and the clinic gets fewer confused callbacks the next morning. ## Designing for the patient who is not tech-confident A portal that only works for the youngest, most digitally fluent quarter of patients has failed the majority who need it most. The design has to assume a tired, anxious, sometimes older user on a mid-range phone with patchy signal. That means large tap targets, plain language, minimal steps to the common tasks, and graceful behaviour when the connection drops. It means not forcing a password reset odyssey to see a blood test. And it means the front desk can still do everything on the patient's behalf, so the portal is an addition to human help, never a replacement that leaves the less-confident stranded. A portal patients actually use is not the one with the longest feature list. It is the one that shows results they understand, lets them manage appointments against the real calendar, and hands them their instructions in a form that survives the journey home. Build those honestly on top of the same records the clinicians trust, and the login screen stops being a dead end and starts being the front door people choose.

Read article
Why Discharge Takes So Long - and How to Fix It — Patient Experience | KōamiPatient Experience
Patient Experience· 5 min read

Why Discharge Takes So Long - and How to Fix It

Discharge is the part of a hospital stay that patients remember with the least fondness, and often for the most avoidable reasons. The doctor said "you can go home today" at half past ten in the morning. It is now four in the afternoon, the bed is still occupied, the family has taken a day off work, and nobody can quite say what everyone is waiting for. Meanwhile, downstairs in the emergency department, a patient who needs that exact bed is waiting on a trolley. Discharge delay is not a comfort problem. It is a capacity problem wearing a comfort problem's clothes, and it is almost always caused by process, not by clinical need. ## The morning the decision is made The decision to discharge is a moment. The discharge itself is a chain of tasks, and the gap between the two is where the hours disappear. Once a consultant marks a patient fit to leave, a surprising number of separate things have to happen, usually in sequence, usually owned by different people who cannot see each other's progress: - The discharge summary has to be written, reviewed, and finalised. - Pending investigations have to be chased, resulted, and acknowledged. - Take-home medication has to be prescribed, dispensed by pharmacy, and counselled. - Final billing has to be assembled, including charges that are still being posted. - Insurance or scheme approval has to clear the final amount. - Someone has to physically confirm the bed is vacated so housekeeping can turn it over. Any one of these can stall the whole thing, and because they are handed off by phone call and paper, nobody has the full picture. The nurse thinks pharmacy is the holdup. Pharmacy is waiting on the summary. The summary is waiting on a lab result that came back an hour ago but nobody saw. This is the ordinary anatomy of a six-hour discharge. ## Initiate discharge early, not at the end The single most effective change is to treat "initiate discharge" as an action taken on ward rounds, not a status that appears when the patient is already dressed and waiting. When the treating team flags a likely discharge the evening before, or first thing on the round, every downstream station gets a head start. In Kōami, initiating discharge fans the work out in parallel rather than in series. The pharmacy sees the take-home prescription forming and can pre-pack it. Billing begins assembling the final statement while the patient is still on the ward. The nurse gets a checklist of what remains outstanding, item by item, instead of discovering the gaps at the last minute. > Discharge should be a countdown that everyone can see, not a surprise that lands on the ward clerk at 3 p.m. That shift - from sequential to parallel, from silent to visible - is where most of the recovered hours come from. Nothing about the clinical care changes. The care was already done. What changes is that the administrative tail stops being run one baton-pass at a time. ## The discharge summary as a shared, living document The discharge summary is both a clinical handover and a bottleneck. When it lives in one doctor's head until the last moment, it holds up medication, follow-up, and the patient's own understanding of what happens next. When it is built up through the stay, it is nearly finished by the time discharge is called. A good system lets the summary accrue: the diagnosis, the course of treatment, the medications, and the follow-up plan populate as they are decided, drawing on data already captured in the record rather than being retyped. The consultant reviews and signs rather than authoring from a blank page. Kōami keeps the summary connected to orders, results, and prescriptions, so the take-home medication list and the follow-up appointment are not re-entered by hand into three places. Two practical wins follow. First, the patient leaves with a document that is actually complete and legible, not a hurried scrawl. Second, the follow-up loop closes, because the summary can trigger the follow-up booking and, where relevant, feed the patient portal so the family has the instructions after they get home. ## Billing and approvals that keep pace Money is the quiet reason discharges stall past clinical readiness. Final billing cannot close until every charge is posted, and charges trickle in from pharmacy, from the last round of investigations, from consumables used that morning. If billing only starts assembling when discharge is called, it is starting from behind. The fix is to keep the bill live throughout the stay so that at the moment of discharge only the final few items remain to be reconciled. Where an insurer or scheme is involved, the approval workflow should run alongside, not after, so the pre-authorisation and the final settlement are not a fresh negotiation at 3 p.m. - Keep charges posting in near real time so the final bill is minutes of work, not hours. - Surface the outstanding-charge list to billing before discharge is called. - Run payer approval in parallel with clinical clearance, not after it. - Give the ward a single view of billing status so the nurse can answer the family honestly. When billing keeps pace with care, the financial step stops being the thing that adds two hours to an otherwise finished discharge. ## Turning the bed over on purpose The last mile is physical. A patient marked as discharged in the system but still in the bed is not a freed bed. Housekeeping needs to know the room is vacated, turn it over, and mark it ready, and the admissions or bed-management desk needs to see that readiness the moment it happens. Without that loop, beds sit "discharged but dirty" for an hour while the emergency department queues. Kōami connects the discharge event to bed status and the ADT flow, so a completed discharge triggers the cleaning task and, when the room is ready, releases the bed back into the live count. The waiting patient downstairs moves up not because someone made a lucky phone call, but because the system carried the handoff. Fixing slow discharge is not about pushing people to hurry. It is about starting earlier, working in parallel, keeping the summary and the bill alive through the stay, and closing the loop on the bed. Do that, and "you can go home today" starts to mean today - by lunchtime, not by dusk.

Read article
Cutting the OPD Wait with Token and Queue — Patient Experience | KōamiPatient Experience
Patient Experience· 5 min read

Cutting the OPD Wait with Token and Queue

Ask any hospital administrator where the day starts to go wrong, and most will point at the same place: the OPD. The consultation itself might take eight minutes, but the patient has already spent ninety in a corridor, unsure whether they have been forgotten, whether they missed their name being called, whether the person who arrived after them is somehow ahead. The waiting is not just uncomfortable. It shapes how the patient rates the entire visit, and it quietly burns through front-desk goodwill all morning. A token and queue system does not make doctors faster. What it does is make the wait legible, fair, and predictable - and that turns out to matter almost as much as speed. ## What actually creates the queue Most OPD congestion is not a doctor problem. It is a flow problem, and it usually comes from a handful of concrete causes that stack on top of each other: - Registration and consultation share the same physical line, so new patients and follow-ups fight for the same counter. - Appointments are booked but walk-ins are also accepted, and the two streams are never reconciled at the point of care. - A doctor runs late by twenty minutes at 9 a.m., and because nothing rebalances the load, that twenty minutes is still there at 1 p.m. - Patients have no signal about their position, so they crowd the door of every room to avoid missing a call. When you name the causes plainly, the fix stops being "hire more staff" and becomes "design the flow." A token is just the first step of that design: a stable identity in the queue that the patient can trust. ## Tokens that carry context, not just numbers A paper token with a printed number solves one problem - order - and nothing else. A digital OPD token in Kōami carries context. It knows whether the patient is a new registration or a scheduled follow-up, which doctor and which department they are waiting for, and roughly where they sit in that specific queue. That context is what lets you do the interesting things. You can run parallel queues per doctor instead of one giant line, so a busy cardiologist's backlog does not stall the dermatology patients. You can weight the queue so that a booked appointment holds priority over a walk-in who arrived at the same minute, which is the only fair way to honour appointments at all. And you can hold a token in a "called but not arrived" state for a short grace period, then cycle to the next patient without losing the first one entirely. > A good queue is not the shortest one. It is the one where every patient can see that the rules are the same for everybody. The display board and the patient's phone show the same token state, so the corridor empties out. People stop hovering at the door because they can watch their number advance from a bench, or from the pharmacy, or from the café downstairs. ## Giving the front desk a live picture The counter staff need a different view from the patient. They need to see the whole floor: which doctors are running behind, which rooms have gone quiet, how many walk-ins are still unassigned, and where a bottleneck is forming before it becomes a crowd. Kōami puts that on one screen. When a consultant is thirty minutes behind, the supervisor can see it at a glance and act - open a second room, redirect a few follow-ups to a colleague, or simply reset expectations with the people waiting. That last option is underrated. A patient told honestly that the wait is now forty minutes, and given the freedom to step away, is far calmer than one left guessing. The system supports that by pushing a status update to the patient's phone when their token moves into the next band. Reassignment matters too. If a doctor is called into an emergency, the affected tokens should not evaporate. They should shift, as a group, to another available consultant or to a clearly communicated hold, with the patients notified rather than surprised. ## Measuring the wait so you can shrink it You cannot improve a wait you do not measure. Every token generates timestamps almost for free: when it was issued, when the patient was called, when the consultation started, when it closed. From those, real numbers fall out - average time to first call, the gap between appointment time and actual start, turnaround per department, and the shape of the morning peak. Those numbers change decisions. If registration is the choke point, you add a counter at 9 a.m. rather than at 11. If one clinic consistently overbooks, you cap its slots. If the peak is always 10 to 11:30, you stagger appointment blocks to flatten it. Kōami keeps this history so the OPD manager is tuning against evidence instead of yesterday's argument. - Time-to-first-call tells you if registration and triage are keeping up. - Appointment-to-start delay tells you whether your booking model is honest. - Per-doctor turnaround tells you where to rebalance load. - No-show and grace-period cycling rates tell you how much slack to build in. Over a few weeks these metrics stop being a report and start being a habit. The floor supervisor reads them the way a shift nurse reads vitals. ## Closing the loop with the rest of the visit The queue does not end when the patient sees the doctor. A consultation usually spawns a lab order, a pharmacy pickup, a follow-up booking, or a billing step, and each of those is its own small queue. When the token flows through to those stations, the patient is not starting from zero each time. Their lab request is already waiting when they reach the collection counter; pharmacy can see the prescription before they arrive. Because Kōami connects OPD, orders, and billing in one ecosystem, the token becomes a thread that runs through the whole visit rather than a slip that gets thrown away at the consulting-room door. Cutting the OPD wait is rarely one dramatic change. It is a token that carries context, a fair queue the patient can watch, a live floor view for staff, and a steady diet of timing data that tells you where to push. Do those four things well and the corridor stops being the worst part of the visit - and the eight-minute consultation finally gets to be the point of the morning.

Read article
Capturing Charges as Care Happens — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 5 min read

Capturing Charges as Care Happens

Here is a number that should bother every hospital finance lead: the revenue you lose is rarely the bill you failed to collect. It is the charge you never captured in the first place. A consumable used in theatre and never scanned. An injection given on the ward and never posted. A procedure done at the bedside that nobody billed because the person who did it was busy doing the next one. Charge capture is the discipline of turning care that happened into charges that exist, and the gap between the two is pure, silent leakage. ## The leak nobody sees Uncollected bills are visible. They sit in a receivables report, they get chased, someone owns them. Uncaptured charges are invisible by definition - you cannot chase a charge that was never created. The service was delivered, the cost was incurred, and no revenue record was ever made against it. It does not appear as a loss because it never appeared at all. The leak concentrates in predictable places, all of them characterised by care happening faster than paperwork. - Consumables and implants used in theatre under time pressure - Drugs and injections administered on the ward between other tasks - Bedside procedures done by clinicians who are not thinking about billing - Investigations ordered verbally and performed before any order exists in the system None of these are fraud or laziness. They are the natural result of asking busy clinical staff to also be the billing department, using a workflow that treats charging as a separate task to be done later. Later is where charges go to be forgotten. ## Capture at the point of care, not after it The core principle is simple to state and hard to retrofit: the charge should be created as a byproduct of the clinical action, at the moment and place it happens, not reconstructed afterwards from notes and memory. When a nurse records that an injection was administered, that record should be the charge. When a consumable is taken from theatre stock for a case, that issue should generate the charge. The clinical act and the billable event are the same event, captured once. This is the opposite of the common pattern, where care is delivered all day and a clerk sits down at some point to bill it from the chart. Every hour between the act and the billing is an opportunity to lose it, and every reconstruction from notes is an opportunity to get it wrong. > A charge captured where the care happened is a charge that cannot be forgotten later, because it was never waiting to be remembered. Kōami ties charge capture to the clinical and stock events themselves - the administration record, the consumable issue, the procedure note - so the billable item is created as care is delivered rather than assembled from it afterwards. ## Let the tariff do the pricing Capturing that something happened is half the job; pricing it correctly is the other half. If clinical staff have to know or look up the price of everything they use, capture will fail, because that is not their job and they will not do it. The clinical action should record what was done and how much; the tariff should turn that into a priced charge automatically. When every service and item carries its tariff rate, the person at the point of care never has to think about money. They record the clinical fact - this drug, this dose, this procedure, this implant - and the correct charge follows from the rate card without a manual pricing step. This also keeps charges consistent, since the same tariff prices the same item every time regardless of who captured it. - Record the clinical fact at the point of care, not a price - Let the tariff convert the fact into a correctly priced charge automatically - Price the same item the same way every time, independent of who captured it - Keep the charge linked to the clinical event, so it can be justified if questioned ## What you get when the charge and the care are one When charge capture rides on the clinical workflow, several problems solve themselves at once. The bill at discharge is complete, because it was assembled continuously as care happened rather than reconstructed at the end. The running total is real throughout the stay, so a patient or a TPA can see an accurate figure at any point, not just a rough guess. And the leakage - the injections and consumables and bedside procedures that used to vanish - largely stops, because there is no longer a gap between doing the thing and charging for it. There is a second benefit that is easy to miss. A charge captured at the point of care carries its context - who did it, when, to which patient, against which order or clinical note. That context is exactly what you need when a charge is later questioned by a patient or an insurer. Instead of defending a line item reconstructed from memory, you have a charge tied to the moment of care that produced it. Charge capture is unglamorous, and that is precisely why it leaks. Nobody wakes up thinking about the injection that did not get billed, and no single missed charge is worth chasing. But the sum of them, across every ward and every theatre and every day, is a large number quietly missing from the hospital's revenue. Close the gap by making the charge and the care the same event - captured once, priced by the tariff, tied to the moment it happened. The care was already delivered. The only question is whether you charged for it, and that should never be left to memory.

Read article
Package Billing vs Open Billing, Explained — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 5 min read

Package Billing vs Open Billing, Explained

Two patients have the same operation on the same day by the same surgeon. One is billed a single fixed figure agreed in advance. The other is billed line by line - every investigation, every consumable, every day of the room. Both are legitimate. Which one you use changes what the patient expects, what the hospital collects, and how much argument happens at discharge. Package billing and open billing are two different contracts with the patient about how care becomes a bill, and confusing them is where revenue and goodwill both leak. ## The two models, plainly Open billing is the itemised approach. Every service the patient consumes is captured and charged at its tariff rate: consultations, investigations, procedures, drugs, consumables, room charges per day. The final bill is the sum of everything that actually happened. It is transparent and it is precise, and its total is not known until care is complete. Package billing is the fixed-price approach. A defined set of services is bundled into a single agreed price for a defined episode - a normal delivery, a cataract, a knee replacement. The patient knows the figure up front. The bundle specifies what is included, for how long, and under what conditions, and the hospital absorbs the ordinary variation within those bounds. - Open billing: pay for exactly what was used, totalled at the end - Package billing: pay a fixed price for a defined episode, known at the start - Open billing shifts variation onto the patient; package billing shifts it onto the hospital ## Where package billing earns its keep Packages exist because predictability has value to everyone. The patient gets a number they can plan around. The hospital gets a clean, fast-settling bill and a competitive offer for common, well-understood procedures. Insurers and TPAs like packages because they cap exposure and simplify approval. For high-volume, low-variance work, a package is usually the better instrument. The discipline a package demands is a clear definition of what is inside it. A package that is vague about inclusions is a dispute waiting to happen. The bundle has to state, precisely, the room category it assumes, the length of stay it covers, the procedures and investigations included, and what happens when reality exceeds the bundle. > A package is only as good as its list of what happens when the patient does not fit the package. That last part is where packages actually live or die. Real patients develop complications, need an extra day, or arrive with a comorbidity that changes the work. A workable package defines its boundaries: what is included, what triggers a move to itemised charging, and how the overage is handled. Kōami lets a package carry its inclusions, its room-category and stay assumptions, and its exclusion rules, so the point where a case leaves the package is defined rather than argued. ## Where open billing is the honest answer Open billing is right when the work is genuinely variable and cannot be predicted into a bundle. Complex medical admissions, long ICU stays, cases where the diagnosis itself is still moving - forcing these into a fixed package either overcharges the simple ones or bankrupts the hospital on the complex ones. Itemised billing charges for what actually happened, which is the fair answer when what happens is genuinely uncertain. ## Choosing the right instrument per case The two models are not rivals to pick between once and forever. A single hospital runs both, and often a single admission uses both: a package for the core procedure, open billing for what falls outside it. The important thing is that the choice is deliberate and visible, not an accident of which clerk raised the bill. - Use packages for high-volume, predictable episodes where a firm price serves everyone - Use open billing where clinical variation is real and a fixed price would misprice the case - Expect to combine them: a package core with itemised extras for what exceeds it - Make the tariff the common foundation, so both models price from the same rate card The common thread is the tariff. Both models ultimately reference the hospital's rate card - open billing charges each item at tariff, and a package is essentially a pre-agreed roll-up of tariff items at a negotiated total. When both are built on the same tariff, switching a case from package to open billing at the boundary is a controlled transition rather than a re-pricing exercise from scratch. ## Get the transition right and the rest follows Most billing disputes at discharge are not about the model. They are about the moment a case crossed from one model to the other and nobody told the patient. A package patient who quietly accrued three days of open charges because of a complication, and only discovers it at discharge, is an unhappy patient and a slow payment - even when every charge is legitimate. The fix is to make the boundary explicit and early. When a case exceeds its package - an extra day, an excluded procedure, a higher room category - that transition should be recognised when it happens, communicated to the patient, and reflected in the running estimate. The final bill then contains no surprises, because the patient watched it change in real time rather than meeting it at the counter. Package versus open billing is not a question of which is better. It is a question of matching the instrument to the case: fixed price where the work is predictable, itemised where it is not, and a clean, visible boundary between them when a single patient needs both. Build both on one tariff, define the package edges honestly, and handle the crossover in the open. Do that and the model serves the patient and the hospital instead of becoming the thing they fight about at discharge.

Read article
Pre-Auth and TPA Claims Without the Back-and-Forth — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 5 min read

Pre-Auth and TPA Claims Without the Back-and-Forth

The patient is admitted, the surgery is booked, and now begins the other procedure - the one between the hospital and the insurer. Pre-authorisation requests go out, queries come back, documents get re-sent, and somewhere in that exchange a discharge gets delayed or a bill gets stuck. Anyone who has worked a hospital's insurance desk knows the real enemy is not rejection. It is the back-and-forth: the endless round trips of missing information, mismatched figures, and requests for one more document. Cut the round trips and you have solved most of the problem. ## What pre-auth is really asking for A TPA - Third Party Administrator - sits between the hospital and the insurer, processing cashless claims on the insurer's behalf. Before a planned admission or procedure, the hospital submits a pre-authorisation request: who the patient is, what is wrong with them, what treatment is planned, and what it is expected to cost. The TPA reviews it and, if satisfied, approves a sum for the cashless treatment. Every query in that process is really the TPA saying one of a few things. - We cannot match this patient to a valid policy - The clinical justification does not support the treatment claimed - The estimated cost does not line up with the tariff we expect - A document we need is missing or unreadable Each of those is preventable at source. The back-and-forth is not an inherent feature of insurance; it is the accumulated cost of sending incomplete or inconsistent requests and then answering questions one at a time. ## Get the request right the first time The single biggest lever is a first submission that is complete and internally consistent. A pre-auth that arrives with the correct policy details, a clear diagnosis, the planned procedure, and a cost estimate built from the actual tariff gives the TPA nothing to query. The round trips do not get faster; they stop happening. That means assembling the request from data the hospital already holds rather than re-typing it onto a form. The patient's demographics, the treating consultant, the diagnosis and planned procedure, and the estimate all exist in the system already. Pulling them together, rather than re-keying them, removes the transcription errors that trigger half the queries. > Most pre-auth queries are not clinical disagreements. They are the TPA asking you to confirm something you could have stated clearly the first time. Kōami assembles the pre-auth request from the patient's existing clinical and billing record and builds the cost estimate from the applicable tariff, so the figure the TPA sees is grounded in the hospital's own rate card rather than a guess that invites a query. ## The approximate bill is a negotiation, not a formality The cost estimate - the approximate bill - is where a lot of the friction concentrates. Submit a number that is too low and you will be topping up authorisation mid-stay, one enhancement request at a time. Submit one that is disconnected from your tariff and the TPA queries it. Build it properly and it holds. An approximate bill worth submitting is itemised against the tariff that will actually be charged: room category, procedure, likely consumables, investigations. When it is derived from the same tariff that will generate the final bill, the estimate and the eventual claim are consistent by construction, which is exactly what keeps the final settlement clean. - Build the estimate from the tariff that will produce the final bill, not a separate guess - Itemise it so the TPA can see what each component covers - Account for the room category and package terms up front, since these drive approval limits - Raise enhancement requests early when the clinical picture changes, not at discharge When the approximate bill is anchored to the real tariff, the gap between what was authorised and what is finally claimed shrinks, and the shrinking of that gap is where disputed deductions live. ## Track the claim like the live thing it is A pre-auth is not fire-and-forget. It has a state - submitted, queried, approved, enhanced, and eventually the claim itself - and that state changes while a patient occupies a bed. The hospital that loses money is usually the one that lost track of where each request stood: a query that sat unanswered for two days, an approval that came in but never got attached to the file, a discharge cleared before final authorisation landed. ## Keeping every claim in view until it settles Visibility is the fix. Every pre-auth and every claim should have a clear current status and a clear owner, so nothing sits in a silent queue. When a query comes back, the person who can answer it should know immediately, and the answer should go out with the supporting document attached rather than promised. - Show the live status of every pre-auth and claim in one place, not scattered across inboxes - Flag queries the moment they arrive so response time is measured in hours, not days - Keep the clinical documents linked to the request, ready to send without a hunt - Reconcile the approved amount against the final bill before discharge, not after Kōami keeps each pre-auth and claim as a tracked item with a visible status against the patient's stay, so the insurance desk works from a live picture rather than reconstructing where things stand from a pile of emails. The insurance process will never be frictionless; there is a genuine reviewer on the other side doing a real job. But most of the pain is self-inflicted, manufactured by incomplete first submissions and lost track of afterwards. Send a complete, tariff-grounded request, anchor the approximate bill to the real rate card, and keep every claim visible until it settles. Do that and the back-and-forth mostly disappears, which means the discharge happens on time and the money arrives without a fight.

Read article
Ward Indents That Reconcile Themselves — Pharmacy | KōamiPharmacy
Pharmacy· 5 min read

Ward Indents That Reconcile Themselves

The ward runs out of something at 3 in the morning. The nurse raises an indent to pharmacy. Stock moves up, gets used, and somewhere in the handover the paperwork and the reality quietly part ways. By month end the ward's consumption on paper does not match what actually went into patients, the pharmacy's issue records do not match what the ward thinks it received, and someone spends a day reconciling two versions of the same truth. The ward indent is one of the most repeated transactions in a hospital, and it is where stock accuracy most often goes to die. ## What a ward indent is actually doing An indent is a request from a ward or department to the central pharmacy or store for stock to replenish its own working supply. It is an internal transfer, not a sale and not a dispense against a prescription. The ward holds a small stock of common items - fluids, analgesics, dressings, emergency drugs - and tops it up as it gets used. That sounds simple, and the single indent is. The problem is the chain of events each indent sets off, and how many places it can break. - The ward requests a quantity of each item - The pharmacy reviews, may adjust, and issues stock against the request - Stock physically moves and the ward's on-hand should increase - Consumption at the ward should eventually draw that stock back down Every one of those steps is a chance for the paper trail and the physical stock to disagree. Request more than issued. Issued more than received. Received but never booked into ward stock. Consumed but never recorded. Each gap is small; together they are why ward-level stock figures are so often fiction. ## Make issue and receipt two ends of one transaction The classic failure is treating the pharmacy's issue and the ward's receipt as separate records that happen to be about the same event. Pharmacy writes down what it sent. The ward, maybe, writes down what it got. Nothing forces the two to be the same number, so they drift. The fix is structural: the indent is one transaction with two ends, not two transactions that need reconciling. When pharmacy issues against an indent, that issue is the same record the ward receives against. The quantity issued and the quantity received are the same field, moving stock out of one location and into another in a single booked movement. There is nothing to reconcile because there was only ever one number. > Two records of the same transfer will disagree. One record with two ends cannot. Kōami models the ward indent as a single stock movement between locations, so an issue from pharmacy is a receipt at the ward by construction, and the two can never quietly diverge. ## Reconcile by design, not by effort "Reconcile themselves" is not a slogan; it is a description of what happens when the data is modelled correctly. Reconciliation is the labour of making two records agree. If there is one record, the labour disappears. The month-end exercise stops being detective work and becomes a report you read. That holds only if a few things are true throughout. Stock has to move at the moment of the transaction, not be reconstructed later. The item, quantity, and batch have to be captured once and carried through, not re-entered at each step. And the ward's on-hand has to be a live consequence of issues in and consumption out, not a periodically guessed figure. - Book the movement when it happens, so records never trail reality - Carry item, quantity, and batch through the whole indent without re-keying - Drive ward on-hand from actual issues and actual consumption, continuously - Track batch and expiry across the transfer, so FEFO survives the move to the ward When those hold, the ward's stock position is always current and always ties to pharmacy's issue records, because they are the same underlying data seen from two locations. ## Close the loop with consumption An indent that only tracks stock in is half a system. The other half is consumption - what the ward actually used. Without it, ward stock looks permanently overstated, because everything issued appears to still be sitting there. Linking administration and consumption back to ward stock is what makes the on-hand figure mean something. When consumption draws down ward stock as it happens, replenishment becomes rational. The indent quantity can be driven by real usage rather than a nurse's guess and a fear of running short at 3 in the morning. Over-indenting - the habit that fills ward cupboards with slow-moving stock that then expires - fades, because the system can see what the ward genuinely turns over. ## What ward indents that reconcile themselves buy you - Ward on-hand reflects issues in minus consumption out, kept current - Replenishment quantities are informed by real turnover, not habit - Expiry risk at the ward is visible, because batch and expiry followed the stock - Month-end becomes a report, not a reconciliation project The ward indent will never be interesting. It is plumbing. But it is plumbing that runs constantly and leaks quietly, and the cumulative cost of those leaks - inaccurate stock, wasted reconciliation time, expired ward cupboards - is large precisely because the transaction is so ordinary. Model it as a single movement with two ends, drive on-hand from real issues and real consumption, and the indent stops needing to be reconciled at all. It reconciles itself, which is the only version of this that survives contact with a busy ward.

Read article
Keeping the NDPS Register Audit-Ready — Pharmacy | KōamiPharmacy
Pharmacy· 5 min read

Keeping the NDPS Register Audit-Ready

There is a particular kind of quiet in a hospital pharmacy when the drug inspector is due and someone remembers the narcotics register has not been reconciled in a fortnight. Controlled substances carry a weight that ordinary stock does not. The rules under the NDPS framework are strict, the penalties are personal, and the register is the document that stands between a compliant pharmacy and a very bad afternoon. Keeping it audit-ready is not a periodic scramble. It is a discipline that either lives in your daily workflow or does not exist at all. ## Why the narcotics register is different Ordinary stock tolerates a bit of slack. A few units of paracetamol unaccounted for is a variance to investigate, not a legal problem. Narcotic and psychotropic substances - the scheduled drugs governed by NDPS - tolerate nothing. Every unit received, dispensed, administered, wasted, or returned has to be accounted for, in sequence, with a running balance that always ties out. The register is a continuous ledger, not a snapshot. It records each transaction against a drug, with the quantity, the date, the source or destination, the person responsible, and the balance remaining after the movement. The defining property is that the balance is never allowed to drift. Physical count and register balance must agree, every time, for every scheduled drug. - Every movement recorded, in order, with no gaps in the sequence - A running balance that reconciles to physical stock on demand - The responsible person named for each transaction - Nothing edited away silently after the fact ## Capture the entry where the movement happens The register fails when it is maintained separately from the actual work - a paper book updated at the end of the shift from memory and scraps of paper. Every gap between the movement and the record is a chance for the two to diverge, and divergence in a narcotics register is exactly what an inspection is looking for. The fix is to make the register entry a byproduct of the transaction itself. When a scheduled drug is received, dispensed to a ward, administered to a patient, or wasted, the register entry is created at that moment, from that action, with the balance recalculated automatically. No parallel book, no end-of-day reconstruction, no arithmetic done by hand under time pressure. > A narcotics balance you calculate by hand at closing is a balance you will eventually get wrong. Kōami records controlled-substance movements as they happen and maintains the running balance continuously, so the register is a live reflection of stock rather than a document someone has to rebuild before an audit. ## Two-person control and the trail it leaves Controlled drugs conventionally demand more than one set of hands. Witnessed administration, witnessed wastage, dual-signature receipts - the point is that no single person can move a scheduled substance without a second person attesting to it. This is as much protection for the staff as it is control over the stock; a clean witnessed trail is what clears a nurse or pharmacist when a count comes up short somewhere else. The register should carry that structure, not sit beside it. Where a movement requires a witness, the record should capture both people. Where wastage occurs - a partial ampoule, a discontinued dose - it should be recorded as its own witnessed event, not quietly absorbed into a balance. - Capture both the responsible person and the witness on movements that require it - Record wastage as an explicit, witnessed transaction with a reason - Keep amendments as visible corrections with their own trail, never as overwrites - Tie each entry to the specific batch it moved, so recalls and discrepancies trace cleanly The test of a good register is not that it never contains a correction. Corrections happen. The test is that every correction is visible, attributed, and explained, so an auditor reads a story rather than finding a hole. ## Ready on demand, not after a scramble Audit-ready is a state, not an event. A register that is genuinely continuous is ready at any moment, because there is no backlog to clear and no reconciliation to perform before someone can look at it. That is the whole objective: to remove the pre-inspection panic by making the register correct all the time instead of correct just before it is examined. That readiness rests on a few plain properties. The balance ties to physical stock now, not after an afternoon of catch-up. The sequence is unbroken. Every entry names its person. Every discrepancy that ever arose has a recorded investigation and resolution attached, so there are no unexplained gaps waiting to be discovered. When the register can be produced and reconciled on request, an inspection becomes a review of good records rather than a test of how fast you can assemble them. - A balance that reconciles to physical count without preparation - An unbroken transaction sequence with no missing entries - Every discrepancy logged, investigated, and closed on the record - The whole ledger retrievable on demand, for any drug and any period Controlled substances are the part of pharmacy where process discipline and legal exposure sit closest together. The register is where that discipline is proven. Build it into the daily flow of receiving, dispensing, administering, and wasting - captured at the moment of movement, witnessed where it must be, corrected in the open - and audit-readiness stops being a thing you prepare for. It becomes the ordinary condition of the register, which is exactly where you want it.

Read article
FEFO: Stop Letting Drugs Expire on the Shelf — Pharmacy | KōamiPharmacy
Pharmacy· 5 min read

FEFO: Stop Letting Drugs Expire on the Shelf

Walk into most hospital pharmacy stores and you will eventually find it: a strip of something in a back row, three months past expiry, still on the shelf because nobody picked it up in time. It is not theft and it is not fraud. It is just stock that sat while newer stock in front of it got dispensed first. Expiry losses are quiet, they are constant, and they are almost entirely a process problem. FEFO - First Expiry, First Out - is the process that fixes it, if the software actually enforces it. ## FEFO is not FIFO, and the difference is money FIFO - First In, First Out - moves the oldest received stock first. That is fine for a warehouse of tinned food. It is wrong for medicines, because the date that matters is not when you received a batch but when it expires. A batch received later can easily expire sooner, depending on how much shelf life the supplier shipped you. FEFO orders dispensing by expiry date, not receipt date. The batch that expires soonest goes out first, regardless of when it arrived. In a pharmacy carrying dozens of batches of the same molecule, all with different expiry dates, this is the only rule that consistently drains stock before it dies on the shelf. - FIFO asks: which batch did we receive first? - FEFO asks: which batch expires first? - For drugs, only the second question protects against write-offs ## Batch and expiry have to be real data, not a label FEFO is impossible if the system does not know the expiry date of the exact stock in hand. That means every unit has to be tracked at batch level, with its expiry captured the moment it enters the building. The Goods Receipt Note (GRN) is where this discipline starts. When stock is received against a purchase order, each batch number and its expiry date get recorded as the stock is booked in - not estimated, not left blank, captured off the pack. > If the expiry date was not captured at GRN, FEFO has nothing to sort by. Once batch and expiry live in the record, everything downstream can reason about them. Kōami tracks stock at batch and expiry level from GRN onward, so every dispensing decision and every stock count knows exactly which batch it is touching and exactly when that batch runs out. ## Let the system pick the batch The moment of truth is dispensing. A pharmacist filling an order should not have to scan the shelf, compare expiry dates in their head, and consciously choose the soonest-expiring batch. That is cognitive load that fails under pressure, and pressure is the default state of a hospital pharmacy. Instead, the system should suggest the FEFO batch automatically. When an item is dispensed, the software already knows which available batch expires first and proposes it. The pharmacist confirms rather than calculates. Override is still possible - a damaged strip, a batch on hold, a specific clinical reason - but the default action is the correct one. - Suggest the soonest-expiring available batch at the point of dispensing - Skip batches that are quarantined, recalled, or on hold - Allow a deliberate override with a reason, rather than silent free choice - Decrement the exact batch that was actually handed over, so stock stays accurate This is where FEFO stops being a poster on the store-room wall and becomes what actually happens, thousands of times a day, without anyone having to remember the rule. ## See expiry before it becomes a loss FEFO reduces expiry losses; it does not eliminate them. Some stock will approach expiry faster than it can be used - slow-moving items, over-ordered lines, a drug whose protocol changed. The answer is visibility early enough to act while the stock still has value. A near-expiry view that surfaces batches expiring in the next thirty, sixty, or ninety days turns a write-off into a decision. Stock coming up on expiry can be transferred to a higher-turnover location, returned to the supplier where terms allow, or simply flagged so ordering pauses until it clears. The earlier the warning, the more options remain. - Flag batches entering their final ninety days while there is still time to move them - Highlight slow movers whose on-hand quantity will outlast their expiry - Block, or at least warn on, dispensing of already-expired stock so it cannot slip out - Feed expiry risk back into purchasing so you stop reordering what you are about to bin Kōami surfaces near-expiry batches ahead of time and keeps expired stock out of the dispensing flow, so the pharmacist sees the problem while it is still solvable rather than discovering it at the annual stock audit. There is a cultural shift that comes with this too. When expiry is visible early and the FEFO batch is chosen for you, the pharmacy stops treating write-offs as an unavoidable cost of doing business and starts treating them as a signal that something upstream needs attention - usually over-ordering or a protocol that quietly changed. A near-expiry list that keeps surfacing the same slow-moving molecule is telling you to buy less of it, not to keep binning it. Used that way, expiry data stops being a record of losses already taken and becomes a tool for preventing the next ones. Expiry losses feel inevitable because they are diffuse - a few strips here, a bottle there, spread across hundreds of lines and never large enough on any single day to trigger action. Add them up across a year and they are a real number on the budget. FEFO, enforced by software that knows every batch and every date, turns that slow leak off. Capture expiry at GRN, let the system pick the batch, and watch the near-expiry list so nothing sneaks up on you. The drugs get used before they expire, which is the entire reason you bought them.

Read article
Closing the Loop on Critical Results — Radiology | KōamiRadiology
Radiology· 5 min read

Closing the Loop on Critical Results

A radiologist spots a large pulmonary embolism at 2 in the afternoon. The report is dictated, signed, and sitting in the system within twenty minutes. Good. Now the only question that matters: did the person who can act on it actually find out, and can you prove when? Critical results are not a reporting problem. They are a communication problem wearing a reporting costume, and the gap between "the report exists" and "the right clinician acknowledged it" is where patients get hurt. ## The report is not the message Signing a report puts a finding into the record. It does not put it in front of a human. The referring clinician might be in theatre, off shift, or simply not looking at that patient's chart in the next hour. For a routine finding, that latency is fine. For a critical one - a tension pneumothorax, an acute bleed, a misplaced line, a new mass with impending airway compromise - an hour of silence is a clinical event in its own right. This is why critical results need a channel of their own, separate from the ordinary flow of signed reports. The finding has to be pushed, not waited for, and the push has to land on a specific responsible person, not a shared inbox that everyone assumes someone else is watching. - A named recipient, not a role or a distribution list nobody owns - A defined severity, so a critical finding is visibly different from an urgent-but-not-emergent one - A time expectation attached to that severity - minutes for the emergent, hours for the urgent - A fallback path for when the first recipient does not respond ## Acknowledgment is the whole point A critical result that has been sent but not acknowledged is not closed. It is in flight. The loop closes only when the responsible clinician confirms they have seen it and understood what it means. That confirmation - the critical results acknowledgment - is the single most important artifact in the whole workflow, because it is the moment responsibility for the finding transfers from radiology to the treating team. > A finding you communicated but cannot prove you communicated is, in an incident review, a finding you did not communicate. Acknowledgment has to be an explicit, recorded action. Not "the report was available." Not "the phone rang." A person, a timestamp, and a confirmation that this specific finding was received. Kōami records the acknowledgment as a discrete event tied to the study, the finding, and the clinician who cleared it, so the loop has a defined and auditable close. ## Escalation is what makes it safe People miss messages. That is not a failure to design around by hoping harder; it is a certainty to build for. The strength of a critical results workflow is entirely in what happens when the first attempt does not land. An unacknowledged critical result must escalate on a clock. If the primary clinician has not acknowledged within the window their severity demands, the alert moves - to a covering colleague, to the on-call, to a supervisor, up a defined ladder until someone takes it. Silence can never be the resting state. The system should treat an unacknowledged emergent finding as an active problem that keeps demanding attention until a human resolves it. - Start a timer the moment the result is raised, scaled to its severity - Escalate automatically when the timer expires without acknowledgment - Follow a documented chain so the next recipient is never ambiguous - Keep escalating rather than giving up, because an unread emergent finding is not a state you can safely leave alone The reassuring version of this is boring by design: most critical results get acknowledged quickly and never escalate at all. The escalation ladder exists for the few that would otherwise fall through, which are precisely the ones that end up in a coroner's report. ## The trail you will be glad you kept Every critical result carries a second life as evidence. When something goes wrong and the case is reviewed, the questions are always the same. When was the finding made? When was it communicated? To whom? When did they acknowledge it? What happened in between? A workflow that captures each of those as it happens turns a frightening reconstruction into a simple read of the record. Kōami keeps the full timeline as a byproduct of doing the work: finding raised, notification sent, escalations fired, acknowledgment recorded, each with its actor and its timestamp. Nobody has to assemble it after the fact, because it was never scattered in the first place. The same data that keeps a live result from being forgotten is the data that answers the review board six months later. It is worth being honest about what should count as a critical result in the first place, because a workflow that fires on too much is a workflow people learn to ignore. If every mildly abnormal finding triggers the same urgent channel, the genuinely emergent ones drown in the noise, and acknowledgment becomes a reflex click rather than a considered one. The severity tiers exist precisely so that the emergent finding looks and behaves differently from the merely notable one. A department that defines its critical findings carefully, and reserves the escalating channel for them, keeps that channel meaningful. Alert fatigue is not a side issue here; it is the failure mode that quietly undoes the whole system. Closing the loop on critical results is unglamorous work. It is timers, recipients, and confirmation clicks, not clever imaging. But it is the part of radiology where the discipline of the process is directly the safety of the patient. Make the message its own channel, make acknowledgment explicit, make silence escalate, and keep the trail without anyone having to think about it. Do that, and the finding you caught in twenty minutes actually reaches the person who can act on it - which was the entire point of catching it.

Read article
Window/Level Presets That Match How You Read — Imaging | KōamiImaging
Imaging· 5 min read

Window/Level Presets That Match How You Read

Ask two radiologists to read the same chest CT and watch their hands. One drops to a lung window almost before the images finish loading. The other sits in soft tissue, scrolls, then flicks to bone when something on the ribs catches their eye. The pixels are identical. What differs is the window - the slice of the greyscale each reader chooses to see. Window/level is not a cosmetic setting. It is how you decide what to look at, and presets are how you stop deciding it manually forty times a day. ## What window and level really mean A CT stores far more shades of grey than a monitor can show or an eye can resolve. Each voxel carries a Hounsfield Unit (HU) value, running from around -1000 for air to +1000 and beyond for dense bone, with water sitting at zero. Your display can show maybe 256 shades. Window/level is the mapping between those two worlds. - Window width (WW) is the range of HU values spread across the available greys. A narrow window means high contrast over a small HU band; a wide window means lower contrast over a broad band. - Window level (WL), sometimes called window centre, is the HU value sitting in the middle of that range. A lung window might be WW 1500, WL -600, stretching contrast across the air-filled parenchyma. A soft-tissue window sits nearer WW 400, WL 40, where liver, spleen, and nodes separate cleanly. Bone runs wide, around WW 2000, WL 400. Same scan, three completely different images, because you moved the window. ## Presets are muscle memory, made explicit Experienced readers carry these numbers in their fingers. The value of a preset is that it takes that memory out of the individual's hands and makes it a shared, one-key action. Press a key, land on the exact WW/WL for the tissue you want, every time, on every study. The difference at volume is real. A body radiologist reading a busy list is switching windows constantly - lung, mediastinum, bone, sometimes a narrow window to chase a subtle bleed. Manual mouse-drag windowing on each switch is a small tax paid hundreds of times a shift. Presets collapse it to a keystroke. > The best window preset is the one your hand reaches for without your brain getting involved. Kōami ships sensible defaults for the common tissue windows and, more importantly, lets a reader save their own. Because the preset you actually use is rarely the textbook number - it is the number you nudged to two years ago and never changed. ## Match the preset to the read, not the textbook Standard windows are a starting point, not a rule. How you read shapes what your presets should be. - Stroke work wants a narrow window - something like WW 30 to 40 at WL 35 - to tease out the loss of grey-white differentiation that a routine brain window hides. - Liver lesion hunting benefits from a tighter window than a general abdomen preset, so low-contrast lesions stop blending into background parenchyma. - CT angiography reads want a window set for opacified vessels, not for the soft tissue around them. - Temporal bone and other fine osseous work wants a very wide, sharp window that a general bone preset will not match. The point is that a preset library should reflect the reading a department actually does. A stroke centre and a cancer centre reading the same anatomy still want different one-key windows because they are hunting for different things. ## Presets that follow the study, and the reader The frustrating part of most systems is that presets are dumb about context. You open a non-contrast head and the viewer starts you in a bone window; you open a chest and it starts in soft tissue when you wanted lung. Every mismatch is a manual correction. The fix is presets that key off the study. A modality and body-part combination should open at the window that read most wants, with the alternates one key away. Better still, the system should remember that this particular reader always flips a head CT to a narrow stroke window, and honour it, without overwriting the neighbour who reads it differently. - Bind presets to study type so the first image is already close to right - Keep the full ladder - lung, soft tissue, bone, brain - on adjacent keys for fast switching - Let individual readers save personal presets that travel with them across workstations - Preserve the raw HU data untouched, so windowing is always a display choice and never a permanent edit That last point is the one that gets forgotten. Windowing changes what you see, never what is stored. The full dynamic range is always there in the pixels, and any preset is just a lens you hold up to it. Kōami keeps the underlying data intact and treats every window as a view, so you can flick between them freely and measure HU values that mean exactly what they should. One more practical note: presets are worth revisiting, not setting once and forgetting. The mix of studies a department reads shifts over time, new protocols arrive, and a reader's own eye changes as they gain experience. A window that felt right two years ago may be a keystroke you now fight against. Treating the preset library as something you tune, rather than a fixed inheritance, keeps it matched to the reading actually being done rather than the reading someone did when the system was first configured. Window/level is one of the few tools in imaging that is both completely standard and deeply personal. The physics is fixed; the way you use it is yours. Good presets respect both - solid defaults grounded in the HU scale, and the freedom to bend them to the way you actually read.

Read article
From Dictation to Structured Reports — Radiology | KōamiRadiology
Radiology· 5 min read

From Dictation to Structured Reports

Every radiologist has a dictation style. Some read head to toe, some lead with the finding that matters and bury the rest, some circle back three times to the same lung nodule. Free-text dictation lets all of that happen, which is exactly the problem. The referring clinician on the other end does not want your narrative arc. They want to know whether the mass is there, how big it is, and what to do next. Structured reporting is the shift from telling a story to filling in a form that already knows what the reading physician needs. ## What structured reporting actually changes The honest version: structured reporting swaps a blank text box for a template with named fields. Instead of dictating a paragraph, you populate discrete elements - technique, comparison, findings by organ system, impression - each of which lives in its own slot. The output still reads like prose to the clinician, but underneath it is data. That distinction matters more than it sounds. When a lesion size lives in a labelled field rather than mid-sentence, it can be tracked across studies, pulled into a tumour board list, or flagged when it crosses a threshold. When a free-text line says "stable 8 mm nodule, previously 6 mm" the software sees a sentence. When a structured field says diameter equals 8, the software sees a number it can compare. - Fewer missing elements, because the template asks for laterality, size, and comparison every time - Consistent language across a department, so "probably benign" means the same thing from every reader - Findings that map cleanly to standardised systems like BI-RADS, LI-RADS, or Lung-RADS - Report data that can flow downstream instead of being re-keyed by hand ## DICOM SR and why the plumbing matters Underneath the readable report sits a machine-readable one. DICOM SR (Structured Reporting) is the standard that lets a report carry coded content - measurements, findings, and their relationships - as structured objects rather than a flat blob of text. A CT measurement made on the workstation can travel as an SR object and land in the report already populated, with the units and the anatomical site attached. RadReport-style templates give you the clinical scaffolding: a library of report layouts, organ by organ and study by study, that a department can adopt and adapt. Pair that library with SR as the transport, and the measurement you drew on the axial slice does not need to be dictated at all. It is captured where it was made and carried into the field where it belongs. > A number you typed twice is a number you will eventually type wrong. Kōami treats the report as structured data from the first click, so a diameter measured on the image and the diameter printed in the impression are the same value, not two copies that drift apart. ## Where speed comes from, and where it goes Radiologists resist structured reporting for one honest reason: naively done, it is slower. Clicking through twelve fields to say "unremarkable chest" is a worse experience than dictating one sentence. If a template forces the same clicks for a normal study and a complex oncology follow-up, it has failed. The fix is normal defaults and smart branching. A well-built template loads a fully normal report on open, so a clean study is a quick read and sign. You only touch the fields that deviate. Positive findings expand the relevant section; negative ones stay collapsed and pre-populated. The reader spends keystrokes where the pathology is, not where it is not. - Start every study from a normal baseline, not a blank page - Expand detail only for the organ systems with findings - Let voice still drive the workflow for readers who prefer to talk, mapping speech into the structured fields - Keep an escape hatch: a free-text zone for the genuinely unusual case that no template anticipated Done this way, the routine study gets faster and the complex study gets more complete. That is the trade you want. ## The impression is still yours Structure is for the findings. It should never flatten the impression. The impression is where a radiologist earns their keep - synthesis, judgement, the recommendation that ties three findings into one actionable sentence. A good structured system leaves that section as expressive as you need it while still letting you tag the critical result, the follow-up interval, or the recommended next study as discrete, trackable items. The goal is not to turn radiologists into data-entry clerks. It is to stop asking them to be the transport layer for information that software could carry perfectly well on its own. When the measurement, the laterality, and the follow-up date are all structured, the report becomes something the rest of the hospital can act on without a human re-reading and re-typing it. There is a quieter benefit that shows up over months rather than minutes. A department reporting into consistent structured fields accumulates data it can actually look at: how many studies carried a given finding, how often a recommendation was for a specific follow-up, where reporting language drifts between readers. None of that is available when every report is a unique paragraph. Structure is what turns a pile of reports into something a department can learn from without a research project. Structured reporting is not about constraining how you think. It is about capturing what you concluded in a form that survives the trip to the next clinician intact. Get the templates right, keep the impression free, and let the plumbing carry the numbers. The reading gets no harder, and everything downstream gets a great deal easier.

Read article
Streaming Slices Instead of Downloading Studies — Imaging | KōamiImaging
Imaging· 5 min read

Streaming Slices Instead of Downloading Studies

There is a moment familiar to anyone who has waited on medical imaging: the study has been ordered, the images exist, and now everyone stands around while a viewer downloads a study that is hundreds of megabytes, sometimes more, before showing a single slice. The clinician wants one image. The system insists on delivering all of them first. That gap - between what the reader needs to see and what the old model forces them to fetch - is exactly what streaming imaging closes. Instead of downloading a study, you stream its slices, and the difference in experience is the difference between waiting and working. ## Why the Download Model Fails at Scale The download-then-view approach made sense when studies were small and networks were local. A plain radiograph is a modest file; fetching it whole costs nothing anyone notices. But imaging did not stay small. A modern CT or MRI produces hundreds or thousands of slices, and a study can run to a gigabyte. The download model scales badly against that reality in every direction that matters. - Time to first image grows with the size of the whole study, so the reader waits longest exactly when the study is largest and the stakes are often highest. - Bandwidth is spent moving data that may never be looked at, because a reader who needs to check one region does not need every slice at full fidelity. - The client has to hold the entire study in memory, which pushes the hardware requirement up and the portability down. The fundamental error is coupling the unit of transfer to the unit of storage. A study is how the images are stored. It is not how they are read. Kōami's imaging back end breaks that coupling deliberately, treating the study as something you draw from rather than something you must first swallow whole. ## What WADO-RS Actually Streams The mechanism is DICOMweb, the family of web-native standards for medical imaging, and specifically WADO-RS - Web Access to DICOM Objects, the RESTful retrieval part. Where the old WADO fetched whole objects, WADO-RS lets a viewer request imaging at the granularity it needs: a study, a series, a single instance, or the frames within a multi-frame instance, addressed by ordinary web requests. - The viewer can ask for one series, or one image, without pulling the rest of the study along with it. - Frame-level retrieval means a viewer can pull individual slices as the reader scrolls into them, rather than the whole stack up front. - Because it is REST over HTTP, it flows through the same web infrastructure everything else uses - caches, load balancers, ordinary firewalls - with no special protocol tunnel to maintain. > The insight of DICOMweb is small and powerful: address medical images the way the web addresses everything else, and imaging stops needing its own private plumbing. Kōami's viewer speaks WADO-RS to its back end so that the pictures arrive as the reader moves through them, at the resolution the moment calls for. ## Progressive Loading Is the Experience the Reader Feels Streaming is not only about fetching less; it is about ordering the fetch intelligently so the reader is productive within seconds. The techniques stack together, and their combined effect is a viewer that feels immediate even against a large study on an ordinary connection. - First image first: the viewer prioritises the slices the reader is looking at now, so an image appears in seconds while the rest of the series loads behind it. - Progressive resolution: a lower-resolution version can render immediately and sharpen as the full-fidelity data arrives, so there is always something on screen to orient by. - Predictive pre-fetch: as the reader scrolls in one direction, the viewer fetches ahead of them, so the next slices are already waiting by the time the reader reaches them. - Server-side heavy lifting: reconstruction and decompression can be handled by the back end where the client is modest, so a laptop is not asked to do a workstation's job. Kōami combines these so that opening a large study feels less like a download and more like turning to a page in a book that is already open. The reader never experiences the study's total size; they experience only the slices in front of them. ## What Streaming Gives You Beyond Speed The obvious win is that studies open faster, and that alone justifies the approach. But the architecture pays dividends past raw speed, in ways that shape how a whole imaging service can operate. - Reading over ordinary networks becomes practical, so a radiologist on a home connection or a clinician on hospital wifi is not gated by the need to pull gigabytes. - The central archive stays the single source of truth, because the viewer streams from it rather than making local copies scattered across devices that then have to be reconciled. - Modest client hardware suffices, which is what makes browser-based, install-free reading genuinely viable rather than technically possible but painfully slow. Streaming, in other words, is the enabling layer beneath portable, browser-first imaging. Kōami builds on it so that the lightness of the reading experience is backed by an architecture that keeps the data governed, current, and central. Streaming slices instead of downloading studies is one of those changes that sounds like a technical detail and turns out to reshape the daily experience of everyone who touches imaging. The reader stops waiting for data they will not look at. The network stops straining under transfers it does not need to carry. The archive stays authoritative while the images travel to wherever the reader happens to be. WADO-RS and DICOMweb are not exotic; they are imaging finally adopting the ordinary logic of the web. And the result the clinician feels is simply this: they open a study and the picture is there, which is all they ever wanted the system to do.

Read article
Why the Browser Is Enough for Reading Studies — Radiology | KōamiRadiology
Radiology· 5 min read

Why the Browser Is Enough for Reading Studies

For most of the history of medical imaging, reading a study meant sitting at a specific machine. The radiology workstation was a heavy box under a desk, loaded with proprietary software, tied to a licence, and physically located in the reading room. If you wanted to read a study, you went to the workstation. The idea that a radiologist might open a full diagnostic study in an ordinary web browser, on whatever screen happened to be in front of them, would once have sounded like a compromise. It is not a compromise anymore. It is, for a great deal of clinical work, simply the better way, and it is worth being precise about why. ## What the Browser Can Now Actually Do The old objection was capability. A browser, the reasoning went, cannot handle the pixel density, the window-level manipulation, the measurement tools, the multi-planar reconstruction that real reading demands. That objection has quietly expired. Modern browsers expose the graphics and compute primitives that image rendering needs, and open toolkits like Cornerstone have been built specifically to drive diagnostic-grade viewing inside them. A browser-based viewer today handles the operations a reading actually requires: - Window and level adjustment in real time, so a chest study can be swung from lung window to mediastinal window without a round trip to a server. - Measurement, annotation, and comparison, including linked scrolling between a current study and a prior for the same patient. - Multi-planar reconstruction and stack scrolling through hundreds of slices, driven by the client where the hardware allows. Kōami's PACS viewer is built on this foundation, using the browser as a genuine imaging surface rather than a thin window onto a screen-scraped session somewhere else. > The question stopped being whether a browser can render a study to diagnostic standard. It can. The question is why you would still tether a radiologist to one particular desk. ## Zero Install Changes Who Can Read, and Where The deepest advantage of a browser-first approach is not technical elegance. It is that it removes the workstation as a chokepoint. When reading requires no installation, no licence transfer, and no specific hardware, the pool of people who can read a study and the places they can read it from both expand dramatically. - A radiologist can open a study from home for an after-hours call without driving to the hospital, because the reading environment is a URL and a login, not a building. - A referring clinician on the ward can pull up the images alongside the report, so the conversation about a patient happens with the actual pictures in front of both people. - A second opinion from a specialist elsewhere becomes a link, not a burned disc couriered across a city. This is the quiet revolution. The technology of browser-based viewing is interesting; the consequence - that expertise is no longer trapped at a physical console - is what actually changes how a hospital or a network operates. Kōami is designed around this reach, treating the viewer as something you send to a person rather than a place you send a person to. ## The Server Does the Heavy Lifting A browser-first architecture does not mean a browser doing everything. The intelligence of the design is in the division of labour: the client renders and interacts, and the server handles the data, the storage, and the streaming so that the client is never asked to swallow a whole study at once. A modern imaging back end speaks DICOMweb, and its streaming member WADO-RS in particular, so that the viewer requests exactly the pixels it needs, when it needs them, rather than downloading a gigabyte before the first image appears. - The archive stays authoritative and central, so there is one source of truth for every study rather than copies scattered across workstations. - Pre-fetching and progressive loading mean the first image is on screen in seconds even for a large study, because the viewer streams rather than transfers. - Compute-heavy reconstruction can be done server-side where the client hardware is modest, so a reading on a laptop is not limited to what the laptop alone could render. Kōami pairs its browser viewer with a DICOMweb back end precisely so that the lightness of the client does not come at the cost of performance. The browser is enough on the front end because the server is doing the right work behind it. ## Being Honest About the Boundaries A responsible case for browser-first reading has to name its limits, because overselling it helps no one. The display still matters: a diagnostic read of fine detail depends on a calibrated, high-resolution monitor, and the browser does not change the physics of the screen it runs on. Colour and grayscale calibration remain the reading site's responsibility. And where AI assists the read - flagging a region, prioritising a worklist - it is decision-support that helps a clinician look in the right place, not an autonomous device that renders a diagnosis. The radiologist reads; the software assists. - A calibrated diagnostic display is still required for primary reading of subtle findings, regardless of the viewer's capability. - Any AI assistance in the viewer is there to support the clinician's judgement, not to replace it, and the reporting clinician remains responsible for the read. Kōami's viewer is built to serve that reality: powerful and portable, while leaving the diagnosis firmly with the person qualified to make it. The browser is enough to read studies not because someone lowered the standard, but because the tools rose to meet it. The rendering is genuine, the streaming keeps it fast, and the archive keeps it safe. What you gain in return is freedom from the physical workstation, and with it a reach that the old model could never offer - the radiologist at home, the clinician at the bedside, the specialist across the country, all looking at the same images through nothing more exotic than the browser already open in front of them. That is not a compromise. It is progress that happens to be convenient.

Read article
The Five Numbers a Center Head Checks First — Analytics | KōamiAnalytics
Analytics· 5 min read

The Five Numbers a Center Head Checks First

A center head running a hospital or a diagnostic chain has access to hundreds of metrics and time to look at perhaps five. The dashboards built for them usually get this exactly backwards, presenting fifty tiles of equal weight in the hope that the important ones are in there somewhere. They are, and they are drowned. The skill in management information is not collecting more numbers; it is knowing which handful a leader should check before their first cup of tea, and making those numbers honest, current, and impossible to misread. Here are the five that consistently earn their place. ## One: Today's Revenue Against the Run Rate The first number is money, but not as a raw figure. A revenue total on its own tells you almost nothing, because you have no idea whether it is good until you compare it to something. What a center head actually needs is today's revenue against the pace required to hit the month's target, and against the same day last month and last year. - Revenue to date this month, against the target, so the leader knows if they are ahead or behind with enough of the month left to react. - The daily run rate, because a month that started strong and is fading looks fine on a cumulative chart and terrible on a daily one. - The mix - OPD, IPD, diagnostics, pharmacy - because a revenue number that is holding up on pharmacy while OPD collapses is a warning dressed as good news. Kōami presents revenue as pace-against-plan rather than a bare total, which is the difference between a number you glance at and a number you can act on. ## Two: Occupancy and Throughput The second number is utilisation, and which form it takes depends on the business. For an inpatient facility it is bed occupancy. For a diagnostic center it is throughput - studies per modality, tests per bench. The underlying question is the same: are the expensive assets being used, and where is the constraint. - Occupancy by ward or utilisation by modality, so an idle CT scanner or a full ICU is visible before anyone has to ask. - The trend, not just today's snapshot, because occupancy drifting down over two weeks is a commercial problem forming quietly. > A dashboard that shows today's occupancy but not last fortnight's trend tells a leader where they are and hides where they are going. Kōami ties utilisation to the trend so the center head sees direction, not just position. ## Three: The Cash Conversion Signal The third number is the one that separates a business that looks profitable from one that actually has cash: how fast billed revenue turns into collected money. A center can post strong revenue and still be starved of cash if claims are stuck in TPA queues and receivables are ageing. - Days in accounts receivable, trending, because a rising number here is cash quietly leaving the building. - The first-pass claim rate, since claims that bounce are revenue that has been earned but not collected, and every bounce lengthens the cash cycle. - The ageing bucket - what share of receivables is over ninety days - because old receivables are the ones most likely to become bad debt. Kōami surfaces the collection health alongside the revenue, so a leader never mistakes billing for banking. Revenue is a promise; collection is the fulfilment, and the gap between them is where businesses get into trouble. ## Four: The Quality Signal That Cannot Be Gamed Every leader needs one number that speaks for the patient, and it has to be one that resists being gamed by the people whose work it measures. Depending on the setting, that is average turnaround time for a lab, or average length of stay against expected for a hospital, or the wait time from registration to consultation for an OPD. - A service metric the patient actually feels - TAT, wait time, or length of stay - reported as a distribution rather than a flattering average. - Against a target, so the leader sees not just the value but whether it is acceptable, and whether it is drifting. The reason this belongs in the top five is that commercial numbers and quality numbers pull against each other, and a leader who watches only the money will optimise the business into a place patients quietly stop coming back to. Kōami keeps a patient-experience metric on the same board as the revenue, so the trade-off is visible and deliberate rather than accidental. ## Five: The Exception That Needs a Person The fifth item is not a metric at all; it is the exception list. The first four numbers tell a leader how the business is doing. The fifth tells them what needs a human decision today - the things that have crossed a threshold and are waiting for someone with authority. - Critical stockouts - the items that will run out within the lead time and threaten clinical care. - Escalations - the complaint, the denied high-value claim, the credit request that exceeds a manager's limit. - Anomalies - a revenue figure or a volume that has moved far enough from normal to warrant a look, flagged by the system rather than hunted for by the leader. Kōami surfaces these as an actionable exception queue, because the highest-value thing a leader can do in the morning is not admire a chart but resolve the two things that only they can resolve. The discipline of a good management dashboard is subtraction, not addition. Any competent system can show a center head five hundred numbers; the useful ones show five and make them trustworthy. Pace against plan, utilisation with its trend, the cash conversion signal, a quality metric that cannot be gamed, and the short list of exceptions that need a person. A leader who checks those five before the day begins knows where the business stands, where it is heading, and what only they can fix - and that is genuinely all the morning requires.

Read article
Raising First-Pass Claim Rates — Revenue Cycle | KōamiRevenue Cycle
Revenue Cycle· 5 min read

Raising First-Pass Claim Rates

There is a number buried in every hospital's revenue cycle that quietly determines how much of the money it earns it actually collects, and how much it spends chasing what it earned. It is the first-pass claim rate: the share of claims that get paid on the first submission, without a rejection, a query, or a resubmission. A hospital with a high first-pass rate has cash arriving predictably and a small back office. A hospital with a low one has a growing pile of rework, a lengthening collection cycle, and a finance team that spends its days re-doing work that should have been right the first time. ## Why Claims Fail, and Why It Is Rarely the Clinician When a claim comes back rejected, the instinct is to blame the payer. Sometimes that is fair. Far more often the rejection was earned, at the point of registration or coding or documentation, by an error that was entirely preventable. Understanding the taxonomy of failure is the whole game, because different failures need different fixes. - Eligibility failures - the patient's policy had lapsed, the treatment was not covered, the pre-authorisation was never obtained. These happen at the front desk, before any care is delivered. - Data failures - a mismatched name, a wrong policy number, a missing TPA reference. Trivial to prevent, expensive to chase, and responsible for a startling share of rejections. - Coding and documentation failures - a diagnosis that does not justify the procedure billed, a missing operative note, an unbundled charge. These originate in the clinical and coding workflow. The pattern to notice is that most first-pass failures are born long before the claim is submitted. By the time the claim file is being assembled, the error is already baked in. Kōami's revenue-cycle tooling pushes the checks upstream, to where the errors are actually created, rather than catching them at the end when it is too late to fix cheaply. > Every rupee of denied claim was already earned once. Collecting it a second time costs you a second time. ## Catch It at the Front Desk, Not the Back Office The cheapest denial to fix is the one that never happens, and the front desk is where you prevent most of them. A registration clerk who verifies eligibility while the patient is standing there can resolve a lapsed policy or a missing pre-authorisation in real time. The same problem discovered a month later, after discharge, becomes a phone call to a patient who has left, a query to a TPA, and a claim in limbo. - Verify eligibility at registration, so a coverage problem surfaces while it can still be discussed with the patient. - Validate the payer and TPA details against the scheme's rules at entry, so a wrong policy number is caught by the field, not by the rejection three weeks later. - Flag procedures that require pre-authorisation before they are performed, so the approval is obtained in advance rather than begged for in retrospect. Kōami runs these validations at the point of entry, turning the front desk into the first line of revenue-cycle defence. It is far cheaper to stop a bad claim from forming than to rescue it once formed. ## Scrub the Claim Before It Leaves Between the assembled claim and the payer's inbox there should sit a scrubbing layer - a set of rules that inspects every claim against known payer requirements and holds anything that would predictably be rejected. This is the difference between submitting claims and lobbing them hopefully at a payer. - Completeness checks, so a claim missing a mandatory field or document never gets submitted to be bounced. - Consistency checks, so the diagnosis, the procedure, and the charges tell one coherent story rather than three contradictory ones. - Payer-specific rules, because each TPA and scheme has its own quirks, and a rule engine remembers them all where a human reviewer cannot. The rules are not static. Every genuine rejection is a lesson, and a claim that failed for a reason the scrubber did not catch should teach the scrubber a new rule. A hospital that feeds its denials back into its scrubbing logic watches its first-pass rate climb quarter over quarter. Kōami is built to make that feedback loop explicit, so the rule set gets smarter from the hospital's own history. ## Work Denials as a System, Not a Chore No first-pass rate reaches a hundred percent, and pretending otherwise is how denials rot. Some claims will come back, and the discipline is to work them as a managed queue with ownership and analysis, not as a demoralising pile someone gets to when they can. - Categorise every denial by root cause, because the value of a denial is the lesson it carries about the failure that produced it. - Route denials to the function that owns the fix - eligibility issues to the front desk process, coding issues to the coders - so the same mistake stops recurring. - Track the denial rate by cause over time, so you can see whether the fixes are working and where the next biggest leak is. Kōami treats denials as data, surfacing the patterns so that a hospital fixes the process that generates a category of denials rather than endlessly reworking individual claims. Rework is a symptom; the process that caused it is the disease. Raising the first-pass rate is not a single project with an end date. It is a habit: catch errors where they are born, scrub every claim against what payers actually require, and treat every denial as a lesson rather than a nuisance. Each point of improvement is money that arrives sooner and a back office that shrinks instead of grows. In a sector where margins are thin and the work is hard, getting paid correctly the first time is one of the most humane efficiencies a hospital can build, because the alternative is spending clinical revenue on the administrative cost of collecting it.

Read article
Turnaround Time: The Metric That Runs a Lab — Analytics | KōamiAnalytics
Analytics· 5 min read

Turnaround Time: The Metric That Runs a Lab

Ask a lab director what single number they would keep if they could keep only one, and a surprising share will say turnaround time. Not accuracy, which they take as non-negotiable, and not volume, which is a business input. Turnaround time, because TAT is the number that a clinician on the ward actually feels, the number that determines whether a result changes a decision or arrives too late to matter. A potassium result that is perfectly accurate and four hours late did not help the patient in front of the doctor. TAT is where the lab's quality meets the hospital's reality. ## Decide What You Are Actually Measuring The first argument in any TAT project is about definitions, and it is worth having properly because a metric everyone measures differently is a metric nobody can improve. "Turnaround time" can mean any of several intervals, and they behave completely differently. - Order-to-result - from the moment the clinician places the order to the moment the verified result is available. This is what the clinician experiences and arguably the only number that matters to them. - Collection-to-result - from sample draw to result, which excludes the delay in getting a phlebotomist to the patient. - Receipt-to-result - from the sample arriving in the lab to the verified result, which is the interval the lab actually controls. Each is legitimate, and a serious lab tracks more than one, because the gap between them is diagnostic. If order-to-result is terrible but receipt-to-result is excellent, your problem is in phlebotomy and transport, not in the lab. Kōami timestamps each of these transitions, so the total interval can be decomposed instead of argued about. > If you only measure receipt-to-result, you will optimise the one part of the journey the clinician never sees and wonder why they still complain. ## The Median Lies, the Tail Tells the Truth The second mistake is reporting TAT as an average. A mean is dragged around by outliers and hides the shape of the distribution, and the shape is the whole story. What a clinician remembers is not the average result; it is the one that took six hours when they needed it in one. So report percentiles. - The median tells you the typical experience, which is useful for capacity planning. - The 90th percentile tells you what a bad day looks like, and it is the number that generates the complaints. - The maximum, examined case by case, is where you find the sample that got lost on a trolley, the analyzer that went down, the result that failed verification and sat in a queue. Chasing the median down while ignoring the tail produces a lab that looks good on the dashboard and feels unreliable on the ward. The improvement work lives in the tail. Kōami reports TAT as a distribution with percentiles rather than a single reassuring average, because the average is the number that hides the problem. ## Break the Journey Into Steps You Can Fix A long TAT is never one delay; it is an accumulation of small ones, and you cannot fix what you cannot see. The path from order to result has distinct stages, and instrumenting each transition tells you where the time actually goes. - Pre-analytical: order placed, sample collected, sample transported, sample received and accessioned. In most labs this is where the largest and most fixable delays hide - a sample waiting for the next transport run, a mislabelled tube sent back for recollection. - Analytical: sample loaded, instrument run, result produced. This is usually the fastest and most stable stage, which is why labs that only look here run out of things to improve. - Post-analytical: result verified, critical values called, report released. A result that waits in an unattended verification queue is a post-analytical delay masquerading as a slow lab. When you can see that forty minutes of a ninety-minute TAT is transport, you stop buying faster analyzers and start fixing the transport schedule. Kōami's step-level timestamps make that decomposition visible, which is what turns a vague complaint into a specific fix. ## Make TAT a Live Signal, Not a Monthly Report A TAT report that arrives on the fifth of next month tells you about problems you can no longer do anything about. To actually run a lab, TAT has to be a live signal that lets a supervisor intervene while the sample is still in the building. - Flag samples that are approaching their TAT target while there is still time to expedite them, not after they have breached. - Segment targets by priority, because a STAT troponin and a routine lipid panel should never be held to the same clock. - Watch the queues in real time, so a verification backlog building at shift change is visible before it becomes an hour of delayed results. Kōami surfaces in-flight samples against their targets so a supervisor can act on the sample that is running late today, not read about it next month. That shift - from retrospective reporting to live management - is what makes TAT a metric that runs the lab rather than merely grades it. Turnaround time endures as the lab's master metric because it refuses to let the lab grade itself in isolation. It ties the bench to the bedside and insists that a result only counts when it arrives in time to be used. Measure it honestly, by the right interval and the right percentile, break the journey into steps you can actually change, and make it a live signal a supervisor can act on. Do that and TAT stops being a number you report and becomes the number that runs the place.

Read article
Forecasting Bed Occupancy 48 Hours Out — Predictive Analytics | KōamiPredictive Analytics
Predictive Analytics· 5 min read

Forecasting Bed Occupancy 48 Hours Out

The bed manager's job is a forecasting job that nobody calls forecasting. Every afternoon someone in a hospital is trying to answer a question about tomorrow: will we have a bed for the elective admissions we promised, or are we about to spend the evening boarding patients in the emergency department corridor. They answer it with a whiteboard, a phone, and thirty years of instinct. Instinct is remarkable, and it is also unevenly distributed, unavailable at 3am, and impossible to hand over at a shift change. A 48-hour occupancy forecast is an attempt to write that instinct down. ## Occupancy Is Two Flows, Not One Number The mistake is to treat occupancy as a single figure - beds full, beds empty. It is really the balance of two independent flows, and forecasting each one separately is what makes the whole thing tractable. Admissions add to the ward. Discharges subtract from it. The occupancy in 48 hours is simply today's census plus the admissions you expect minus the discharges you expect, and the art is in estimating each side honestly. - Predictable admissions - the elective surgical list, scheduled transfers, booked procedures - which you largely know in advance and can read straight off the schedule. - Unpredictable admissions - emergency presentations that convert to inpatient - which are genuinely stochastic but follow strong day-of-week and seasonal patterns you can learn from history. - Expected discharges - which is where length-of-stay modelling does the heavy lifting, because a patient admitted three days ago for a condition with a typical stay of four days is probably leaving tomorrow. Kōami models these flows separately and recombines them, so a bed manager sees not just a predicted number but where that number comes from. ## Length of Stay Is the Engine If you can predict when patients will leave, you can predict occupancy, because the admissions side is comparatively easy. That makes length-of-stay estimation the engine of the whole forecast. A patient is not an average; a patient is a case with a diagnosis, an age, a set of comorbidities, and a procedure, and each of those shifts the expected discharge date. The useful output is not a single predicted day but a distribution, because certainty here is false comfort. A post-operative patient recovering normally has a tight, predictable stay. An elderly patient admitted with a chest infection and three comorbidities has a wide, uncertain one. A forecast that pretends both are equally knowable will mislead you exactly when it matters. So the model should express its own confidence, and the bed manager should see it. > Predicting the average patient's discharge is easy and nearly useless. The forecast earns its keep on the patients whose stay is uncertain, by being honest about that uncertainty. ## A Forecast You Cannot See Is a Forecast You Cannot Use A number in a report that nobody opens changes no decisions. The occupancy forecast has to arrive where the bed manager already looks, at the time they are already deciding, and in a form they can act on. That is a design problem as much as a modelling one. - Show occupancy by ward and by bed category, not just hospital-wide, because a full ICU and an empty general ward is not the same as a hospital that is half full. - Highlight the crossing points - the projected hour at which a ward exceeds a safe threshold - so the warning arrives before the crisis, not during it. - Make the levers visible. If the forecast says the surgical ward tips over tomorrow afternoon, the manager wants to know that pulling forward two discharges or delaying one elective case resolves it. Kōami presents the 48-hour view as an operational board rather than a static report, so the forecast is a thing people act on during the morning huddle instead of a file they read after the fact. ## The Forecast Has to Earn Trust, Then Keep It Every predictive system in a hospital faces the same adoption problem. The first time the forecast is confidently wrong, the staff who were sceptical feel vindicated, and rebuilding that trust is slow. So you plan for the forecast to be wrong sometimes and you design for it. - Compare predicted occupancy against what actually happened, every day, in the open, because a forecast whose accuracy nobody checks is just a rumour with a chart. - Degrade gracefully. When data is thin - a new ward, an unusual case mix - the forecast should widen its bands and say so, not project false precision. - Treat the model as decision-support that informs the bed manager's judgement, never as an autopilot that books and cancels admissions on its own. The human owns the decision; the forecast sharpens it. Kōami is built to sit alongside the bed manager rather than replace them, surfacing the projection and its track record so the team can calibrate how much weight to give it. A good 48-hour occupancy forecast does not eliminate the afternoon scramble on its own. What it does is move the conversation earlier and ground it in something more durable than one person's memory. Instead of discovering at 8pm that there is no bed, the team sees the pressure building at the morning huddle and has a full day to act - a discharge chased, an elective rescheduled, a transfer arranged. That head start, repeated every day, is the whole point. The forecast is not there to be clever. It is there to buy time.

Read article
Forecasting Hospital Supply Pipelines — Predictive Analytics | KōamiPredictive Analytics
Predictive Analytics· 5 min read

Forecasting Hospital Supply Pipelines

A hospital pharmacy running out of a first-line antibiotic is not a spreadsheet problem. It is a clinician switching to a second choice, a patient staying an extra day, and a procurement officer making a panicked call to a distributor who now holds all the pricing power. Supply forecasting in a hospital is the discipline of making sure that call never has to happen. It is unglamorous, it is deeply operational, and it is where a surprising amount of money and clinical quality quietly leaks away when it is done by gut feel. ## Why Hospital Demand Refuses to Behave Retail demand forecasting has a comfortable assumption: sales are roughly stationary and seasonal in predictable ways. Hospital consumption breaks that assumption constantly. A single trauma admission can burn through a month of a particular suture size overnight. A dengue season triples IV fluid demand for six weeks and then vanishes. A new consultant joins and their preference for a specific implant reshapes an entire category. So the first honest step is to segment your items by how they actually behave, because one model will not fit all of them: - Steady movers - routine consumables like gloves and saline - where demand is high-volume and reasonably smooth, and simple statistical forecasting works well. - Lumpy movers - specialised implants, less-common drugs - where demand is intermittent and a naive average badly overstocks you. - Clinically critical items - emergency drugs, blood products - where the cost of a stockout is measured in patient harm, not rupees, and you deliberately hold more than pure math would suggest. Kōami's inventory analytics classify items into these behaviours from consumption history rather than treating the whole formulary as one undifferentiated list. ## The Reorder Point Is the Real Decision Most of the value in supply forecasting collapses into one number per item: the reorder point, the stock level at which you place a new order. Set it too low and you stock out during the lead time. Set it too high and you tie up cash and shelf space in inventory that expires. The reorder point is not a guess; it is a calculation with three honest inputs. - Average demand during the lead time - how much you expect to consume between placing an order and receiving it. - Lead-time variability - because a supplier who quotes seven days but sometimes takes twenty is the real risk. - Safety stock - the buffer sized to the demand variability and to how much you are willing to risk a stockout on that specific item. The mistake labs and pharmacies make is using a single flat lead time for every supplier. In reality lead times have tails, and it is the tail - the delayed shipment, the customs hold, the manufacturer backorder - that causes the stockout. Forecasting has to model the variability, not just the average. > A reorder point built on average lead time protects you on an average day. Stockouts do not happen on average days. ## Expiry Is the Forecast Nobody Runs Stockouts get all the attention because they are visible and embarrassing. Expiry is the quieter loss, and in a hospital pharmacy it can be larger. A batch of a slow-moving drug bought in bulk to get a discount, sitting untouched until it crosses its expiry date, is money that was spent and then thrown away. Good supply analytics forecast expiry risk with the same seriousness as stockout risk. This means watching two things together: - Days of cover - how long current stock will last at the forecast consumption rate - flagged against the batch expiry dates you already hold. - FEFO discipline - first-expiry-first-out - so that when stock does move, the batch nearest expiry leaves first, which no amount of forecasting achieves if the store issues from the front of the shelf. Kōami surfaces items where days-of-cover exceeds shelf life, which is the early warning that you are about to write off stock. Catching it a month out means you can slow ordering or redistribute; catching it on the expiry date means you can only dispose of it. ## Forecasts Are Proposals, Not Commands The failure mode of every automated ordering system is the same: it generates a suggestion, the suggestion is occasionally absurd, a human overrides it, and after a few absurd suggestions the humans stop trusting all of them. The way to keep a forecast useful is to treat its output as a proposal a procurement officer reviews, with the reasoning visible. - Show why the system suggests an order - the forecast, the current stock, the lead time, the safety buffer - so the officer can sanity-check it in seconds. - Let known events be entered as inputs. A planned surgical camp or a seasonal outbreak is information the officer has and the history does not. - Track forecast accuracy over time per item, so the items where the model is unreliable get more human attention and the items where it is dependable get less. Kōami is built around this review-and-approve loop rather than silent automation, because a hospital procurement decision carries consequences that justify a human in the path. Forecasting a supply pipeline well does not require exotic mathematics. It requires taking three ordinary questions seriously for every item that matters: how much will we use, how long and how reliably does resupply take, and what does it cost us to be wrong in each direction. Answer those with real data instead of habit, keep a competent human in the loop, and the panicked call to the distributor stops happening. That quiet absence of crisis is exactly what a good forecast is supposed to buy.

Read article
Wiring Analyzers into the LIS — Interoperability | KōamiInteroperability
Interoperability· 5 min read

Wiring Analyzers into the LIS

Walk into any mid-sized diagnostic lab and you will find a technologist retyping results. The haematology analyzer prints a strip, someone reads the strip, and someone keys the numbers into the information system. It works, until it does not: a transposed digit on a potassium result, a sample ID typed one off, a critical value that sat on a printout for twenty minutes because nobody was standing at the machine. Analyzer interfacing exists to close that gap. Done well, the result leaves the instrument and lands in the LIS with no human hand in between. Done badly, it introduces new and stranger failures than the manual process it replaced. ## The Two Dialects Every Lab Speaks Most laboratory instruments talk in one of two dialects, and you will meet both. The older one is ASTM E1381/E1394, a serial protocol that predates the web and still runs the majority of installed analyzers. The newer one is HL7, usually version 2.x, carrying ORU result messages and ORM order messages. Plenty of instruments now speak HL7 over TCP; plenty of older ones only offer a nine-pin serial port and an ASTM frame. The interface engine's job is translation. It has to: - Read the instrument's native frames, whether that means listening on a serial line or accepting an HL7 message on a socket. - Map the instrument's test codes to your LIS test codes, because the analyzer calls it GLU and your LIS calls it Glucose-F. - Normalise units and reference ranges so a result means the same thing regardless of which of your three chemistry analyzers produced it. Kōami's LIS sits on an interface layer that speaks both dialects, so a lab can run a decade-old cell counter and a brand-new immunoassay analyzer side by side without maintaining two mental models. ## Unidirectional Is Simple, Bidirectional Is Worth It There are two levels of ambition. A unidirectional interface pushes results from the analyzer to the LIS. It is straightforward, it eliminates transcription, and for a low-volume bench it may be all you need. A bidirectional interface adds the return path: the LIS sends the worklist and the sample identity to the analyzer, so the instrument knows which tests to run on which tube before the technologist touches anything. Bidirectional is more work to commission, and it is worth it in any lab with real volume: - It removes the second transcription - the one where a technologist programs the analyzer by hand - which is where sample mix-ups are born. - It supports host query, where the analyzer scans a barcode, asks the LIS "what do I run on this tube," and gets an answer in real time. - It lets you add or cancel a test after the tube is loaded without walking back to the machine. > A unidirectional interface saves typing. A bidirectional interface changes who is responsible for getting the right test on the right tube - and hands that responsibility to software that does not get distracted. ## Nothing Auto-Verifies Until the Rules Say So The fear every lab director voices is the same: if results flow straight through, will a wrong number reach a clinician unchecked? The answer is that raw instrument output should never post automatically. Between the analyzer and the verified report sits a layer of rules, and that layer is where a good interface earns its keep. Auto-verification releases a result without human review only when it passes every gate you set: - Delta checks, which flag a result that has moved implausibly far from the patient's previous value for the same test. - Analytical range limits, which hold anything outside the instrument's reportable range for a technologist to look at. - Critical-value rules, which never auto-release. A potassium of 6.8 or a platelet count of 15 gets escalated to a human and, ideally, triggers a documented call to the ward. Everything that fails a rule lands in a review queue. Everything that passes flows through. The point is not to remove the technologist; it is to spend their attention on the ten results that need it instead of the four hundred that do not. Kōami lets a lab tune these rules per test and per analyzer, because a delta check that makes sense for creatinine is nonsense for a one-off tumour marker. ## Commissioning Is Where Interfaces Live or Die An interface that passed a vendor demo can still fail in production, and the reasons are mundane. A firmware update changes the frame format. Someone swaps the serial cable for one with a different pinout. The analyzer's clock drifts and results arrive stamped in the wrong order. The unglamorous work of commissioning and monitoring is what separates an interface that runs for years from one that quietly corrupts data. Treat it as an operational discipline: - Validate the mapping with real samples across the full analytic range before going live, not just the two control levels that happen to be loaded. - Reconcile counts daily at first - results produced by the analyzer versus results landed in the LIS - so a silent drop is caught in hours, not weeks. - Alarm on silence. An interface that stops sending is more dangerous than one that sends errors, because errors get noticed and silence does not. Kōami surfaces interface health as something a lab supervisor can watch, so a stalled connection raises a flag instead of a mystery. Analyzer interfacing is one of those investments whose payoff is measured in things that stop happening: the mistyped result, the delayed critical call, the sample run twice because nobody was sure the first run posted. It is not glamorous engineering. It is careful mapping, honest rules, and monitoring that assumes something will eventually break. Get that right and the lab gets faster and safer at the same time, which is a rare combination worth working for.

Read article
Connecting to ABDM/ABHA the Practical Way — Interoperability | KōamiInteroperability
Interoperability· 5 min read

Connecting to ABDM/ABHA the Practical Way

Every hospital that has tried to connect to the Ayushman Bharat Digital Mission learns the same lesson in the first fortnight: the hard part is not the API. The specifications are published, the sandbox is reachable, and a competent developer can generate an ABHA number in an afternoon. The hard part is the plumbing between ABDM and the way your front desk, wards, and records room actually work. A registration clerk who is already juggling a queue of forty patients will not stop to explain consent artefacts. So the practical question is never "can we integrate" but "where do we put each step so nobody has to think about it." ## Start With ABHA Creation Where It Is Painless The ABHA (Ayushman Bharat Health Account) number is the anchor. It is a 14-digit identifier that ties a patient to their longitudinal record across facilities. The temptation is to make ABHA creation a separate counter or a separate screen. Resist it. Fold it into the registration flow you already have. In practice this means two paths, and you should build both: - Aadhaar-based creation, where the patient consents to an OTP and the demographic details flow back automatically. Fast, but depends on a working mobile number linked to Aadhaar. - Mobile-driven creation, for the large number of patients whose linked number is stale or belongs to a relative. This path is slower and needs manual demographic entry, so route it to a clerk who has thirty seconds to spare, not the peak-hour window. Kōami handles both from inside the same registration screen, so the clerk sees one extra field, not one extra system. If the patient already has an ABHA, verification replaces creation, and the flow is shorter still. > The measure of a good ABDM integration is that a busy clerk never has to leave the screen they were already on. ## Consent Is a Workflow, Not a Checkbox The single most misunderstood part of ABDM is consent. Data does not move because a hospital wants it to move. It moves because a patient granted a consent artefact that specifies exactly what, for how long, and to whom. A consent request carries a purpose code, a data range, a set of HI (health information) types, and an expiry. The patient approves it on their own app, and only then does the Health Information Exchange release the records. This has real consequences for how you design the screen. When a physician wants to pull a patient's prior discharge summary from another facility, the request has to be phrased in ABDM's terms and the patient has to act. If your workflow assumes instant access, it will feel broken. Build for the asynchronous reality: - Raise the consent request early, ideally at check-in, so the artefact is often approved by the time the patient reaches the consultation room. - Show the physician a clear state - requested, granted, denied, or expired - rather than a spinning loader that implies the data is on its way when it may never arrive. - Store the artefact reference against the encounter so an audit can reconstruct precisely why a record was accessible. Kōami keeps the consent state visible on the patient's timeline, which turns an invisible protocol into something the clinical team can reason about. ## Care Context Linking Is Where the Value Lives Creating an ABHA does very little on its own. The value appears when you link care contexts. A care context is a single episode of care - an OPD visit, an admission, a lab panel - registered against the patient's ABHA so that it becomes discoverable later. Skip this step and you have handed out identifiers that point to nothing. The discipline is to link a care context at the moment the episode becomes real: when the visit is confirmed, when the admission is booked, when the report is finalised. Do it in the background, triggered by events your system already emits. A discharge that is finalised in the HMIS should fire a care-context link without a human pressing anything. When you get this right, a patient who walks into a different hospital next year can, with their consent, surface the discharge summary your team wrote today. ## Design for the Network You Actually Have ABDM assumes connectivity that Indian hospitals do not always have. Registration desks lose their link mid-morning. Gateway calls time out. The Health Information Provider on the other side is offline for maintenance. If your integration treats every failure as fatal, your clerks will quietly stop using it, and then you have an expensive feature nobody touches. Build for graceful degradation: - Queue outbound linking and consent callbacks so a dropped connection retries automatically rather than losing the event. - Let ABHA creation fail soft: register the patient in the local record first, attach the ABHA when the network returns, and never block clinical care on a gateway response. - Log every gateway interaction with its correlation identifier so that when a call fails, someone can actually trace it instead of guessing. Kōami is designed to run this way, treating ABDM as an eventually-consistent partner rather than a synchronous dependency, which is the only assumption that survives contact with a real hospital network. Connecting to ABDM is less a coding exercise than an operations exercise. The specification tells you how to speak the protocol. It says nothing about where consent belongs in your queue, how a clerk creates an ABHA without slowing down, or what a physician sees when a record has not yet been released. Get those human details right and ABDM becomes quietly useful. Get them wrong and you have a compliant integration that everyone avoids. The practical way is to make the digital health account something your staff barely notice they are using.

Read article
Designing APIs Hospitals Can Actually Build On — Interoperability | KōamiInteroperability
Interoperability· 5 min read

Designing APIs Hospitals Can Actually Build On

Most healthcare software promises an API, and most of those APIs are a disappointment when a hospital's own team finally tries to build on them. The endpoints exist but the documentation lags the behaviour. Authentication is a bespoke scheme nobody else uses. There is no way to be notified when something changes, so integrations resort to polling every few minutes and hoping. The gap between "we have an API" and "you can actually build on our API" is enormous, and hospitals only discover which side of it a vendor sits on after they have signed. Designing APIs that hospitals can genuinely build on is a discipline, and it is worth being explicit about what it takes. ## The difference between an API and a platform Having endpoints is table stakes. Being buildable is a higher bar, and it is defined by whether an integrator who has never met your team can succeed from the documentation alone. That means a few things have to be true at once: - Predictable, resource-oriented REST, so once someone learns one endpoint they can guess the shape of the next. - Consistent authentication using an approach integrators already know, rather than a scheme invented in-house. - Clear versioning, so an upgrade on the vendor side does not silently break a hospital's working integration. - Honest, current documentation that matches what the API actually returns, including the error cases. > An API is only as good as the worst surprise it springs on the developer at 2 a.m. during a go-live. The test is simple and unforgiving: can a hospital's IT team, or a third-party integrator, build something real without a single support call? If the answer is no, it is not a platform. It is a set of endpoints with a marketing label. ## Stop polling, start listening The single biggest quality-of-life difference between a mediocre API and a good one is webhooks. Without them, any integration that needs to react to a change has to poll - ask "has anything happened yet?" over and over, most of the time to be told no. Polling is wasteful, it is slow, and it scales badly as the number of integrations grows. Webhooks invert the model. Instead of the hospital's system asking repeatedly, Kōami's platform calls the hospital's system the moment something relevant happens. The events that matter in a hospital map naturally onto this: - A patient is admitted, discharged or transferred, so the pharmacy or billing system reacts immediately to the ADT event. - A lab result is finalised, so an external portal updates without a five-minute delay. - An inventory item crosses its reorder threshold, so procurement is notified in real time. - A credential is approaching expiry, so an external compliance dashboard picks it up. Real-time delivery is not a luxury feature. In a hospital, the difference between "now" and "in five minutes" is sometimes the difference between a safe workflow and a dangerous one. ## Build webhooks that survive the real world Webhooks are easy to demo and hard to do well, because the real world is unreliable. The receiving system will occasionally be down, slow, or briefly unreachable, and a naive webhook simply loses the event. A serious implementation plans for failure: - Retries with backoff, so a momentary outage on the hospital's side does not drop the event permanently. - Signed payloads, so the receiver can verify the call genuinely came from Kōami and not from an impostor. - Idempotency keys, so a retried delivery does not cause the same admission to be processed twice. - A replay or catch-up mechanism, so a system that was down for an hour can recover the events it missed. Skip these and you have a webhook that works in the demo and fails in production. The unglamorous reliability engineering is exactly where "we support webhooks" becomes "you can depend on our webhooks." ## Design for least privilege An open API in healthcare is also an expanded surface for accessing sensitive data, and that has to be treated with respect rather than bolted-on caution. Buildable does not mean wide open. The right posture is granular scopes, so an integration that only needs to read inventory levels cannot reach patient records, and every credential is scoped to the least it needs to do its job. Access should be auditable, so a hospital can see which integration read what and when. This is a capability question, not a certification claim: the point is to give hospitals the controls to grant narrow, revocable, observable access rather than handing out keys to everything. ## Documentation is part of the product The last mile of a buildable API is the part vendors most often neglect: the documentation, the sandbox, and the examples. An integrator should be able to read the reference, try a call against a test environment that behaves like production, see a worked example for the common flows, and understand the error responses without reverse-engineering them. Kōami treats this material as part of the product rather than an afterthought, because an undocumented capability is, for practical purposes, a capability that does not exist. Hospitals are not asking for a magic integration that reads their minds. They are asking for the plumbing to connect the systems they already run - the LIS, the third-party portal, the analytics stack - without a services contract for every small change. That is what open, well-versioned REST APIs and reliable webhooks provide: the ability to build, to react in real time, and to do it safely with access scoped to exactly what each integration needs. The measure of success is quiet. A hospital's own team ships something useful, on their own, and never needs to call you to do it.

Read article
Breaking Down Data Silos in Healthcare — Interoperability | KōamiInteroperability
Interoperability· 5 min read

Breaking Down Data Silos in Healthcare

A patient arrives in the emergency department at midnight, unconscious, with a chronic condition managed at the same hospital's OPD for years. The registration clerk creates a fresh record because the ED system cannot see the OPD one. The lab results from last week sit in a database the ED clinician cannot reach. The old CT is in a PACS that speaks a different language. Somewhere in the building, every piece of information needed to treat this patient well already exists. It just cannot travel. This is the everyday cost of data silos, and it is paid in duplicated tests, delayed decisions and the small, dangerous gaps where important context falls through. ## How silos form without anyone deciding to build them No hospital sets out to fragment its own data. Silos accumulate one reasonable decision at a time: - The lab buys a best-of-breed LIS; the radiology department picks its own RIS and PACS. - The HMIS grows organically, with modules added by different vendors over a decade. - A new insurance-desk tool is bolted on because it was quick to deploy. - Each system has its own patient identifier, so the same person is three different IDs across three databases. Individually, every choice made sense. Collectively they produce a hospital where the UMR in one system does not resolve in another, and where "integration" means a staff member re-keying data from one screen into the next. The clerk becoming a human data bus is not a workflow; it is a symptom. ## What breaks when data cannot move The consequences are not abstract. They show up at the bedside and on the balance sheet: - Tests get repeated because the earlier result is invisible, wasting money and, for imaging, exposing patients to avoidable radiation. - ADT events - admission, discharge, transfer - do not propagate, so the pharmacy, the diet kitchen and the billing desk work from stale information. - Discharge summaries are assembled by hand from systems that will not talk, delaying beds and frustrating families. - Clinical decisions are made with partial information because pulling the full picture takes more time than anyone has at 2 a.m. > Every silo is a place where a clinician has to choose between spending time they do not have or deciding with less than they should. The deepest cost is the one nobody logs: the decision made without a piece of context that existed all along, one system away. ## The standards that let systems talk The good news is that healthcare interoperability is not an unsolved research problem. There are mature standards for exactly this, and the job is to use them properly rather than to invent something bespoke: - HL7 v2 remains the workhorse for ADT, orders and results messaging between hospital systems, and most existing kit already speaks it. - FHIR offers a modern, resource-oriented, REST-friendly model - Patient, Encounter, Observation, DiagnosticReport - that is far easier to build against. - DICOM and DICOMweb move imaging, so a study acquired on one modality can be viewed and shared without exporting a folder of files. The point of a standard is that it decouples systems. When the lab publishes results as FHIR Observations, any authorised system can consume them without a custom, brittle, point-to-point integration that breaks the next time either side upgrades. ## Identity is the hard part The unglamorous truth is that most interoperability failures are really identity failures. If system A calls the patient UMR-4471 and system B calls the same human PT-88213, no amount of HL7 will reliably stitch them together. Before messages can flow meaningfully, a hospital needs a way to resolve one patient to one identity across every system that touches them. The Kōami approach treats the patient identity as the anchor the modules share, so that an OPD encounter, an IPD admission, a lab result and an imaging study all hang off the same person rather than off four disconnected records that happen to describe the same body. Get identity right and the messaging standards do their job. Get it wrong and even perfect FHIR produces confidently linked nonsense. ## Connected by design, not by adapter The distinction that matters when evaluating clinical software is whether interoperability was designed in or bolted on. A suite where the HMIS, the inventory, the imaging and the HRMS were built to share identity and to exchange data through standard interfaces behaves differently from a collection of products stitched together with adapters after the fact. In the Kōami ecosystem the modules are meant to speak to each other natively - an admission is visible where it needs to be, an imaging study is reachable over DICOMweb by the clinician who needs it - while open, standards-based interfaces let the hospital's other systems join the conversation rather than being walled out. None of this requires a hospital to rip everything out and start again, which is rarely realistic. It requires choosing systems that speak the common languages - HL7, FHIR, DICOMweb, plain REST - and that anchor on a shared patient identity. Breaking down silos is less a single project than a standing principle: every new system earns its place partly by how well it lets data move. The patient in the ED at midnight does not care about your architecture. They only benefit from the fact that, this time, everything the hospital already knew about them was actually there when it counted.

Read article
Reading Attrition Before the Resignation Letter — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Reading Attrition Before the Resignation Letter

By the time a resignation letter lands on a manager's desk, the decision is usually weeks or months old. The nurse mentally left a while ago; the letter is just the paperwork catching up. This is the uncomfortable truth about attrition in hospitals: the moment you learn about it is the moment it is already too late to do much. Yet the departure was rarely silent. The signals were there in the roster, the attendance record and the overtime ledger, scattered across systems that were never asked to notice them. Reading attrition early is not about predicting individuals with spooky precision. It is about paying attention to patterns you already have the data to see. ## Why hospital attrition hurts more Losing a nurse is not like losing a generic employee. The cost compounds in ways that are specific to clinical work: - Recruitment and onboarding for a specialised role - ICU, dialysis, OT - takes months, not weeks. - The remaining team absorbs the gap, which raises their workload and their own attrition risk. - Institutional knowledge walks out: the nurse who knew the ward's rhythms, the difficult families, the quirks of the equipment. - Agency and overtime spend rises to plug the hole, so the departure costs money long before the replacement arrives. Because the cost is so high and the replacement so slow, even a few weeks of early warning is worth a great deal. It is the difference between a managed transition and a scramble. ## The signals are already in your systems The data that predicts disengagement is not exotic. It is the operational exhaust a hospital already generates every day, sitting in the HRMS and the roster. The problem is that no single screen puts it together. Some of the more reliable signals: - A sustained rise in unplanned leave or late check-ins from someone previously reliable. - Overtime that has been climbing for months, a sign of a person being quietly overloaded. - A drop in shift-swap participation, or a pattern of always offloading shifts and never picking any up. - Repeatedly being rostered into the unpopular slots that others avoid. - Leave balances hoarded and untaken, then a sudden burst of usage. > Attrition rarely announces itself. It leaks, one changed habit at a time, through data you are already collecting. None of these is proof on its own. A nurse taking more leave might simply have a sick parent. But a cluster of these shifts, moving together over a quarter, is a pattern worth a conversation. ## Patterns, not verdicts It is worth being clear about what this kind of analysis should and should not do. The aim is not to hand a manager a ranked list of "flight risks" and invite them to treat people as suspects. That is both ethically corrosive and operationally counterproductive; staff who sense they are being scored will disengage faster, not slower. The aim is to surface changes in pattern that prompt a human check-in. In the Kōami HRMS, the useful framing is a shift in a person's own baseline rather than a comparison against colleagues. Someone whose overtime has doubled and whose swap participation has fallen is not a data point to be flagged and filed. They are a colleague who may be quietly burning out, and the right response is a manager asking how they are doing - not a spreadsheet deciding their fate. The technology's job is to make sure that conversation happens before the letter, not after. Framing the signal as a change in someone's own pattern also protects against the unfairness of comparing very different people. A nurse who has always worked a lot of overtime is not the story; a nurse whose overtime has suddenly climbed is. Watching each person against their own history keeps the focus on what changed rather than on who happens to look busy, and that distinction is what makes the resulting conversation feel supportive instead of accusatory. ## Fix the causes the data reveals Early signals are only useful if they lead somewhere. Often the same data that flags an individual also reveals a structural problem worth fixing: - If overtime is concentrated on a few names, the roster is leaning on your best people until they break. - If certain units generate most of the unpopular-shift complaints, the differential or the rota design needs attention. - If leave is chronically unusable because cover never exists, the staffing model is the problem, not the person. - If swap participation is collapsing across a team, morale is sliding for reasons no individual conversation will fix. Treating attrition signals purely as an individual matter misses the point. Frequently the data is telling you something about how the ward is run, and the highest-leverage response is to change the system rather than to counsel one nurse. ## Turn the signal into a habit For this to work it cannot be a heroic quarterly analysis that one motivated manager runs and then abandons. It has to become routine: a regular look at the trends, a low-key check-in when a baseline shifts, and a willingness to act on what the aggregate patterns say about the roster itself. The hospitals that retain nurses are not the ones with the cleverest prediction model. They are the ones that notice a good nurse being quietly ground down and do something while there is still time. Retention is won in the weeks before the resignation, not in the counter-offer after it. The data to see it coming is already flowing through your rosters and attendance logs. The only question is whether anyone is reading it in time - and whether, when the pattern shows up, the response is a genuine conversation and a fairer roster rather than a flag in a file.

Read article
Never Staff an Expired Licence Again — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Never Staff an Expired Licence Again

There is a particular kind of quiet risk in a hospital that never shows up until an auditor or a lawyer goes looking for it: the staff member on duty whose licence, registration or mandatory training lapsed weeks ago, and whom the roster kept assigning because nobody was watching the dates. Nothing looks wrong on the day. The nurse is competent, the shift is covered, the ward runs. The problem is entirely on paper - until the paper is what matters, in an accreditation review, an insurance query, or an adverse event investigation. Credential expiry is one of the most preventable risks in healthcare operations, and one of the most commonly ignored. ## The credentials that actually lapse "Credential" is a broad word, and the things that expire are more numerous than most rosters track. In a typical hospital the list runs long: - Nursing council registration and its periodic renewal. - Medical registration for clinicians. - BLS, ACLS and other life-support certifications with fixed validity windows. - Radiation safety badges and training for staff working near imaging. - Fire safety, infection control and other mandatory annual trainings. - Role-specific competencies that a unit requires before it will accept a nurse onto its rota. Each of these has an issue date and an expiry date, and each one is somebody's responsibility to renew. In practice that responsibility is scattered across the individual, the HR file, and a supervisor's memory, which is to say it is nobody's reliable job. ## Why the spreadsheet always loses The default tool for tracking credentials is a spreadsheet with a column of expiry dates, and it fails in the same way every time. Somebody has to remember to open it, sort it, and act on it before a date passes. That person goes on leave, gets busy during an NABH cycle, or simply trusts that the last update is still current. The spreadsheet does not raise its hand. It waits to be asked, and by the time someone asks, the expiry has already happened and staff have already worked shifts they were not, on paper, cleared to work. > A credential register that does not warn you is just a record of when you found out too late. The failure is structural, not personal. Any control that depends on a human remembering to check a static list will eventually fail on the day that human is distracted. The fix is to make the credential data active rather than passive. ## Make the credential block the assignment The decisive move is to connect the credential record to the roster itself, so that expiry is not merely reported but enforced. In the Kōami HRMS, each staff member's credentials are held as structured records with expiry dates, and those dates participate in scheduling decisions. That changes the question from "did anyone notice?" to "can this person even be assigned?" Concretely, the system can: - Warn well ahead of expiry - 60, 30 and 7 days out - to the individual, their supervisor and HR, so renewal happens before the deadline, not after. - Flag a scheduled shift where the credential will lapse before the shift is worked. - Prevent, by policy, the assignment of a nurse to a unit whose required competency she does not currently hold. - Surface a live dashboard of who is expiring when, by department, so managers see the wave coming. The graduated warnings matter. A single alert on the expiry date is useless; a renewal often takes weeks to arrange. Nudging at 60 days gives people time to actually do something, and enforcing the block at the roster level means that even if every reminder is ignored, an expired credential still cannot quietly end up on a duty list. It is worth stressing how different this is from the reporting model most hospitals rely on. A report tells you, after the fact, that something went wrong. An enforced rule stops the wrong thing from happening in the first place. The credential register moves from being an archive you consult during an audit to being an active guardrail that shapes today's roster. ## Design the reminders so people act An alert that everyone ignores is worse than no alert, because it trains people to dismiss the system. Credential reminders earn attention when they are specific, escalating and owned: - Specific: name the credential, the person, the exact expiry date and what renewal requires. - Escalating: if the 60-day nudge is ignored, the 30-day and 7-day reminders widen to include the supervisor and then HR. - Owned: every credential has a clear responsible person, so a reminder lands somewhere accountable rather than in a shared inbox nobody reads. Get this right and renewals stop being fire drills. The unit knows in advance that three nurses need ACLS refreshers next quarter and can schedule the training without pulling the ward apart at the last minute. ## From risk register to routine The payoff is not only avoiding a bad audit finding, though that alone justifies the effort. It is that credential management stops being a periodic panic and becomes a quiet routine. When the roster itself refuses to staff an expired licence, the worst outcome is designed out rather than watched for. Accreditation reviews become a matter of exporting a clean report rather than scrambling to plug gaps in the fortnight before the assessors arrive. No hospital sets out to staff an expired credential. It happens because the information sits in a passive list while the roster carries on regardless. Close that gap - let the expiry date reach into the scheduling decision - and the problem largely solves itself. The nurse gets renewed on time, the ward stays properly covered, and the paper tells the same true story as the practice. That alignment, boring as it sounds, is what good clinical governance actually looks like day to day.

Read article
Getting PF, ESI, PT and TDS Right, Every Month — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Getting PF, ESI, PT and TDS Right, Every Month

Payroll in an Indian hospital is not one calculation. It is a stack of them, each with its own rules, thresholds and filing calendar, sitting on top of attendance data that is often messy to begin with. Provident Fund, Employee State Insurance, Professional Tax and Tax Deducted at Source each answer to a different authority, and each one is unforgiving about deadlines. Get them right and nobody notices, which is the whole point. Get them wrong and you are looking at interest, penalties, and a queue of staff outside the HR office asking why their take-home dropped. Getting statutory payroll right every month is less about cleverness and more about discipline built into the system. ## Four deductions, four different rulebooks The reason payroll feels harder than it should is that these four components do not share a logic. Treating them as one lump is exactly how mistakes creep in. - PF applies on a defined wage base with employer and employee contributions, and the base itself is a source of endless confusion when allowances enter the picture. - ESI applies to employees below a wage threshold, which means a mid-year increment can push someone out of coverage - but only from the correct contribution period, not the day the raise lands. - PT is a state subject, so a hospital with units in more than one state is running different slabs and different due dates in parallel. - TDS on salary depends on the employee's declared regime, investment proofs and projected annual income, and it has to be smoothed across the year rather than lumped into March. > The danger is not the arithmetic. It is the assumption that last month's rules still apply this month. They often do not. Each of these has moving parts that change with a promotion, a threshold revision, a new state of operation, or a mid-year statutory update. ## Where hospitals actually get caught Across the units we have seen, the errors are rarely exotic. They are the same handful, repeated: - Applying an ESI threshold change from the wrong date, so an employee is deducted after they should have exited or vice versa. - Running PT on the head-office state slab for staff who actually work in another state. - Treating LOP inconsistently, so the PF and ESI bases do not match the days actually worked. - Under-deducting TDS early in the year and then shocking staff with a large March cut when the shortfall is recovered. Notice how many of these trace back to attendance. If the LOP is wrong, every downstream deduction inherits the error. Statutory payroll is only as clean as the attendance and roster data feeding it. ## Start upstream, at attendance This is why payroll cannot be an island. In the Kōami ecosystem the payroll engine reads from the same roster and attendance records that the HRMS already maintains, so the days-worked figure that drives PF, ESI and LOP is the one the geofenced check-ins and approved leave actually produced. A swap that was properly recorded, a night differential that was earned, a leave that was sanctioned - these arrive as facts, not as month-end reconstructions. When the input is trustworthy, the statutory calculation stops being a guess. The corollary is blunt: if a hospital is fixing attendance by hand every month, no payroll software will save it. The leverage is in getting the presence data right the first time, so payroll has something honest to compute on. ## Make the month-end run boring A good statutory payroll process is deliberately unexciting. The system should carry the current rules, apply them to clean data, and produce outputs that map directly to what each authority expects: - Contribution registers for PF and ESI aligned to the correct wage bases and periods. - PT computed against the right state slab for each employee's place of work. - TDS projected across the financial year, adjusted as declarations and proofs come in, and reconciled so March holds no nasty surprises. - Payslips that show each deduction as a distinct, explainable line rather than an opaque net figure. That last point earns disproportionate goodwill. When an employee can see exactly why PF, ESI, PT and TDS were deducted, the HR queue at the counter shrinks. Transparency is not a compliance requirement, but it is a trust requirement, and it costs nothing once the line items are already there. ## Keep the audit trail, because someone will ask Compliance is not only about computing correctly this month. It is about being able to show, later, that you did. A payroll run should leave behind a defensible record: which rule version was applied, what the wage base was, how LOP was derived, when the deduction was remitted. When an inspector or an auditor asks about a specific employee in a specific month, the answer should be a lookup, not an investigation. Kōami's approach is to keep these calculations and their inputs traceable so that the story holds together after the fact, without anyone reconstructing it from spreadsheets. None of this is glamorous, and that is precisely the ambition. Statutory payroll done well is invisible: staff are paid correctly, deductions land where they should, filings go out on time, and the phrase "payroll dispute" slowly disappears from the HR vocabulary. It gets there not through a single clever feature but through the unglamorous discipline of clean attendance, current rules, transparent payslips and a trail you can stand behind. Every month, the same way, without drama.

Read article
Letting Nurses Swap Shifts Without Chaos — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Letting Nurses Swap Shifts Without Chaos

Ask any charge nurse what actually happens when someone needs to swap a shift, and you will hear a story about WhatsApp. A message goes out to the ward group. Someone replies "I can take it." A third person, half-reading, assumes it is handled. The supervisor is looped in, or is not. Two weeks later the roster still shows the original name, the payroll run docks the wrong person, and nobody can reconstruct who agreed to what. Swaps are not the problem. Nurses covering for each other is a sign of a healthy team. The chaos comes from swaps happening in a channel the roster never sees. ## The hidden cost of an informal swap A shift swap looks like a private arrangement between two colleagues. In a hospital it is nothing of the sort. A single unmanaged swap can quietly break several things at once: - Skill mix: the nurse taking over may not hold the competency the shift requires, so the unit is short on paper strength even though the headcount looks fine. - Ratios: a swap that stacks one person into back-to-back shifts can breach rest rules and fatigue limits. - Attendance: the person who actually worked is marked absent, and the person who did not is marked present. - Pay: overtime, night differential and LOP all attach to the wrong name. None of this shows up on the day. It shows up at month end, in a payroll dispute, and by then the evidence is a scroll of chat messages nobody wants to arbitrate. ## What a governed swap looks like The fix is not to ban swaps. It is to give them a path that the roster and payroll can see. In the Kōami HRMS a swap is a small, structured transaction rather than a verbal agreement. A nurse offers a shift; eligible colleagues see it; one accepts; a supervisor approves or the rules approve automatically; the roster updates. The important word is eligible. The system only offers the shift to people who can legitimately take it: - They hold the skill and competency the unit and shift require. - They are not already rostered into a conflicting or adjacent shift. - Taking it will not breach hours or minimum-rest rules. - They are not on approved leave for that period. > A swap should be as easy as a WhatsApp message and as accountable as a signed form. Those two things are not in tension if the roster is doing the work. By the time a swap is confirmed, it is already valid. Nobody discovers the skill-mix problem when the patient deteriorates. ## Approvals that match how wards really run There is a temptation to route every swap through a supervisor and call it governance. On a busy ward that just moves the bottleneck. The better model is tiered approval, where the level of scrutiny matches the risk of the swap: - A like-for-like swap between two equally qualified nurses on the same unit can auto-approve within policy. - A swap that changes the skill mix, crosses units, or triggers overtime routes to the supervisor. - Anything that would breach a hard rule - rest, ratio, credential - is simply not offered in the first place. This keeps humans in the loop where judgement is needed and out of the loop where it is just friction. Supervisors stop rubber-stamping the obvious and start spending their attention on the swaps that actually deserve a second look. ## The payroll payoff The strongest argument for governed swaps is the one you feel on the last day of the month. When a swap flows through the roster, the downstream arithmetic is automatic and correct. The nurse who worked the night gets the night differential. The one who gave up the shift is not marked absent and does not take an unearned LOP. Overtime, if the swap created it, is attributed to the person who actually earned it. There is no reconstruction, no arbitration, no digging through chat history. Consider the alternative that most hospitals live with today. A swap made by phone means someone, somewhere, has to remember it and key it in. If they forget, the system confidently pays the wrong result. Every informal swap is a small debt that comes due at payroll, and the interest is paid in disputes and eroded trust. ## Fairness people can see Swaps also carry a quiet fairness dimension. In an informal system, the nurses with the best social connections get their shifts covered and the newer or quieter staff get stuck. A transparent swap board changes the dynamic: open shifts are visible to everyone eligible, not just to whoever is in the right WhatsApp group. Over time you can even see the pattern - who is always giving up shifts, who is always picking up extra, whether the load is shared or quietly dumped on the willing few. That visibility is worth as much to morale as it is to compliance. Nurses will always need to trade shifts. Life does not fit neatly into a roster drawn up a fortnight ago. The question is whether those trades happen in the daylight, where the roster records them and the pay follows correctly, or in the shadows of a chat thread where they turn into next month's argument. Give people an easy, accountable way to swap, and they will use it - not because policy forces them, but because it is genuinely less hassle than the WhatsApp scramble it replaces.

Read article
Geofenced Check-In Without the Friction — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Geofenced Check-In Without the Friction

Attendance sounds like the most solved problem in a hospital. People arrive, people leave, a machine records it. Then you look closely and find the exceptions eating everyone alive: the biometric reader that rejects wet or gloved hands, the queue at shift change when three hundred people badge in within ten minutes, the home-visit nurse who was never near a fixed device, and the ward sister covering for a colleague across the building. Geofenced check-in is meant to remove that friction. Done badly, it adds a new kind. Done well, it becomes invisible, which is exactly what good attendance should be. ## Why fixed devices quietly fail The classic hospital attendance setup is a biometric terminal at a staff entrance. It works until it does not, and the failure modes are boringly predictable: - Clinical staff scrub, glove and sanitise constantly, so fingerprint reads degrade through the shift. - Shift-change crowding turns a five-second punch into a five-minute queue. - Community and field roles - home care, sample collection, camp duty - are nowhere near the device. - One broken reader at one door creates a day of manual corrections in the HRMS. Every one of those exceptions becomes a manual regularisation, and manual regularisations are where payroll disputes are born. The person keying the correction is guessing, and the nurse who lost forty minutes to a dead reader is the one who pays for the guess. ## How a geofence changes the model A geofence is simply a defined boundary around a place - a hospital campus, a specific block, a patient's home for a scheduled visit - expressed as coordinates and a radius. Check-in then becomes a question the phone can answer: is this person inside the boundary they are meant to be in, at the time they are meant to be there? The staff member opens the Kōami app, confirms, and the location plus timestamp is captured. No queue, no shared surface, no hunt for a working terminal. > The point of a geofence is not to watch people. It is to let the honest, present majority prove they were where they said, without waiting in a line to do it. For a home-visit nurse this is transformational. The check-in happens at the patient's doorstep, tied to the scheduled visit, and the record reflects the actual care delivered rather than a punch at a building she visited hours earlier. ## Getting the friction out without inviting fraud The reasonable worry is that a phone-based check-in is easy to game. A serious implementation closes the obvious holes rather than pretending they do not exist: - Location integrity checks that look for mock-location and spoofing signals, not just a raw coordinate. - Device binding, so an account checks in from its registered phone rather than any handset. - Optional selfie or supervisor confirmation for high-trust roles or first check-in of a shift. - Sensible radius tuning, so a large campus is covered without a boundary so loose it becomes meaningless. The goal is proportionate assurance. A ward nurse checking in inside a bound device, inside the campus geofence, at her rostered time is low risk and should sail through. The exceptions are where you spend your scrutiny. ## Where geofence meets roster and payroll Attendance that lives in its own silo is just data. The value appears when the check-in event flows straight into the roster and the payroll run. In the Kōami HRMS, a geofenced check-in is matched against the shift the person was rostered for, and the arithmetic follows automatically: - On-time arrival closes the shift expectation with no human touch. - A late or missed check-in surfaces as an exception for a supervisor, not a silent LOP. - Overtime and shift differential accrue from the same event that recorded presence. - Month-end LOP is computed from real attendance rather than reconstructed from memory. This is the difference between attendance as a tracking exercise and attendance as the spine of accurate pay. When the same event that proves presence also drives the differential and the loss-of-pay calculation, the arguments at month end mostly disappear, because everyone is looking at the same record. ## Respecting the humans holding the phone Location capture is sensitive, and pretending otherwise erodes the trust you need. A geofence used for attendance should capture location at the moment of check-in and check-out, not track people continuously through their shift. Staff should know exactly what is recorded and when. The boundary is a gate you pass through, not a leash. Hospitals that communicate this plainly get adoption; those that stay vague get quiet resistance and a workforce that assumes the worst. There is also a fairness argument. A well-tuned geofence protects staff as much as it protects the employer. The nurse who was present has proof. The field worker who completed her visits has a record nobody can dispute. Friction removed on the honest side of the ledger is worth more than the small fraction of gaming it prevents. Attendance should be the least dramatic part of anyone's day. When check-in is a two-second confirmation from the place you already are, when the record flows cleanly into roster and pay, and when staff understand and trust what is captured, the whole apparatus fades into the background. That invisibility is the goal. The best attendance system is the one nobody has to think about, and nobody has to argue with at the end of the month.

Read article
Overcoming Nursing Shortages with Dynamic Shift Allocation — Workforce Operations | KōamiWorkforce Operations
Workforce Operations· 5 min read

Overcoming Nursing Shortages with Dynamic Shift Allocation

Every nursing superintendent knows the feeling of a Monday morning that has already gone wrong by 7 a.m. Two staff nurses have called in sick, one is on unplanned leave after a family emergency, and the medical ICU is running at census with a skill mix that no longer adds up. The shortage is real and structural, but a lot of the daily pain is not about how many nurses exist. It is about how the ones you have are matched to the shifts that need them. Dynamic shift allocation will not manufacture nurses out of nowhere. It will stop you from bleeding the ones you have. ## The shortage is real, but the roster makes it worse India runs well below the nurse-to-population ratios that professional bodies recommend, and the units that feel it most - critical care, emergency, dialysis, oncology day care - are exactly the ones where a wrong skill mix is dangerous, not merely inconvenient. Yet a surprising amount of avoidable strain traces back to how rosters are built. When a roster is drawn up a fortnight in advance on a spreadsheet and then patched by phone, three things happen: - Senior nurses get loaded onto the shifts nobody else will take, and burn out faster. - Gaps are filled by whoever answers the call, not by who is best suited or best rested. - Overtime and agency spend balloon, because last-minute cover always costs more. A static roster assumes a static hospital. Hospitals are not static. Census swings, acuity changes, and people are human. ## What "dynamic" really means Dynamic allocation does not mean an algorithm barks orders at your nurses. It means the roster is a living object that reflects current reality and known constraints, and that filling a gap becomes a matter of matching rather than pleading. A good system holds a few things in its head at once: - Skill and competency, so a paediatric-trained nurse is not auto-assigned to adult ICU by accident. - Ratios and acuity, so the allocation respects the nurse-to-patient targets each unit is meant to hold. - Fatigue and fairness, so nobody is silently rostered into a third night in a row. - Statutory and contractual limits on hours and rest between shifts. > A roster is not a grid of names. It is a promise about who will be competent, present and rested when a patient deteriorates at 3 a.m. When those constraints are encoded rather than carried in one supervisor's memory, the system can propose a valid fill in seconds and flag the ones that break a rule. ## From gap to cover, in minutes The workflow that matters is the one that plays out when a shift falls short. In the manual world it is a flurry of phone calls in an order that reflects who the supervisor remembers, not who is eligible. In Kōami's HRMS the same gap becomes a targeted broadcast: the open shift, with its unit, timing and any shift differential, goes to the nurses who are qualified, not on leave, not already at their hour limit, and not about to breach rest rules. The first suitable nurse to accept is confirmed, the roster updates, and the ripple effects - attendance expectation, overtime accrual, differential pay - are captured without a second data entry. That last part matters more than it sounds. When cover is arranged by phone, the payroll consequences are reconstructed at month end from memory and half-remembered WhatsApp messages. When it flows through the roster, the LOP that should not have happened does not happen, and the extra-hours pay that was earned actually shows up. ## Design the incentives, not just the grid Technology can match a nurse to a shift. It cannot, by itself, make an unpopular shift attractive. The hospitals that get the most from dynamic allocation pair it with honest incentive design: - A transparent shift differential for nights, weekends and short-notice cover, applied consistently rather than negotiated case by case. - Visible fairness, so nurses can see that the hard shifts are shared rather than dumped. - A predictable core roster with a smaller flexible layer on top, so people can plan their lives. Nurses tolerate a hard schedule far better when it is visibly fair and honestly paid. The fastest way to worsen a shortage is to make your most capable people feel like the system quietly punishes competence with more work. ## What to measure once it is running If you cannot see it, you cannot manage it. A dynamic allocation approach earns its keep when it produces numbers a superintendent can act on: - Time to fill an open shift, tracked as a trend rather than a war story. - Overtime and agency spend as a share of total nursing hours. - Distribution of unpopular shifts across the team, to catch quiet unfairness. - Vacancy hours by unit and skill, so recruitment targets the real gaps. These are the signals that turn "we are short-staffed" from a permanent complaint into a set of problems you can chip away at. Recruitment pipelines take months, and the nursing shortage will not resolve on a hospital's timetable. What a hospital can control is whether its existing nurses are matched intelligently, paid correctly for the shifts they take, and treated fairly enough to stay. Dynamic shift allocation is not a slogan about doing more with less. It is a practical way to stop wasting the scarce, skilled, tired people already walking your wards - and, more often than not, to keep them from becoming next quarter's resignation.

Read article
Where Your Patient Data Lives, and Why It Matters — Data Security | KōamiData Security
Data Security· 5 min read

Where Your Patient Data Lives, and Why It Matters

When a patient hands over their name, their UMR, a scan of an old discharge summary and a photo of a rash, they are not thinking about which server rack that data lands on. That is your job. Where patient data physically lives, who can reach it, and under whose laws it sits are not abstract concerns for a compliance binder. They shape what happens when a regulator asks a question, when a cloud region has an outage, or when a hospital in Pune wants to be certain its records are not sitting in a data centre three continents away. ## What "residency" actually means Data residency is the answer to a deceptively simple question: in which country do the bytes rest when nobody is looking at them? It is easy to confuse with two neighbours. Data sovereignty is the legal reality that whichever jurisdiction hosts the data can, in principle, compel access to it. Data localisation is a rule that says certain records must not leave a defined boundary at all. A hospital can be perfectly happy with residency in Mumbai while still being exposed if the management console, the backups, or the support team quietly sit elsewhere. The honest version of the story includes the parts that are easy to forget: - Primary storage: the OPD note, the IPD chart, the lab result. - Backups and snapshots, which often replicate to a second region for durability. - Search indexes and caches, which hold copies of the same clinical text. - Logs and telemetry, which can leak identifiers into a monitoring system abroad. - The imaging tier, where a single CT study is hundreds of DICOM instances that have to live somewhere too. If you only reason about the first line, you have described a fraction of where the data really is. ## Why Indian hospitals feel this sharply For a hospital operating in India, residency is not a philosophical preference. The Digital Personal Data Protection framework treats health information as sensitive and sets expectations about how it is handled and where it can be processed. Empanelling bodies, insurers and large corporate clients increasingly ask pointed questions in their onboarding forms. "Where is our data stored?" is now a line item, not a courtesy. > The safest answer to a residency question is one you can prove with an architecture diagram, not one you assert in a sales call. There is also the practical matter of latency and continuity. A radiologist scrubbing through a study over DICOMweb does not want frames arriving from a far region. A registration desk booking an OPD slot at 9 a.m. rush does not want a round trip across an ocean for every keystroke. Keeping the hot path close to the users is both a compliance posture and a performance one. ## How Kōami thinks about it Across the Kōami ecosystem - the HMIS, the HRMS, the inventory and imaging modules - the design principle is that a hospital should be able to name its region and trust that the whole footprint honours it. That means the transactional database, the object storage holding scanned documents, the PACS tier holding DICOM, and the daily backups all resolve to the same declared boundary rather than drifting to wherever a default happened to point. A few capabilities make that real rather than aspirational: - Region pinning at the tenant level, so a hospital's records are provisioned into a chosen geography from day one. - Encryption of data at rest and in transit, so that residency is paired with confidentiality rather than standing alone. - Segregation of tenants, so one hospital's data is never commingled with another's in a way that makes residency claims meaningless. - Access logging that records who read what, which turns "we keep it safe" into something you can actually audit. None of this is a certification claim. Kōami is young, and it would be dishonest to wave a badge we have not earned. What we can do is describe the controls plainly and let a hospital's own security team verify them. ## The questions to ask any vendor If you take one thing from this piece, let it be a short interrogation to run on every clinical software vendor, including us: - Where does primary storage sit, by region and provider? - Do backups and disaster-recovery copies stay in that same region, or cross a border for durability? - Who, on the vendor side, can technically access production data, and is that access logged? - When you delete a record, how long do copies persist in snapshots and logs? - If you had to exit the contract, in what format and from which region do you get your data back? The answers separate vendors who have thought about this from vendors who will improvise when the regulator calls. A vague or shifting answer to the backup question in particular is a reliable tell. ## Residency is a promise, not a setting It is tempting to treat residency as a checkbox flipped once during setup. In practice it is a promise that has to survive every future decision: the new analytics feature that ships logs somewhere convenient, the support engineer who pulls a copy to debug, the cost optimisation that moves cold storage to a cheaper region. A residency guarantee is only as strong as the discipline behind the least glamorous parts of the system. For a hospital, the goal is not to become an infrastructure expert. It is to ask the right five questions and to work with software that answers them the same way twice. Patient trust is built quietly, in places patients never see. Knowing where their data lives, and being able to say so with confidence, is one of those quiet foundations worth getting right.

Read article
Making MFA Painless for Busy Wards — Data Security | KōamiData Security
Data Security· 5 min read

Making MFA Painless for Busy Wards

Security teams love multi-factor authentication and wards quietly hate it, and both are right. MFA genuinely stops the most common way accounts get compromised, a stolen or guessed password, from being enough on its own. It is also, in its clumsier forms, exactly the kind of friction that makes a nurse with a deteriorating patient reach for a shared login instead. The whole challenge is not whether to use MFA on clinical systems. It is how to make it fast enough that nobody has a reason to route around it. ## Why a password alone stopped being enough Passwords fail in predictable ways. They get reused across systems, so a leak somewhere else becomes a way into the EMR. They get written on notes stuck to monitors. They get phished. On a busy ward they get shared, which means they are not really secret at all. A single factor, something you know, is a thin defence for data this sensitive, because knowing is easy to steal. MFA adds a second, different kind of factor, something you have or something you are, so that a stolen password is not a stolen account. The attacker who phished the credential still cannot log in without the second factor. That is the entire value, and it is substantial: it neutralises the most common attack against the most sensitive data in the hospital. - Something you know: the password, which alone is too easy to compromise - Something you have: a device, a token, a passkey on a phone - Something you are: a fingerprint or face, fast and hard to lend to a colleague ## The friction is the whole problem Here is the uncomfortable truth. If MFA takes too long or interrupts too often, clinicians will defeat it, not out of malice but out of clinical necessity. A prompt that fires every few minutes, or demands a code typed from a separate device while the clinician's hands are gloved and busy, does not make the ward more secure. It makes the ward invent a workaround, and the workaround, usually a shared always-on session, is far less secure than the password MFA was meant to strengthen. So the design goal is specific: authentication strong enough to stop stolen credentials, light enough that the safe path is also the fast path. That means paying attention to the moments where friction actually bites. - The first login of a shift, which should be quick even if it is the most secure step - Returning to a workstation after stepping away, where a full re-login is overkill - Shared ward devices, where the challenge is switching users fast, not proving identity slowly - Gloved or sterile contexts, where typing a code from a phone is simply not going to happen > An MFA scheme that clinicians route around has negative value; it created friction and bought no security. ## What painless actually looks like Painless MFA is not weaker MFA. It is MFA that fits the shape of clinical work. Several design choices make the difference between adoption and revolt. Fast factors first. A tap on a registered device or a fingerprint is far more ward-friendly than reading a six-digit code off one screen and typing it into another. Push approvals and passkeys give strong security with a single gesture. The less the clinician has to type, the more likely the control survives contact with a real shift. Risk-based prompting. Not every action needs the same challenge. A first login of the day on a new device deserves full verification. Continuing an active session on the same trusted workstation does not need to be interrupted every few minutes. Prompting harder when the context is unusual, and staying quiet when it is routine, concentrates the friction where it earns its keep. Sensible sessions. On shared ward devices the real need is fast user switching: one clinician steps away, the next authenticates in seconds and the session is unambiguously theirs. Sessions that stay open during active use but time out when a device is abandoned protect the record without forcing constant re-entry. This is also what finally kills the shared login, because individual access is now quick enough that the shortcut offers nothing. Kōami supports multi-factor authentication designed for this reality, favouring fast factors and session handling that suits a ward, so that strong authentication does not come at the price of a workaround. ## Rolling it out without a revolt Even good MFA fails if it is dropped on a ward as a mandate with no groundwork. The rollouts that stick share a pattern. They enrol staff in advance, so nobody is registering a device for the first time while a patient waits. They pilot on one ward, learn where the friction actually lands, and fix it before scaling. They provide a fallback for the genuine edge case, the lost phone, without making the fallback so easy that it becomes the default. And they explain the why in terms clinicians care about, which is not compliance but the fact that this is what stops someone else logging in as you and touching your patients' records. The measure of success is quiet. If MFA is working, clinicians stop noticing it, shared logins fade because individual access is no longer slower, and the security team stops seeing the account compromises that a single password used to allow. Nobody thanks a login screen, and they should not have to. The best outcome is that strong authentication simply becomes the unremarkable way the day starts, fast enough to disappear into the routine, strong enough that the one attack it was built to stop no longer works.

Read article
What a Good Audit Log Actually Records — Data Security | KōamiData Security
Data Security· 5 min read

What a Good Audit Log Actually Records

An audit log is one of those features everyone assumes they have until the moment they need it. Then someone asks a specific question, who opened this patient's record last Tuesday, and the honest answer turns out to be we are not sure. A good audit trail is not a box ticked for a policy document. It is a truthful, detailed, tamper-resistant account of what happened in the system, built so that months later it can answer a question nobody thought to ask at the time. ## The question an audit log has to answer Every audit log exists to answer one shape of question: who did what, to which record, when, and from where. That sounds obvious, yet plenty of systems log something far weaker, a vague note that a record was viewed, with no reliable link to a person or a time you can trust. When the question is real, for instance a patient asking who has seen their data or an investigation into a suspected inappropriate access, the vague log is worthless. A useful entry pins down the specifics. For a single access to a patient record it should capture, at minimum: - The individual who performed the action, tied to their own account - The exact action: viewed, created, edited, printed, exported, deleted - The specific record or field affected, identified by UMR or equivalent - The timestamp, precise and from a trusted clock - The context: the device or location, and the session it belonged to Notice the dependence on individual identity. This is where shared logins quietly poison the whole thing. If several people use one account, every line in the log names that account and none of them names a person. The audit trail is only ever as good as the identities underneath it, which is why individual accounts are a precondition for meaningful auditing, not a separate concern. ## Reads matter as much as writes Many systems dutifully log changes, a record was edited, a result was entered, and ignore reads. That is a serious gap in healthcare, because inappropriate access is usually about looking, not changing. The curious member of staff opening a colleague's record, or a public figure's, does not alter anything. They read. If the log only records writes, that access is invisible. So a healthcare audit log has to treat viewing as an auditable event. Opening a record is an action worth recording, because the ability to say who has looked at this patient's data is exactly what patients and regulators expect. This is the kind of access tracking that workflows such as NABH lean on, and it is meaningless if reads go unlogged. > If your audit log only shows what changed, it is blind to the most common form of misuse, which is simply looking. ## A log you cannot trust is not a log An audit trail is only evidence if it cannot be quietly altered by the people it might implicate. If a user with enough access can edit or delete log entries, then the log proves nothing, because any incriminating line could have been removed. The integrity of the log is as important as its content. That leads to a few design properties that separate a real audit trail from a decorative one. - Append-only: entries are added, never edited or overwritten in place - Separated from user control: no ordinary clinical or admin role can alter the log - Retained for a defined period, long enough to be useful when a question arrives late - Time-trustworthy: timestamps come from a reliable source, not an editable local clock - Complete: security-relevant events are captured consistently, not selectively Kōami records access and changes to patient data in an audit log built on these principles, so that the record of what happened is itself protected from casual tampering. The aim is simple to state: when someone finally asks the awkward question, the answer should come from a log that no one had the chance to tidy up first. ## Logs are only useful if someone can read them A perfect log that nobody can search is a filing cabinet nailed shut. The value of the trail is realised only when a person with the right authority can actually interrogate it: show me every access to this UMR in the last month, show me everything this user did on this date, show me who exported data last week. If answering those takes a database engineer and three days, the log will not be used, and unused controls decay. So the trail needs to be queryable by the people responsible for oversight, with access to the log itself controlled and, ideally, itself audited. There is a neat recursion here: looking at the audit log is an action, and a mature system logs that too, because the people who can see everything are exactly the people whose access most deserves a record. Reviewing the log should be routine, not a thing that only happens after a crisis, because regular review is what turns a passive record into an actual deterrent. ## What good looks like in practice Put it together and a good audit log has a recognisable character. It names people, not shared accounts. It records reads as well as writes. It cannot be quietly edited by those it might expose. It keeps entries long enough to matter and stamps them with a time you can trust. And it can be searched by the right people quickly enough that it actually gets used. None of these on their own is exotic. The failures come from missing one, a log that captures changes but not views, or names accounts but not individuals, or holds rich detail that any admin can rewrite. The test of an audit trail is never how it looks in a demo. It is the moment, maybe a year later, when a specific and uncomfortable question arrives and the log has to answer it plainly and completely. Build it for that moment, and it will serve every quieter purpose along the way. Build it for the policy checkbox, and it will fail you at exactly the moment it was supposed to help.

Read article
Why Role-Based Access Beats Shared Logins — Data Security | KōamiData Security
Data Security· 5 min read

Why Role-Based Access Beats Shared Logins

Walk into a busy ward and you will often find a workstation logged in under a generic account, left open so whoever needs it can chart quickly. It is understandable. It is also the single habit that undoes almost every other security control a hospital has. The moment several people share one login, the record can no longer tell you who did anything. Role-based access exists to make the fast, safe path and the traceable path the same path, so nobody has a reason to reach for the shared account again. ## What a shared login actually costs A shared account feels efficient. In reality it quietly disables the things that protect both patients and staff. When five nurses use one login, the audit log records five people's work under one name, which means it records nothing useful. If a record is accessed inappropriately, there is no way to know who did it. If a medication is charted in error, the trail leads to an account, not a person. The clinician who did everything correctly is now indistinguishable from the one who did not. The costs stack up quickly. - Accountability disappears, because every action traces to a shared name - Access cannot be scoped, so the shared account tends to accumulate broad permissions - Offboarding breaks, because you cannot remove one person from a shared credential without disrupting everyone - Passwords get written down and rarely changed, because rotating them means retraining a whole ward - Investigations stall, because the log cannot answer the one question that matters: who None of this means the staff are careless. It means the system offered them a shortcut that was faster than doing it right, and people under pressure take the faster path. The fix is not a lecture about compliance. It is making individual access fast enough that the shortcut loses its appeal. ## Roles map to how a hospital actually works Role-based access control, RBAC, starts from a simple observation: a hospital is already organised by role. A ward nurse, a consultant, an OPD receptionist, a pharmacist, a lab technician, a billing clerk. Each needs a different slice of the system, and those slices are stable. A nurse needs the observation charts and medication administration for their ward. A billing clerk needs the financial and demographic data but has no business reading clinical notes in depth. RBAC formalises this. Instead of granting permissions to individuals one by one, you define roles with the access that role requires, and assign people to roles. When someone joins, they get a role and the correct access follows automatically. When they move from the ward to theatre, you change their role and their access changes with it. The permissions live with the role, and the person simply inherits them. > Access should follow the job, not the person, and certainly not a password stuck to a monitor. ## Least privilege is the discipline that keeps it honest Defining roles is the easy part. The discipline that gives RBAC its value is least privilege: each role gets the minimum access it needs to do the work, and no more. It is tempting to grant generously, because broad access means fewer requests and fewer complaints. That generosity is exactly how a compromised account or a curious insider ends up with reach across the whole hospital. Least privilege applied properly looks like this. - Each role is scoped to the data and actions its work genuinely requires - Access is reviewed periodically, not granted once and left forever - Elevated access is deliberate and time-limited rather than permanent by default - Access is removed promptly when someone changes role or leaves - Sensitive categories get tighter scoping, so not every clinical user can open every record The point is not to make clinicians' lives harder. A nurse should never notice least privilege on a normal day, because their role already contains everything their job needs. They notice it only at the edges, when the system declines to show them something outside their remit, which is precisely the moment you want a boundary. ## Individual identity makes everything else work Here is the part that ties it together. Almost every other security control depends on knowing who is acting. Audit logs are meaningful only if each action maps to a person. Multi-factor authentication protects an account only if that account belongs to one individual. Least privilege can only be scoped if the system knows which person, in which role, is logged in. Shared logins knock the foundation out from under all of it. That is why Kōami is built around individual accounts with role-based permissions rather than shared credentials. Each person authenticates as themselves, carries the access their role defines, and leaves a trail under their own name. The convenience that once drove people to shared logins, fast access on a busy ward, comes instead from quick individual sign-in and sensible session handling, so the safe path is also the fast one. ## Making the transition realistic Moving a ward off shared logins fails when it is imposed as a rule without removing the friction that created the workaround. The transition works when individual login is genuinely quick: fast authentication, sessions that do not force constant re-entry during active use but time out when a device is abandoned, and roles pre-built so nobody waits days for access. Get that right and staff stop resenting the change, because the new way is not slower, it is simply attributable. Role-based access with least privilege is not a security feature you bolt on. It is the model that lets every other protection mean something. It gives each action an owner, keeps each person's reach matched to their job, and turns the record from a shared blur into an honest account of who did what. The shared login was never really about convenience. It was about the system not making individual access easy enough. Fix that, and the shared login has nothing left to offer.

Read article
Securing Patient Data in Cloud-Based EMR Systems — Data Security | KōamiData Security
Data Security· 5 min read

Securing Patient Data in Cloud-Based EMR Systems

Moving an EMR to the cloud does not make patient data more or less secure by itself. It changes where the risks live and who is responsible for which layer of the defence. A hospital that treats the cloud as someone else's problem is exposed; a hospital that understands the split, and builds on top of a platform designed for it, ends up with protections that an on-premise server room rarely matched. The security of patient data in a cloud EMR is not a product you buy. It is a set of controls you configure, operate, and check. ## The shared responsibility line The first thing to get straight is who does what. A cloud platform secures the physical infrastructure, the data centres, the hypervisor, the base network. That is real and valuable, but it is not the whole job. The application layer, the access controls, the way data is handled inside the system, the discipline of who can see which record: those sit with the software and the hospital that runs it. Confusing the two is how breaches happen. The infrastructure was never the weak point; the misconfigured access was. So the useful question is not is the cloud secure but is the whole stack secure, from the data centre up through the application to the clinician logging in on a ward tablet. Each layer needs its own controls, and they have to fit together. - Infrastructure: the physical and network security of the hosting platform - Platform: encryption, key management, network isolation, backups - Application: authentication, role-based access, audit logging, session handling - Operational: the hospital's own policies on who gets access and how it is reviewed ## Encryption in transit and at rest Encryption is the baseline, and it has to cover data both while it moves and while it sits still. In transit means every connection between a clinician's device and the system is encrypted, so a UMR travelling across the network cannot be read by anything sitting in the middle. At rest means the stored data, including the database and any backups, is encrypted so that a stolen disk or a copied backup file is useless without the keys. The keys are the part people forget. Encryption is only as good as the management of the keys that unlock it. That means keys held separately from the data they protect, rotated on a schedule, and never sitting in plain text in a config file or a code repository. Kōami encrypts patient data both in transit and at rest, and treats key handling as a distinct discipline rather than an afterthought, because encryption with careless keys is theatre. > The database being encrypted means nothing if the key is in the same place, readable by the same account. ## Access is where most breaches actually happen Ask where health data actually leaks and the answer is rarely broken cryptography. It is access. An account with more reach than it needed, a shared login nobody can trace, a leaver whose credentials still worked, an internal user browsing records they had no business opening. The strongest encryption in the world does not help when the person reading the record is authenticated and simply should not be. So the controls that matter most day to day are the boring ones. - Role-based access, so a clinician sees what their role requires and not the whole hospital - The principle of least privilege applied and reviewed, not granted once and forgotten - Multi-factor authentication, so a stolen password is not enough on its own - Prompt de-provisioning when someone changes role or leaves - Session controls that time out abandoned logins on shared ward devices These are capabilities Kōami provides and the hospital operates. The platform can enforce role-based access and MFA; it is the organisation that decides who gets which role and reviews those decisions. That division is not a gap; it is how it should work. The software makes the right thing possible and the wrong thing hard, and the hospital's governance does the rest. ## Proving it after the fact Prevention is only half of data protection. The other half is being able to reconstruct what happened, because sooner or later someone will ask who accessed a particular record and when. A cloud EMR should log access to patient data comprehensively: who opened which record, from where, and when, retained long enough to be useful for review. This audit capability does double duty. It deters casual snooping, because staff know that access to a record leaves a trace. And it is the mechanism by which a hospital investigates a concern, whether that is a suspected inappropriate access or simply a routine check that access patterns look reasonable. Aligned with the kind of access-tracking that workflows such as NABH expect, comprehensive logging turns security from a promise into something you can actually examine. ## A word on certification, honestly It is worth being plain here. A new platform can build strong technical controls, encryption, role-based access, MFA, comprehensive audit logging, from day one. What it cannot honestly claim on day one is a shelf of external certifications, and any vendor waving certification badges before they are earned should make you cautious. The right questions to ask a cloud EMR are about capabilities you can inspect: how is data encrypted, how are keys managed, how is access controlled and reviewed, what exactly is logged, and who on our side holds which responsibility. Security in a cloud EMR is not a status you reach and stop thinking about. It is the ongoing operation of a set of controls that span the platform and the hospital, checked and adjusted as roles change and threats evolve. The encryption keeps the data unreadable to outsiders. The access controls keep it readable only to the right insiders. The audit log lets you prove both. Get those three working together, and the cloud becomes not a risk to patient data but one of the better places to protect it.

Read article
Catching Sepsis Earlier with Trend Signals — Clinical AI | KōamiClinical AI
Clinical AI· 5 min read

Catching Sepsis Earlier with Trend Signals

Sepsis rarely announces itself. By the time it is obvious, with a crashing blood pressure and a patient who looks unwell to anyone walking past, the easy window has already closed. The difficult truth of sepsis is that the early hours, when treatment does the most good, are also the hours when the signs are subtle and scattered across a chart nobody is reading as a whole. Early warning is not about spotting the dramatic moment. It is about noticing the drift before it becomes a fall. ## The signal is in the trend, not the snapshot A single set of observations can look reassuring while a patient is quietly heading in the wrong direction. A heart rate of 96 is unremarkable. A heart rate that has climbed from 72 to 96 over six hours, alongside a respiratory rate creeping up and a temperature that will not settle, is a different story entirely. The individual numbers stay inside their normal ranges right up until they do not, and a clinician glancing at the latest vitals sees nothing wrong. This is why trend beats snapshot. The information that matters is the direction and the rate of change, read across several parameters at once. Humans are not built to do this well across a busy ward. We anchor on the most recent reading, we compare it loosely to some remembered baseline, and we move on to the next of twenty patients. A model does not tire of watching the slope. - Rising heart rate over hours, even within the normal band - Respiratory rate climbing, often the earliest and most ignored sign - Temperature instability, high or unexpectedly low - Blood pressure trending down from the patient's own baseline - Falling urine output and rising lactate where available ## From MEWS to a moving picture Most wards already run an early-warning score such as MEWS, and it is genuinely useful. It turns scattered vitals into a single number that triggers an escalation. But a periodic score is a series of snapshots. It fires when the patient has already crossed a threshold, and it does not see the six hours of drift that led there. It is a smoke alarm, not a thermostat. A trend-based warning layer sits underneath the score and watches the movement between calculations. It combines the observation stream with what else the record knows: recent surgery, an existing infection, immunosuppression, the results that came back from the lab an hour ago. The result is not a replacement for MEWS but a sharpening of it. Where the score says this patient is now unwell, the trend layer can say this patient is becoming unwell, and here is why. > Sepsis care is a race against a clock that started before anyone noticed. ## Why the alert has to be quiet and specific Every clinician has been trained by bad alarms to ignore alarms. A sepsis warning that fires too often, or fires on patients who are obviously fine, will be muted within a week and rightly so. Alert fatigue is not a minor usability issue; it is the single most common reason these systems fail in the real world. The design constraint is brutal: the warning must be right often enough that people keep listening. That means a few things in practice. - The alert names the reason: which parameters are trending and over what period - It fires early enough to matter but not so early that it cries wolf - It routes to someone who can act, not to a screen nobody watches - It supports escalation rather than replacing clinical judgement about it - It can be acknowledged and its outcome recorded, so the system can be tuned Because Kōami's early-warning layer reads the same observation and result streams that the rest of the record already captures, the clinician does not enter anything twice. The vitals charted at the bedside feed the trend analysis directly, and the warning appears where the ward already looks rather than in a separate application. ## The clinician still owns the decision A trend warning is a prompt, not a diagnosis. It says: look at this patient now, and consider whether the sepsis pathway applies. It does not order antibiotics, it does not diagnose the source, and it does not override the judgement of the person at the bedside who can see things no model can, such as how the patient actually looks and what the family is reporting. This matters for adoption as much as for safety. Clinicians accept a tool that hands them a well-reasoned prompt and leaves the decision with them. They reject a tool that presumes to make the call. The correct division of labour is the one that already works in good clinical practice: the system watches tirelessly and flags the drift; the human assesses, decides, and acts. Every alert and its outcome are logged, so the ward can review its false alarms, tighten its thresholds, and see whether the tool is actually shortening the time to treatment. The reward for getting this right is measured in hours saved at the front of a sepsis course, and those hours are the ones that change outcomes. Catching the drift at hour three instead of the fall at hour eight means antibiotics sooner, fluids sooner, and a senior review while the patient is still recoverable with less. No model catches every case, and none should be trusted to. But a tireless watcher on the slope of the numbers, handing a specific and timely prompt to a clinician who can act, turns some of those late falls back into early catches. In sepsis, that is the whole game.

Read article
Cutting Clinician Typing with Ambient Notes — Clinical AI | KōamiClinical AI
Clinical AI· 5 min read

Cutting Clinician Typing with Ambient Notes

Ask any clinician what they like least about their day and the answer is rarely a patient. It is the notes. The consultation that took twelve minutes generates twenty minutes of typing, and the typing does not happen between patients; it piles up and gets finished late in the evening, from home, long after the details have started to blur. Ambient documentation aims at this directly. It listens to the encounter, drafts the note, and hands the clinician back the minutes that used to disappear into the keyboard. ## The documentation burden is a clinical problem, not an admin one It is tempting to file paperwork under administration and move on. But documentation debt has clinical consequences. A note written six hours after the consultation is less accurate than one written during it. Details soften, exact figures get approximated, the specific phrasing a patient used gets lost. Worse, the sheer volume drives clinicians to shortcuts: cloned notes, copy-forward errors, templates padded with text nobody read. The record fills up while actually containing less. There is a human cost layered on top. Time spent typing is time not spent looking at the patient, and it is time stolen from rest at the end of a shift. The burnout literature keeps returning to documentation load as a driver, and any OPD clinician running a full clinic recognises why. - Notes written long after the encounter drift from what actually happened - Copy-forward and cloned text bloat the record and hide real change - Screen-facing data entry pulls attention away from the patient in the room - After-hours charting eats into recovery and fuels burnout ## What ambient capture actually does Ambient documentation uses the audio of a normal consultation, with the patient's knowledge and consent, and drafts a structured note from it. The clinician talks to the patient the way they always would. In the background the system distinguishes the clinical conversation from small talk, pulls out the history, examination findings, and plan, and lays them into the note structure the department already uses. The important word is draft. What lands in the EMR is a starting point, not a finished record. The clinician reads it, corrects it, adds the reasoning that was in their head but never spoken aloud, and signs it. That review step is not a weakness of the approach; it is the whole safety model. The human who saw the patient is the one who commits the note. > The goal is not a note written by a machine. It is a note the clinician can finish in two minutes instead of twenty. ## Fitting the note into a real record A drafted paragraph of prose is only half the job. A clinical note has to slot into the actual record: the right patient under the right UMR, the correct OPD or IPD encounter, coded where coding is needed, with medications and follow-up landing in the fields the rest of the system reads. Ambient text that sits in a free-text blob helps the writer and nobody else. This is where being part of the wider clinical system matters more than the transcription quality. Because Kōami's ambient layer writes into the same EMR that holds the patient's history, the draft can be checked against what is already known: the allergy the patient forgot to mention, the medication they are already on, the result that came back this morning. The note is not composed in isolation; it is composed against the record. A follow-up mentioned out loud can become an actual OPD appointment. A drug named in conversation can be reconciled against the current list rather than retyped blind. ## Keeping the record trustworthy Handing note-writing to a model raises fair questions, and they deserve concrete answers rather than reassurance. - The clinician reviews and signs every note; nothing enters the record unread - The draft is clearly marked as draft until a named clinician commits it - The audio is handled as sensitive patient data, encrypted and access-controlled like the rest of the record - What was captured, what was drafted, and who signed it are all logged, so the note has a clear provenance - The clinician can always write or dictate manually; ambient capture is an option, not a mandate The failure to avoid is a plausible-sounding note that quietly invents detail. Language models can produce fluent text that was never said. The defence is the review step and the discipline of checking the draft against the structured record, not trusting the prose on its own. A clinician who treats the draft as a colleague's rough notes, to be verified before signing, gets the benefit without the risk. ## Measuring whether it actually helps The promise is easy to state and worth checking honestly. Does documentation time per encounter fall? Do clinicians finish their notes before they leave rather than at home? Does the record get more specific, or just longer? A tool that produces beautiful prose but still needs heavy rewriting has not solved the problem; it has moved it. The encounters where ambient capture helps most are the conversational ones: a complex history in OPD, a discharge discussion, a consultation where the clinician would otherwise be typing while the patient talks. It helps least where the work is procedural and the data structured, and that is fine. The aim is not to automate every note. It is to take the heaviest, most narrative documentation and make it fast enough that it gets done in the room, while the details are still fresh and the patient is still there to correct them. Ambient notes will not, and should not, remove the clinician from the record. What they remove is the tax that turned a twelve-minute consultation into a thirty-minute one. Give a clinician back those minutes across a full clinic and you have not just saved time; you have moved their attention back to where it belongs, which is the person sitting across the desk.

Read article
AI Findings as a Second Reader, Not a Replacement — Clinical AI | KōamiClinical AI
Clinical AI· 5 min read

AI Findings as a Second Reader, Not a Replacement

There is a version of clinical AI that promises to read the scan for you. It is the version that makes radiologists nervous, and they are right to be. A more honest and more useful framing has been sitting in radiology practice for decades: the second reader. A second pair of eyes on the same study, catching the thing the first reader's attention slid past at the end of a long list. AI is very good at being that second reader, and it is a poor and dangerous substitute for the first. ## What a second reader actually does Double reading is not a new idea. Screening programmes have long used two independent readers precisely because a single human, however skilled, misses things. Fatigue, satisfaction of search, the subtle nodule at the edge of the lung field on the two hundredth chest study of the day. A second reader does not have to be smarter than the first. It only has to be tired at a different time and biased in a different direction. That is the role AI fits naturally. It never gets bored on the night shift. It looks at every part of every image with the same consistency. It has no memory of the last case colouring its read of this one. Those are exactly the failure modes that catch human readers, which is why pairing the two covers more ground than either alone. - The human brings context, clinical history, and judgement about what matters for this patient - The model brings consistency, tirelessness, and pixel-level attention across the whole image - Together they catch both the subtle finding and the finding that only makes sense in context ## Second reader, not replacement, and the difference is not semantic The distinction sounds like marketing caution, but it reflects how the workflow is actually built. In a replacement model, the AI reads and the human rubber-stamps, and the human's attention quietly decays because they assume the machine has already done the work. That is the worst of both worlds: automation bias on top of a model that will, sometimes, be confidently wrong. In a second-reader model, the human reads first and forms their own impression before seeing the AI's findings. The order matters. The clinician commits to a read, then the model's marks appear as prompts to reconsider, not as answers to accept. A flagged region asks a question: did you look here, and are you sure? The radiologist can dismiss it, and dismissing it is a normal part of the workflow, not an override that fights the system. > The AI is allowed to be wrong, because a named clinician still owns the report. ## Where the extra pair of eyes pays off The findings AI second reading helps with most are the ones humans miss for predictable reasons. - Small pulmonary nodules that hide against vessels or at the lung apices - Subtle fractures on trauma films read quickly under pressure - Findings incidental to the clinical question, which attention naturally skips over - The second abnormality, once the eye has locked onto the obvious first one - Interval change on follow-up imaging, where side-by-side comparison is tedious and easy to shortcut Notice what is not on that list. The model is not there to make the primary diagnosis on a complex case, weigh competing possibilities, or decide what a finding means for this particular patient. It is there to make sure nothing was skipped. The radiologist still reads through DICOM on PACS the way they always have; the second-reader marks simply overlay on the same study, sourced through WADO, so there is no separate tool to open and no images to shuffle between systems. ## Designing so it helps instead of nagging A second reader that flags everything trains people to ignore it. The failure mode is alert fatigue, and it kills these tools. So the design has to respect the radiologist's time and attention as the scarce resource it is. Flags should be specific, few, and confident enough to be worth a second look. The interface should let a reader accept or dismiss a mark in one motion, and it should never block sign-off waiting for the human to acknowledge every suggestion. Just as important, every interaction leaves a trail. When a radiologist dismisses a flag, that decision is recorded, not to police the clinician but to let the department study the model's behaviour over time. Which flags get dismissed constantly? Those thresholds need tuning. Which dismissed flags later turned out to matter? That is the review that makes the system safer. In Kōami's imaging workflow the marks, the confidence, and the reader's response all sit in the audit log, so accountability and quality review draw on the same record. ## Keeping the line of accountability clean The single most important property of a second-reader system is that it never blurs who is responsible. The report carries a radiologist's name. The AI's marks are inputs to that person's judgement, exactly like a prior study or a clinical note, and they carry no authority of their own. If the model misses something, the human is still reading. If the model flags something wrong, the human dismisses it. At no point does the machine get to be the reason a mistake reached the patient unchallenged. That clarity is what makes the second-reader model both safe and adoptable. Radiologists do not have to trust the AI to be right, because they are not relying on it to be right. They only have to accept that a tireless, consistent extra look, offered after they have formed their own view, catches things worth catching. Framed that way, AI stops being a threat to the profession and becomes what a good colleague has always been: someone who says, before you sign off, did you see this?

Read article
Triage That Reads the Worklist Before You Do — Clinical AI | KōamiClinical AI
Clinical AI· 5 min read

Triage That Reads the Worklist Before You Do

A radiology worklist at 8am is a wall of studies stacked in the order they arrived. The chest CT that will change someone's afternoon sits three rows below a routine follow-up that can safely wait until lunch. First-in-first-out is fair, but fairness and urgency are not the same thing. AI triage does something quietly powerful: it reads the worklist before the radiologist does, and reorders it so the study that matters most is the one waiting at the top. ## The worklist is not a queue, it is a risk pile Most PACS worklists are sorted by time, modality, or referring location. That is easy to build and easy to defend, but it assumes every study carries the same clinical weight. It does not. A non-contrast head CT flagged from the emergency department may hold a bleed that needs a call to the on-call team within minutes. The same list holds surveillance scans where a day's delay changes nothing. When these are interleaved by arrival time alone, the urgent study depends on luck: whoever happens to open it first. Triage models change the sorting key from when to how urgent. They pre-read incoming studies as they land on PACS and attach a priority signal, so the worklist reflects clinical risk rather than clock order. The radiologist still reads everything. They just read the frightening things first. ## Reading pixels and context together A useful triage layer does not look at the image alone. It combines the DICOM pixel data with the metadata and the request context that already travel with the study. - The image findings themselves, for example a suspected large-vessel occlusion or a pneumothorax - DICOM tags: modality, body part, contrast, and the referring source - The clinical question on the request, which separates a trauma scan from routine imaging - Where the order came from, since an ED or ICU origin carries different urgency than an OPD follow-up - Patient flags already in the EMR, such as a recent stroke pathway activation Pulling these together matters because pixels without context mislead. A small effusion is unremarkable in one patient and a red flag in another. When the triage layer in Kōami's imaging stack reads the study through WADO alongside the order details, the priority it assigns reflects the whole picture, not just the greyscale. > Triage does not tell the radiologist what to think. It tells them what to look at next. ## Sensitivity is the whole game For a triage tool, the costly error is the miss. If the model quietly downgrades a genuine emergency, it has actively caused harm by burying the study deeper in the list. So these systems are tuned to favour sensitivity: when unsure, escalate. That means accepting more false alarms in exchange for catching the true ones. The trade is only acceptable if false positives stay cheap. Escalating a study that turns out to be normal costs a few minutes of a radiologist's attention. Because the radiologist reads every study regardless, an over-cautious flag does not remove anyone from care; it only nudges the reading order. The design principle is simple to state and hard to violate: triage may reorder the worklist, but it must never remove a study from it or mark anything as safe to skip. ## Where it changes turnaround time The metric that improves most visibly is TAT, and specifically the tail of the distribution. Average turnaround can look fine while a handful of critical studies wait far too long because they landed behind a batch of routine imaging. Triage attacks that tail directly. Concretely, the workflow shifts in a few ways: - Critical studies surface at the top of the worklist within moments of hitting PACS - The on-call radiologist covering several sites sees the most urgent study across all of them, not just the newest at each - Overnight, when one person may cover a large volume, the ordering protects the cases that cannot wait for morning - Referring teams get faster answers on the studies where speed changes management The routine work still gets read, and gets read properly. It simply stops competing for pole position with the emergencies. Over a week, that is the difference between a stroke call going out in minutes and going out after a reader has ploughed through an unlucky backlog. ## Trust comes from being legible and auditable A radiologist will not hand their reading order to a system they cannot question. So the triage flag has to explain itself and has to leave a record. Each prioritised study should carry the reason it was escalated and the confidence behind it, and every reordering should be logged so a department can review, weeks later, whether the tool helped or hindered on a given case. That audit trail is not bureaucracy. It is how a department learns the model's blind spots, tunes its thresholds, and defends its workflow if a case is ever reviewed. It also keeps accountability where it belongs. The AI arranged the list; the radiologist made the diagnosis. Nothing about triage dilutes that line. Triage is one of the least glamorous applications of clinical AI and one of the most defensible. It does not diagnose, it does not replace anyone, and it does not ask the radiologist to trust a machine with a patient. It just makes sure that when a busy reader sits down to a full worklist, the study that could not wait is already the one in front of them.

Read article
AI-Driven Ward Scheduling & Optimal Care — Clinical AI | KōamiClinical AI
Clinical AI· 5 min read

AI-Driven Ward Scheduling & Optimal Care

Any charge nurse can tell you that a ward schedule looks tidy on paper and falls apart by 10am. A patient in bed 12 deteriorates, two admissions arrive from OPD at once, a senior resident gets pulled into theatre, and the careful staffing plan built the night before is suddenly wrong. Ward scheduling is not really a rostering problem. It is a live matching problem between the acuity of the patients in front of you and the skills, hands, and beds available right now. AI helps most when it treats it exactly that way. ## Scheduling is an acuity problem, not a headcount problem The old way of planning a shift counts people. Six nurses for thirty beds, tick, move on. It ignores the fact that three of those beds hold stable post-operative patients waiting for discharge while two hold unstable IPD cases who need hourly observations. A model that reads live signals from the EMR can weight the ward by workload rather than by bed count. The inputs that actually matter are already flowing through the system: - ADT events that tell you who was admitted, transferred, or discharged in the last hour - MEWS or early-warning scores trending up on specific patients - Nursing task load: due medications, dressing changes, drain checks, vitals frequency - Skill mix on the floor, including who is credentialed for high-dependency care - Pending OPD-to-IPD conversions and expected theatre returns When Kōami's scheduling layer combines these, the output is not a fixed roster. It is a ranked picture of where the pressure is building, so the nurse in charge can move one person from a settling bay to the bay that is about to get busy. ## Predicting the next four hours, not the next month Long-range rosters still matter for fairness and for leave planning. But the value of AI shows up in the short horizon. If admission patterns from the last several weeks show that Monday mornings bring a surge of post-weekend OPD referrals into IPD, the model can flag that surge before it lands, not after the beds are full. > The best schedule is the one that is already adjusting while the shift is still calm. A short-horizon forecast lets the ward do three practical things. It can hold a float nurse instead of releasing one early. It can sequence discharges so beds open before the predicted admissions arrive. And it can warn the bed manager that the ward will breach its safe ratio in about two hours unless something changes, which is a very different conversation from discovering the breach once it has happened. ## Keeping the human in charge of the roster Clinicians are right to be wary of a black box that reshuffles their day. A scheduling model earns trust by being legible. Every suggestion should carry its reason: this bay is flagged because two patients crossed a MEWS threshold and three medications are due within the hour. The charge nurse can accept, ignore, or override, and the override is data, not defiance. Over time those overrides teach the system where its assumptions are wrong. Good practice here mirrors safe clinical workflow. The AI proposes; a named human disposes. Assignments still respect the constraints that no algorithm should quietly break: statutory rest between shifts, credentialing rules, and continuity of care so a patient is not handed between four different nurses in one afternoon. When the tool respects those guardrails, staff stop treating it as an adversary and start treating it as an extra set of eyes on the whole floor. ## What optimal care actually looks like on the floor Optimal is a loaded word, so it helps to be concrete about the outcomes a scheduling model should move. - Fewer moments where a deteriorating patient waits because the nurse who noticed is tied up three beds away - Shorter gaps between a discharge decision and the bed being ready for the next admission - More even task loads, so one nurse is not carrying eight heavy patients while a colleague carries four light ones - Cleaner handovers, because the system already knows who held which patients and for how long None of this replaces judgement. A patient who looks stable on every number can still be the one the experienced nurse wants to sit closest to, and the schedule has to bend to that. The point is to remove the avoidable friction: the reshuffles that happen too late, the surges nobody saw coming, the quiet inequities in who carries the heaviest bay. ## Making it usable during a bad shift A scheduling tool that demands attention during a crisis is worse than useless. The interface has to survive the reality of a busy ward, where nobody has a spare hand to click through five screens. That means suggestions surface where staff already look, whether that is the ward board or the handover view, and it means the number of alerts stays low enough that people still read them. Integration is what makes this practical. Because the scheduling layer sits alongside the same records that drive admissions, orders, and observations, it does not ask anyone to enter data twice. The ADT feed updates the workload picture automatically. When a patient is discharged in the EMR, the bed frees in the schedule in the same moment. This tight coupling is the difference between a planning tool people use and a planning tool that gathers dust. Ward scheduling will never be fully solved, because the ward will never stop surprising you. What AI can do is shrink the window between a change on the floor and the response to it, so that the plan bends early instead of breaking late. Done well, it gives the charge nurse back the thing the job keeps stealing: a few minutes of warning.

Read article