ABDM 3.0: What the New Interoperability Rules Mean for Your Practice

India’s Ayushman Bharat Digital Mission has been the most ambitious attempt to digitise a national healthcare infrastructure anywhere in the developing world. Since its formal launch on 27 September 2021, ABDM has created over 840 million ABHA (Ayushman Bharat Health Account) identifiers, linked more than 670 million electronic health records, and onboarded over 450,000 health facilities onto its digital backbone. Those numbers are staggering. But for most practitioners on the ground, ABDM has remained something that exists in government press releases rather than in their daily workflow. That is about to change.

ABDM’s latest regulatory push — widely referred to as the 3.0 phase — marks a decisive shift from voluntary participation to mandatory compliance. If you are a practitioner, hospital administrator, diagnostic lab operator, or healthtech vendor in India, the implications are both immediate and significant. This is not a future aspiration. The compliance timelines are being enforced now, and the penalties for non-compliance are real.

This article breaks down what has changed, who is affected, what the technical requirements look like, and what you should be doing today to prepare.

From Voluntary Adoption to Mandatory Compliance

The most consequential shift in ABDM 3.0 is regulatory teeth. For the first three years of its existence, ABDM operated largely as a voluntary framework. Hospitals could choose to integrate. EMR vendors could choose to support ABDM protocols. Patients could choose to create an ABHA ID. The result was predictable: adoption was concentrated in large urban hospital chains and government facilities, while the vast middle layer of Indian healthcare — the district hospitals, private nursing homes, standalone diagnostic labs, and solo practitioner clinics — remained largely untouched.

ABDM 3.0 ends that ambiguity. Under the new framework, all healthcare IT systems — electronic medical record (EMR) platforms, hospital information systems (HIS), laboratory information systems (LIS), pharmacy management tools, and telemedicine platforms — are required to comply with standardised health data exchange protocols. This is not a recommendation. It is a compliance requirement with defined timelines, certification milestones, and enforcement mechanisms.

The first domino to fall has been AB-PMJAY hospitals. A directive from the ABDM State Mission Director in Bihar — now being replicated across states — has mandated that all private hospitals empanelled under the Ayushman Bharat Pradhan Mantri Jan Arogya Yojana (AB-PMJAY) insurance scheme must achieve ABDM compliance. This effectively brings tens of thousands of private hospitals and their software vendors under the compliance umbrella. Failure to comply risks de-empanelment from AB-PMJAY, which for many hospitals means losing access to a significant portion of their insured patient base.

The National Medical Commission has added a parallel mandate: every medical college in India is now required to issue ABHA IDs to all outpatients, inpatients, and emergency patients. This serves a dual purpose — it accelerates ABHA adoption at the point of care and creates a verifiable clinical workload record that the NMC can audit, addressing long-standing concerns about institutions inflating patient numbers during inspections.

ABDM 3.0 is not an incremental update. It is a regulatory line in the sand: interoperability is no longer optional, and every healthcare IT system in India will need to comply.

The Technical Foundation: FHIR, ABHA, and the Three Gateways

Understanding what compliance actually requires means understanding the technical architecture that ABDM has built. There are three foundational components that every practitioner and IT team needs to know.

HL7 FHIR R4: The Universal Data Language

At the centre of ABDM’s interoperability mandate is the adoption of HL7 FHIR (Fast Healthcare Interoperability Resources) R4 as the primary data exchange standard. FHIR has become the global default for health data interoperability, used by systems ranging from the NHS in the United Kingdom to the ONC-mandated frameworks in the United States. India’s adoption of FHIR under ABDM means that patient records, diagnostic reports, prescriptions, and discharge summaries must all conform to a common structural format.

The National Resource Centre for EHR Standards (NRCES) has published a detailed FHIR Implementation Guide — currently at version 6.5.0 — that defines the minimum conformance requirements for health data exchange in the Indian context. The guide specifies FHIR resource profiles for four key document types:

• Clinical consultations — structured encounter records with diagnosis codes, clinical notes, and treatment plans
• Diagnostic reports — laboratory and imaging results in standardised formats that any receiving system can parse and display
• Prescriptions — medication records with drug identifiers, dosages, and dispensing instructions
• Discharge summaries — comprehensive care summaries that follow a patient from inpatient to outpatient settings

All data must be encapsulated in FHIR Composition bundles with encryption, ensuring that when a patient’s record moves from one facility to another, the receiving system can parse, display, and act on it without manual re-entry. The days of proprietary data silos — where one hospital’s EMR cannot communicate with another’s — are being formally ended by regulation.

ABHA: The Universal Patient Identifier

The ABHA (Ayushman Bharat Health Account) is a 14-digit health identifier linked to Aadhaar that serves as the universal patient identity layer. With over 840 million ABHAs created as of early 2026, the scale of coverage is approaching universality. Every healthcare encounter under the ABDM framework must be linked to the patient’s ABHA, creating a longitudinal health record that follows the patient across facilities, specialties, and care settings.

For practitioners, this means that when a patient presents their ABHA ID, you can — with appropriate consent — access their complete medical history from any ABDM-linked facility they have previously visited. Consultations, lab reports, prescriptions, imaging records, and discharge summaries are all accessible through the Health Information Exchange. This is not a theoretical capability. It is operational today in facilities that have completed ABDM integration.

The Three Gateways

ABDM’s interoperability architecture rests on three gateway systems that facilitate different types of health data transactions:

Health Information Exchange and Consent Manager (HIE-CM): This is the core data exchange layer. When you request access to a patient’s records from another facility, HIE-CM handles the consent request, manages the data transfer, and maintains the audit trail. Every data access event is logged, timestamped, and linked to a specific consent grant — providing legal clarity for both providers and patients.

Unified Health Interface (UHI): Think of UHI as the “UPI for healthcare.” It is an open, interoperable network that connects patients with providers across platforms. Through UHI, patients can discover doctors, book physical or teleconsultation appointments, find available hospital beds, schedule home lab sample collection, and locate diagnostic services — all without being locked into a single application. For telemedicine providers, UHI integration means your services become discoverable across every UHI-enabled health app in the country, dramatically expanding your patient reach.

National Health Claims Exchange (NHCX): This gateway handles claims data exchange between providers and insurers. Under the new framework, claims processing becomes standardised and interoperable — reducing the paperwork burden on hospitals and accelerating reimbursement cycles. For hospitals that bill insurance companies, NHCX integration is not just about compliance. It is about operational efficiency and cash flow.

What This Means for Different Practice Types

The practical impact of ABDM 3.0 varies significantly depending on the size and digital maturity of your practice. But the universal truth is: no one is exempt.

Large Hospitals and Multi-Specialty Chains

For large hospital groups — Apollo, Fortis, Max, Narayana Health, AIIMS network — the transition may be smoother but the scope is substantial. Most major chains already use established EMR platforms, whether proprietary or from vendors like Practo, BahmniHealth, or international systems adapted for India. These platforms need to be updated to support FHIR R4-based data exchange, ABHA-linked patient identification, and the new consent protocols.

IT departments must audit current data formats, map them to FHIR resource profiles, test interoperability with the ABDM gateway through the sandbox environment, and then progress through the M1, M2, and M3 certification milestones. The typical integration timeline runs three to six months from scratch, though hospitals with existing digital infrastructure can often accelerate this. The critical dependency is vendor readiness — if your EMR vendor has not yet achieved ABDM certification, that becomes your bottleneck.

District and Tier 2/3 Hospitals

This is where the compliance challenge is most acute. Many district hospitals and mid-sized private hospitals operate on legacy IT systems — sometimes a basic HIS for billing and bed management, sometimes nothing more than a shared Excel spreadsheet. These facilities must now adopt ABDM-compliant EMR systems that can generate FHIR-formatted health records, link encounters to ABHA IDs, and participate in the consent-driven data exchange framework.

The good news is that the National Health Authority maintains a registry of approved, ABDM-certified EMR and health locker applications, several of which are available at low or no cost for smaller facilities. The challenge is implementation: training staff on new digital workflows, migrating existing records, establishing reliable internet connectivity, and finding someone — even a single person — who can manage the technical integration on an ongoing basis. For hospitals already empanelled under AB-PMJAY, the urgency is compounded by the risk of de-empanelment for non-compliance.

Small Clinics and Solo Practitioners

For the hundreds of thousands of small clinics and solo practices across India, ABDM 3.0 represents the most fundamental shift. Many of these practices still operate without any digital EMR, relying on paper records or basic software that stores data in non-standardised formats. The new framework effectively mandates digital record-keeping that conforms to national standards.

The transition path involves adopting an ABDM-certified EMR application — many of which are cloud-based and designed specifically for small practice workflows. The NHA has worked with several vendors to create lightweight applications that can run on a smartphone or tablet, with minimal training required. But adoption requires investment: not just in software, but in changing deeply ingrained clinical documentation habits. Practitioners who have written prescriptions by hand for decades will need to adapt to structured digital entry. This is a cultural shift as much as a technical one.

Diagnostic Labs and Pharmacies

Laboratories and pharmacies face specific compliance requirements. Labs must generate diagnostic reports in FHIR-formatted bundles that can be linked to the ordering physician’s consultation and the patient’s ABHA record. Pharmacies must record dispensing events that link prescriptions to their fulfilment. For large chain labs — Thyrocare, SRL, Dr Lal PathLabs, Metropolis — this means upgrading their LIS and LIMS systems to FHIR compliance. For standalone labs, the compliance path is similar to small clinics: adopt a certified system and begin generating standardised records.

Consent Management: The New Clinical Workflow

One of the most practically significant changes under ABDM 3.0 is the overhaul of consent management. The Health Information Exchange and Consent Manager (HIE-CM) framework has been strengthened with granular consent controls that will become a routine part of clinical encounters.

Under the new framework, patients have precise control over their health data:

• What data is shared (specific documents, date ranges, or entire records)
• With whom it is shared (specific providers, facilities, or categories)
• For what purpose (clinical care, second opinion, insurance claim, research)
• For how long the access grant remains valid

Before accessing a patient’s records from another facility, you will need to request and receive digital consent through the HIE-CM. The patient approves — or denies — the request through their ABHA-linked health app. The consent trail is fully auditable, which protects both the patient and the provider. If a data access dispute ever arises, there is a timestamped, cryptographically verifiable record of exactly who consented to what, and when.

For practitioners, this adds a step to patient interactions, particularly for new patients or referral cases where you need historical records. But it also provides legal clarity that the current informal system of paper consent forms and verbal agreements cannot match. The key is to integrate consent workflows smoothly into your EMR system so that requesting and receiving consent becomes as routine as ordering a lab test.

The AI Connection: Why ABDM 3.0 Matters for Clinical AI

For those following the clinical AI space in India, ABDM 3.0 is arguably the most important policy development in recent years — not because it directly regulates AI, but because it creates the data infrastructure that makes clinical AI viable at scale.

Solving the Data Problem

The fundamental bottleneck for AI in Indian healthcare has never been algorithms. It has been data. Clinical AI models require large volumes of structured, standardised health data to train effectively and perform reliably across diverse populations. Until now, India’s health data has been fragmented across thousands of incompatible systems, stored in inconsistent formats, and largely inaccessible for secondary use.

ABDM 3.0’s interoperability mandates begin to solve this problem at the structural level. When every facility generates records in the same FHIR format, linked to a universal patient identifier, the resulting data ecosystem becomes vastly more useful for AI applications. Population health analytics, predictive models for disease outbreaks, clinical decision support systems, and drug interaction alerts all become more feasible when the underlying data is standardised and accessible.

AI-Ready Data Pipelines

ABDM 3.0 explicitly acknowledges that structured, interoperable health data is a prerequisite for clinical AI. The framework includes provisions for anonymised data aggregation that can feed into population health analytics and AI model training, provided appropriate consent and de-identification protocols are followed. This is the first time India’s digital health policy has directly addressed the data infrastructure needs of artificial intelligence in healthcare.

The second phase of ABDM priorities explicitly includes automated patient-matching via AI and integration with wearables and IoT devices for continuous care monitoring. This signals a clear trajectory: as the standardised data layer matures, AI-driven tools will be layered on top of it — not as standalone products, but as integrated components of the national health information architecture.

Accountability Goes Both Ways

There is a reciprocal dimension that AI vendors must understand. As structured data enables better AI inputs, the regulatory framework also increases scrutiny on AI outputs. ABDM’s provisions around data use, consent, and auditability mean that any AI system operating within the ABDM ecosystem must demonstrate compliance with the same standards. If an AI tool generates a diagnostic suggestion based on a patient’s ABDM-linked records, the data access must be consented, the processing must be auditable, and the output must integrate into the structured record in a standards-compliant way.

Interoperability does not just feed AI — it governs it. The same data standards that make clinical AI possible also make it accountable.

The Compliance Roadmap: M1, M2, and M3 Milestones

ABDM certification follows a structured milestone-based process. Understanding these milestones is essential for planning your compliance timeline.

Sandbox Registration and Testing

The first step is registering your healthcare software on the ABDM sandbox environment. The sandbox provides a testing environment where you can validate your FHIR implementations, test consent workflows, and verify ABHA integration without affecting real patient data. All integrations must be thoroughly tested in sandbox before applying for production access.

M1: ABHA Creation and Verification

The first certification milestone focuses on the ability to create and verify ABHA IDs within your system. This includes Aadhaar-based and mobile-based ABHA creation, demographic verification, and linking patients to their ABHA accounts at the point of registration.

M2: Health Record Linking

The second milestone requires demonstrating that your system can generate FHIR-compliant health records and link them to patient ABHA accounts through the HIE-CM framework. This includes creating structured clinical documents, pushing them to the health information exchange, and responding to data access requests from other providers.

M3: Full Interoperability

The final milestone validates end-to-end interoperability: your system must be able to discover, request, receive, and display health records from other ABDM-linked facilities. This includes full consent management workflows, data encryption in transit and at rest, and compliance with ABDM’s API specifications including correct field names, response codes, and data types.

The typical timeline from sandbox registration to M3 certification runs six to twelve weeks for organisations with strong technical teams. However, delays are common — particularly around API compliance, where even minor variations like incorrect field names or unsupported data types can lead to rejection. Building integration from scratch typically requires three to six months of development effort.

The Ground-Level Challenges

It would be misleading to present ABDM 3.0 as a purely positive development without acknowledging the very real challenges facing implementation.

Infrastructure Gaps

Reliable internet connectivity remains inconsistent in much of India, particularly in rural and semi-urban areas where ABDM adoption is most needed. Cloud-based ABDM integrations require stable broadband — uploading and downloading FHIR bundles, processing consent requests in real-time, and syncing with the ABDM gateway all demand reliable connectivity that many facilities do not yet have. Edge computing and offline-first approaches are being developed by some vendors, but these are not yet widely available.

Digital Literacy

A lack of digital literacy among both healthcare workers and patients is a significant barrier. Many patients — particularly senior citizens, rural populations, and women — struggle to navigate digital health platforms. Many healthcare workers have limited experience with structured digital documentation. Training programmes must accompany technology deployment, and these programmes need to be sustained, not one-off.

Vendor Fragmentation

The Indian healthcare IT market is highly fragmented, with hundreds of EMR, HIS, and LIS vendors of varying quality and scale. Not all vendors have the technical capacity or commercial incentive to achieve ABDM certification quickly. Hospitals and clinics that depend on smaller or regional software vendors may find themselves stuck if their vendor lags on compliance. Evaluating vendor ABDM readiness should be an immediate priority.

Privacy and Trust Concerns

Despite ABDM’s alignment with the Digital Personal Data Protection Act (DPDP Act, 2023) and its federated architecture — which keeps data at the source rather than centralising it — concerns about data privacy and security persist. Patients need to trust that their health data will not be misused. Practitioners need assurance that the consent framework provides adequate legal protection. Building this trust requires transparency, education, and a demonstrated track record of data security — all of which take time to establish.

What You Should Do Now

The transition timelines for ABDM 3.0 compliance are being enforced in phases, but the direction is clear and the window for preparation is now. Here are the concrete steps every practitioner should take.

1. Audit your EMR compliance. If you are using an EMR system, check whether your vendor has achieved ABDM certification or has published a clear roadmap for FHIR-based data exchange and ABHA integration. Specifically, ask about M1/M2/M3 milestone status. If your vendor has not communicated a clear plan, that is a signal to start evaluating alternatives. If you are not using an EMR at all, begin exploring ABDM-certified options from the NHA’s registry of approved applications.

2. Understand the consent framework. Familiarise yourself with how the Health Information Exchange and Consent Manager works. Understand how patients grant and revoke consent, how you request access to records from other facilities, and what your obligations are when another provider requests access to records you have created. This is not just a technical workflow — it has medico-legal implications that every practitioner should understand.

3. Register on the ABDM sandbox. If you have an in-house IT team or work with a health IT vendor, ensure that ABDM sandbox registration has been completed and testing is underway. The sandbox environment is free to use and provides the testing infrastructure needed to validate FHIR implementations before going live.

4. Initiate the conversation with your IT team or vendor. Whether you work in a large hospital with a dedicated IT department or a small clinic using a cloud-based EMR, the people who manage your technology stack need to be actively planning for these changes. Ask specific questions: What is the timeline to M3 certification? What resources are needed? What is the fallback if the current system cannot be made compliant?

5. Train your clinical and administrative staff. ABDM compliance is not just a technology problem. Front-desk staff need to know how to create and verify ABHA IDs. Clinicians need to understand structured digital documentation. Administrative teams need to manage consent workflows. Invest in training now so that when the technical integration goes live, your team is ready to operate within the new framework.

6. Monitor official timelines and enforcement actions. ABDM 3.0 is being rolled out in phases. The National Health Authority and the Ministry of Health and Family Welfare are publishing updates on compliance deadlines, certification requirements, and support resources. For AB-PMJAY empanelled hospitals, compliance enforcement has already begun. Subscribe to official NHA channels, follow digital health industry bodies, and stay current on state-level directives that may affect your facility.

7. Plan for the cost of compliance. While many ABDM-certified applications are available at low cost, the total cost of compliance includes software licensing or subscription, integration development (if not using a turnkey solution), staff training, potential hardware upgrades, and ongoing maintenance. Budget for these costs now rather than treating them as an emergency expense later.

The shift toward mandatory interoperability is not a threat to clinical practice. It is an upgrade to the infrastructure that supports it. Practitioners who prepare now will find themselves better equipped to deliver care, collaborate across institutions, and leverage the next generation of clinical tools — including AI — that depend on structured, accessible health data. Those who delay will face a steeper climb later.

The regulatory landscape is shifting. The question is not whether these changes will affect your practice, but whether you will be ready when they do.