ABDM and ABHA for hospitals: what to implement and what to defer

The Ayushman Bharat Digital Mission (ABDM) defines the national digital health infrastructure: ABHA IDs for patients, Health Information Provider (HIP) and User (HIU) roles for hospitals, consent-based data exchange, the Health Facility Registry (HFR) and the Health Professional Registry (HPR). Understanding what each piece actually does, and in what order a hospital should realistically implement them, matters more than treating ABDM as a single undifferentiated compliance requirement to check off.

For most tier-2/3 hospitals, the question is not "should we integrate" — PMJAY and CGHS empanelment are increasingly tied to ABDM participation. The question is "what do we implement now and what can wait?" Getting this sequencing right avoids two common failure modes: spending scarce implementation time on complex, lower-priority pieces first, or deferring even the low-effort, high-signal pieces out of a mistaken belief that all of ABDM is equally complex to implement.

Implement now: ABHA linkage at registration. This is a consent-gated field on the patient master. The patient provides their ABHA number, you verify it and store the link. No data exchange happens yet — you're just linking the ID. This is low-risk and high-signal for empanelment.

Implement now: HFR registration. Your hospital should be in the Health Facility Registry. This is a one-time process through the ABDM portal.

Implement now: HPR for doctors. Doctors should be registered in the Health Professional Registry with their NMC registration number.

Defer (but prepare): HIP consent-based data exchange. This requires sandbox clearance, integration testing and production onboarding. The payload format (FHIR R4 resources) should be ready in your ERP, but the live pipe can wait until the sandbox process completes.

Defer: HIU role (pulling data from other providers). This is operationally complex and most hospitals don't need it immediately.

OneCity's approach: ABHA linkage is built into patient registration. FHIR R4 payloads are generated and stored for discharge summaries, prescriptions and diagnostics. Live exchange enables after HIP onboarding — we don't claim it's live when it isn't.

What ABHA actually is: a 14-digit health ID a patient creates voluntarily, using either Aadhaar-based e-KYC or a mobile number with OTP verification. It's not issued by a hospital — the patient creates it themselves, through the ABHA app, a state health portal, or at a participating facility's help desk. A hospital's own UHID and a patient's ABHA number serve different purposes: the UHID is the hospital's internal record identifier, while ABHA is the patient's portable identity across every facility they visit, present or future. Linking the two at registration doesn't replace the UHID system — it adds a second identifier the patient can use to eventually pull their own records together across providers.

Patient consent runs through a Consent Manager, not directly between hospitals. A Consent Manager is a separate, licensed entity — typically a PHR app the patient has chosen — that sits between the patient and every Health Information Provider holding their records. When a doctor at Hospital B wants to view a patient's prior records from Hospital A, the request goes through the patient's Consent Manager, the patient approves or denies it, and only then does Hospital A release data to Hospital B. Neither hospital talks to the other directly, and neither can see records without a patient-approved consent artefact tied to that specific request. This is deliberate: it keeps the patient, not the hospital, as the actual gatekeeper of their own health data.

HIP and HIU are functional roles, not separate registrations. A Health Information Provider (HIP) is any entity that holds and can release a patient's health records — a hospital's own EMR system fills this role when a patient consents to share their data with another provider. A Health Information User (HIU) is any entity that requests and receives another provider's records — the same hospital fills this role when a doctor needs a patient's prior history from elsewhere. Most hospitals eventually need to act as both, since patients move between facilities in both directions, but there's no requirement to build both simultaneously. Acting as an HIP first — being ready to release your own records on request — is lower operational complexity than acting as an HIU, since releasing data on a specific, consented request is simpler than building the discovery and request-initiation flow needed to pull records from elsewhere.

The empanelment evidence is real, not speculative. State health agencies administering PMJAY have progressively tied empanelment renewal and package rate eligibility to ABDM-linked digital readiness, and CGHS empanelment reviews increasingly ask for the same. A hospital that treats ABHA linkage as a nice-to-have digital feature, rather than a practical empanelment requirement building momentum year over year, risks discovering the gap during a renewal cycle rather than addressing it proactively. This isn't a hard national mandate today for every hospital, but the direction of travel across every scheme touching government reimbursement has been consistently toward requiring it, not away from it.

FHIR R4 resources are the actual data format underneath all of this, and a handful of specific resource types matter most in practice. A DiagnosticReport resource carries lab and radiology results in structured form. A DocumentReference resource wraps a discharge summary or prescription as a shareable record. A MedicationRequest resource structures prescription data specifically. A Bundle resource packages multiple related resources — say, a full discharge summary with its associated diagnostic results — into one exchangeable unit. Getting these payloads generated correctly inside a hospital's own ERP, even before live exchange goes active, is the concrete technical work "implement now" actually means — the payload needs to exist and validate correctly against FHIR R4 schema before there's anything meaningful to exchange once HIP onboarding completes.

HFR and HPR deserve slightly more detail than "register once." The Health Facility Registry captures a hospital's own digital identity — bed count, services offered, systems of medicine practised — verified by state officials after self-declared submission. The Health Professional Registry does the same for individual doctors, verified against their National Medical Commission or state council registration. Both registries feed into the same ecosystem ABHA and consent-based exchange depend on: a patient's shared record needs to show which verified facility and which verified doctor generated it, not just that some hospital somewhere produced the data. A hospital that links ABHA at registration but never completes HFR registration has built half the required identity chain — the patient side works, the facility side doesn't.

Common integration mistakes are consistent across hospitals attempting this without a clear internal owner. The first is treating ABHA linkage as an optional field clerks skip when a patient doesn't have their number handy, rather than a standard part of the registration script every clerk is trained to offer. The second is confusing HFR and HPR registration with ABHA linkage entirely — these are three separate registrations covering three different entities (facility, professional, patient), and completing one doesn't imply progress on the others. The third is attempting HIP production onboarding before the sandbox testing phase is genuinely complete, which typically surfaces payload validation errors that would have been caught earlier with more thorough sandbox testing, delaying the actual production go-live further than a more patient testing phase would have.

Sandbox testing and production onboarding follow a specific sequence that's worth planning for realistically. A hospital's ERP vendor first registers in the ABDM sandbox environment, generating and validating FHIR R4 payloads against test scenarios without touching real patient data. Once payload generation is confirmed correct across the required resource types, the vendor applies for production credentials, a process that includes a security and compliance review by the National Health Authority. Only after production credentials are issued does live, patient-consented data exchange become possible. Skipping or rushing the sandbox phase to reach production faster typically backfires, since payload errors caught in production carry more weight in the review process than the same errors caught and fixed during sandbox testing.

OneCity's implementation covers this sequence directly. ABHA linkage is a standard field in the patient registration module, verified at the point of registration rather than added as an afterthought. FHIR R4 payloads — Bundle, DiagnosticReport, DocumentReference and MedicationRequest resources — are generated and stored for every discharge summary, prescription and diagnostic result as part of normal clinical documentation, independent of whether live HIP exchange is active yet. This means the moment a hospital's HIP onboarding completes, the payloads it needs to exchange already exist and have been validating correctly against real clinical documentation, rather than needing to be built retroactively once onboarding is approved. The ABDM national stack module ties HFR and HPR identifiers into the same record structure, so a shared document carries verified facility and professional identity by default. For the facility-registration side specifically, see our guide to Health Facility Registry registration, and for the professional side, our guide on why hospitals should mandate HPR IDs covers the credentialing angle in depth.

The Unified Health Interface (UHI) is a separate ABDM component worth knowing about even though it's not part of the "implement now" list for most hospitals. Where ABHA and consent-exchange handle a patient's health records, UHI standardises how patients discover and book services — appointments, teleconsultations, diagnostic tests — across participating platforms, similar in spirit to how UPI standardised payments across banks and apps. A hospital doesn't need to build anything for UHI today unless it's specifically integrating with a UHI-enabled booking platform, but the direction is the same as everything else in this guide: standardised, patient-controlled, government-backed digital infrastructure that hospitals will eventually need to plug into rather than build a proprietary alternative to. Treating UHI as entirely irrelevant because it's not urgent risks the same kind of late scramble that ungoverned ABHA adoption created for hospitals that waited — it's reasonable to defer active UHI integration, but worth tracking as part of the same broader digital-health direction the rest of this guide covers.

Where this fits alongside a hospital's broader digital-health picture: patient data shared through ABHA-linked exchange falls under the same DPDP Act 2023 consent obligations as any other patient record, meaning the consent captured through ABDM's own Consent Manager framework doesn't substitute for a hospital's separate DPDP-compliant consent practices — the two frameworks operate alongside each other, not as substitutes. For hospitals also pursuing NABH accreditation, digital health readiness including ABDM participation is increasingly part of what assessors expect to see as evidence of a hospital's overall quality and technology maturity, not a separate initiative disconnected from accreditation review. And for a hospital sequencing ABDM implementation alongside other technology priorities, our guide to realistic ERP implementation timelines covers how this kind of phased, multi-piece rollout typically fits into a broader go-live plan without becoming the single blocking item holding up everything else.

Multi-location hospital groups face the same per-facility registration reality here as with other ABDM-adjacent requirements. HFR registration is scoped to a specific facility, not a corporate entity — a group running five hospitals across three states needs five separate HFR registrations, each verified by that state's own officials, not one registration covering the whole group. HPR registration is per-professional, meaning a doctor who splits time across two of the group's hospitals still registers once as an individual, but each facility's own patient records need to correctly attribute that doctor's HPR-verified identity. A group treating this as a single centralised project risks assuming one location's completed registration implies progress everywhere, when in practice each site's registration status, sandbox testing, and production onboarding move on entirely independent timelines.

What to track on an ongoing basis, once initial implementation is done: ABHA linkage rate across new patient registrations, since a hospital that implements the field but doesn't train staff to consistently offer it ends up with a low linkage percentage despite having the technical capability in place. HFR and HPR registration status per facility and per doctor, particularly for hospital groups where new locations or new hires need the same registrations completed as existing ones. FHIR R4 payload validation status, confirming that discharge summaries, prescriptions and diagnostic reports continue generating correctly as the ERP itself gets updated over time, since a payload format that validated correctly at initial sandbox testing can silently break if a later software update changes how a specific field gets populated. And HIP onboarding status specifically, since production credentials and sandbox clearance are not indefinite — confirming current standing periodically avoids discovering a lapsed credential only when a genuine data-exchange request fails.

The broader pattern worth naming directly: ABDM readiness isn't a single project with a single completion date — it's five or six separate, ongoing pieces (ABHA linkage, HFR, HPR, FHIR R4 payload generation, HIP sandbox and production onboarding, eventually HIU if needed) that a hospital can implement in sequence, starting with the lowest-risk, highest-signal pieces first. Treating "we did ABDM" as a single checkbox, rather than tracking each piece's actual status independently, is the single most common reason a hospital believes it's further along than it actually is when a PMJAY or CGHS empanelment review asks for specific evidence.

A practical self-check before assuming ABDM readiness is further along than it is: confirm ABHA linkage is actually offered at every registration point, not just the main OPD desk — a hospital with multiple entry points (emergency, direct IPD admission, satellite clinics) sometimes implements the field at one location and forgets to extend the same workflow to the others. Confirm HFR registration shows as verified, not just submitted, since self-declared submission and state-verified status are different stages with a real gap between them. Confirm every doctor generating patient records has completed HPR registration, not just the doctors who were part of an initial rollout push. Confirm FHIR R4 payloads are actually validating correctly against current sandbox test scenarios, not just that they validated once during initial implementation months ago. And confirm someone specific owns tracking HIP sandbox and production credential status, rather than assuming the initial setup covers the hospital indefinitely without any ongoing check.