Architecture

ABDM is a federated architecture: health data never moves to a central store. Instead, a set of national registries and a central gateway coordinate identity, consent, and encrypted peer-assisted data exchange between the systems that already hold the data.

The big picture

flowchart LR
  subgraph Patient
      PHR["PHR / ABHA App"]
  end
  subgraph ABDM["ABDM Central Services"]
      GW["Gateway"]
      CM["HIE-CM<br/>(Consent Manager)"]
      ABHA["ABHA Service"]
      HPR["HPR"]
      HFR["HFR"]
  end
  subgraph Providers
      HIP["HIP<br/>(Hospital / Lab HMIS)"]
      HIU["HIU<br/>(Doctor / Insurer App)"]
  end

  PHR -- "manage consents" --> CM
  HIP -- "link records, share data" --> GW
  HIU -- "request data" --> GW
  GW --- CM
  GW --- ABHA
  HIP -. "encrypted FHIR bundle" .-> HIU

Three things to internalise:

1. The gateway is a router, not a store. All consent and data-flow APIs go through it, but health records flow (encrypted) between HIP and HIU directly via a data push URL.
2. The HIE-CM enforces consent. Nothing is shared without a valid consent artefact signed by the patient's consent manager.
3. Everything is asynchronous. Nearly every gateway API is a request/callback pair — you call an endpoint, get a 202 Accepted, and receive the result later on your registered callback URL.

Central services

ABHA service

Issues and verifies ABHA numbers (14-digit health IDs) and ABHA addresses (like name@abdm). Supports Aadhaar-based and driving-licence based creation, plus mobile-OTP verification flows. See ABHA.

HIE-CM

The Health Information Exchange & Consent Manager holds the patient's consent artefacts, manages linked care contexts, and orchestrates discovery/linking flows. Patients interact with it through PHR apps. See HIE-CM.

Gateway

The single entry point for HIP/HIU traffic: session tokens, API routing, callback delivery. See ABDM Gateway.

Registries

• HPR — Healthcare Professionals Registry (doctors, nurses).
• HFR — Health Facility Registry (hospitals, labs, clinics, pharmacies).

Facilities must be registered in HFR before they can act as HIPs. See HPR & HFR.

Where your application sits

Design principles to build around

• Asynchronous callbacks everywhere — design your integration as a state machine keyed by requestId / transactionId correlation IDs.
• Idempotency — callbacks can be retried; handle duplicates gracefully.
• End-to-end encryption — data bundles are encrypted with ECDH key exchange (Curve25519) + AES-GCM; the gateway never sees plaintext. See Health Data Flow.
• FHIR R4 — all shared records are FHIR bundles conforming to NRCeS profiles. See FHIR & Data Standards.