ABDM and ABHA Guide for Hospitals: What to Do in 2026

What is ABDM, and why do hospitals keep hearing about it?

The Ayushman Bharat Digital Mission (ABDM) is the national digital health programme run by the National Health Authority. The Government of India launched it in September 2021, according to the Press Information Bureau (PIB). Its aim is a connected system where a patient's records follow them from one provider to another, but only with the patient's consent.

For a hospital, ABDM changes three everyday workflows: how a patient is identified at registration, how records such as lab reports and discharge summaries are created and linked, and how consent is captured before anything is shared. It is less a certificate you hang on the wall and more a set of workflow and data-quality habits supported by your software.

This guide covers what each ABDM building block is, what the M1/M2/M3 milestones mean, how Scan and Share works at the front desk, and a practical readiness checklist. It does not replace the official documentation. Rules, incentive schemes and technical specifications get revised, so as of 2026, always confirm current requirements on the ABDM website before you plan.

What are the ABDM building blocks hospitals should know?

PIB's July 2026 factsheet on ABDM lists the core pieces. In plain terms:

Two clarifications save a lot of confusion. First, ABHA does not replace your UHID. Your UHID remains the hospital's internal key, and the ABHA is linked to it. Second, ABDM is not a central database where hospitals upload everything. Records stay with the provider that created them; the network shares them on request, once consent is given.

You can read definitions of the terms in our glossary: ABDM, ABHA, HFR and HPR.

What do ABDM M1, M2 and M3 actually mean?

When software vendors talk about ABDM, they usually talk about milestones. These are commonly described as follows:

1. M1: ABHA and identity. The software can create and verify ABHA numbers and addresses, typically through OTP-based authentication, and link them to patient registration.
2. M2: Health Information Provider (HIP). The software can create "care contexts" (an encounter such as an OPD visit or an admission), link them to a patient's ABHA, respond to discovery and consent requests, and send the records in the prescribed format.
3. M3: Health Information User (HIU). The software can request records from other providers, with the patient's consent, and display them to the treating clinician.

M2 is where most of the engineering effort sits. Health records must be exchanged using FHIR, the international health data standard. The National Resource Centre for EHR Standards (NRCeS) publishes a FHIR Implementation Guide for ABDM, based on FHIR R4, with record types that include diagnostic reports and discharge summaries. If you want the background, see our glossary entries on FHIR and HL7.

Per the ABDM sandbox documentation, any solution first integrates in a sandbox environment that is separate from the live ecosystem. After that, the integrating entity goes through an exit process that includes a demonstration, functional testing and a security audit by NHA-empanelled agencies, and submission of an exit form with the supporting reports.

As a hospital buyer, the question to ask is simple: "Which of M1, M2 and M3 has your software completed, and can I see the evidence?" Treat any vendor that answers vaguely with caution. Likewise, be careful about reading marketing claims as legal guarantees. The honest wording for any HMS is that it is "designed for", "supports" or is "ready for" ABDM workflows.

How does Scan and Share work at the OPD counter?

Scan and Share is the most visible ABDM feature for patients. According to PIB, the National Health Authority launched it in 2022. The patient scans a facility's QR code using an ABDM-enabled app, and their demographic details (name, gender, mobile number, date of birth and ABHA details) arrive in the hospital's system, which issues a digital queue token.

A PIB factsheet from July 2026 cites a study by the Indian Institute of Health Management Research (IIHMR) that found waiting times at registration fell from roughly an hour to a few minutes at participating facilities. Your own results will depend on how your front desk is organised.

For this to work smoothly, your OPD management system needs to:

• Receive the shared demographic profile and match it against existing patients, so a returning patient is not given a second UHID.
• Issue a token and route the patient to the right doctor queue.
• Store the ABHA number against the UHID for later record linking.
• Let reception staff create an ABHA for a patient who does not have one, with the patient's consent.

Duplicates are the main failure point. If registration staff create a fresh record each time a patient arrives, records scatter across multiple UHIDs and linking becomes unreliable. A duplicate-merge process in your medical records department is therefore part of ABDM readiness, which is why medical records (MRD) software with a merge queue matters.

How does consent work, and what does it mean for your software?

The official explanation is that ABDM-enabled software lets facilities create digital health records linked to the ABHA, access a patient's earlier records after taking the patient's consent, and exchange records through the patient's revocable, time-bound consent.

Three practical implications follow:

• Consent is per purpose and per period. Your system should record what was consented to, for whom, and until when.
• Consent can be withdrawn. Staff and software must stop sharing when it is revoked.
• Everything should be logged. A full audit trail of who viewed, created or shared a record is how you answer questions later.

Consent also links directly to India's data protection law. We cover that in our guide to DPDP Act obligations for hospitals.

What do hospitals need to do before going live? A practical checklist

Use this as a working checklist for a hospital or nursing home. The order matters.

1. Register the facility on HFR. Collect the facility's licence and registration documents, specialities and contact details. Assign one person to own the profile.
2. Register treating doctors on HPR. Each doctor needs a verified professional identity. Do this early, because verification depends on the doctor's own documents.
3. Clean your patient master. Run a duplicate check, fix missing or shared mobile numbers, and agree one rule for name spelling and date-of-birth entry.
4. Choose ABDM-enabled software. Confirm the milestone status in writing, the sandbox-to-production path, and who handles updates when specifications change.
5. Map your records. Decide which records you will link first. Most hospitals start with OPD prescriptions and diagnostic reports, then add discharge summaries.
6. Define consent and privacy procedures. Train front-desk staff to explain ABHA in simple language and to record consent properly.
7. Pilot in one department. Start with OPD or the lab, measure how many registrations carry an ABHA, and fix problems before adding IPD.
8. Train, monitor, review. Track error queues and failed links monthly.

If you run a full inpatient service, build in your IPD discharge summary workflow early, since that is one of the most useful records to share.

Which records matter first: lab reports, prescriptions or discharge summaries?

Start where volume is high and the document is structured.

• Diagnostic reports. Lab and imaging results are already generated digitally in most hospitals. A laboratory information system that issues typed, template-based reports is a natural source. Our guide to the laboratory information system explains how orders become reports.
• OPD prescriptions. Doctors in an OPD workflow with live case sheets produce structured prescriptions daily.
• Discharge summaries. Valuable for continuity of care, but they depend on complete IPD documentation, so they come later.

Notice what the list has in common: ABDM is much easier when your basic clinical documentation is already digital. A hospital still writing OPD slips by hand has a documentation problem before it has an ABDM problem. That is why we treat the two goals together in ABDM and NABH readiness.

What about incentives and claims?

PIB's July 2026 factsheet describes a Digital Health Incentive Scheme (DHIS) under which participating facilities, and digital solution companies, can earn incentives for creating interoperable digital health records, and can be reimbursed for digitisation expenses. The same document lists clinics, nursing homes, hospitals, laboratories, imaging centres and pharmacies as eligible facility types.

The scheme's conditions, caps and timelines can change, so do not build a business case on a number you read in a blog post, including this one. Read the current scheme notice on the ABDM website, and ask your software vendor to explain how record linking is counted.

On the insurance side, the same factsheet describes NHCX as a digital exchange for claims-related information among payers, providers and beneficiaries. If your hospital handles heavy TPA and scheme volumes, structured claims data matters, and we cover the workflow side in our post on TPA claim management.

What mistakes slow ABDM adoption down?

• Treating registration as the finish line. Getting on HFR is step one. The real work is the daily workflow.
• Ignoring data quality. Shared family mobile numbers and misspelt names create wrong matches.
• Not training the front desk. Patients ask reception what ABHA is. If staff cannot explain it in a sentence, adoption stalls.
• Skipping privacy design. Consent, access control and logs need to be designed in, not patched.
• Buying a bolt-on that cannot see your clinical data. If the ABDM component is disconnected from OPD, lab and discharge workflows, staff end up re-keying data.

Where does DevOrbital HMS fit?

DevOrbital HMS offers an ABDM-ready add-on module designed to work with its OPD, laboratory, medical records and discharge workflows, and every module can also be adopted on its own. We do not claim any specific ABDM milestone certification here. Ask any vendor, including us, for the current status and evidence during your evaluation. Details are on the ABDM integration module page.

Next steps

Start with the checklist above and a one-department pilot. To see how the identity, consent and record-linking pieces connect, read about the ABDM integration module, and review how medical records (MRD) handles duplicates and record completeness.