What ABDM integration involves for hospital and clinic software

Why hospitals are being asked about ABDM

Patients now arrive with an ABHA number on their phone. State health departments, insurers and government schemes ask hospitals whether their software is ABDM compliant. And if you sell an HMIS, a clinic app or a lab system, your customers will ask you the same thing.

The Ayushman Bharat Digital Mission, run by the National Health Authority, sets up shared building blocks so health records can move between providers with the patient's consent. Integrating means your software talks to those building blocks through the APIs the NHA publishes.

Quick answer

ABDM integration usually covers three milestones:

1. Milestone 1: ABHA. Create or verify a patient's ABHA number and ABHA address inside your registration flow.
2. Milestone 2: Health Information Provider. Link the records your system creates, such as prescriptions, lab reports and discharge summaries, to the patient's ABHA, and share them when the patient consents.
3. Milestone 3: Health Information User. Request and view a patient's records from other providers, again with consent.

You build and test in the ABDM sandbox, pass the NHA's functional review, complete a security audit, and then move to production. For a team that knows the domain, each milestone typically takes a few weeks of development plus review time.

The building blocks you will touch

• ABHA (Ayushman Bharat Health Account). A health ID for each patient, with an ABHA address that works like a username.
• Health Facility Registry (HFR). Your hospital, clinic or lab registers here. Each facility gets an ID used in record sharing.
• Healthcare Professionals Registry (HPR). Doctors, nurses and other professionals register here.
• Consent manager. The patient approves or denies each request to share their records, through their ABHA app.
• Health Information Exchange. The pipe that carries encrypted records between providers once consent is given.

What changes in your software

Registration

Add ABHA creation and verification at the front desk, using Aadhaar or mobile OTP flows as ABDM allows. Support Scan and Share, where the patient scans a QR code at your counter and their details fill in automatically. This alone can shorten OPD queues.

Clinical records

Records must be shared as FHIR R4 documents following the profiles published for India by NRCeS. That means mapping your data to standard structures:

• Prescriptions, with medicines coded properly
• Diagnostic reports, with lab values and units
• OP consultation notes
• Discharge summaries
• Immunisation records

This mapping is usually the biggest piece of work. If your system stores a prescription as free text in one field, you will need to restructure it, at least for new records.

Linking and consent

When a record is created, it must be linkable to the patient's ABHA. When a consent request arrives, your system must find the right records for the period and types the patient approved, encrypt them as specified and send them. You also need to respect consent expiry and revocation.

Security and privacy

Health data is sensitive personal data in every practical sense, and the DPDP Act 2023 applies alongside ABDM's own policies. Encrypt data at rest and in transit, log access, and limit staff access by role. ABDM requires a security assessment of your application before production access, so plan for a CERT-In empanelled auditor or the route the NHA specifies at the time.

A realistic plan

1. Week 1. Register on the sandbox, read the current specifications, and map your data to the FHIR profiles.
2. Weeks 2 to 3. Build Milestone 1 and Milestone 2 in the sandbox. Test with sample ABHA accounts.
3. Weeks 3 to 5. Fix review findings, complete the security audit and apply for production.
4. After go live. Train front desk staff, watch for failed linkings and consent errors, and add Milestone 3 if your clinicians want to pull external records.

Timelines vary with the state of your codebase and the NHA's review queue, which you do not control. Leave slack.

What goes wrong

• Treating it as an API task only. The front desk process changes. If staff are not trained, ABHA fields stay empty.
• Poor data quality. Unstructured or inconsistent clinical data makes FHIR mapping slow. Fix the source where you can.
• Ignoring incentives and schemes. The Digital Health Incentive Scheme has rewarded facilities for digital transactions. Check the current terms with the NHA before you count on it.
• Building against old specifications. The APIs and documents are updated. Always build against the current sandbox version.

Buying or building

Questions to ask if you buy

If you are a hospital choosing an HMIS, ask the vendor directly:

• Which ABDM milestones are live in production today, not planned?
• Which record types do you share as FHIR documents, and which are still PDFs or free text?
• Does your front desk screen support Scan and Share, and how long does a registration take with it?
• Who handles failed links and consent errors after go live, and how quickly?
• Where is our data hosted, and how do you meet DPDP Act obligations as our processor?

Vague answers to the first two questions usually mean the integration is not yet in real use.

When you need outside help

If you run a single clinic, choose a ready ABDM integrated clinic product. If you are a hospital group with your own HMIS, or a software company serving many facilities, integration is a real engineering project. A partner who has worked with FHIR and consent based sharing can save you weeks of trial and error in the sandbox.