Complete guide to ABDM & health data compliance

01What ABDM is

The Ayushman Bharat Digital Mission (ABDM), run by the National Health Authority under the Ministry of Health and Family Welfare, is India's federated digital health infrastructure — launched 27 September 2021. ABDM is the technology backbone of India's universal health coverage push and the digital twin of the Ayushman Bharat Pradhan Mantri Jan Arogya Yojana (AB-PMJAY) insurance scheme.

ABDM does not centralise health records. It provides a national identity, registry, and consent layer that lets locally-held records be exchanged — with patient consent — between providers, payers, and patients. Architecturally it follows the same federated-with-consent model as Account Aggregator (AA) does for finance.

For any hospital, clinic, lab, pharmacy, or healthtech operating in India, ABDM compliance means integrating with the registries (ABHA, HFR, HPR), implementing the consent flow via a Consent Manager, supporting standards-based EHR exchange (FHIR R4 + EHR Standards 2016), and meeting the security baseline of the Health Data Management Policy. Practically: by 2026, ABDM compliance is a hard prerequisite for AB-PMJAY claim settlement, IRDAI cashless claims via Bima Sugam, and digital prescription and report flows used by every modern healthtech platform.

02ABDM building blocks

• ABHA (Ayushman Bharat Health Account) — the patient's health ID. 14-digit number plus an @ handle. Used to discover and link records across facilities.
• Health Facility Registry (HFR) — registry of hospitals, clinics, labs, and pharmacies. Each registered facility gets a unique ID used in all ABDM transactions.
• Healthcare Professional Registry (HPR) — registry of doctors, nurses, and allied health professionals, each with a verified unique ID.
• Health Information Exchange & Consent Manager (HIE-CM) — licensed entity that orchestrates consent-based record exchange between HIPs and HIUs.
• Health Information Provider (HIP) — entities holding records (HMIS, hospitals, EHR vendors, labs). Must expose care-context APIs.
• Health Information User (HIU) — entities consuming records (other providers, insurers via Bima Sugam, patients via PHR apps).
• Personal Health Record (PHR) Apps — patient-side apps that retrieve, view, and manage linked records via the ABHA handle.

03Who must integrate

ABDM is not yet legislatively mandatory across the entire ecosystem, but participation has become the de-facto operating standard for any entity handling health data at scale:

• Public-funded healthcare — mandatory for AB-PMJAY claim processing and government-scheme integration.
• Private hospitals and nursing homes — required for ABHA-linked patient onboarding and digital insurance settlement via Bima Sugam.
• Diagnostic labs, pharmacies, telemedicine — register as HFR; integrate with ABHA for digital prescription and report delivery flows.
• HMIS and EHR vendors — must support HIP/HIU APIs, FHIR R4, and EHR Standards 2016 to achieve ABDM certification and sell to certified facilities.
• Healthtech and DPC apps — Digital Personal Care apps need ABDM integration to access patient-consented health records and be commercially credible.

04Health Data Management Policy

The HDM Policy is the data-protection rulebook for ABDM, published and periodically updated by NHA. It sits below the DPDP Act in the regulatory hierarchy but is more specific to health data operations. Key principles:

• Patient ownership — the data subject controls who sees what and for how long.
• Consent-based access — every cross-facility record fetch requires a valid, signed consent artefact.
• Federated storage — records remain with the originating facility; ABDM does not centralise clinical data.
• Security baseline — AES-256 at rest, TLS 1.2+ in transit, access controls, immutable audit logs, and breach notification obligations.
• Data localisation — health data primarily stored in India; cross-border conditions defined and enforced.
• Children's data — additional protections and parental verification requirements for minors.

05Consent architecture

The Consent Manager (a HIE-CM-licensed entity) orchestrates the full consent lifecycle. The flow is standardised across every ABDM-connected platform:

1. HIU requests records for a specific purpose, scope, and time window.
2. Consent Manager delivers the request to the patient's device via their PHR app.
3. Patient approves or denies. An approval generates a cryptographically signed consent artefact.
4. HIP validates the artefact and releases the FHIR bundle to the HIU.
5. Every party retains an immutable audit trail of the consent and exchange event.

06EHR Standards 2016 (and updates)

The Ministry of Health's EHR Standards 2016 mandates the clinical terminology and data exchange standards all ABDM-certified systems must implement:

• SNOMED CT — clinical terms, procedures, and findings.
• LOINC — laboratory observations and vital signs.
• ICD-10 / ICD-11 — diagnoses and mortality coding.
• FHIR R4 — all structured data exchange, replacing older HL7 v2 push.
• DICOM — medical imaging and radiology reports.
• UNICODE — vernacular content across all 22 scheduled languages.

ABDM-certified vendors must demonstrate conformance through NHA's milestone certification process before accessing the production environment.

07FHIR & data exchange

FHIR R4 is the exchange protocol backbone of ABDM. Every HIP and HIU must implement it correctly — partial implementations are the most common source of integration failures and security gaps in the field:

• HIP APIs: discover patient → link care contexts → notify HIU on consent-based record request.
• HIU APIs: consume FHIR R4 bundles conformant with the NDHM-FHIR-IG Indian profile.
• Common bundle types: OPConsult, DiagnosticReport, Prescription, DischargeSummary, Immunization, WellnessRecord.
• Digital signatures: FHIR Signature on outbound bundles is increasingly required for higher-assurance integrations and insurance claim workflows.

08Security baselines

The HDM Policy and ABDM technical specifications establish a minimum security baseline. The list below is the auditor-defensible minimum — most production deployments need more:

Transport & cryptography

• TLS 1.2+ mandatory for all data in transit (TLS 1.3 strongly preferred). TLS 1.0 and 1.1 explicitly prohibited.
• Mutual TLS (mTLS) required for all HIP ↔ CM ↔ HIU API calls — client certificates issued by NHA or authorised CAs.
• AES-256 for data at rest. HSM-backed key management (AWS KMS with CloudHSM, Azure Key Vault Premium, or on-prem) for SDF-tier deployments.
• FHIR Signature on outbound bundles for integrity and non-repudiation.

Access control & identity

• RBAC mapped to HPR roles (Doctor, Nurse, Lab Tech, Admin) with least-privilege defaults — no shared credentials.
• MFA mandatory for all administrative access. FIDO2/WebAuthn preferred over SMS OTP for clinical staff.
• Session timeouts — 15-minute idle for clinical workstations, 30-minute absolute maximum per session.
• Immutable audit logs on every record access: who, which record, when, from where, what action. WORM or append-only log store required (Splunk, ELK with WORM, or AWS CloudTrail Lake).

Application & API security

• OWASP ASVS Level 2 minimum bar; Level 3 for SDF-tier or systems handling critical records.
• API rate-limiting per HIU and source IP — prevents bulk-fetch enumeration and data harvesting attacks.
• Anomaly detection on bulk record fetches, off-hours access, and unusual geographies — flagged for human review within minutes.
• WAF in front of all internet-facing ABDM APIs — Cloudflare, AWS WAF, F5, or Imperva.

Operational security

• Annual VAPT by a CERT-In empanelled assessor — mandatory for ABDM-connected systems, not optional.
• Patch SLAs: critical within 7 days, high within 30 days, medium within 90 days. Known Exploited Vulnerabilities (KEV catalog) within 24 hours.
• Incident response plan covering CERT-In 6-hour reporting, DPDP DPB notification, NHA notification, and patient communication — in parallel, not sequentially.
• Backup and recovery — encrypted, off-site, tested quarterly via tabletop exercise. RPO < 24h, RTO < 4h for clinical systems.

09Penalty structure

Healthcare entities operate under a multi-layer penalty regime. A single breach incident can trigger penalties under several statutes simultaneously — they are not mutually exclusive:

10DPDP overlap

The Digital Personal Data Protection Act 2023 became operationally live for healthcare in 2025–2026. Health data sits at the top of DPDP's risk register — the Act treats it as a category requiring heightened protection. Here is the mapping every Indian healthcare entity must internalise:

Significant Data Fiduciary (SDF) classification

Section 10 empowers the Central Government to designate certain Data Fiduciaries as "Significant" based on data volume, sensitivity, risk to data principals, and sovereignty impact. Most material healthcare entities will fall in scope:

• Hospital networks with multi-state operations or 50+ lakh patient records.
• Healthtech and D2C health apps with 10+ lakh active users.
• Insurers processing health claim data at scale.
• EHR/HMIS vendors processing on behalf of multiple facilities.

SDFs must additionally appoint a DPO based in India, conduct periodic DPIAs, undergo annual independent data audits, and report findings to the Board or equivalent governance body. Non-SDFs still face the rest of the Act.

Consent — ABDM versus DPDP

This is the most common point of confusion. The two consent frameworks are not interchangeable:

ABDM consent satisfies the data exchange portion of DPDP. It does NOT satisfy the consent obligation for primary processing (collecting data when a patient registers), marketing, analytics, or research uses. Build both flows together from the start.

Cross-border transfer (DPDP §16)

Health data is among the categories where the Central Government may restrict outbound transfers. As of mid-2026, the prescribed-country allowlist has not been notified — but plan for an India-only data residency requirement for clinical records. AWS Mumbai (ap-south-1), Azure Central India, and GCP Mumbai are the safe defaults. Using US/EU regions as primary storage for health records is a high-risk architectural bet on future government rules.

Right to erasure versus medical records retention

DPDP §12 grants the right to erasure. Medical records retention rules (IMC regulations, Clinical Establishments Act, state-level requirements) typically mandate 3–10 years depending on case type. The DPDP Act recognises legal-obligation retention as an exception. Practically:

• Document the retention period per record type in your DPDP processing register.
• Honour erasure requests for data not subject to retention — marketing preferences, app analytics, optional profile fields.
• Retain clinical records for the regulatory minimum even if a patient requests erasure — but document the legal basis explicitly.
• After the retention period expires, erasure on request becomes mandatory with no override.

Breach notification — dual obligation

A breach of health data triggers both CERT-In Direction 2022 (6-hour reporting window) and DPDP Act §8(6) (notification to the Data Protection Board and affected data principals "without delay"), plus NHA notification under the HDM Policy. These obligations run in parallel — build a single unified runbook that covers all three simultaneously, not sequentially.

11Integration / certification

• Sandbox environment — develop and test against the ABDM Sandbox at sandbox.abdm.gov.in before touching any production system.
• Milestone certification — five milestones for HIP, HIU, HFR onboarding, HPR onboarding, and PHR apps. Each milestone is verified by NHA before the next can begin.
• Production access — granted after milestone completion, security review, and formal agreement signing with NHA.
• Empanelled implementing partners — NHA maintains a list of certified implementation partners; useful for hospitals integrating without a dedicated in-house tech team.

12Common mistakes

• Treating ABHA as a unique-ID-only feature without implementing the full consent and care-context flow.
• HMIS vendors claiming "ABDM-ready" without having completed any milestone certification with NHA.
• Storing patient data with vendor-managed encryption keys — key custody must remain with the healthcare entity.
• Partial FHIR mapping — OPConsult implemented correctly, DiagnosticReport or DischargeSummary bundles broken or missing entirely.
• Consent artefacts not retained as evidence — cannot demonstrate consent to an auditor or in litigation.
• Breach runbook missing the NHA notification path — usually drafted alongside CERT-In and DPDP obligations, then overlooked.
• Children's records without verified parental consent flow — both ABDM and DPDP §9 require it.
• HIP–CM–HIU API endpoints exposed without mTLS or with shared service-account credentials across facilities.

1390-day roadmap

• Days 1–15 — ABDM scope decision (HIP / HIU / both), milestone selection, sandbox account setup, integration-partner shortlist if needed.
• Days 15–30 — HFR + HPR registration audit and cleanup; ABHA linkage flow built into the patient onboarding journey.
• Days 30–50 — FHIR R4 mapping for all relevant bundle types; care-context discovery and notify APIs implemented and tested in sandbox.
• Days 50–65 — Consent flow integrated end-to-end; consent artefact storage and immutable audit trail confirmed.
• Days 65–80 — Security uplift: mTLS, HSM key management, RBAC review, anomaly detection; VAPT by CERT-In empanelled vendor.
• Days 80–90 — NHA milestone walkthroughs; production access application; DPDP gap register initiated for SDF readiness in parallel.