Inside India's Ayushman Bharat Digital Mission: The ABDM Stack Architecture

ABDM — the Ayushman Bharat Digital Mission — is the part of India’s digital public infrastructure that gets less coverage than UPI or ONDC but is operationally larger in scope. The ambition is a unified health-data network spanning 1.4 billion people, every clinical encounter, every prescription, every diagnostic. The implementation has been quieter and more uneven, but as of early 2026 the framework has reached real volume — over 760 million ABHA (Ayushman Bharat Health Account) IDs issued, 350,000+ healthcare facilities registered, and a daily exchange volume that, while still small in per-capita terms, is no longer theoretical.

For builders — hospital IT teams, health-tech startups, EMR vendors, payer-side analytics teams — ABDM is a reality that has to be integrated with, regardless of opinion about how fast adoption is moving.

The components#

ABDM is structurally similar to the UPI architecture: a centrally-operated registry and gateway, with all participants — patients, providers, payers, app vendors — connecting via standardized APIs. The components are:

ABHA (Health ID) — a 14-digit identifier (and an associated abc@abdm health handle) issued to any Indian citizen who opts in. It is the patient’s lifelong health identifier. It can be obtained via Aadhaar (the fast path) or via mobile number plus driving license / PAN / other ID (the non-Aadhaar path). The ABHA app and PHR app both let citizens manage their record and consents.

HIE-CM (Health Information Exchange — Consent Manager) — the consent management layer, analogous to AAs in the Account Aggregator framework. The CM holds and processes consent artefacts. There are currently a small number of CMs, with the National Health Authority running the reference CM.

HIP (Health Information Provider) — entities that hold patient health records — hospitals, clinics, labs, pharmacies. They register with the network and expose ABDM-compliant FHIR APIs for record sharing.

HIU (Health Information User) — entities that consume patient health records with consent — telemedicine apps, insurance underwriters, secondary-care providers, public-health researchers.

HFR (Healthcare Facility Registry) and HPR (Healthcare Professional Registry) — the directories of facilities and professionals. Anyone integrating must register both.

HMIS / EMR vendors — the actual software that hospitals run. ABDM integration is increasingly a checkbox in EMR procurement; vendors who do not integrate are being shut out of public hospital contracts.

The consent flow#

The flow is similar in spirit to the Account Aggregator framework but with domain-specific extensions. A typical use case — a telemedicine platform pulling a patient’s recent prescription history before a consultation — looks like:

1. Patient logs into the telemedicine app and links their ABHA ID.
2. The app (as HIU) sends a consent request specifying purpose (“care provision”), data scope (prescriptions, last 12 months), date range, and frequency (one-time for this consultation, or recurring for ongoing care).
3. The consent manager presents the request to the patient via the ABHA app or PHR app. The patient approves.
4. The signed consent artefact is returned to the HIU.
5. The HIU sends an FI request through the gateway to all relevant HIPs identified by the consent.
6. Each HIP responds asynchronously with the requested FHIR bundles, encrypted with the HIU’s public key.
7. The HIU decrypts and uses the data for the specific consented purpose.
8. The data must be deleted at the end of the consent’s stated dataEraseAt time.

The full first-consent flow takes 30-60 seconds for the patient. Subsequent consents on saved templates can be near-instant.

The FHIR profile#

ABDM mandates FHIR R4 with India-specific profiles, maintained as a versioned standard. The core resource types in active use are:

• OPConsultation for outpatient consultations
• DiagnosticReportLab for lab results
• DiagnosticReportImaging for radiology
• Prescription for prescriptions
• HealthDocumentRecord for unstructured documents (the catch-all)
• DischargeSummary for inpatient discharge
• WellnessRecord for wellness and fitness data

The profiles tighten FHIR R4’s cardinalities — making certain fields required that are optional in the global standard — and add India-specific value sets for things like ABHA IDs, Aadhaar references (always referenced, never embedded), and the National Health Claims Exchange terminology.

Hospitals integrating typically have one of two paths. Path A: their EMR vendor already exports ABDM-compliant FHIR bundles, and the hospital’s job is to register and enable. Path B: their EMR is custom or legacy, and they layer an integration middleware — typically a small set of microservices that read from the EMR’s database, transform to FHIR, sign, and publish to the gateway. We have built path-B integrations for several hospital networks in India and Nepal.

What’s actually working in 2026#

Adoption is uneven across the participant types.

Patients with ABHA IDs: large — 760M+. Most are passive holders; only a fraction actively share records.

Hospitals registered as HIPs: 350,000+ on paper but the share actively exchanging records is much lower — perhaps 25-30%. Tier 1 city private hospitals and the AIIMS network are the leaders. Tier 3 town facilities are largely registered-but-not-integrated.

Telemedicine and chronic-care apps as HIUs: the most aggressive adopters. Tata 1mg, PharmEasy’s diagnostic arm, Practo, MediBuddy, and a long tail of vertical players have meaningful HIU volume.

Insurance underwriting via NHCX: the National Health Claims Exchange, a sibling initiative under NHA, is the part of the stack growing fastest in 2026. Insurers pull claims data via NHCX with consent, which has reduced claim cycle time at participating hospitals from 5-7 days to 6-12 hours.

Public-sector adoption: mixed. State-level public health programs have been slow to adopt; the AYUSH ministry’s integration is still in pilot.

The honest assessment is that ABDM is operating as critical infrastructure but the network effects are not yet at the UPI level. It will likely take another two-to-three years for the patient-side behavior — actively granting consent for record sharing — to become routine.

Integration practicalities#

For a hospital IT team planning ABDM integration in 2026:

1. Decide on EMR posture. If your EMR vendor is ABDM-certified, the integration is configuration; you register, install the vendor’s connector, and turn it on. If not, you build middleware or replace the EMR.

2. Register on the HFR and HPR. Every facility and every clinician must be in the directories. The registration UX is improving but still has corners; allocate a week for paperwork.

3. Set up the consent manager integration. Most hospitals use the NHA reference CM for simplicity; some use commercial CMs for additional features.

4. Wire up the FHIR endpoints. The four key endpoints — discovery, link, request, transfer — are HTTPS REST with mTLS and HMAC-signed payloads. Reference implementations exist on the NHA GitHub.

5. Implement consent revocation handling. When a patient revokes, your access stops immediately. Your downstream uses of fetched data must respect the dataEraseAt window.

6. Audit the FHIR profile compliance. ABDM publishes a profile validator. Run it against your test bundles before going live. The most common failures are missing identifiers, wrong code systems, and partial-resource issues.

7. Plan for the data residency requirement. All ABDM-flowed data must remain in India. This means your cloud architecture must use Indian regions for any storage or processing of ABDM-derived data. AWS Mumbai, GCP Mumbai/Delhi, and Azure Pune are the standard choices.

The interaction with DPDPA#

DPDPA applies to all health data processing, with sectoral overlays. ABDM’s consent framework was built consent-first, so most DPDPA obligations are met by design. The key engineering additions for DPDPA on top of ABDM are:

• Children’s data: minors under 18 require verifiable parental consent for ABHA creation. The ABHA app supports parent-managed accounts.
• Significant Data Fiduciary designation: large hospitals and insurance companies are being designated SDFs, with the additional DPDPA obligations covered in the DPDPA compliance post.
• Algorithmic transparency: any AI clinical decision support that operates on ABDM data must have an explanation surface for clinicians and, on request, for patients.

Where pdpspectra fits#

Our healthcare engineering practice — based out of our Kathmandu and Boston offices — has integrated ABDM and the related NHCX framework for hospital networks across India and Nepal. We do the EMR middleware, the FHIR profile work, the consent UX, and the regulatory architecture.

Related reading: the AA framework implementation post, the hospital data interoperability post, and the AI implementation in healthcare Nepal post.

---

ABDM is the largest health-data network ever attempted. Talk to our team about your integration.