ABHA / ABDM Integration

The Ayushman Bharat Digital Mission is India's national health data infrastructure. For a hospital, ABDM integration means three things in practice: every patient can be identified through a nationally unique ABHA number instead of a local UHID; health records created at your hospital can follow the patient to their next provider through a consent-based exchange; and your facility appears in the national Health Facility Registry, which increasingly determines discoverability in ABDM-linked patient apps and PMJAY claim processing eligibility.

In practice, most hospital software vendors treat ABDM as an API checkbox. They create the ABHA number at registration and stop there. The harder parts, acting as a Health Information Provider that pushes structured clinical records into the ABDM network, or acting as a Health Information User that pulls records from other providers with patient consent, require deep integration into the clinical workflow. A lab result needs to be pushed as a FHIR Diagnostic Report, not just stored locally. A discharge summary needs to be structured as a FHIR Composition document. OneCity handles this at the point of clinical documentation, not as a batch export after the fact.

Health Information Provider (HIP) is the role your hospital plays when it creates clinical records. Every OPD consultation note, lab report, discharge summary, and prescription your hospital generates becomes a health record that the patient can share with other providers. Your software must structure these records in FHIR R4 format and push them to the ABDM Health Information Exchange when the patient or a requesting provider initiates a consent flow. OneCity generates FHIR-compliant bundles from the clinical documentation workflow automatically.

Health Information User (HIU) is the role your hospital plays when it needs to pull records from another provider. A patient arrives at your emergency department with a history at three other hospitals. With ABDM consent, your doctor can pull their records electronically. OneCity's emergency module handles the consent request flow and displays the retrieved records inline with the current encounter.

Health Facility Registry (HFR) registration is the prerequisite. Your hospital must be registered on the national Health Facility Registry before it can act as either HIP or HIU. OneCity stores and tracks the HFR registration ID alongside your other facility identifiers.

Healthcare Professionals Registry (HPR) links each doctor and nurse to a nationally verified identity. When a clinical record is pushed to ABDM, the authoring clinician's HPR ID is attached, creating a verifiable chain of authorship. OneCity maps HPR IDs to user accounts at the point of onboarding.

ABDM consent is granular and patient-controlled. A patient can grant access to specific record types, from specific providers, for a specific time window. The consent artefact is digitally signed and stored on the ABDM Consent Manager, not on your hospital's server. When a consent request arrives at your hospital (because another provider wants to pull your patient's records), your software must respond programmatically, not by sending an email to the medical records department.

OneCity handles inbound consent requests through an automated flow: the request arrives via the ABDM gateway, matches to the patient's local record, checks the scope against available record types, and responds within the SLA window. The doctor or medical records officer sees a dashboard of pending and completed consent flows rather than managing them manually. This also ties into DPDP Act 2023 compliance, since ABDM consent and DPDP consent are related but distinct obligations.

The NHA publishes sandbox and production APIs that change with each milestone release. A hospital software vendor that integrated against Milestone 1 APIs in 2022 may find that Milestone 3 requirements in 2026 demand restructured consent flows and additional record types. OneCity maintains a dedicated ABDM integration team that tracks NHA milestone releases and updates the integration layer without requiring the hospital to do anything beyond accepting a software update.

For hospitals already running OneCity, ABDM integration is a module activation, not a migration project. The clinical data is already structured internally in a way that maps to FHIR resources. For hospitals running older software that does not support ABDM natively, migrating to OneCity is often the fastest path to compliance. The implementation timeline covers what that migration involves.

The broader compliance picture matters here. ABDM integration connects to NABH accreditation readiness because many NABH quality indicators rely on the same structured clinical data. It connects to Clinical Establishment registration because HFR registration is increasingly cross-referenced with state registers. And it connects to blood bank operations because blood product records are among the clinical record types ABDM expects providers to share.

Is ABDM integration mandatory for hospitals in India?

ABDM integration is currently mandatory for hospitals participating in government insurance schemes such as PMJAY and CGHS. For private hospitals outside these schemes it is technically voluntary, but the regulatory direction is clear: Health Facility Registry registration is increasingly required for empanelment, and ABHA-based patient identification is becoming the default in several states. Most hospitals treating it as optional today will need it within the next compliance cycle.

What is the difference between ABHA number and ABHA address?

The ABHA number is a 14-digit nationally unique health identifier created through Aadhaar or mobile OTP verification. The ABHA address is a user-chosen handle in the format name@abdm that acts as a human-readable alias for the ABHA number. Patients use the ABHA address to discover and link health records. Your hospital software needs to handle both: create the ABHA number at registration and link it to the ABHA address for record exchange.

Does ABDM integration require hospitals to share all patient records?

No. Record sharing under ABDM is consent-based. A patient must explicitly grant consent for a specific provider to access specific record types for a specific time period. Your hospital pushes records to the ABDM network as a Health Information Provider, but no other provider can pull those records without a valid consent artefact. The patient controls the consent through their ABHA app or any ABDM-compatible patient app.

Can existing hospital software be upgraded to support ABDM, or does it require a new system?

It depends on the architecture. Software that already stores clinical data in structured formats can potentially add ABDM APIs as an integration layer. Software that stores clinical data as free-text notes or scanned PDFs cannot generate the FHIR-compliant records ABDM requires without a fundamental rebuild. In practice, many hospitals find that migrating to ABDM-native software is faster and cheaper than retrofitting a system that was never designed for structured health data exchange.