ABDM Compliance Guide for Hospitals, Labs and Health Software

ABDM compliance means building and running health software that follows the rules and standards of the Ayushman Bharat Digital Mission, India's national digital health ecosystem run by the National Health Authority (NHA). ABDM gives people an ABHA health account, registers doctors and facilities, and lets health records move between hospitals, labs and apps only with the patient's consent. The records themselves stay with the providers that created them.

The Health Data Management Policy sets the privacy and security rules for everyone in the ecosystem, and technical standards such as FHIR profiles define how data is exchanged. Integration is tested in the ABDM sandbox before production use. This guide explains the building blocks, roles, consent model, policy requirements, standards, certification milestones and how software vendors can build ABDM-ready products that also meet the DPDP Act.

What is ABDM?

The Ayushman Bharat Digital Mission was launched nationally on 27 September 2021, building on the National Digital Health Blueprint and the earlier National Digital Health Mission pilot. Its goal is to create digital infrastructure for an integrated health system, so that patients can access and share their records, providers can see relevant history with consent, and the system can make better use of health data. The NHA implements it under the Ministry of Health and Family Welfare.

ABDM uses a federated architecture. There is no central database of everyone's medical records. Instead, records stay in the systems of hospitals, labs and other providers, and ABDM provides the registries, identifiers, consent management and exchange gateway that let records move securely when the patient agrees.

ABDM building blocks

• ABHA (Ayushman Bharat Health Account): a 14-digit health ID number for individuals, plus an ABHA address used to link records and give consent.
• Healthcare Professionals Registry (HPR): a verified registry of doctors, nurses and other professionals.
• Health Facility Registry (HFR): a registry of hospitals, clinics, labs, pharmacies and other facilities.
• Health Information Exchange and Consent Manager (HIE-CM): the gateway that routes consent requests and encrypted health data between participants.
• Personal health record (PHR) apps: apps through which individuals view records, manage consent and link facilities.
• Unified Health Interface for discovering and booking health services, and the National Health Claims Exchange for standardised insurance claims.

Roles: HIP and HIU

ABDM defines two main roles for systems that hold or request health records:

Role	What it does	Examples
Health Information Provider (HIP)	Creates and holds health records, links them to a patient's ABHA, and shares them when the patient consents.	Hospitals, clinics, labs, pharmacies and their HMIS, EMR or LIMS software.
Health Information User (HIU)	Requests access to health records with the patient's consent to provide care or services.	Doctors' EMRs, hospitals receiving referrals, PHR apps, telemedicine services.

Many systems act as both. A hospital information system, for example, provides records it creates and requests records from elsewhere when treating a patient.

Who must comply?

Participation in ABDM is voluntary for individuals and private providers. However, government schemes, public hospitals and some insurance and empanelment processes increasingly require ABDM integration, and incentive schemes have encouraged adoption. Once an organisation or software system joins the ecosystem, it must follow the Health Data Management Policy, the participation terms and the technical standards. Software vendors whose products are integrated must ensure their systems meet these requirements on behalf of the facilities that use them.

Is it mandatory or voluntary?

Voluntary to join, mandatory to follow once integrated. Patients can choose whether to create an ABHA and whether to share records. The DPDP Act applies to health data in any case, whether or not a provider uses ABDM.

The consent model

Consent is central to ABDM. Health records can be shared only after the patient approves a specific consent request, typically through a PHR app or at the facility. A consent artefact records who is requesting data, for what purpose, which types of records, for which date range, and for how long access is allowed. The consent manager checks consent before any exchange, and patients can revoke consent. Data moves encrypted end to end between the HIP and HIU through the exchange; the consent manager does not see the clinical content. This approach builds on India's electronic consent framework for data sharing.

The Health Data Management Policy

The Health Data Management Policy sets the data protection framework for ABDM. It was first issued in 2020 and has been revised since. Its main principles and obligations include:

• Consent: processing of personal health data on the basis of free, informed, specific, clear and revocable consent, with specific rules for children and people lacking capacity.
• Purpose limitation and data minimisation: collect and use only what is needed for the stated purpose.
• Rights of data principals: to access, correct, erase and port their data, and to restrict or object to processing, in line with the policy.
• Privacy notices that explain processing clearly.
• Security safeguards: encryption, access controls, audit logs and incident handling appropriate to sensitive health data.
• Data storage within India for ABDM-related data.
• Breach notification to the NHA and affected individuals as set out in the policy.
• Accountability: designated grievance and data protection roles, and audits.

The policy predates the DPDP Act, so organisations must meet both. Where the DPDP Act and its rules set stricter or different requirements, those apply as law.

Technical standards

• FHIR R4 with ABDM profiles for record types such as prescriptions, diagnostic reports, OP consultation notes, discharge summaries, immunisation records and health documents, published in the ABDM FHIR implementation guide by the National Resource Centre for EHR Standards.
• Clinical terminologies such as SNOMED CT, LOINC and ICD codes, as specified in the profiles.
• ABDM APIs for ABHA creation and verification, care context linking, discovery, consent and data transfer.
• Encryption of health data in transit through the exchange using the cryptographic scheme specified by ABDM.

Integration milestones and certification

Software vendors integrate through the ABDM sandbox. Integration is commonly described in milestones:

1. Milestone 1: ABHA creation and verification, so the software can identify patients by ABHA.
2. Milestone 2: HIP functions, linking care contexts to ABHA and sharing records on consent.
3. Milestone 3: HIU functions, requesting and receiving records with consent.

After building in the sandbox, vendors complete functional testing and a security audit, typically by a CERT-In empanelled auditor, before NHA approves production access. Each facility using the software registers separately in the Health Facility Registry. Check the sandbox documentation for current milestone definitions and approval steps, as NHA updates them.

Security expectations for ABDM systems

Because ABDM connects many independent systems, a weak link can expose patient data across the network. Integrated software is expected to protect health data at least as well as other sensitive data under Indian law. In practice that means encrypting records at rest and in transit, strong authentication for staff with MFA for administrators, role-based access so that billing staff cannot read clinical notes, detailed audit logs of record access and sharing, secure storage of ABDM credentials and keys, regular vulnerability testing, patching, backups and an incident response plan that covers notification to NHA, CERT-In and affected individuals where required. Vendors offering cloud-hosted systems should host in Indian regions and keep logs in India in line with CERT-In requirements.

Health claims and the National Health Claims Exchange

The National Health Claims Exchange (NHCX) is the ABDM component for exchanging health insurance claims between hospitals, insurers and TPAs in a standard format. Instead of each insurer and TPA using its own portal and document format, claims, pre-authorisations and supporting documents can move as standardised FHIR bundles. Hospitals and their software vendors integrate once with the exchange rather than with each payer. For insurers and TPAs, integration must also satisfy the IRDAI cyber security guidelines, and claim documents remain sensitive health data under the DPDP Act.

Benefits for providers and patients

For patients, ABDM means records from different hospitals and labs can be brought together in one app and shared with a new doctor in minutes rather than carried as paper files. For providers, it reduces repeat tests, gives clinicians relevant history at the point of care, and simplifies insurance claims. For software vendors, ABDM integration has become a selling point with hospitals and labs, and government incentive schemes have rewarded facilities for digital record sharing. These benefits depend on accurate, structured data, which is why FHIR mapping and coding quality matter as much as API connectivity.

How to build ABDM-ready software, step by step

1. Decide your roles: HIP, HIU or both.
2. Register on the ABDM sandbox and review API specifications.
3. Implement ABHA verification and creation in patient registration.
4. Map your data to FHIR profiles and terminologies.
5. Build care context linking and consent-based sharing for HIP functions.
6. Build consent requests and record viewing for HIU functions.
7. Secure the system: encryption, access control, audit logs and India hosting.
8. Complete testing and security audit, then apply for production.
9. Onboard facilities through the Health Facility Registry.
10. Align privacy notices and processes with the HDM Policy and DPDP Act.

Documentation you will need

• Integration design and FHIR mapping documents.
• Sandbox test results and milestone approvals.
• Security audit report.
• Privacy notices and consent records.
• Access control and audit log policies.
• Incident response and breach notification procedures.
• Data hosting and retention documentation.
• Contracts between vendors and facilities defining responsibilities.

Timeline and cost considerations

A focused HIP integration for an existing HMIS or LIMS can take a few weeks to a few months, depending on how structured the existing data is. FHIR mapping and terminology coding are usually the largest effort, followed by security hardening and audit. Costs include development, audit fees and ongoing maintenance as standards evolve.

Common mistakes

• Sharing PDFs without structured FHIR data, limiting usefulness.
• Weak consent handling, such as sharing beyond the consented date range or record types.
• No audit logs of who accessed records and why.
• Hosting outside India or using global tools that receive health data.
• Treating ABDM integration as DPDP compliance; both are needed.
• Not tracking standard updates to FHIR profiles and APIs.

Best practices, tools and technologies

• Use a FHIR server or library to generate and validate ABDM profiles.
• Store consent artefacts and enforce them in code before any data release.
• Encrypt records at rest and in transit, and protect keys.
• Use role-based access for clinical and administrative staff, with break-glass logging.
• Host in Indian cloud regions and keep logs in India.
• Run security testing before every major release.

We build ABDM integrations, FHIR record exchange and consent-aware health platforms for hospitals, labs and health apps through our healthcare and API integration work.

How ABDM relates to other frameworks

Framework	Relationship
DPDP Act	India's personal data protection law, which applies to all health data.
HIPAA	US health privacy law; useful comparison for vendors serving both markets.
IRDAI cyber guidelines	Security rules for insurers and TPAs that receive health data for claims.
CERT-In Directions	Incident reporting and log retention for health systems.
ISO/IEC 27701	Privacy management system that can structure HDM Policy compliance.

Real-world example

A diagnostic lab chain uses a cloud LIMS from an Indian vendor. The vendor completes Milestones 1 and 2: front desk staff verify or create ABHA at registration, and each test report is linked to the patient's ABHA as a FHIR DiagnosticReport with LOINC codes. When the patient's doctor requests the report through an HIU-enabled EMR, the patient approves consent in a PHR app, and the LIMS sends the encrypted report through the exchange. The vendor hosts in India, logs every share against the consent artefact, and completes a security audit before production approval.

Next steps

1. Decide your HIP and HIU roles.
2. Register on the sandbox.
3. Map data to FHIR profiles.
4. Build consent-based sharing with audit logs.
5. Pass testing and security audit.

Frequently asked questions

What is ABDM?

The Ayushman Bharat Digital Mission, India's national digital health ecosystem run by the National Health Authority.

Is ABDM integration mandatory?

It is voluntary for private providers and individuals, but required for some government schemes and increasingly expected by hospitals and insurers.

What is an ABHA number?

A 14-digit health account number that identifies an individual in the ABDM ecosystem and links their records.

What are HIP and HIU?

A Health Information Provider holds and shares records; a Health Information User requests records with consent.

Does ABDM store patient records centrally?

No. Records stay with providers, and ABDM manages identifiers, consent and secure exchange.

What standards does ABDM use?

FHIR R4 with ABDM profiles, plus terminologies such as SNOMED CT, LOINC and ICD.

How does software get approved for ABDM?

By building and testing in the sandbox, completing milestones and a security audit, then receiving production approval.

Does the DPDP Act apply to ABDM data?

Yes. The DPDP Act applies to all digital personal data, including health data exchanged through ABDM.

Can patients revoke consent?

Yes. Patients can revoke consent through the consent manager, and access must stop.

Must ABDM data be stored in India?

The Health Data Management Policy expects ABDM-related data to be stored in India.

What is the Health Data Management Policy?

The NHA policy setting privacy, consent and security rules for all ABDM participants.

Does each hospital need its own ABDM approval?

The software is approved for production once, but each facility using it must register in the Health Facility Registry and link to the software.

What is the National Health Claims Exchange?

The ABDM gateway for exchanging standardised health insurance claims between hospitals, insurers and TPAs.