Milestone 2 Health Information Provider

Become a Health Information Provider on ABDM

A HIP is the side of ABDM that holds the record. You link each episode of care to the patient’s ABHA, answer when their PHR app comes looking, and release exactly what a consent covers — encrypted for the one requester who asked. ABDM itself stores none of it.

Get sandbox keys HIP or HIU?

01 The role

What a Health Information Provider has to do

Four obligations. The first is bookkeeping; the other three are asynchronous conversations with the gateway, and each has a way of failing that nobody notices until a patient or an auditor does.

Record: Register patients and care contexts

Each patient by your own MRN, each OPD visit, admission or lab order as a care context with a patient-facing label, an HI type and the date the care actually happened — the date consent ranges are matched against.
Link: Attach them to the ABHA

So the episode appears in the citizen’s PHR app. You start it when the ABHA is on file; the citizen starts it when it is not.
Discover: Answer when a patient goes looking

ABDM asks whether you hold records for a person. Answering wrongly attaches one citizen’s history to someone else’s ABHA, which is the worst thing this role can do.
Release: Share under consent, and only under consent

When an HIU exercises a granted artefact, send the care contexts it covers — its HI types, its date range, that patient — as FHIR bundles sealed for that requester alone.

02 Linking

From an OPD visit to the patient’s PHR app

Three calls and a webhook. Linking is answered by ABDM on a separate channel, so the call returns 202 and the outcome arrives later, correlated for you.

Register the patient

POST /v1/patients upserts on your facility and MRN, so calling it on every registration event is safe — a repeat updates rather than duplicating.
Create the care context

POST /v1/care-contexts with its HI type and occurred_at. Attach the record now or later; a care context without one can be linked, but cannot be sent when an HIU asks for it.
Attach the record

A FHIR bundle of your own, or plain fields and a PDF that the connector turns into one. Either is validated before it is stored. How records become bundles.
Link, then listen

POST /v1/care-contexts/link returns a link request you can check at GET /v1/link-requests/{id}. The outcome is care_context.linked or care_context.link_failed, with ABDM’s reason.

register, record, link Sandbox

POST /v1/care-contexts
{
  "patient_reference": "MRN-90881",
  "reference": "OPD-2291",
  "display": "OPD visit - Medicine - 7 Sep 2026",
  "hi_type": "OPConsultation",
  "occurred_at": "2026-09-07T10:30:00+05:30"
}

← 201 Created
{
  "id": "9b0e…",
  "status": "created"
}

POST /v1/care-contexts/link
{
  "patient_reference": "MRN-90881",
  "care_context_references": ["OPD-2291"]
}

← 202 Accepted
{
  "id": "5f3c9a1e",
  "mode": "hip_initiated",
  "status": "initiated"
}

# later, on your webhook
{
  "event": "care_context.linked",
  "data": {
    "link_request_id": "5f3c9a1e",
    "patient_reference": "MRN-90881",
    "care_contexts": ["OPD-2291"]
  }
}

03HIP-initiated linking

When the patient’s ABHA address is already on the record — captured at registration, or verified at the counter — the facility links new care contexts itself. Behind the one call the connector requests a link token from ABDM, waits for it on the callback channel, adds the care contexts with that token, waits for the second callback, then tells ABDM new records exist so the PHR app shows them without the citizen going looking.

That is two round trips on a channel that answers minutes later. The connector keeps the request id from each half, verifies the callback against ABDM’s published keys, and ignores a retried callback it has already processed. If the patient has no ABHA address on file, POST /v1/patients/{reference}/invite sends ABDM’s deep-link SMS instead.

04User-initiated linking, and why matching is strict

Here the citizen searches for your facility in their PHR app. ABDM sends a discovery request; the connector matches it against your patients, answers with the care contexts it found, and when the citizen picks them issues an OTP. The OTP reaches you in the care_context.link_requested webhook, because your hospital owns the patient relationship and the SMS channel — the connector never messages a patient itself. The citizen reads it back in their app and the link completes.

Discovery matching is deliberately conservative. A verified ABHA address is conclusive. A verified mobile number that matches two of your patients is narrowed by demographics, and if that still leaves more than one, the match is refused rather than guessed. A false positive puts one person’s records under another person’s ABHA, and the citizen has no way to undo it. A missed match costs a phone call.

05The step most often missed

A facility needs an entry in the Health Facility Registry, and that entry has to have its HIP and HIU services registered against the software’s bridge. Until the bridge linkage succeeds, the facility is in HFR, authenticates against the gateway without complaint, and has every linking call rejected — with no ABDM error that names the missing linkage as the cause.

Bridge linkage in the Swastik portal does it, and records when it succeeded. Do it before the first linking call, not after a week of debugging one. Registering the facility itself is covered on the HFR integration page.

06 Consent enforcement

What happens when an HIU asks for your records

The HIP never sees the consent request — only the artefact the citizen granted over its records, and later a request to exercise it. Everything below runs without a call from your software.

Selection

Consent is not a boolean

The classic HIP failure is treating “consent granted” as permission to send everything held for that patient. The connector selects care contexts by the artefact’s HI types, its clinical date range, the consenting citizen’s ABHA address and the facility — and sends nothing outside all four.

Checked in an audit · nothing outside the granted range or types

Re-validation

ABDM asking is not authorisation

The artefact is checked again at transfer time. A revoked artefact, an expired one and one that was never granted are refused with different reasons, because the HMIS and the clinician need a different message for each.

Revocation · stops the next transfer, not the one after expiry

Encryption

Sealed for one requester

Each bundle is validated, then encrypted with Fidelius: ECDH over Curve25519 in its short-Weierstrass form, HKDF-SHA256 and AES-256-GCM, with a fresh key pair for every transfer. It is pushed straight to the address the HIU gave, which is checked before anything is sent to it, so a hostile address cannot point the server inward.

The gateway · routes ciphertext it holds no key for

Partial

One bad record does not sink the transfer

A care context that cannot be sent errors that entry alone. The session is still reported TRANSFERRED — ABDM’s status holds only TRANSFERRED and FAILED — with the failed contexts marked ERRORED, which is what the citizen’s PHR app shows.

Idempotent · a re-delivered request reuses the transfer, never sends twice

You are told at each step. consent.notified when an artefact over your records arrives, health_information.requested when an HIU exercises it, and health_information.sent or health_information.failed with the entry and delivered counts when it ends. A callback that fails every retry raises an abdm.error webhook rather than failing silently.

07 Certification

What M2 sign-off asks you to show

The scenarios a testing agency walks through for a HIP, and the connector endpoint each runs through. Every one has to be run against the real ABDM sandbox, not a mock.

Scenario	Runs through	Shown by hand
Create a health record	`POST /v1/care-contexts`, then `PUT …/bundle` or `PUT …/record`	A prescription, a lab report with its PDF, fetched by a sandbox HIU
HIP-initiated linking	`POST /v1/care-contexts/link`, `GET /v1/link-requests/{id}`	The care context appearing in the PHR app
User-initiated linking	Discover, init and confirm on the bridge; `care_context.link_requested`	Find the facility, receive the OTP, link — and an ambiguous match refused
Consent granted, revoked, expired	Consent notify on the bridge; `consent.notified`	A revocation stopping a later transfer
Share under consent	Health-information request, encrypted push, status notify	The HIU receiving the consented types and range, and nothing else

Budget roughly 4–12 weeks for M2, including sandbox testing, plus a security audit by a CERT-In empanelled auditor that typically runs 5–8 weeks with remediation. The connector removes the integration work from that; the certification is still yours. The milestone guide covers the whole path.

08 Who becomes a HIP

Anyone who creates the record

01 / LABS

Diagnostic laboratories

Every report is a care context. Publish results with their PDF, coded to LOINC where the test name matches.

ABDM for labs

02 / HOSPITALS

Hospitals and clinics

OPD notes, prescriptions and discharge summaries. Most hospitals are an HIU as well, requesting the history they need under separate consents.

The HIU side

03 / SOFTWARE VENDORS

HMIS and EMR products

Build the HIP role once and every hospital on your product inherits it, each with its own facilities, credentials and audit trail.

For HMS vendors

Link your first care context today

Sandbox credentials are issued on signup. Register a patient, create one OPD visit, link it, and watch the webhook arrive.

Create an account API reference

FAQ Common questions

Frequently asked questions

What is a HIP in ABDM?

A Health Information Provider is any facility that creates health records and makes them available through ABDM: a hospital, clinic, diagnostic lab or pharmacy. It links records to the patient's ABHA and releases them to a requester only when the patient consents.

What is a care context in ABDM?

A care context is one episode of care at a provider — an OPD visit, an admission, a lab order. It is the unit a patient sees in their PHR app, the unit consent is granted over, and the unit a HIP releases records against.

What is the difference between HIP-initiated and user-initiated linking?

In HIP-initiated linking the facility already knows the patient's ABHA and links new care contexts itself, with no action from the patient. In user-initiated linking the patient searches for the facility in their PHR app, the HIP matches them to a record, and an OTP confirms the link.

What does a HIP send when consent is granted?

Only the care contexts the consent artefact covers: its health information types, its date range and that patient. Each record is a FHIR R4 bundle, encrypted with Fidelius for that one requester and pushed to the address it gave.

Become a Health Information Provider on ABDM

What a Health Information Provider has to do

Register patients and care contexts

Attach them to the ABHA

Answer when a patient goes looking

Share under consent, and only under consent