ABDMPM-JAYHealthcare Interoperability

ABDM Compliance for AB-PMJAY Hospitals (2026): M1 and M2 Requirements, Incentives and a Step-by-Step Plan

March 18, 202614 min readUpdated Oct 15, 2026
Written by
Yogesh Daga
Yogesh Daga

Founder & CEO

15+ years building healthcare technology. Founder & CEO of Nirmitee.io, whose teams deliver EHR integrations, FHIR and HL7 platforms, ABDM and NHCX connectivity, and clinical AI for health systems and healthtech companies.

ABDM Compliance for AB-PMJAY Hospitals (2026): M1 and M2 Requirements, Incentives and a Step-by-Step Plan

ABDM compliance for an AB-PMJAY hospital means that the hospital's software (HMIS) is integrated with the Ayushman Bharat Digital Mission at Milestone 1 and Milestone 2 or higher: it creates and verifies ABHA numbers at registration (M1) and links and shares each patient's records with their consent (M2), under the hospital's HFR facility ID. If the PMJAY transaction system shows "Hospital incentives are inactive in PMJAY application due to non-compliance with ABDM-HMIS and M1, M2 (or higher) requirements", the hospital's software is not yet recognized as meeting that bar. The fix starts in the HMIS; the PMJAY portal only reflects it.

This guide explains that message, what ABDM compliance means in plain language, what is actually at stake for a PMJAY hospital, and a step-by-step plan to get there, whether you run a 50-bed hospital or build software for hundreds of them. Updated September 2026.

"Hospital incentives are inactive in PMJAY application": what it means and how to fix it

This message appears in the PMJAY application when the hospital's ABDM-HMIS status does not meet the M1 and M2 (or higher) requirement. In practice it means one of three things: the hospital's software has not completed ABDM Milestones 1 and 2 in production, the software is not linked to the hospital's HFR (Health Facility Registry) ID, or the software is integrated but the hospital is not yet creating and linking ABHA records in day-to-day use.

  1. Ask your HMIS vendor for their ABDM production status. Has their software exited the ABDM sandbox with M1 and M2? A vendor that is "working on ABDM" or only has M1 does not meet the requirement; the sandbox exit itself needs at least two milestones.
  2. Check the HFR ID in your software. Your facility must be registered on the Health Facility Registry, and the same HFR ID must be configured in the HMIS so the records it links are attributed to your hospital.
  3. Start linking in production. Create or verify ABHA at registration and link each visit (care context) to the patient's ABHA. Compliance is judged on real, daily use of ABHA linking.
  4. Raise it with your State Health Agency with your HMIS name, its ABDM status and your HFR ID, so the status can be reviewed.

If your HMIS vendor cannot support ABDM, you can switch to software that has already exited the sandbox, or add an ABDM layer to your current system. Our ABDM integration services team does the second for hospitals and for HMIS vendors.

Who this affects

AB-PMJAY is India's largest government health scheme, providing cover of up to ₹5 lakh per family per year for secondary and tertiary hospital care. More than 15,700 private hospitals were empanelled under it as on 31 December 2025, according to a PIB update on AB-PMJAY, alongside thousands of public hospitals. ABDM compliance reaches beyond the hospitals themselves:

  • HMIS and EMR vendors whose software runs empanelled hospitals must support ABDM in their product.
  • Laboratory, radiology and pharmacy systems hold records that belong in the patient's ABDM history.
  • Integrators and health-tech companies serving hospitals need ABDM in what they build.
  • State Health Agencies administer PMJAY and review hospital status in their state.

The platform is already at national scale: in May 2026 PIB reported more than 100 crore health records linked to more than 90 crore ABHA accounts. ABDM Milestone 1 is also the first step for hospitals that want to process PMJAY claims inside their own HMIS through NHCX; see PMJAY on NHCX for the full path.

What ABDM compliance means, in plain language

ABDM compliance is a set of capabilities your hospital's software must show, grouped into three milestones. ABDM itself, the Ayushman Bharat Digital Mission run by the National Health Authority, was launched nationally in September 2021. For the wider context beyond hospital compliance, see our guide to comparing national health data networks.

Milestone 1 (M1): knowing the patient, the ABHA layer

  • Create an ABHA number for patients who do not have one, with Aadhaar or mobile OTP.
  • Verify the ABHA of patients who already have one, including by Scan and Share at the registration desk.
  • Save the ABHA on the patient's record in your HMIS.

Milestone 2 (M2): sharing your records, the HIP role

Milestone 2 refers to your hospital acting as a Health Information Provider (HIP). Your software must:

  • Link each visit, admission, lab report and discharge (a care context) to the patient's ABHA.
  • Answer when a patient searches for their records at your hospital and links them in a PHR app.
  • Respond automatically when a consent is granted, sending the records as FHIR R4 bundles, encrypted.

M2 is the heavy lift for most hospitals, because it needs structured records; scanned documents alone are not enough. Our ABDM FHIR bundles patient journey shows which records a typical visit produces.

Milestone 3 (M3): seeing outside records, the HIU role

M3 compliance makes your hospital a Health Information User (HIU): doctors can request a patient's records from other hospitals and labs with the patient's consent, see them before a consultation, and the software must delete them when consent is revoked or expires. It is optional for the PMJAY M1 and M2 requirement, but it is where doctors see the benefit.

For the technical detail of each milestone, see our ABDM milestones M1 to M4 guide and the developer-level ABDM integration step-by-step guide.

Certification and security: what happens before go-live

Building the milestones in the ABDM sandbox is only part of it. To get production credentials, the software (usually your HMIS vendor's product) must:

  1. Pass NHA's functional test cases for each milestone.
  2. Pass a web application security audit (WASA) by a CERT-In empanelled auditor.
  3. Demonstrate the integration to NHA's team.
  4. Complete the sandbox exit, which needs at least two milestones.

If your vendor has already done this, the hospital does not repeat it; you use their certified software under your own HFR ID. Our ABDM certification process guide covers each stage.

What is actually at stake for a PMJAY hospital

  • Scheme incentives. The TMS message above ties hospital incentives to ABDM-HMIS status at M1 and M2 or higher. Separately, NHA's Digital Health Incentive Scheme (DHIS) pays eligible facilities and software companies for ABHA-linked digital health records, with incentives of up to ₹4 crore per entity when it was announced (PIB). A non-compliant hospital earns neither.
  • Empanelment conditions set by your state. State Health Agencies manage empanelment and can set ABDM expectations for their hospitals. Check the latest circulars from your SHA rather than relying on reports from other states.
  • Scheme enforcement is active. In a Lok Sabha reply in August 2026, the government reported 2,359 hospitals de-empanelled and 1,200 suspended under AB-PMJAY up to 31 May 2026, with ₹328.49 crore in penalties (ETV Bharat). Those actions were for guideline violations such as unauthorized billing and misuse of patient identity. They show how closely hospital conduct is monitored, and ABHA-verified identity strengthens that monitoring.
  • The move to digital claims. PMJAY claims are moving into hospital software through NHCX, and that route starts with ABDM Milestone 1.

The ABDM compliance roadmap, step by step

Step 1: Assess your digital readiness

  • Do you register patients digitally, with demographics captured at the desk?
  • Does your HMIS store structured data (diagnoses, medicines, lab values), or mostly free text and scans?
  • Who is your HMIS vendor, and what is their ABDM production status?
  • Do you have IT staff or a partner who can support integration and go-live?
  • Is your facility registered on HFR, and are your doctors on HPR?

Step 2: Choose your path

Use ABDM-ready software, add an ABDM layer to what you have, or build it yourself. The next section compares them, and our build vs buy vs SDK guide goes deeper for software teams.

Step 3: Complete M1 (ABHA)

ABHA creation and verification at registration, including Scan and Share. Get this right before M2: every later link depends on the patient's identity being correct.

Step 4: Complete M2 (HIP)

Care-context linking, patient discovery, consent handling and FHIR record sharing. This is the most demanding step because it depends on the quality of your data.

Step 5: Add M3 (HIU) if you want outside records

Consent requests and a viewer for records from other providers, with deletion when consent ends.

Step 6: Certification

NHA functional testing, the WASA audit, the demo and sandbox exit, done by whoever owns the software.

Step 7: Go live and keep it running

Configure your HFR ID in the software, train front-desk and clinical staff, and monitor linking every day. Compliance is an operating habit that continues after go-live.

Three paths to compliance: software, an ABDM layer or building

ABDM-ready HMISABDM layer on existing systemsBuild in-house
Best forHospitals ready to change softwareHospitals that want to keep their HMIS, lab and pharmacy systemsLarge chains or hospitals that develop their own software
DisruptionHigh: migration and retrainingLow: staff keep their screensLow to medium
CertificationAlready done by the vendor, if they have exited the sandboxDone once for the layerYou do it
Several systemsUsually one system onlyDesigned for HMIS plus lab, radiology and pharmacyComplex
Main riskData migration and lock-inNeeds API or database access to your systemsFHIR and callback expertise; ongoing ABDM changes

ABDM compliance checklist for a PMJAY hospital

ItemDone whenWho owns it
Facility on HFRYour hospital has an HFR ID and the details match your PMJAY empanelmentHospital administration
Doctors on HPRTreating doctors have HPR IDsMedical administration
HMIS at M1 and M2 in productionYour vendor confirms sandbox exit and production credentials for M1 and M2HMIS vendor
HFR ID configured in the HMISRecords your HMIS links are attributed to your facilityHMIS vendor and IT
ABHA at registrationEvery new patient is asked for ABHA; Scan and Share QR is at the deskFront desk
Visits linkedOPD visits, admissions, lab reports and discharges are linked as care contextsHMIS, lab and pharmacy systems
Consent handled automaticallyConsent requests are answered and records shared without manual stepsHMIS
MonitoringSomeone checks linking counts and failures every dayIT

Questions to ask your HMIS vendor this week

  1. Has your software exited the ABDM sandbox, and for which milestones (M1, M2, M3)?
  2. Is it running on ABDM production credentials today, and at which hospitals?
  3. Where do we enter our HFR ID, and how do we check that records are linked under it?
  4. Are lab, radiology and pharmacy reports linked, or only OPD visits?
  5. How are consent requests handled, and what happens if a callback from ABDM is missed?
  6. Which ABDM API version do you use, and how quickly did you move to V3?
  7. Does your roadmap include PMJAY claims through NHCX?

What decides how long compliance takes

The timeline depends far more on your starting point than on ABDM. The main drivers:

  • Whether your vendor has already exited the sandbox. If yes, most of the work is configuration, HFR setup and training.
  • How structured your records are. M2 is fast on structured data and slow on scanned documents.
  • How many systems hold records. Each extra system adds mapping and testing.
  • Queues for testing and audit. NHA functional testing and WASA slots are outside your control; start security work early.

Practical guidelines for hospitals to support ABDM day to day

  • At the registration desk: ask every patient for ABHA, offer Scan and Share, create ABHA for those without one, and do not skip verification when the queue is long.
  • At every stage of treatment: keep the PMJAY stages (registration, pre-authorization, treatment, discharge, claim) and the HMIS record in step, so the same visit is linked once with the right ABHA. Our PMJAY claim process guide explains the stages in TMS.
  • In clinical documentation: enter diagnoses, medicines and results as structured fields; they become the FHIR records ABDM shares.
  • In the lab and pharmacy: make sure their reports reach the same patient record so they are linked too.
  • In IT: monitor daily linking counts and failed links; a drop usually means a configuration or connectivity problem.

What small and mid-size hospitals should do differently

  • Do not rebuild your HMIS for ABDM. If your vendor is not ready, an ABDM layer that reads from your existing system is usually faster and cheaper.
  • Use a partner that has taken software through sandbox exit. A single IT administrator cannot also learn FHIR, Fidelius and NHA's test cases.
  • Train people before go-live. ABHA at the desk changes the registration routine.
  • Automate consent handling. Consent requests should be answered by software automatically.
  • Prefer hosted components if on-site servers or connectivity are weak, while keeping patient data within the controls your contracts require.

Common mistakes hospitals make on the ABDM journey

  1. Treating ABDM as an IT-only project. Registration, clinical documentation, lab and billing all change.
  2. Rushing M1. Wrong ABHA links create problems in every M2 record that follows.
  3. Underestimating FHIR. Converting records to FHIR R4 is data modeling work that takes clinical input.
  4. Building on outdated API documentation. ABDM has moved to V3; discovery and many other flows are asynchronous and answer through callbacks. See our V3 migration guide.
  5. Leaving the security audit to the end. WASA findings take time to fix.
  6. Integrating only the HMIS. Lab and radiology reports are part of the patient's record.
  7. Waiting for a single national deadline. Status is already visible in the PMJAY application; incentives and state requirements move first.

How we help hospitals and HMIS vendors

We have taken hospital software through ABDM's milestones, including an HMIS that has cleared sandbox exit and runs ABDM in production for its hospitals, and we build the next step for PMJAY hospitals: claims from the HMIS through NHCX. If your PMJAY application shows ABDM-HMIS non-compliance, or your vendor cannot say when they will be ready, our ABDM integration team can assess your systems and plan the fastest route. Talk to our team.

Ready to scale?

Talk to our healthcare engineering team about building, integrating, and shipping faster.

Frequently Asked Questions

What does "Hospital incentives are inactive in PMJAY application due to non-compliance with ABDM-HMIS and M1, M2 (or higher) requirements" mean?

It means the PMJAY application does not see your hospital's software as integrated with ABDM at Milestone 1 and Milestone 2 or higher. Check that your HMIS vendor has exited the ABDM sandbox with M1 and M2, that your HFR ID is configured in the HMIS, and that ABHA-linked visits are being created in production, then ask your State Health Agency to review the status.

What is ABDM compliance, and what does ABDM compliant mean?

ABDM compliance means your hospital's software is integrated with the Ayushman Bharat Digital Mission: it creates and verifies ABHA numbers (M1), links and shares records with patient consent as a Health Information Provider (M2), and optionally fetches records as a Health Information User (M3). A hospital is ABDM compliant when this runs in production under its HFR facility ID.

Is ABDM compliance mandatory for AB-PMJAY hospitals?

ABDM integration at M1 and M2 or higher is linked to hospital incentives in the PMJAY application, and State Health Agencies can set ABDM expectations for empanelled hospitals. Check your State Health Agency's latest circulars for requirements in your state.

What does Milestone 2 refer to in ABDM?

Milestone 2 refers to the Health Information Provider (HIP) role: your software links each visit and report to the patient's ABHA, answers discovery and consent requests, and shares the records as encrypted FHIR bundles when the patient consents.

What is ABDM M3 compliance?

M3 compliance means your software can act as a Health Information User: it requests a patient's records from other providers with consent, shows them to doctors, and deletes them when the consent is revoked or expires.

Can we become ABDM compliant without replacing our HMIS?

Yes. If your HMIS vendor cannot support ABDM, an ABDM layer can read records from your existing HMIS, lab and pharmacy systems, convert them to FHIR, and handle ABHA, linking and consent, so staff keep using the screens they know.

When did ABDM start?

The Ayushman Bharat Digital Mission was launched nationally by the National Health Authority in September 2021. By May 2026 more than 100 crore health records were linked to more than 90 crore ABHA accounts.

What are the ongoing obligations after going live on ABDM?

Keep creating or verifying ABHA for new patients, link every visit and report, answer consent requests automatically, keep the software current with ABDM API changes, and monitor linking daily so failures are caught early.
Share