Introduction

The Ayushman Bharat Digital Health Account (ABHA) is a foundational initiative designed to build the core infrastructure for India’s digital health ecosystem. It serves as a vital enabler for seamless and secure exchange of health information across various stakeholders. By creating interconnected digital highways

Stakeholders in ABDM

Patients/Individuals

The Ayushman Bharat Digital Mission (ABDM) enables patients to quickly register during their healthcare visits, access their health records from any health facility, book doctor appointments, and share their health information securely with consent. To use these services, patients are required to create an ABHA address, which acts as their unique digital health identifier within the ABDM ecosystem.

Health professionals

Health professionals, including doctors, nurses, lab technicians, and others, must register in the Health Professional Registry (HPR) and obtain an HPR ID to participate in the ABDM ecosystem. This registration also allows them to be recognized and discovered as verified professionals within the digital health network.

Health Facilities

Health facilities, such as hospitals, nursing homes, clinics, laboratories, and pharmacies, must register in the Health Facility Registry (HFR) and obtain an HFR ID to be part of the ABDM ecosystem. Additionally, they are required to use ABDM-compliant software to generate ABHA-linked digital health records.

Digital Solution Companies

Digital Solution Companies (DSCs) are organizations that offer software solutions to patients or health facilities. To participate in the ABDM ecosystem, DSCs are required to integrate their applications with ABDM's core building blocks and obtain certification for their solutions.

DSCs are the primary users of the ABDM Sandbox, where they register, test, and validate their applications before applying for formal certification.

ABDM Components

The following are the main components of ABDM

ABHA Number 

The ABHA number is a 14-digit unique identifier that establishes your identity within India’s digital healthcare ecosystem. It serves as a trusted and universally accepted ID by healthcare providers across the country. With an ABHA number, you can seamlessly sign up for PHR (Personal Health Records) applications, such as the ABDM ABHA app, to enable secure and convenient health data sharing.

HFR - Health Facility Registry

The Health Facility Registry (HFR) is a comprehensive database of all health facilities across the country, encompassing various systems of medicine. It includes both public and private institutions such as hospitals, clinics, diagnostic laboratories, imaging centers, pharmacies, and more.

HPR-Healthcare Professionals Registry

The Healthcare Professionals Registry (HPR) is a comprehensive repository of all healthcare professionals engaged in delivering healthcare services across both modern and traditional systems of medicine.

UHI - Unified Health Interface

The Unified Health Interface (UHI) is envisioned as an open protocol designed to support a wide range of digital health services. The UHI Network will consist of an open ecosystem of End User Applications (EUAs) and Health Service Provider (HSP) applications. It will enable seamless interactions between patients and HSPs for services such as appointment booking, teleconsultation, service discovery, and more.

ABHA App 

A Personal Health Record (PHR) is an electronic application that allows patients to maintain and manage their health information, as well as the health data of others they are authorized to represent, within a private, secure, and confidential environment.

Development Roadmap

The API implementation of ABDM is divided into 3 milestones.

Milestone 1: Creation and Verification of ABHA Numbers for Patients/Individuals

In this milestone, the focus is on implementing functionality to create and verify ABHA (Ayushman Bharat Digital Health Account) numbers for patients or individuals. This is a foundational step to establish a unique and secure digital health identity for every user.

We will build modules that allow individuals to generate a 14-digit ABHA number using either their Aadhaar or Driving License, based on user consent. Identity verification will be handled through secure OTP-based authentication to ensure data privacy and validation.

During the patient registration workflow, the system must support real-time verification of the ABHA number or ABHA address (Health ID) provided by the user. This ensures that the health identity is correctly linked to their medical records, enabling smooth access to digital health services and maintaining consistency across different healthcare providers.

As part of the ABHA integration, we need to fetch the public key by calling the API endpoint.

Once retrieved, the public key will be used to encrypt all sensitive data before transmitting it in any future communications with the ABHA system. This ensures end-to-end security by making sure that sensitive information (like identity details, health records, etc.) is protected during transit according to ABDM guidelines.

Milestone 2: Linking and Sharing of Patient Health Records

Milestone 2 focuses on enabling Health Information Providers (HIPs) and Health Information Users (HIUs) to integrate care context linking and health record management into their applications under the Ayushman Bharat Digital Mission (ABDM) ecosystem.

Core Technical Areas in Milestone 2

Health Record Data Models:

• Standardized JSON schemas and data structures for storing and exchanging patient health information.

• Ensure backend APIs serialize/deserialize data strictly according to ABDM specifications to maintain interoperability.

Care Context Management:

• Implementation guide for defining, creating, and managing "Care Contexts"

(treatment episodes or health interactions).

Your system must expose APIs for:

•Fetching linked care contexts

•Managing user consent for sharing care contexts

Care Context Linking Workflow:

• HIPs must implement APIs to trigger context linking.

• Mobile number-based notification flows are required (OTP-based user verification to approve linking).

You must support APIs for:

• Initiating linking requests

• Fetching pending linking requests

•Accepting/rejecting linking via the consent manager

Security and Compliance:

• All communication must be encrypted (use ABDM’s public key infrastructure).

• Audit trails are mandatory capture logs for all linking and record-sharing transactions.

Milestone 3: Transfer between health information providers

M3 focused on data transfer between health information providers. The patient needs to confirm the data transfer.

Requesting Consent

• Whoever wants to access health data they have to request user consent. They do this by sending a consent request with the user’s ABHA address to the HIE-CM.

• From an HIU perspective, the flow begins when the HIU (e.g., a Doctor at a Hospital) requests consent to view the patient’s data.

• Upon receipt of such a request from Gateway, HIE-CM acknowledges and sends back a consent request ID to the HIU via the Gateway.

• The HIE-CM then notifies the patient that an HIU has made a consent request. The patient can view the request details and choose to either grant it or deny it.

• Subsequently, the HIE-CM notifies the HIU requester of the patient’s consent or denial status via the gateway.

• If the request is granted, the HIE-CM sends the IDs of the consent artefacts that were created against the request to the HIU.

• If the request is denied, the HIE-CM simply notifies the HIU of the denial of the request.

At the time when the patient registers with the hospital (for accessing medical history), this is (can be) initiated when the user scans the Health facility QR code & registers, the Health Facility now has the user’s ABHA address and can initiate a consent request

Sandbox Exit Process 

Post-milestone integration, we must follow the 4-step process below to exit the Sandbox environment. The integrating team is responsible for completing all the steps:

Functional Testing

Step 1a: Upon completing the milestone integration, the integrating entities must contact an NHA-empanelled functional testing agency to evaluate their integrated software/application.

List of NHA empanelled functional testing agencies is as below: 

M/s AKS Information Technology Services Private Limited

M/s Avasure Technologies Private Limited

M/s AQM Technologies Private Limited

M/s Code Decode Labs Private Limited

M/s ESF Labs Limited

M/s FIME India Pvt. Ltd

M/s Nangia & Co LLP

M/s Oxygen Consulting Services Private Limited

M/s Suma Soft Pvt. Ltd

M/s Tata Communications

Internal Demo by NHA

Step 1b:   Post successful completion of the evaluation process by the FT (Functional Testing) agency, FT report(s) are to be submitted to NHA for approval. These FT reports submitted by FT agencies are in the standard template as approved by NHA. No FT report will be accepted if the report is not in the approved format. 

The ABDM Integration team will review the FT reports. Upon approval, an internal demo will be scheduled for the integrating agency. This step has been included to ensure that the testing conducted by the FT agencies is as per the defined test scenarios with all the updated functionalities.

WASA Certification (Website Application Security Assessment) 

Step 2: Security testing of the web/mobile application from any STQC or CERT-IN empanelled agency. Applicants are requested to engage with relevant agencies and submit the “Safe-to-Host” certificate to NHA

Step 3: A final round of approval for the application to go live will be sought from the internal team at NHA. Applicants will be required to share the following before the committee:

• Functional testing report for integrations completed

• Safe-to-Host certificate for the application

• Submission of Exit Form on sandbox with required artefacts.

Production Access

Step 4: Once approved, access will be shared for integration in the production environment. Client ID and Secret for the PRODUCTION environment will be shared separately on your registered email address