M2 Attach: linking and sharing
Milestone 2 attaches the health records you hold to a person's ABHA address. After it you can group records into care contexts, link them, answer discovery requests from PHR apps, and push encrypted records when a consented request arrives.
In short
- Your facility is the HIP when it publishes a record, and your software is how it publishes. A valid facility ID and registration in the HIP role come first, either from the NHPR portal by hand or by building M4 Enrol.
- M2 is keyed to an ABHA address, so M1 Create has to work before M2 can.
- Hold a link token per patient. Its validity is six months.
- Records go out as FHIR R4 against the ABDM profiles.
- Four callbacks name a path and carry no documented payload. Do not assume a body.
What M2 gives you
| Capability | What your system can do |
|---|---|
| Care contexts | Group each visit or admission into a named unit that can be linked to an ABHA address |
| HIP initiated linking | Link a care context yourself, when the patient gave you their ABHA address at registration |
| Notification to mobile | Make a record findable when you hold only a mobile number, a name, an age and a gender |
| Discovery | Answer a patient's search for their records at your facility, and let them link what you return |
| Data request and transfer | Receive a consented request, package the records, encrypt them, and push them to the requester |
Requesting records from other facilities is M3 Retrieve.
Who needs it
Hospitals, laboratories, pharmacies and imaging centres, through the software they record care in. A citizen pushing their own records from a PHR app builds P2 Linking and records, the patient side of M2.
Prerequisites
- A valid facility ID and registration in the HIP role. That authorises your facility to create health records and share them with whoever asks to read them as the HIU. It comes from M4 Enrol.
- A working M1 Create integration. Linking is keyed to an ABHA address.
- A link token per patient, stored when the patient registers. Validate it before use. If you hold no valid one, regenerate it using demographic authentication.
- FHIR R4 output conforming to the ABDM profiles at nrces.in.
Four callbacks name a path and carry no documented payload: discovery, link init, link confirm, and consent notify. Do not assume a body for them. The data notification callback is documented in full.
Record types you can link
Each type can be a simple bundle wrapping a PDF or image attachment, or a structured bundle with coded clinical data.
| Record type | What it holds |
|---|---|
| Diagnostic Report Record | Radiology and laboratory reports |
| Discharge Summary Record | The discharge summary for the ABDM health data set |
| Health Document Record | Unstructured historical records, usually uploaded through a health locker |
| Immunization Record | Immunisations, vaccine certificates and next dose recommendations |
| OP Consult Record | Outpatient notes: examinations, procedures, medications and advice |
| Prescription Record | Medication advice, following Pharmacy Council of India guidelines |
| Wellness Record | Vitals, physical examination and general health data captured in PHR apps |
| Invoice Record | Pharmacy invoices, consultation invoices and other billing records |
An HMIS must implement every HI type.
Build it with an agent
Hand M2 to the agent you already use, as one file it loads once. Install it, or open it there in one click.
Certification
M2 has no certification step of its own. One exit process covers the whole integration, run once, after every milestone your role needs works end to end. See Going live for the four steps and what each one asks of you.
Test data is in the data dictionary. Support lists the channels. The cases you are certified against are in M2 testing use cases.
The journey, one diagram per flow
Milestone 2 (M2) of ABDM has four flows. This page draws each one, so you can see the round trips before you read the detail.
"Your system" is the HMIS or LMIS your facility publishes through. "HIE-CM" is the Health Information Exchange and Consent Manager gateway.
Journey 1: HIP initiated linking
The patient gave you their ABHA address at registration. Link the care context as soon as the record is ready: linking is what makes it reachable from PHR apps.
Step 8 is the acknowledgement. Step 9 is the answer. The link is confirmed only when the callback arrives at /v3/link/on_carecontext on your bridge carrying status, so do not mark a record as linked on the strength of the 202. See the outcome of a care context linking call.
A step drawn from the HIE-CM to your system is a POST to the callback URL registered for your bridge. It arrives on its own. Do not poll for it.
- No valid link token. Validate the stored token before use, with a tool such as JWT.io. If it is expired or missing, regenerate it through demographic authentication.
- An existing care context gains new records. The step 10 notification fires for that too, not only for a new context.
Journey 2: Notification to mobile
You hold a mobile number, a name, an age and a gender, but no ABHA address. You cannot link, so you ask the HIE-CM to tell the patient a record is waiting.
Journey 3: Discovery and link
The patient starts discovery from a PHR app and picks the facility they visited. Your system matches them on the identifiers the gateway passes you and answers with care contexts.
Step 3 hands you two groups of identifiers.
- Verified. ABHA address, mobile number, name, gender, year of birth. Weight these higher.
- Unverified, user declared. Facility issued identifiers such as a medical registration number or patient ID.
Step 5 has a hard rule: care context metadata only. No diagnosis, no test result, no report content.
Steps 8 to 11 are drawn in words. The error codes name them init, confirm, on-init and on-confirm, so the shape is a gateway request and a callback from you. Their fields are not yet published.
Journey 4: Health record request and data transfer
Another facility, an insurer or a citizen's PHR app asks for records under a consent artefact the patient granted. Whoever asks is the HIU.
Four constraints apply to step 9, the push.
- The HIU supplies the data push URL. It can differ from its registered gateway URL, which keeps the requester harder to identify.
- The push has a 20 minute window from the start of the request. Past that, expect failure or timeout.
- Large datasets such as CT or MRI images may be split across multiple parts.
- Stream very large files rather than sending one whole payload.
Encryption uses ECDH, Elliptic Curve Diffie Hellman, over Curve25519. Mechanics: use cases. Call order: API reference.
Next
- The four flows as diagrams: the journey below.
- The calls, callbacks and error codes: M2 API reference.
- The next milestone: M3 Retrieve.