ABDM building blocks explained: ABHA, HFR, HPR, HIP, HIU and the consent manager

The short answer

The Ayushman Bharat Digital Mission (ABDM) is built around three core registries and three gateways. The registries say who the patient is (ABHA), who the professional is (HPR) and which facility it is (HFR). The gateways move health records with consent (HIE-CM), claims (NHCX) and service bookings (UHI). Hospitals that hold records act as Health Information Providers (HIPs); those that request them act as Health Information Users (HIUs).

The government launched ABDM in September 2021. A facility using ABDM-enabled software can create records linked to a patient’s ABHA, see the patient’s earlier records after taking consent, and exchange records through the patient’s revocable, time-bound consent.¹ By July 2026, the government said over 104 crore health records were linked to over 93 crore ABHA accounts.¹

This post is a map, not legal or integration advice. It sticks to what NHA and the Press Information Bureau publish.

The three registries

Each registry answers one identity question. Everything else in ABDM leans on them. The health ministry also lists a fourth, the Drug Registry.⁵

A practical consequence: the registries are how other parts of the network decide whom to trust. UHI, for example, authenticates patients with their ABHA credentials and verifies providers and facilities through HPR and HFR.¹

The three gateways

NHA describes the Health Information Exchange and Consent Manager (HIE-CM) as one of three digital gateways built under ABDM, the other two being the Unified Health Interface and the National Health Claims Exchange.²

• HIE-CM moves health records between facilities and apps, and manages the patient’s consent for each exchange. NHA calls it a “data blind gateway”: it facilitates sharing without itself accessing the data, and it ensures consent for every data transaction.²
• NHCX carries claims information among payers, providers, beneficiaries, regulators and observers.¹ Its messages are FHIR bundles defined in the ABDM FHIR guide.⁴
• UHI is an open network for health services, such as booking a consultation or finding a blood bank, across apps. Requests go through a common gateway that NHA operates.¹

HIP and HIU: the two roles

The two roles trip people up because one hospital usually plays both.

• A Health Information Provider (HIP) holds records and provides them: a hospital, a lab, a diagnostic centre.²
• A Health Information User (HIU) requests and uses records, again usually a hospital or doctor, or a public health programme.²

When your outpatient clinic pulls a patient’s discharge summary from another hospital, you are the HIU and the other hospital is the HIP. When a different hospital asks for your lab report, the roles flip.

How a record moves

The key design choice is that records don’t sit in one central database. The PIB backgrounder says data stays with whoever created it, there’s no central government server storing all of it, and records are shared within the network only when the patient consents.¹

NHA’s own example journey runs like this:²

Code What the screen or file shows, copied as is.

 Patient            Doctor (HIU)          HIE-CM              Other hospital (HIP)
    |  registers by     |                    |                         |
    |  scanning QR ---->|                    |                         |
    |                   |-- consent request->|                         |
    |<------------------------ asks patient -|                         |
    |-- accepts ------------------------------>|                       |
    |                   |                    |-- request records ----->|
    |                   |<------------- records sent (with consent) ----|
    |                   |-- prescription shared back to patient's app   |

Two things follow. First, every exchange has a consent artefact behind it, so your system needs to keep a link between the records it received and the consent that allowed it. Second, consent can be revoked and is time-bound¹, so “we had consent once” is not a standing licence to keep pulling data.

What your software has to handle

The PIB backgrounder says every new app must first be tested in a sandbox and pass a security audit of how it handles patient data before going live.¹ Beyond the audit itself, a hospital information system or EMR connecting to ABDM has to handle a short list of jobs well:

1. Identity. Create or link ABHA at registration, and look up HFR and HPR ids for your own facility and staff.
2. Consent. Raise consent requests as an HIU, respond to requests as an HIP, and record which consent each exchange used.
3. Records in FHIR. ABDM’s FHIR implementation guide from NRCeS is based on FHIR R4. It has no AuditEvent, Provenance or Consent profile of its own³, so the audit trail of who did what inside your system is yours to design.
4. Claims. If you take insured patients, NHCX connects the facility’s insurance coverage.¹
5. Expiry and revocation. Stop using data when consent ends.

Where AI tools fit

AI assistants are starting to read and draft records inside hospital systems. Each of the blocks above sets a boundary such a tool should respect:

The last row matters most in practice. Because records stay with the facility that made them¹, a wrong value your system writes is the value other hospitals receive. Our FHIR write benchmark shows how often a “success” response hides a write that wasn’t stored as sent. For the numbers behind the network, read ABDM statistics from official sources; for claims, NHCX claims and FHIR; for what Indian rules ask of logs, AI agent audit logs under the DPDP Rules. For what Deedglass does around AI agent writes in hospitals, see /healthcare.

To try the checks on synthetic data, open the playground in your browser. To see what an AI agent on your machine can change, run npx deedglass scan (what the grade means) or paste its MCP config into /check; neither uploads your data. Our AI agent permissions report shows what public agent setups commonly leave open.

Written with AI assistance and checked against our claims register.