Guide ABDM certification
ABDM integration, milestone by milestone
ABDM is not one integration. It is four milestones, each with its own endpoints, its own certification and its own way of going wrong. Here is what each actually involves.
01The four milestones
The National Health Authority certifies ABDM integration in stages. You do not have to do all of them — a diagnostic lab that only publishes reports needs M1 and M2; a hospital that also wants to read a patient’s history from elsewhere needs M3 as well.
02M1 — ABHA creation and verification
The Ayushman Bharat Health Account is the patient’s identity on
the network. M1 covers creating one from an Aadhaar number or a mobile
number with OTP, verifying an existing account, and resolving an ABHA
address such as asha.devi@sbx to the person behind it.
The part that catches people out is that Aadhaar numbers and OTPs must be RSA-sealed with ABDM’s published public key before transmission, and must never be stored. The connector does the sealing and holds nothing.
03M2 — linking and sharing records as a HIP
As a Health Information Provider you tell the network which patients you hold records for. A care context is one episode of care — an OPD visit, an admission, a lab order. Linking makes it visible in the citizen’s PHR app, where they can then consent to share it.
Sharing is the other half of M2. When a consent request reaches you, you must release only what the artefact authorises. Two rules decide whether an audit passes: records outside the granted date range or HI types must not be sent, and a revoked artefact must stop working immediately rather than at its natural expiry.
Discovery and linking are asynchronous: ABDM calls you back, sometimes minutes later, and the correlation between request and response is yours to maintain. This is the single largest source of half-finished ABDM integrations.
04M3 — consent requests as a HIU
As a Health Information User you raise a consent request naming a purpose, a date range and the HI types you want. The citizen decides in their PHR app, which can take minutes or days. If they grant it, you receive a signed consent artefact and can then request the data.
The records arrive encrypted for you alone. You decrypt them, keep them only under the consent that fetched them, and erase them when the artefact’s erase-by date passes — a revoked consent must stop them opening at once.
05M4 — the registries
The Health Facility Registry and Healthcare Professional Registry are the directories of who is on the network. Registering your facility in HFR is a four-step flow sharing one tracking id, and a duplicate entry can only be merged by NHA afterwards — a support conversation measured in weeks. Search before you register.
06 Fidelius
Encryption is not optional
Health information moving between a HIP and an HIU is end-to-end encrypted. The gateway carries the ciphertext and never holds a key that opens it.
- Step 1
-
Ephemeral keys per transfer
Both sides generate fresh Curve25519 key pairs for each transfer and exchange public keys through the consent flow. Nothing long-lived is reused, so a key that leaks opens one transfer and no others.
- Step 2
-
Shared secret, derived not sent
A Curve25519 ECDH exchange produces a secret both ends can compute and nobody in between can. HKDF-SHA256 derives the working key from it with the nonces agreed in the same exchange.
- Step 3
-
AES-256-GCM on the bundle
The FHIR bundle is sealed with AES-256-GCM, which authenticates as well as encrypts — a modified ciphertext fails to open rather than decrypting to something plausible.
- Result
-
The gateway sees nothing
ABDM routes the payload between the two parties named on the consent artefact. It never holds the key, so the national infrastructure carries records it cannot read.
The connector implements all of it. You send clinical data as flat JSON over TLS to an endpoint you already trust; key exchange, derivation and sealing happen server-side before anything leaves for the gateway.
07 The gate
What production access requires
Sandbox is open to anyone. Production is not — and the security audit, not the integration, is usually the long pole.
| Stage | What happens | Typical duration |
|---|---|---|
| Sandbox build | Integrate and exercise every flow against the NHA sandbox | 2–6 weeks |
| Functional testing | Test cases mapped to the NHA milestone checklist, with API logs as evidence | 1–2 weeks |
| WASA security audit | Web Application Security Assessment by a CERT-In empanelled auditor. STQC and internal audits are not accepted | 5–8 weeks |
| NHA review | Audit report, evidence pack and Safe-to-Host certificate submitted for committee review | 2–4 weeks |
| Go live | Production credentials issued against the live gateway | — |
Building on this connector removes the integration work from that timeline. It does not remove the certification — nobody can do that for you.
08 The boundary
Where the connector fits
You hold your clinical data. It holds the protocol — token lifecycle, request signing, callback verification against the gateway’s JWKS, correlation ids, retries, FHIR assembly and Fidelius encryption. You call ordinary REST and receive signed webhooks when the network answers.
- Yours
-
The clinical record
Patients, encounters, prescriptions, reports — in your own database, in your own schema.
- Ours
-
The protocol
Tokens, signing, JWKS verification, correlation, retries, FHIR R4 assembly and Fidelius.
- Shared
-
The audit trail
One correlation id traces a request from your software, through ABDM, to the provider and back.
09 The components
Each part, in depth
This guide is the map. Each milestone and registry has its own page with the endpoints, the sequence and the failure modes.
ABHA integration
Enrolment, Find ABHA, biometric verification, Scan & Share and the link to your MRN.
HIU integration
Consent requests, signed artefacts, and the encrypted records that come back.
FAQ Common questions