ABDM HIP and HIU roles and the consent flow explained

If your product touches patient records in India, you will be asked one question early: are you a HIP, a HIU, or both? The answer decides which Ayushman Bharat Digital Mission (ABDM) integration milestone you build, what you must certify, and what you may keep after you fetch a record. This page explains the two roles, the consent manager between them, and the order in which a record moves. It is for product managers and founders in healthtech, not for lawyers. The source is ABDM's own guideline document for providers and users, in the version dated 24 October 2022, read together with the Health Data Management Policy and ABDM's consent manager brochure.

1. Who is a HIP and who is a HIU

The guideline defines a Health Information Provider (HIP) as any healthcare provider that creates, stores or distributes health information while treating a patient, and agrees to share it digitally with the patient using the consent framework ABDM has adopted. Hospitals, diagnostic centres, clinics, public health programmes and telemedicine players are all encouraged to become HIPs.

A Health Information User (HIU) is any permitted entity that wants to access an individual's health records with that person's informed consent. The guideline names hospitals and doctors who want to see a patient's history, and mobile apps that display health data to users, including Personal Health Record (PHR) apps.

Two neighbours get confused with these roles:

• Health Repository Provider (HRP). A software vendor that offers ABDM-compliant software and long-term record storage to hospitals, labs and clinics. A small lab that adopts a hosted lab system becomes a HIP through the vendor's software.
• PHR app. The patient's own app. The guideline treats it as a separate entity because it behaves like a HIU when it shows and stores records, like an HRP when it stores them, and like a HIP when it shares them.

One company can be several of these at once. A hospital is a HIP when it issues a discharge summary and a HIU when its doctor asks for last year's reports from another hospital.

2. The consent manager sits in the middle

Neither side talks to the other directly. The Health Information Exchange and Consent Manager (HIE-CM) routes requests and holds the consent record. ABDM's brochure calls it a data blind gateway that passes information without accessing it. The guideline adds that the National Health Authority stores no patient health record data; the record stays with the HIP that created it.

The Health Data Management Policy puts three duties on a consent manager. It must not access, process or store the personal data shared under a consent. It must keep a record of consents shared and revoked, in a form that allows audit. And if a patient revokes consent, it must tell the data fiduciary, which here means the HIP holding the record.

The guideline says the National Health Authority runs one HIE-CM today and expects more to appear over time.

3. The flow, step by step

The sources do not publish one numbered flow, so this sequence is assembled from the guideline, the policy and the brochure. Check it against the current API documentation before you build.

1. The patient has an ABHA address. It is linked to an HIE-CM, which holds the links and consents for that address. Creating one is voluntary, and a HIP may not force a patient to give an ABHA number.
2. The HIP links records. For each visit the HIP links a care context, and it must notify ABDM through the APIs whenever a new record is generated for a patient.
3. The HIU raises a consent request. The brochure shows the simplest case: a doctor asks to see previous health records and raises a consent request. The request must follow NHA's rules on the purposes for which consent can be sought.
4. The patient decides. The patient approves or refuses from a PHR app. On approval, a digital consent artefact is created. It states the purpose of use and how long the data will be available.
5. The HIP checks before it shares. Under the policy, the HIP must verify the consent, including whether it has been revoked, and share only if it is valid.
6. The record moves to the HIU. The HIP sends it through the exchange, in the standard health record formats.
7. The HIU keeps it only on the artefact's terms. Data held by a HIU is bound by the rules in the consent artefact, including how long it may be retained.
8. The patient can revoke. The guideline says a patient can revoke consent or refuse access at any point.

4. What a HIP has to build and promise

The guideline lists eight obligations for HIPs. The ones that shape a product backlog are:

• Capture and validate the ABHA at registration if the patient has one, and link it to existing records.
• Run an online HIP service that answers data requests from the consent manager and shares records only after validating consent.
• Meet the uptime that ABDM measures with heartbeat checks, and pass certification before going live.
• Share records in the ABDM data standards, which use FHIR R4 bundles profiled for India. A HIP may begin with documents such as PDFs but must start sharing fully structured data within one year of certification.
• Keep OPD and IPD records digitally for the period the retention policy sets, and migrate them to another provider if the facility closes or changes software.

5. What a HIU has to build and promise

The HIU list is shorter and sharper:

• Register with ABDM and obtain an access key.
• Get certified; the guideline says HIU implementations need certification to show they follow the rules of the consent artefact.
• Make sure each consent request follows NHA's policies on purpose.
• Handle all three record formats: simple text, structured documents with attachments, and fully coded records.
• Store what you fetch under the retention, data management and security policies, and stop holding it once the retention period in the artefact ends.

6. How this maps to build milestones

ABDM describes integration in milestones. M1 is ABHA creation and verification. M2 is building HIP services to share records. M3 is building HIU services to show a patient's history to authorised health workers with complete consent. A hospital system must reach at least M2; acting as a HIU is M3. Production access keys are issued only after the entity is verified in the ABDM registry and the software is certified, and the July 2026 PIB backgrounder repeats that every new app is tested in a sandbox first.

7. What to do next

• Decide your role per feature, not per company. List each screen that writes records (HIP) and each that reads another party's records (HIU).
• Build the revocation path before the happy path. Define what your app deletes, hides or stops syncing when consent ends.
• Treat consent as data. Store the artefact reference, purpose and expiry next to every fetched record so you can prove why you hold it.
• Read the sibling pages on ABHA integration, ABDM Scan and Share and the wider ABDM rules. If you offer remote consults, the telemedicine rules apply as well.

What I could not confirm

ABDM's own file server and its sandbox documentation pages did not open on 1 November 2026, so I read archive copies of the guideline, the policy and the brochure. The guideline is dated October 2022, and ABDM has issued newer API versions since. Endpoint names, the artefact fields and the exact consent request screens are therefore not covered here; take them from the current sandbox pages. This page is general information, not legal advice; check the current rules with a qualified professional before you build or certify.

Questions people ask

Can one product be both a HIP and a HIU?

Yes. The guideline treats PHR apps as acting as both, and a hospital system that reaches M2 and M3 acts as both. Each role is certified for its own behaviour.

Does the HIE-CM store patient records?

No. The guideline says the National Health Authority is not storing any patient health record data, and the brochure calls the consent manager a data blind gateway.

Can a patient take back consent after sharing?

Yes. The guideline says consent can be revoked at any point, and the policy requires the consent manager to notify the data holder of the revocation.

Does a clinic have to be a HIP?

The guideline says all healthcare providers are expected to become HIPs over time and that participation starts by signing up with ABDM. Check the current status with ABDM for your facility type.

Sources

1. Guidelines for Health Information Providers, Health Repository Providers, Health Information Users and PHR Apps, ABDM, version 24 October 2022 (archive copy)
2. Health Data Management Policy, National Digital Health Mission (undated, archive copy)
3. Health Information Exchange Consent Manager (HIE-CM) brochure, National Health Authority (undated, archive copy)
4. Ayushman Bharat Digital Mission: India's Digital Health Backbone, PIB, 6 July 2026