ABDM Integration for Hospital Software: ABHA, HFR and M1-M3 Explained

ABDM integration connects your hospital software to India's national digital health network, so patients can create or link their ABHA, share records with you by consent, and carry your discharge summaries and lab reports to their next doctor. For a hospital, it touches registration, records, consent and reporting, not just a single API.

The Ayushman Bharat Digital Mission (ABDM), run by the National Health Authority (NHA), is building shared building blocks: a health ID for every citizen, registries of facilities and professionals, and a consent-based way to exchange records. Your hospital management system plugs into these blocks.

This guide explains each piece in plain terms, what the M1, M2 and M3 milestones mean, how the Digital Health Incentive Scheme fits in, and how to plan ABDM integration without disrupting your front desk.

The ABDM building blocks in one view

Before talking about integration, it helps to know what you are integrating with. ABDM has a handful of core components, and each one maps to a part of your hospital workflow.

Your hospital is registered once in HFR. Your doctors register in HPR. Patients bring an ABHA. Your software, if ABDM-integrated, ties them together for every visit.

ABHA creation and linking at registration

The first and most visible part of ABDM integration is ABHA at the front desk. A patient arriving for OPD should be able to do one of three things: create a new ABHA, verify an existing ABHA, or link the ABHA to their hospital record so future records are associated with it.

Creation typically uses Aadhaar-based OTP or other permitted methods. Verification can be done by OTP to the mobile linked to the ABHA or through the patient's ABHA app. Once verified, the demographic details from ABHA can pre-fill your registration form, cutting typing errors in name, age and gender.

Good front-desk design keeps this quick:

• Make ABHA optional, never a gate to care, as ABDM intends
• Offer ABHA lookup by number, ABHA address or mobile
• Pre-fill registration from verified ABHA data, with staff able to correct local details like address
• Store the ABHA number and address against the patient master, not just against a visit
• Show a clear indicator on the patient banner when ABHA is linked

Scan and Share: the queue-friendly feature

Scan and Share lets a patient scan a QR code displayed at your registration counter using an ABHA-enabled app. Their profile is shared with your facility, and your system can generate a token without the patient filling a form or staff typing details.

For busy OPDs, this is often the most practically useful ABDM feature. It moves data entry from the counter to the patient's phone. It also pairs well with a patient queue management system, because the token issued via Scan and Share can drop straight into the doctor's queue.

To make it work you need a facility-specific QR code linked to your HFR entry, an integration that receives the shared profile and creates or matches a patient record, and a front-desk screen showing incoming Scan and Share registrations in real time.

Understanding the M1, M2 and M3 milestones

NHA describes ABDM integration for software in milestones. They are not separate products. They are levels of capability, and each builds on the previous one.

M1 is mostly a registration change. M2 is where your hospital becomes a source of records: every OPD consultation, lab report or discharge summary becomes a care context linked to the patient's ABHA, which the patient can later share. M3 makes your hospital a consumer, so a doctor can request and view, with consent, records created elsewhere.

Records are exchanged in FHIR format using profiles published for India, covering health information types such as OP consultation notes, prescriptions, diagnostic reports, discharge summaries and immunisation records. If your clinical data is mostly free text in scanned PDFs, M2 will expose that quickly. See our HL7 and FHIR integration guide for the underlying standards.

HFR and HPR: getting the registries right

Two registries sit under every ABDM transaction. The Health Facility Registry is where your hospital is listed with verified details: ownership, location, specialities and services. The Healthcare Professionals Registry lists doctors, nurses and other professionals, verified against their council registrations.

For integration, your software needs your facility's HFR ID configured correctly, and ideally each doctor's HPR ID stored in the doctor master. When a record is shared, it carries information about where and by whom it was created.

Common snags we see:

1. HFR details that do not match the hospital's legal documents, delaying verification
2. Branches registered under one HFR ID when they should be separate facilities
3. Visiting consultants who have not completed HPR registration
4. No one in the hospital owning the registry logins after the person who set them up leaves

Assign a named owner for ABDM administration, usually in the medical records or IT team, and document the credentials and process.

Consent: the heart of ABDM

ABDM is built on consent. When another facility or the patient wants records you hold, a consent request flows through the consent manager. The patient approves it in their ABHA app, choosing which records, for what period and for how long access lasts. Only then does your system send the encrypted records.

For your hospital, this means three things. Your software must respond to consent-based requests automatically and securely, without staff manually emailing files. Records must be correctly linked to care contexts, or the patient will not see them to share. And you must log what was shared, when and with whom, which supports your obligations under the DPDP Act and hospital data security.

The Digital Health Incentive Scheme

To encourage adoption, NHA runs the Digital Health Incentive Scheme (DHIS). Under it, eligible hospitals, diagnostic labs and in some cases digital solution providers can receive incentives based on the number of digital health transactions they generate, such as records linked to ABHA, beyond a defined baseline.

The amounts, thresholds, eligibility rules and the scheme's validity period have been revised over time, so check the current DHIS guidelines on the ABDM website before you build a business case around it. Treat incentives as a bonus, not as the main reason to integrate.

How to plan ABDM integration

Whether you build it into custom software or ask your current vendor to enable it, a structured plan helps. A realistic sequence for a mid-sized hospital:

1. Register the facility in HFR and get doctors onto HPR
2. Complete M1 in your software and go live at registration with one counter first
3. Set up Scan and Share at OPD counters and measure registration time
4. Clean up clinical templates so OPD notes, lab reports and discharge summaries are structured
5. Build M2: link care contexts and test record sharing end to end
6. Build M3 for doctors who will benefit from seeing outside records, such as emergency and referral clinics
7. Monitor transactions, errors and consent requests weekly

Integrators work in the ABDM sandbox first, then go through NHA's testing and approval process before production access. Budget time for that process, not just for coding.

If your current software cannot do this, an integration layer can sometimes sit alongside it. Our healthcare integration work often takes this route when replacing the core system is not on the table.

Common mistakes in ABDM projects

Most ABDM projects that disappoint do so for operational reasons, not technical ones. The integration passes testing, but daily use stays low.

The mistakes we see most often:

• Treating ABDM integration as an IT task with no owner at the front desk or medical records
• Creating duplicate patient records because ABHA matching was not designed against the existing patient master
• Linking care contexts only for some departments, so patients see an incomplete history
• Sharing scanned PDFs labelled as structured records, which defeats the purpose of FHIR
• Forgetting multi-branch setups, where each branch needs its own HFR identity and QR code
• No monitoring, so failed transactions go unnoticed for weeks

The fix is the same in each case: give ABDM a business owner, measure it weekly, and review a sample of linked and shared records with real staff. A short dashboard showing ABHA links, Scan and Share registrations, care contexts linked and consent requests served will tell you within a month whether the integration is working in practice.

Questions to ask your vendor

Use these to separate real ABDM integration from a checkbox:

• Which milestones are live in production today, and at how many facilities?
• Is Scan and Share supported, and how does it create or match patient records?
• Which health information types are shared in FHIR, and are they structured or PDF wrappers?
• How are consent requests logged and shown to the hospital?
• Who handles NHA approvals and changes when the ABDM APIs are updated?
• What happens to registration if ABDM services are temporarily unavailable?

Conclusion

ABDM integration is worth doing properly. M1 and Scan and Share can shorten your registration queue within weeks. M2 and M3 take longer because they depend on structured clinical records, but they make your hospital part of a connected network patients increasingly expect.

Algon builds ABDM-ready flows into the custom hospital management system projects we deliver from Kochi. If you want to understand what it would take for your hospital, contact us and we can walk through your current registration and records setup.