HIP vs HIU in ABDM: who shares, and who asks

01Two roles, one exchange

The Ayushman Bharat Digital Mission does not keep patients’ records in a central store. Records stay with whoever created them, and move only when the patient agrees. Every such movement has two parties, and ABDM gives them names:

• Health Information Provider (HIP) — the party that holds the record. A hospital that wrote a discharge summary, a lab that issued a report, a clinic that printed a prescription.
• Health Information User (HIU) — the party that wants to read it. A doctor at another hospital who needs the patient’s history before an operation, or the patient’s own health app.

Between them sits the consent manager, reached through the ABDM gateway. It knows which HIPs have linked records to a patient’s ABHA, it shows the patient every request in their PHR app, and it issues a signed consent artefact when the patient says yes. Neither side trusts the other directly; both trust the artefact.

The roles are not job titles or licence categories. They are sets of API endpoints and obligations, and the same organisation can hold both. In the milestone scheme, being a HIP is M2 and being an HIU is M3; both depend on M1, ABHA, because every exchange keys on the patient’s identity. The milestones guide covers how each is tested.

02What a HIP does

A HIP’s work has three phases, and only the last one involves another provider.

Make records findable

Records are organised into care contexts: one episode of care the patient would recognise, such as an OPD visit, an admission or a lab order. Each care context has a stable reference in the HIP’s own system, a display name, and a health information type (hiType) such as OPConsultation, DiagnosticReport or DischargeSummary.

A care context becomes visible to the patient once it is linked to their ABHA. There are two ways that happens:

• HIP-initiated linking. The hospital already has the patient’s ABHA on file. It asks the gateway for a link token, then attaches care contexts with it. No action is needed from the patient, and the hospital can send a deep-link SMS telling them new records exist.
• User-initiated linking. The patient searches for the hospital in their PHR app. The gateway calls the HIP’s discover endpoint with the patient’s details; the HIP matches a patient, lists their care contexts, and confirms the link with an OTP.

Discovery matching is where a HIP can do real harm. Attaching one person’s records to another’s ABHA is not something the patient can undo, so a mobile number that matches two patients should be reported as ambiguous, not resolved by guessing.

Hear about consent

When a patient grants a consent that covers the HIP’s records, the gateway notifies the HIP with the artefact: which care contexts, which hiTypes, what date range, which HIU, and until when. Later it sends REVOKED or EXPIRED for the same artefact. Those three — GRANTED, REVOKED, EXPIRED — are the only statuses a HIP receives.

A HIP never sees the consent request the HIU raised, including the purpose text and whatever the HIU originally asked for. It sees only what the patient granted. If the patient denied the request, the HIP hears nothing at all; a denial concerns a request, and only the HIU gets it.

Release records under that consent

When the HIU asks for data, the gateway forwards a health information request to the HIP naming the artefact, a date range, the HIU’s public key material and a dataPushUrl. The HIP then:

1. Re-checks the artefact it holds: granted, not revoked, not past expiry.
2. Selects only the care contexts inside the artefact’s hiTypes, its date range (intersected with the request’s, which may be narrower but never wider), the consenting patient and the facility.
3. Builds a FHIR document bundle for each selected care context.
4. Encrypts each bundle with fresh key material for this transfer.
5. POSTs the ciphertext directly to the HIU’s dataPushUrl.
6. Notifies the gateway of the outcome: DELIVERED or ERRORED per care context, and a session status of TRANSFERRED or FAILED.

A transfer where one care context could not be built is still TRANSFERRED; the failed context is marked ERRORED, and that is what the patient’s app shows.

03What an HIU does

An HIU’s job starts with a question a clinician is asking and ends with records it is obliged to delete.

Ask precisely

A consent request names the patient’s ABHA address, a purpose, the hiTypes wanted, a clinical date range, an access mode, an expiry and a dataEraseAt time. It also names the requester — typically the clinician, with a registration number the patient sees when deciding. A trimmed example of the body sent to the gateway’s consent request endpoint:

"consent": {
  "purpose": {
    "code": "CAREMGT",
    "text": "Care Management",
    "refUri": "https://www.nrces.in/ndhm/fhir/r4/ValueSet/ndhm-purpose"
  },
  "patient": { "id": "asha.devi@sbx" },
  "hiu": { "id": "CITY-HOSP-HIU" },
  "requester": {
    "name": "Dr Ravi Kumar",
    "identifier": {
      "type": "REGNO",
      "value": "MH-123456",
      "system": "https://www.nmc.org.in"
    }
  },
  "hiTypes": ["DiagnosticReport", "DischargeSummary"],
  "permission": {
    "accessMode": "VIEW",
    "dateRange": { "from": "2024-01-01T00:00:00Z", "to": "2026-09-01T00:00:00Z" },
    "dataEraseAt": "2026-10-12T00:00:00Z",
    "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 }
  }
}

The purpose codes come from a published value set: care management, break the glass, public health, healthcare payment, disease-specific research and self-requested. The request may also name one HIP; leaving it out asks every HIP where the patient has linked records, which suits a full history and wastes everyone’s time when the doctor wanted one hospital’s reports.

Wait, then read what was actually granted

The patient decides in their PHR app, which can take minutes or days. The HIU hears GRANTED with artefact ids, or DENIED, or EXPIRED if nobody answered in time. On a grant it fetches each artefact, because the patient can narrow the terms: fewer hiTypes, a shorter date range, an earlier expiry. The artefact, not the request, is the contract.

Request, receive, decrypt

To exercise an artefact, the HIU generates an ephemeral key pair and a nonce, stores the private key, and sends a health information request with the public key and a dataPushUrl. HIPs push encrypted bundles to that URL. The HIU decrypts them, validates them as FHIR, stores them, and reports OK or ERRORED per care context. If the private key was not stored before the request went out, the pushed data can never be opened and the consent has to be exercised again.

Keep only what it may keep

Received records carry a deadline. When the artefact’s dataEraseAt passes, the HIU must erase them. When the patient revokes, use stops at once — not at the next nightly job, and not at the artefact’s natural expiry. An HIU that caches records in a clinician’s view, a search index or a report export has to be able to find and remove every copy.

04How consent connects them

Put the two sides together and the sequence looks like this. Every arrow except one passes through the gateway, and nearly every reply arrives as an asynchronous callback rather than in the HTTP response.

Step 7 is the only direct connection, and it carries ciphertext. The gateway routes the key material but never holds a private key, so it cannot read what it helped arrange. The bundles are sealed with ABDM’s Fidelius scheme: ECDH over Curve25519, HKDF-SHA256 to derive the key, and AES-256-GCM on the payload. The integration walkthrough covers the gateway, tokens and callbacks in more depth.

05Side by side

Both sides store consent artefacts, for opposite reasons: the HIU holds consents it was granted, the HIP holds consents granted over its records. A data model with one artefact table needs a role column, or the two will be confused the first time a hospital acts as both for the same patient.

The endpoint-level detail for each side is on the HIP integration and HIU integration pages.

06What an audit checks

Before production access, an integration goes through functional testing by an agency NHA has empanelled and a security audit by a CERT-In empanelled auditor. The scenarios differ by role, and the ones that fail are nearly always about scope and time.

On the HIP side

• Scope. A test HIU asks for one hiType over a narrow date range, and receives exactly that. A lab report from outside the range, or a prescription when only lab reports were granted, is a failure.
• Revocation. The patient revokes in the PHR app, and a later request for the same artefact gets nothing.
• Linking. Care contexts appear in the patient’s app with sensible names, and an ambiguous discovery is refused rather than guessed.

On the HIU side

• Narrowed consent. The patient approves less than was asked, and the stored artefact shows the narrower terms.
• Interoperability. Records from a different HIP decrypt and render. Testing against your own HIP proves only that you agree with yourself.
• Revocation and expiry. After either, a record that opened a minute ago refuses to open.

On both

Callbacks from the gateway are signed, and an auditor will check that you verify the signature against ABDM’s published keys. A bridge URL that accepts unsigned callbacks lets anyone who finds it forge a consent notification. Both sides also need an audit trail that can answer “what did you send, to whom, under which artefact”. The security page describes how this connector handles those controls.

07Why hospitals are both

A standalone diagnostic lab is usually a pure HIP: it produces reports and rarely needs to read anyone else’s. It can go live with M1 and M2 and stop. The lab page covers that shape.

A hospital is different. Its OPD writes prescriptions, its wards write discharge summaries and its lab writes reports — all HIP work. The same doctors see referred patients whose history lives elsewhere, and reading it is HIU work. Refusing either role leaves a gap a clinician will notice within a week.

Being both has practical consequences for the build:

• Two service registrations per facility. The facility’s HIP and HIU services are linked to your software in the Health Facility Registry. Miss the linkage and linking calls are rejected without an error that names the cause.
• Two consent paths through one table. The same patient can have an artefact over your records and an artefact granting you someone else’s, at the same time.
• Two retention rules. Your own records follow your medical-records policy. Received records follow the artefact, and must not quietly become part of your own chart unless your process and the consent allow it.
• One set of plumbing. Session tokens, callback verification, idempotency and FHIR validation are shared, which is why the second milestone costs less than the first.

For how the pieces fit into a hospital system end to end, see integrating ABDM with an HMIS.

08Mistakes on each side

HIP mistakes

• Treating consent as a boolean. “There is a granted artefact for this patient” followed by sending everything. Scope is hiTypes, dates, patient and facility, every time.
• Trusting the request. The health information request carries a date range. The artefact is the ceiling; intersect, never widen.
• Building the bundle at transfer time and finding it invalid then. Validate a FHIR record when it is created, while the person who entered it can still fix it. The FHIR guide lists the checks that matter.
• Unstable care context references. Regenerating a reference for the same visit creates a duplicate in the patient’s app.

HIU mistakes

• Not persisting the private key first. The data arrives, and nothing can open it.
• Enforcing the request instead of the artefact. The patient narrowed it; the HIU did not notice.
• Erasing the database row and forgetting the copies. Exports, caches and object storage all count.
• Asking for everything. Every hiType over ten years is a request patients deny, and a denial ends the exchange before it starts.