ABDM for hospitals: what joining the health stack actually requires
India's digital health mission is often described as a portal to register on. It is closer to a set of shared rails: a way for a patient to have one identity across providers, a directory of facilities and practitioners, and a consent mechanism through which records move between them.
2 min readOadbox
The four pieces
- A health account and identifier the patient owns, which links records across providers.
- A facility registry, where your hospital, clinic or lab is listed.
- A professional registry, where practitioners are verified and listed.
- A consent-driven exchange through which records are requested and shared.
A hospital participates by registering in the facility registry, linking records to patient identifiers, and integrating with the exchange to respond to consented requests.
Consent is the design constraint
Records do not move because a hospital decides to send them. They move because a patient has granted consent, for a defined purpose and a defined period, and that consent is verifiable.
This has a direct implication for record-keeping: your system must be able to produce a specific patient's records, for a specific period, on request, without a manual retrieval exercise.
Structure your records before you connect them
Scanned images of typed discharge summaries technically satisfy some requirements and defeat the purpose. The value of a shared record comes from it being structured — diagnoses, medications, investigations and their results as data rather than pixels.
Hospitals that digitise properly first find integration straightforward. Hospitals that connect a paper-based process find they have built a very modern way of sharing PDFs.
Registration is not the finish line
Being listed in the facility registry is a milestone, not compliance. The ongoing work is linking every patient to their identifier at registration, keeping practitioner records current, and responding to consent requests reliably.
The front desk carries most of that load, which brings this back to the same point as every other hospital process: the counter decides whether the rest of it works.
The mission's specifications, registries and integration requirements continue to develop. Work from current official documentation rather than a summary.
Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.