ABDM Milestones M1, M2 and M3: What Certification Actually Requires

A hospital IT head gets an email from a state health authority mentioning ABDM compliance, forwards it to the software vendor, and gets back a reply saying the product is ABDM certified. Everyone relaxes. Six weeks later the empanelment paperwork asks for the facility's HFR ID and a demonstration that records are actually being linked, and it turns out that certified software and a compliant facility are two different things, only one of which anybody has.

The distinction is the single most useful thing to understand about ABDM, so it is worth starting there.

What does ABDM certification actually certify?

Certification applies to the software, not to your hospital.

A vendor takes their product through the National Health Authority's sandbox, demonstrates that it correctly implements a set of APIs, and exits with certification for that product. That certification is theirs, once, and it covers every hospital that uses the product.

Your facility then has to do its own part: register in the Health Facility Registry, get an HFR ID, register your clinicians in the Healthcare Professionals Registry, and configure the certified software to act on your behalf. The vendor cannot do that for you, and their certificate does not substitute for it.

So the correct question to a vendor is not "are you ABDM certified" but "which milestones is your certification for, and what do we have to do at our end".

What are the ABDM milestones?

The milestones describe increasing levels of participation, and each builds on the one before it.

• Milestone 1: ABHA creation and verification. Your registration counter can create an ABHA number for a patient who does not have one, and verify an existing one. This is the entry point and the easiest to reach.
• Milestone 2: linking records. Clinical records created in your system are linked to the patient's ABHA as care contexts, so the patient can see that a record exists at your facility and can share it. This is where a hospital becomes a Health Information Provider.
• Milestone 3: exchange. Your system can request records from other facilities, with the patient's consent, and display them to a clinician. This is where you become a Health Information User, and it is where the clinical value finally shows up.

Treat the exact milestone definitions and any further levels as things to verify against the current NHA documentation rather than against a vendor's slide, because the programme has evolved since it launched and will continue to.

Why milestone 1 alone is not worth much

Creating ABHA numbers without linking records is data entry with no payoff.

It is easy to reach, so it is where most implementations stop, and it produces a hospital that has generated thousands of ABHA numbers and shared nothing. The patient sees no records. Other facilities see nothing. The clinical benefit that justified the work never arrives.

Linking is the milestone that changes anything, and it is harder for a reason worth understanding: it forces the question of what counts as a record. A care context has to point at something real and retrievable. If your discharge summaries are unindexed scans on a shared drive, there is nothing coherent to link.

Milestone 1 tests your registration counter. Milestone 2 tests whether your records are actually records.

What consent means here, and why it is not a checkbox

ABDM consent is a scoped, time-bound, revocable artefact managed outside your system, not a signature you collect once.

A patient grants consent for a specific purpose, for a defined set of record types, for a defined period, through a consent manager. Your system receives the granted consent and must honour its boundaries: only the record types covered, only within the window, and only for the stated purpose. When consent expires or is revoked, access ends.

This is unlike anything in a traditional hospital system, where access is governed by staff roles and nothing else. It means your software has to hold a concept it probably did not have before, and it means the audit trail has to record not just who accessed a record but under which consent.

What has to be true inside your hospital before any of this works

Most ABDM projects stall on data quality rather than on APIs, and the failures are predictable.

• One patient, one identity. If a returning patient gets registered afresh because searching was slow, you have two records and only one of them will carry the ABHA link. Duplicate management is a prerequisite, not a follow-up task.
• Records that exist as records. A care context should resolve to a retrievable document. Scans in a folder named by date do not qualify.
• Structured data where the standard expects it. Exchange uses FHIR resources, and a diagnosis recorded as free text cannot become a coded condition without somebody making a judgement call.
• Mobile numbers captured accurately. ABHA creation and consent both depend on reaching the patient. A counter that types the number wrong once has broken the chain.
• Clinicians registered in HPR, because records need an author with a verifiable identity.

None of this is ABDM-specific work. It is the same data hygiene that makes a hospital system worth having. ABDM simply makes the absence of it visible outside your building.

What it takes at the counter

The part everyone underestimates is the twenty seconds at registration.

Creating an ABHA takes a patient interaction: an identifier, a mobile number, an OTP, a moment of explanation. At a counter with a queue of forty on a Monday morning, twenty seconds is not free, and the clerk will skip it if skipping is possible.

What works is making it the default path rather than an extra step, capturing existing ABHA numbers when patients already have them, and giving the counter a script for the question patients actually ask, which is some version of what this is and whether it is compulsory. What does not work is a target on a dashboard and no change to the workflow.

A sequence that does not stall

• Register the facility in HFR and get the ID. Nothing else is possible first.
• Register clinicians in HPR, starting with the ones who sign records.
• Confirm with your vendor which milestones their certification covers and what configuration you need. Get it in writing.
• Fix duplicate patient identity before turning on linking, not after.
• Reach milestone 1 at one counter, not all of them, and watch what it does to the queue.
• Move to linking as soon as ABHA creation is routine, because that is where the value is.
• Only then plan for consent-based retrieval, and decide in advance where a fetched record will be shown to a clinician and who is allowed to fetch it.

The hospitals that find ABDM painful are usually the ones that treated it as a compliance box to be ticked by the vendor. The ones that find it manageable treated it as the identity and records project it actually is, and got a cleaner patient master out of it either way.