Becoming an ABDM Health Information Provider: the steps in the order they actually happen

Becoming an ABDM Health Information Provider is a short registration and a long data problem. The steps, in the order they actually happen in a hospital.

The question usually arrives from the board, not from IT. Someone has read that ABDM participation is now expected of a hospital your size, and you are asked how to become an ABDM Health Information Provider, what it costs, and when it will be done.

The short answer is that the registration is a sequence: register the facility, obtain sandbox access, demonstrate the data-exchange flows required for your facility type, then move to production enablement. The authoritative and current list of those steps sits with the National Health Authority, not with a vendor — the ABDM programme documentation and the ABDM FAQ are where to check it, and worth re-checking, because the requirements and facility categories have been revised more than once. Anything a software company tells you about the process is secondary to that.

That part takes weeks. The part that takes quarters is everything the registration quietly assumes you already have.

What being a Health Information Provider actually asks of you

Strip away the forms and the obligation is operational. To act as a Health Information Provider, a hospital has to be able to do four things on demand, for any patient, without a person assembling anything by hand:

• Resolve identity. The patient at the counter, the patient in the lab system and the patient in the ABHA record have to be the same person, provably.
• Assemble a record. Not a folder of scans — a structured record of an encounter, in a standard a system outside your hospital can read.
• Enforce consent. Sharing happens only against a consent artefact, with its scope and expiry honoured, and the decision has to be defensible months later.
• Serve it on request, inside the applicable window, without anyone walking to the records room.

None of those are forms. All four are properties of your data model.

Why hospitals stall at the third step

Because the record does not exist in one place. Billing holds one identity, the lab another, pharmacy a third, and the mapping between them lives in a spreadsheet maintained by one person in IT. The discharge summary is a document on a share drive. The consent the patient signed is paper in a cupboard, which means it cannot be queried, scoped or expired — only produced later, if someone can find it.

Each of those was a reasonable decision when it was made. Together they mean the hospital can store a record perfectly well and cannot hand one over. Middleware bridges the gap, and often does. The cost is that you then own a permanent integration layer whose only job is to make three systems pretend to be one, maintained forever, re-tested every time any of the three changes.

Storage is a project you finish. Retrieval is a capability you either have or you do not.

Four things worth doing before you talk to any vendor

• Map one encounter end to end. Take a real inpatient admission from last month and list every system holding a piece of it, and who owns the key that joins them. The length of that list is your real ABDM estimate.
• Move ABHA capture to the front desk. If creation and linking is a back-office cleanup task, you will reconcile identities forever. It belongs in registration, inside a conversation you already have with the patient.
• Write your consent flow as a state machine. Who asked, for what scope, when it expires, how it is withdrawn, where that is recorded. If you cannot draw it, you cannot automate it — and DPDP asks the same question ABDM does.
• Test retrieval, not storage. Ask your current vendor to produce a structured record for one named encounter, now, in a standard format. The answer, and how long it takes, tells you more than any readiness questionnaire.

Where Ospia fits

Ospia HOS is a hospital operating system rather than a management system with an interoperability module attached, and the difference shows up precisely here. ABDM and ABHA are listed as supported on our compliance page, where supported means implemented and demonstrable, and by design means the platform produces the required behaviour or evidence as a by-product of normal operation. Registration is ABHA-ready, and every use of personal data traces to recorded consent held in a consent ledger consulted before use.

On the wire: a FHIR R4 read surface covering Patient, Encounter, Condition, Observation, MedicationRequest and DiagnosticReport, gated behind a DPDP data-sharing consent check; an HL7 v2 ADT outbound feed emitting A04, A01, A02 and A03 on registration, admission, transfer and discharge, re-sendable from the message log; DICOM/PACS with DICOMweb retrieve and a viewer; and disease-surveillance submission to IHIP. Each hospital chooses residency — self-hosted on its own infrastructure, or managed cloud in-region. Ospia HOS runs hospitals in production today. For government hospitals, where ABDM participation and IHIP reporting arrive together, that matters more than it does anywhere else.

What we will not tell you is how many. Hospital names and counts are published only as each one completes hypercare and agrees to be named, which is why the case-study slots on our site are still visibly empty. We are also not ISO 27001 certified — it is a roadmap item — and no independent penetration test has been conducted yet; it is planned as a recurring engagement. If ABDM readiness is your decision criterion, read our five comparison guides against Epic, Oracle Health, Napier, MedMantra and Practo Ray, including the parts where they are stronger.

If you want the shorter path

Bring one encounter and one question — can this record be handed over — to an executive demonstration, and we will answer it against a live system rather than a slide. Nothing else about ABDM gets decided until that answer is yes.