Skip to content
MedOrbit
Book a demo

Compliance

What ABDM-ready hospital software actually means

MedOrbit team · Updated 30 July 2026 · 5 min read

ABDM-ready means a system already speaks the Ayushman Bharat Digital Mission's language — ABHA identifiers, consent-managed sharing, FHIR R4 records — and is waiting on National Health Authority sign-off before that traffic goes live. It is a claim about architecture, not about a working government connection. This guide separates the two, walks the M1, M2 and M3 milestones, and gives you six questions that expose the difference in a sales call.

What does ABDM-ready actually mean?

It means the ABHA, consent and FHIR R4 plumbing exists in the product and has been exercised against the ABDM sandbox, while the deployment itself has not yet been cleared by the National Health Authority for live traffic. The capability is real; the government sign-off is pending. A vendor who blurs those two things is selling you a timeline they do not control.

The distinction matters because ABDM is not one API you integrate once. It is a programme with facility and practitioner registries, a health-ID layer, a consent framework and a certification gate — each of which can be finished in a codebase long before a particular hospital is cleared to exchange records. Read a readiness claim as a statement about software, then check the programme's current shape at abdm.gov.in.

What are the M1, M2 and M3 milestones?

They are the staged capability checks an integrator clears in the ABDM sandbox, and they get harder in a specific order. M1 covers creating and verifying an ABHA. M2 covers linking a patient's records to that ABHA and releasing them on consent, as a Health Information Provider. M3 is the reverse direction: pulling records from other facilities as a Health Information User.

  • M1 — ABHA creation and verification: your registration desk can create or verify a patient's ABHA number and address.
  • M2 — Health Information Provider: your facility links care contexts to an ABHA and releases records against a valid consent artifact.
  • M3 — Health Information User: your doctors request records held elsewhere, and the patient's consent decides what comes back.

Most vendors are candid about M1, because it is visible at the counter. M2 and M3 are where the work hides — care-context linking, consent-artifact validation, FHIR R4 bundles another system can parse. Requirements also move as the programme evolves, so check the current definitions in the ABDM sandbox.

How does Scan and Share change the OPD counter?

Scan and Share is the ABDM flow where a patient scans a QR code at your facility, shares their ABHA profile and receives a token without queueing at registration. For a busy OPD it is the most tangible piece of the whole programme, because it removes the re-keying of name, age and phone number on every repeat visit.

It also sets a quiet expectation: if your front desk accepts a shared profile, your records need somewhere sensible to put it. A token landing in a system with no ABHA field and no de-duplication creates a second patient identity instead of removing one. Ask to see the queue after the scan, not only the scan.

Why is ABDM-ready not the same as ABDM certified?

Certification is a decision the National Health Authority makes about a specific integration, after testing it. Readiness is a claim a vendor makes about their own code. One is verified from outside, the other is asserted from inside — which is why a sandbox screenshot is not evidence of a live production connection.

MedOrbit says ABDM-ready and NHCX-ready, never live-integrated: the ABHA, consent and FHIR R4 workflows are built, and mock connectors stay the default until a deployment is cleared. The compliance page states the same gap in the same words.

What should we ask a vendor before we believe an ABDM claim?

Six questions separate real readiness from a badge on a website, and all six have short factual answers. Send them in one email, to every vendor on your list, and compare the replies side by side.

  • Which milestone have you cleared, and for which client deployment — M1, M2 or M3?
  • Can you show a National Health Authority reference for that clearance, rather than a sandbox screenshot?
  • Where does an ABHA number live in your data model, and what happens when the same patient arrives without one?
  • How is a consent artifact stored, and can we see the audit trail for a record that was shared?
  • Which FHIR R4 resources do you emit, and has another vendor's system consumed them?
  • If our facility is not cleared yet, what exactly works on day one — and what is switched off?

The last question protects your budget. A genuinely ready system degrades gracefully: registration, records, consent capture and reporting all work without ABDM, and the exchange layer switches on when clearance lands. Consent is also a DPDP obligation in its own right — the DPDP guide covers that side.

Questions people ask about this

Is ABDM-ready the same as ABDM certified?

No. Ready describes the software — ABHA, consent and FHIR R4 workflows built and exercised in the sandbox. Certification is a National Health Authority decision about a specific integration.

Do we need an ABHA for every patient?

No. ABHA is voluntary for patients, so your registration flow has to work identically with and without one. Treat any system that makes ABHA mandatory as a risk to your OPD throughput.

Can we start with M1 and add the rest later?

Yes, and most facilities do. M1 gives the counter an immediate win, while M2 and M3 depend on the record and consent layers being in place first.

If you want to see what ABDM-ready looks like in a working OPD — ABHA at the counter, a consent trail behind it, and nothing pretending to be cleared — book a 30-minute demo and put the six questions above to us directly.