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 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 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 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, and ask to see the failure paths before the happy one.