“ABDM ready” is one of the most oversold phrases in Indian health software. It hides a real question: ready for what, exactly? The NHA certifies software vendors against a set of milestones, usually described as M1, M2, and M3. Each covers different capabilities. This post explains what those milestones mean at a plain-language level, what Milestone 2 is about, and the exact questions to put to your vendor before you believe the label.
Key takeaways
- ABDM milestones (M1, M2, M3) are a vendor-certification path run by the NHA, not something a clinic passes.
- M1 broadly covers creating and linking ABHA. M2 broadly covers exchanging or linking health records. M3 covers deeper Health Information Provider capabilities.
- There is a real gap between passing in the sandbox and running in production. Ask which one your vendor means.
- Do not accept “ABDM ready” without a milestone name and a production-versus-sandbox answer.
- AI Medical Scribe by Patient Square is not ABDM-certified today; ABDM integration is on the roadmap.
Create and link ABHA
Exchange / link health records
Deeper HIP capabilities
Source: ABDM and NHA portals; confirm current milestone definitions there.
Why the milestone question matters
A vendor can say “ABDM ready” the moment they touch the sandbox. That does not mean patients at your clinic can actually link records under ABDM. Certification runs in stages, and each stage enables different functionality. If you buy on the label alone, you can end up with software that demoed well and does very little of what you assumed.
The fix is to make the vendor name the milestone and say whether it is live in production. That single question filters out most of the fog.
What the milestones broadly cover
The NHA defines the exact scope, and it can change, so treat the descriptions below as the well-known structure rather than a legal spec. Confirm current details on the ABDM portal.
- M1 broadly covers the ABHA basics: creating an ABHA and linking it. This is the entry point. A product at M1 can help a patient get onto ABDM, but that is roughly where it stops.
- M2 broadly covers exchanging or linking health records. This is where a product moves from “can create an ID” to “can participate in record sharing.” For a clinic, M2-class capability is what starts to make ABDM useful in day-to-day care.
- M3 broadly covers deeper Health Information Provider (HIP) capabilities, the fuller set of functions a system needs to serve records into the ecosystem reliably.
If those descriptions feel qualitative, that is on purpose. The precise checklists live with the NHA and get revised. What stays true is the shape: create and link first, exchange records next, deeper provider capability after.
What Milestone 2 means for a clinic
M2 is the one most clinics actually care about. M1 gets a patient an ABHA, which is useful but limited. M2 is where record exchange enters the picture: linking a patient’s records so they can flow, with consent, into the wider system.
Put plainly: a product certified at M2 in production can do more of the interoperability work you probably imagined when you first heard “ABDM.” A product stuck at M1, or only at M2 in the sandbox, cannot yet.
This is why the milestone label is worth chasing. “We support ABDM” could mean M1 in a test environment. It could mean M2 in production. Those are very different products for your front desk and your patients.
Sandbox versus production, the gap nobody mentions
There are two worlds in ABDM certification. The sandbox is a test environment. Production is the live system real patients use. A vendor can pass a milestone in the sandbox long before anything works for your actual clinic.
So there are really two questions, not one:
- Which milestone has the vendor completed?
- Is that milestone live in production, or only in the sandbox?
A confident “M2, in production” is a real answer. A vague “we’re ABDM ready” that dodges both parts is a signal to keep asking.
Questions to put to your software vendor
Bring these to any vendor pitching ABDM support. Ask for evidence, not adjectives.
| Question | Why it matters | Weak answer |
|---|---|---|
| Which ABDM milestone have you completed? | Forces a specific claim | ”We’re ABDM ready” |
| Is it live in production or only in the sandbox? | Separates demo from reality | ”It works in our environment” |
| Can you show current certified status? | Verifiable, not marketing | ”Trust us” |
| Does it create ABHA, link records, or both? | Maps to M1 vs M2 capability | ”It does ABDM” |
| How is patient consent captured for record sharing? | Ties to DPDP obligations | Silence |
That last row connects to your own obligations. Record sharing under ABDM has to sit inside lawful, consent-based handling. Our DPDP guide for clinics covers the consent and data-protection side in more detail.
How ABHA linking fits at the desk
Whatever milestone your vendor claims, the front-desk reality is an ABHA-linking step during registration. If you are setting that up, the ABHA linking clinic workflow post walks through it, and the ABHA number vs address explainer clears up the two things patients confuse. Doctors registering themselves on the provider side will want the HPR registration guide.
There is also a financial angle worth knowing. The NHA runs the Digital Health Incentive Scheme (DHIS), which offers incentives for eligible ABHA-linked digital transactions above a monthly baseline. Under the DHIS as revised by NHA Corrigendum 6, dated 20 November 2025, eligible facilities can receive ₹20 per KYC-verified ABHA-linked transaction above a 100-transaction monthly baseline. Treat that as the one figure worth quoting; the broader scheme details sit with the NHA and change over time. There is more context in the ABDM incentives for doctors post.
Where AI Medical Scribe by Patient Square sits in all this
Straight answer: AI Medical Scribe by Patient Square is not ABDM-certified today, and we will not imply otherwise. ABDM integration is on the roadmap, not shipped. We do not assert any milestone status for the product.
What the scribe does is separate from certification. It listens during the consult and drafts a structured SOAP note, ICD-10 suggestions, and a prescription draft in about two minutes. You review and sign. The record stays yours. So the milestone conversation is one you have with your clinic-software or HMS vendor about record exchange; the scribe is about producing the clinical note quickly and accurately. If you want the note-drafting picture on its own, see the scribe overview for Indian doctors.
The short version
Milestones belong to vendors, not clinics. M1 is create-and-link ABHA. M2 is record exchange, and it is the one that makes ABDM feel useful. M3 is deeper provider capability. Sandbox is not production. Before you believe “ABDM ready,” get the milestone name and the production answer in writing.
Curious how a signed clinical note comes together in about two minutes, with no integration project on your side? Book a demo and see it on a real visit, then check the security page for how we handle data.