A practical roadmap for connecting your clinic to India's national digital health infrastructure
The Ayushman Bharat Digital Mission (ABDM) is India's national framework for creating a unified digital health ecosystem. With over 900 million ABHA (Ayushman Bharat Health Account) numbers already created and government incentives of up to Rs. 4 crore available through the Digital Health Incentive Scheme, the question for private practices is no longer whether to integrate, but how quickly they can do so.
Yet adoption among private facilities remains strikingly low. As of October 2024, only approximately 17,000 out of 1.3 lakh ABDM-enabled facilities belong to the private sector, representing just 7% of private healthcare providers nationally. This gap represents both a compliance risk and a competitive opportunity.
This guide provides a plain-language explanation of ABDM's components, a step-by-step integration roadmap tailored for private clinics, and practical solutions to the most common challenges practices face during implementation.
The Ayushman Bharat Digital Mission, launched nationally in 2022 by the National Health Authority (NHA), is not a software product or a government portal. It is a set of interoperability standards and registries that allow any healthcare provider to share clinical records with any other provider, with the patient's explicit consent.
Think of ABDM as the UPI of healthcare. Just as UPI created a common protocol so any bank account could send money to any other bank account, ABDM creates a common protocol so any clinic can share a patient's health record with any other clinic. The patient controls access through consent, and the data stays with the provider who created it.
| Component | What It Does | Analogy |
|---|---|---|
| ABHA (Health Account) | A unique 14-digit health ID for every citizen, linked to Aadhaar or mobile | Like a bank account number for health data |
| Health Facility Registry (HFR) | A verified directory of all healthcare facilities in India | Like RBI's bank registry |
| Healthcare Professionals Registry (HPR) | Verified digital identities for doctors, nurses, and allied health professionals | Like a verified doctor directory |
| Health Information Exchange (HIE) | The protocol for sharing records between providers with consent | Like NEFT/RTGS for health data transfers |
| Consent Manager | Manages patient permissions for data sharing | Like OTP authorization for a bank transaction |
| ABDM Gateway | Routes requests between providers; does not store clinical data | Like UPI's switch that routes payments |
As of mid-2025, India has created over 900 million ABHA accounts, with 65 crore health records already linked. The infrastructure is not experimental; it is at national scale.
The Digital Health Incentive Scheme (DHIS) offers financial rewards to hospitals and clinics that actively participate in ABDM. Facilities earn Rs. 20 per transaction above a base threshold of 100 transactions per month, with potential incentives of up to Rs. 4 crore per entity. Diagnostic labs and digital health solution providers are also eligible under separate tiers.
With 900 million ABHA accounts created, patients are increasingly expecting their healthcare providers to be digitally connected. Younger patients, particularly in urban areas, are actively choosing providers who can access their complete health history rather than starting from scratch at every visit. When a patient arrives at your clinic with an ABHA number and you cannot link their records, it creates a perception gap.
With only 7% of private facilities currently on ABDM, early adopters have a clear differentiation. As referral networks increasingly route patients through ABDM-linked facilities, practices outside the network risk being invisible to the referral pipeline. Furthermore, insurance companies and third-party administrators are beginning to prefer ABDM-compliant providers for cashless claim processing.
While ABDM participation is currently voluntary for private facilities, the trajectory of Indian health policy suggests mandatory compliance is a matter of when, not if. The government has already mandated ABDM integration for public facilities. Private practices that integrate now avoid the scramble of forced, last-minute adoption.
Your clinic must be able to create new ABHA numbers for patients who do not have one, and verify existing ABHA numbers for patients who do. Creation requires either Aadhaar OTP verification or mobile number verification. The process takes under one minute per patient when integrated into your registration workflow.
Three patient flows must be designed:
Every facility must be individually registered in the HFR. Multi-branch practices must register each location separately. Registration requires:
The facility manager must first create their own HPID through the Healthcare Professionals Registry (HPR) using Aadhaar and professional council registration verification.
ABDM standardizes on HL7 FHIR R4 (Fast Healthcare Interoperability Resources, Release 4) for all clinical data exchange. This means health records shared through ABDM must be structured as FHIR resources, not PDFs or free-text documents.
The primary document types that must be FHIR-compliant include:
| Document Type | FHIR Resource | Required Fields |
|---|---|---|
| OP Consultation | Composition (OPConsultRecord) | Chief complaint, diagnosis (ICD-10/SNOMED), medications, follow-up |
| Prescription | MedicationRequest | Drug name, dosage, route, frequency, duration |
| Discharge Summary | Composition (DischargeSummary) | Admission details, procedures, medications at discharge, follow-up plan |
| Diagnostic Report | DiagnosticReport | Test name, results with units, reference ranges, interpretation |
| Health Document | DocumentReference | Document type, date, author, content attachment |
The National Resource Centre for EHR Standards (NRCES) publishes the official FHIR Implementation Guide for ABDM at nrces.in/ndhm/fhir/r4. This defines the minimum conformance requirements, terminology bindings, and validation rules for all ABDM-compliant records. Your software must produce resources that pass the ABDM FHIR validator.
Every data disclosure under ABDM is gated by a consent artefact. When another provider requests a patient's records from your system, the request arrives through the ABDM gateway with a consent artefact that specifies:
Your system must honour exactly the scope defined in the consent artefact. If consent allows only laboratory results from a specific date range, your system must filter and return only that data. This requires granular record filtering capability, not just whole-chart export.
Your clinic management software connects to ABDM through a bridge layer that communicates with the ABDM Gateway. This bridge layer handles API authentication, session management, callback processing, and data transformation to FHIR R4 format.
Figure 1: Integration architecture showing data flow from clinic software through the ABDM network
Your clinic operates in two roles within the ABDM ecosystem:
The consent flow is the most distinctive aspect of ABDM architecture. Unlike systems where providers share data based on organizational agreements, ABDM puts the patient in control of every disclosure. This is implemented through a Consent Manager application that the patient uses (typically a mobile app like the ABHA app) to review, approve, or deny requests.
Your system must maintain an audit log of every consent-based disclosure, recording what was shared, when, to whom, and under which consent artefact. This log is essential for regulatory compliance and accreditation reviews.
For a private clinic with existing electronic records (clinic management software already in use), the following timeline represents a realistic integration path:
Register the facility on the Health Facility Registry. Ensure the facility manager has a verified HPID. Begin HPR enrollment for all clinicians (this runs in parallel as each doctor must verify individually). Apply for ABDM sandbox access for your software team.
Configure sandbox environment. Implement ABHA verification and creation APIs in your registration workflow. Test the three patient flows (existing ABHA, new ABHA, declined). Begin front-desk staff training on ABHA capture.
Map your existing clinical data fields to FHIR R4 resources. Implement the HIP module for record sharing. Build consent artefact processing and record filtering. Run FHIR validation against the NRCES implementation guide.
Complete sandbox milestone testing (M1, M2, M3). Address validation failures and resubmit. Receive production credentials upon milestone clearance. Deploy to production and begin live ABHA-linked record creation.
The 4-week timeline assumes your software vendor actively supports ABDM integration. If your current system lacks FHIR capability, expect 8-12 weeks for the technical build, with the first two weeks focused on vendor evaluation and procurement. HPR enrollment for all clinicians often takes longer than planned because individual doctors must complete their own verification.
| Challenge | Root Cause | Solution |
|---|---|---|
| Clinician HPR enrollment stalls | Individual doctors must verify themselves; IT cannot do it for them | Track enrollment as a named workstream with weekly follow-up. Set deadlines tied to a specific go-live date. |
| FHIR validation failures | Clinical data stored as free text rather than coded fields | Audit current data capture. Add structured fields for diagnoses (ICD-10), medications, and results before attempting FHIR conversion. |
| Front desk resistance to ABHA capture | Additional steps in registration flow; separate counter approach fails | Embed ABHA capture inside existing registration flow, not beside it. Ensure the no-ABHA path works smoothly too. |
| Consent filtering limitations | System can only export whole charts, not filtered subsets | Implement granular record filtering by document type and date range. Design for this early; retrofitting is expensive. |
| Sandbox milestone delays | Teams underestimate iteration cycles for format and consent checks | Plan for 2-3 submission cycles per milestone. Allocate developer time for iterative fixes. |
| Multi-branch registration confusion | Each branch requires separate HFR registration | Assign a coordinator for multi-site enrollment. Maintain a tracking sheet for each branch's registration status. |
Relaya's clinic management platform is designed with ABDM integration as a core architectural principle, not a bolt-on module. This means practices using Relaya can achieve compliance significantly faster than those working with legacy systems that require extensive modification.
For a new Relaya practice, ABDM integration is not a separate project. Once HFR registration is complete and clinicians have their HPIDs, the technical integration is already done. The 4-week timeline compresses to the time it takes to complete registry enrollment and train staff on the ABHA capture workflow.
Relaya offers a guided ABDM onboarding program for new practices, including HFR registration assistance, staff training, and milestone testing support. Contact our team at relaya.one to schedule a compliance assessment for your practice.
Relaya is a comprehensive clinic management platform built specifically for Indian healthcare. From AI-powered clinical documentation to ABDM-compliant record sharing, appointment management, and patient engagement, Relaya helps private practices deliver better care while reducing administrative burden.
Learn more at relaya.one