Skip to main content
INTEROPERABILITY
PRANA · 2026
NATIONAL DIGITAL HEALTH INFRASTRUCTURE

ABDM Connect.

Ayushman Bharat Digital Mission (ABDM) is India's national digital health infrastructure. It creates a shared ecosystem where patients, hospitals, labs, insurers, and health apps can exchange health data securely, with patient consent driving every transaction.

Prana provides the interoperability infrastructure that handles ABDM gateway complexity: consent orchestration, FHIR transformation, and registry integration.

Read about our architecture direction →

The ABDM Ecosystem

I.REGISTRIES & ROLES

Core Registries.

ABDM is built on four registries. Every entity gets a unique, verifiable identity.

ABHA

Ayushman Bharat Health Account

The patient's health identity. Can be a 14-digit ABHA Number (KYC-verified via Aadhaar) or an ABHA Address like nisha@abdm. All health transactions are anchored to this.

HPR

Healthcare Professionals Registry

A national registry of licensed healthcare professionals. Each doctor, nurse, or practitioner gets a unique HPR ID for verified digital identity.

HFR

Health Facility Registry

A national registry of health facilities, government and private. Each facility gets a unique HFR ID used for record linking and patient discovery.

CM

Consent Manager

Manages the consent flow between HIPs (who hold data) and HIUs (who want access). The ABDM Gateway acts as the Consent Manager.

Roles in the Ecosystem.

There are two roles in ABDM. A system can play both.

HIP

Health Information Provider

Hospitals, labs, clinics, and pharmacies that generate and hold patient health records. After a visit or test, a HIP links records to the patient's ABHA address so they're discoverable and shareable.

Examples: hospital HMS, diagnostic lab, pharmacy software

HIU

Health Information User

Any entity that requests access to a patient's health records with consent. After consent is granted, the HIU pulls FHIR records from the relevant HIPs.

Examples: insurance company, specialist referral system, wellness platform

100%

Operational Reality

Why adoption remains operationally complex.

ABDM creates the right infrastructure. But hospitals face real operational barriers to integration.

Legacy HMS systems lack native FHIR support

Most hospital systems store data in proprietary formats. Transforming this into standards-compliant health records requires infrastructure that most facilities don't have.

High-volume OPDs resist additional workflow steps

Clinicians seeing 100+ patients daily cannot absorb extra steps for ABHA creation, consent handling, and record linking without infrastructure that makes it invisible.

Audit trail requirements for institutions unaccustomed to documentation

ABDM requires traceable, timestamped records of every consent decision and data exchange. This is a significant operational shift for facilities accustomed to minimal digital governance.

Identity reconciliation across fragmented records

Patients may have multiple registrations across facilities with different spellings, IDs, and demographic data. Linking these to a single ABHA identity is operationally non-trivial.

Certification

II.ABDM MILESTONES

ABDM Milestones.

ABDM defines four certification milestones for healthcare system integrations.

100%
M1

ABHA Identity

Required by: All integrations (HIP, HIU, PHR apps)

Every patient needs an ABHA identity before any health data can be linked or shared.

  • Create ABHA Number (14-digit, KYC-verified)
  • Create ABHA Address (username@abdm)
  • Login and session management
  • Profile viewing, updates, and deletion
  • KYC verification
  • ABHA card and QR code generation
View M1 flow chart →
M2

Care Context Linking

Required by: HIPs (hospitals, labs, clinics, pharmacies)

Health records are grouped into care contexts. M2 is about linking these to a patient's ABHA address and serving them when requested.

  • HIP links records to patient's ABHA after each visit/test
  • Patients can discover unlinked records from any facility
  • List all linked providers and care contexts
  • Serve FHIR data when HIU requests it
View M2 flow chart →
M3

Consent & Data Sharing

Required by: HIUs (any entity accessing patient records)

Patients must explicitly consent before an HIU can access their records. M3 covers the full consent lifecycle and data fetch.

  • Patients receive and act on consent requests
  • Approve, deny, or revoke consent at any time
  • Auto-approval policies for recurring access
  • HIU fetches encrypted FHIR data after consent
  • Encryption key management for secure transfer
View M3 flow chart →
M4

HPR & HFR Registration

Required by: All healthcare system integrations

Every professional and facility must be registered in ABDM's national registries before participating in digital health transactions.

  • Create HPR ID for professionals via Aadhaar verification
  • Check existing HPR IDs and get suggested IDs
  • Search, onboard, and link health facilities (HFR)
  • Software linkage for data exchange
View M4 flow chart →

Use Cases

III.WHAT CAN YOU BUILD

Who uses ABDM integration.

Hospital / Clinic (HMS)

If you run a hospital system, you need to be a HIP. After every visit or test, link records to ABHA. When a patient grants consent to another entity, your system serves those records.

Consumer Health App (PHR)

Patient-facing apps: aggregate health history from every facility visited, manage consent, check in at facilities via QR scan.

Insurance / Analytics (HIU)

Need patient health records from any ABDM-connected provider? Request consent, and once granted, pull FHIR records directly.

Integrated Platform

Large hospital networks need HIP + HIU + PHR. Your HMS links records, doctors pull external history, patients have a portal.

Deep Dives

IV.EXPLORE FURTHER