ABDM Milestone 1 is the identity milestone. NHA’s own M1 API document describes it as the creation and verification of the ABHA number: a product proves it can register an ABHA, verify one, and manage that account afterwards. It certifies the software vendor, not your clinic. And no clinical record moves at M1.
That last sentence is where the confusion at Indian clinics usually starts. A vendor says ABDM, the clinic hears records, and what actually shipped is an ABHA field on the registration screen.
Key takeaways
- NHA’s Milestone 1 document scopes M1 to one job: creation and verification of the ABHA number. Identity, not records.
- Milestones are certified against the software. Your clinic’s equivalent homework is HFR and HPR registration.
- M1 is the shallowest true version of “ABDM ready”, which is why so many vendor claims quietly stop there.
- Passing a milestone in the sandbox and running it live in production are 2 different achievements. Ask about both.
- Patient Square is not ABDM-certified at any milestone today, M1 included. ABDM support is on the roadmap.
Key facts
- Creation and verification of the ABHA number, per NHA's M1 API document
- M1
- The ABDM layer M1 sits in; NHA separates identity from consent
- Identity
- Clinical records exchanged by M1 capability on its own
- 0records
Source: NHA, Working with ABHA (Health ID) API, Milestone 1, March 2022.
M1, in NHA’s own words
You don’t have to guess at this one. NHA published an API document for the milestone, titled “Working with ABHA (Health ID) API, Milestone 1”, version 1.0 revision 1, dated March 2022. Its purpose line is unusually blunt for a government spec: the document holds the APIs and sequence diagrams for “Milestone One/M-1 (Creation and Verification of ABHA Number).”
The contents page is the scope. Reading down it, a vendor working M1 has to handle all of this:
- Register an ABHA using an Aadhaar number, or using other ID documents.
- Link and de-link an ABHA address against that ABHA number.
- Log a patient in with an Aadhaar OTP or a mobile OTP.
- Retrieve an account for a patient who’s lost track of theirs.
- Pull a profile, pull its QR code, and edit an email or mobile number on it.
- Delete, deactivate, or reactivate the account.
Look at that last line. Account lifecycle. Most people picture M1 as a create button and stop there, but a vendor also has to handle the unglamorous half: the patient who keyed the wrong email, the patient who wants their account deactivated. That’s real engineering, and it’s the part demos skip.
One caveat, and it matters. That document is from 2022, and NHA has since moved to newer API versions published on the v3 sandbox. So read the list above as the shape of the milestone rather than today’s tick-box checklist. The live checklist is whatever NHA’s current sandbox documentation says, and that’s the only version anyone gets assessed against.
The identity layer stops short of the consent layer
The most useful line in that NHA document isn’t an API at all. ABDM, it says, has now segregated the identity layer from the consent layer: the ABHA number provides a strong identity to an individual, while the ABHA address is what lets that individual share their health records with providers and payers.
M1 lives entirely on the identity side of that split. It answers “who is this person, verifiably, across every facility in India?” It does not answer “where is this person’s history, and may we see it?”
Practically, that means a product certified at M1 and nothing else can identify your patient cleanly and tie your file to a national ID. It cannot push last Tuesday’s OPD note anywhere, and it cannot pull the discharge summary from the hospital across town. Those are separate capabilities on separate milestones, covered in the Milestone 2 explainer and the Milestone 3 explainer. If the number-versus-address distinction is still fuzzy, the ABHA number vs ABHA address post untangles the two identifiers your desk will actually see.
Your clinic doesn’t pass M1. Your software does.
Clinic owners get this one wrong constantly, and it costs them weeks.
Milestones are earned by a software product, integrating against NHA’s APIs in the sandbox and demonstrating the required flows. A hospital doesn’t sit an M1 exam. A three-doctor clinic in Nashik doesn’t either. If someone tells you your clinic needs to “get M1 certified”, they’ve either misread the scheme or they’re selling you something.
Your side of the work exists, it’s just a different shape. It’s registry work. The facility gets registered on the Health Facility Registry at facility.abdm.gov.in, and the treating doctor gets registered on the Healthcare Professionals Registry. That’s what makes your clinic a recognised node the patient’s app can share to, and it’s the prerequisite behind incentive eligibility too. The ABHA linking front-desk workflow walks the desk-level version of all of this, including the duplicate-ABHA mistake that causes more grief than any technical failure.
So there are two tracks running in parallel. Your vendor climbs milestones. You get on the registries. Neither substitutes for the other.
Where “ABDM ready” usually comes from
We’ll say what we think: most “ABDM ready” claims in Indian clinic software are M1 claims wearing a bigger jacket.
The reason is structural, not dishonest. Creating and verifying an ABHA is the shallowest useful integration in the whole stack. There’s no consent manager to wire, and no callbacks to serve when another facility comes asking for records. A competent team can ship an ABHA create-and-verify flow in a fraction of the time the later milestones take. So that’s where a lot of products stop, and “we support ABDM” stays technically true of them.
Which means the claim can be accurate while the purchase is wrong. Buy expecting a patient’s old records to surface mid-consult, get identity plumbing instead, and nobody lied to you. You’re still stuck. One question before you sign closes most of that gap: which milestone, exactly?
Sandbox pass, production live: two different sentences
Every ABDM capability exists twice before it’s real. Once in the sandbox, once in production.
The sandbox is NHA’s test environment, and its own documentation frames it as ready to be integrated with hospital and lab software: EMR, HIMS, LIMS, telemedicine, and similar. A vendor registers there, gets test credentials, builds the flows, and demonstrates them. All of that can be genuinely complete while your Tuesday OPD sees nothing, because the same capability still has to be enabled in the live environment your patients touch.
Which is where the second question comes from, and it’s the one vendors dodge: is your M1 capability live in production, for real patients, today? A vendor with a clean answer gives it in one sentence. A vendor without one starts describing a roadmap, and that’s your answer.
A 90-second vendor check
Run this on your next sales call. It’s a translation exercise more than an interrogation.
| What you hear | What it usually means | Ask this next |
|---|---|---|
| ”We’re ABDM ready” | Anything from a sandbox login to full certification | ”Which milestone, and is it live in production?" |
| "We create ABHA numbers” | M1-class capability, identity only | ”Can you also link and share a visit record?" |
| "We’re integrated with ABDM” | Often M1, possibly still in the sandbox | ”Show me your current milestone status." |
| "Records sync with ABDM” | Needs M2 or M3, not M1 | ”Which one, and can a doctor fetch under consent today?" |
| "It’s on our roadmap” | Honest, and not shipped | ”What happens to my records until then?” |
Cross-check whatever you’re told against the official ABDM and NHA portals rather than a slide. And keep the answers in writing, because “ABDM ready” in an email is a lot harder to walk back than “ABDM ready” in a meeting.
When a different vendor is the better fit
If ABHA creation and linking from inside your clinic software is a hard requirement this quarter, we’re not your answer, and we’ll say so plainly. eka.care publicly ships live ABDM integration across the M1 to M3 milestones, and for a clinic building its workflow around ABDM right now, that’s the honest pick. Put the same two questions to them anyway, because milestone status moves.
The case for going beyond M1 is usually financial as much as clinical. The Digital Health Incentive Scheme can pay facilities for eligible KYC-verified ABHA-linked transactions, but identity creation by itself is not the qualifying event. The effective corrigendum can change the eligible record types, rates, patient limits, API version, security evidence, and filing period. If you are building a business case, use the source-dated DHIS breakdown and verify the vendor’s production status instead of relying on an old flat per-record figure.
The reverse is also true. A vendor certified at M1 in production still has to survive your OPD queue and your billing on a 40-patient Saturday. Milestone status answers one narrow question well. It says nothing about whether the software is any good at the rest of the job.
The honest verdict on where we sit
Patient Square is not ABDM-certified at any milestone today, M1 included, and we won’t imply otherwise. ABDM support is on our roadmap, not shipped. We don’t create or verify ABHA numbers inside the product, and we claim no HIP, HIU, HFR, HPR, NHCX, or Consent Manager integration. If you need an ABDM milestone in production, that conversation belongs with your HMS or EMR vendor.
What we do ship is a packaged copilot. Practice Copilot can use Patient Square EHR or an existing EHR for independent clinics. Hospital Copilot can use the complete Patient Square HIS/EHR or work alongside an existing HIS/EHR for multi-department hospitals, with the ambient AI scribe as one module inside either product. The scribe listens during the consult and drafts a structured SOAP note, ICD-10 suggestions, and a prescription draft in clinical English, ready about two minutes after the visit ends. You review and sign. The ICD-10 entries are suggestions to confirm, never codes applied on your behalf. The prescription is a draft, not something transmitted anywhere. Visit audio is processed and discarded rather than stored, and the note stays yours. This describes live consultation audio; uploaded recordings use a separate retention mode with explicit consent.
The connection to M1 is indirect but real: you can’t link a record you never wrote down properly. Whatever milestone your clinic software eventually reaches, the raw material is a complete, structured note from every visit. How we handle that data is set out on the security page.
If you remember one thing
M1 is identity. It’s the milestone that gets a patient verifiably identified under ABDM, nothing more, and NHA’s own documentation says so in the title. Your vendor holds the certification; you hold the registry registrations. And a milestone completed in the sandbox is not a milestone running in production, which is why both questions get asked every time.
If the documentation half is the part that’s actually broken in your clinic, explore the workflow and bring one consult from last week. Then judge the note on one thing: could you sign it without rewriting it?