The ABDM implementation blueprint.
A practical map of ABHA, HIP and HIU roles, consent artefacts and the integration milestones, and where the Healytix data layer fits.
Three roles to understand
Under the Ayushman Bharat Digital Mission, a patient is identified by an ABHA. A hospital that holds records acts as a Health Information Provider (HIP) when it shares them, and as a Health Information User (HIU) when it requests records held elsewhere. Exchange happens only against a consent artefact the patient approves through a consent manager.
The milestones
Integration is typically staged. The first milestone covers creating and verifying ABHA at registration. The second covers HIP functions: linking the patient's care contexts and sharing records when consent arrives. The third covers HIU functions: requesting consent and fetching and displaying records from other providers. Each is tested in the NHA sandbox before go-live.
Why the data layer decides the effort
ABDM exchanges FHIR R4 bundles that follow India-specific profiles. If a hospital's records are scattered across a HIS, a LIS and scanned PDFs, every bundle becomes a custom job. With a FHIR-native record such as Fabric, validated against the ABDM implementation guide, building a bundle is a query rather than a project.
Consent is a data structure, not a checkbox
Consent artefacts carry purpose, date range, record types and expiry. Storing them as first-class records, and checking them on every access, is also what India's DPDP Act expects of data fiduciaries.
Key takeaways
- 1Know which role you play in each exchange: HIP, HIU or both.
- 2Validate bundles against ABDM profiles before the sandbox does it for you.
- 3Model consent as data that every access checks.