ABHA linkage, HIP and HIU roles, HFR/HPR registration, consent-gated exchange in national FHIR R4 format. The record layer NABH 6th edition now rewards.
The Ayushman Bharat Digital Mission builds a connected health record layer: a portable health ID (ABHA), a facility registry (HFR), a professionals registry (HPR), and consent-gated record exchange. To take part, your system creates and links ABHA numbers, registers as a recognised provider, and exchanges records in the national FHIR format with patient consent.
Two roles decide what your software must do. As a Health Information Provider (HIP) your hospital generates lab reports, discharge summaries and prescriptions and makes them shareable. As a Health Information User (HIU) it requests a patient's history from elsewhere. Software that cannot play both roles cannot participate — and NABH 6th edition now rewards those that can.
There's a real gap between "ABDM-ready" and "ABDM-live" that's worth checking before you buy. Sandbox integration — where a vendor demonstrates the HIP/HIU flow against NHA's test environment — is a meaningfully lower bar than a production gateway that has been through NHA's approval process and is actually exchanging records for real patients. Ask to see the difference on a live call, not a feature list.
| ABDM block | What it does | OneCity module | |
|---|---|---|---|
| ABHA creation & linkage | Portable patient health ID | Patient Registration (ABHA/UHID) | ✓ |
| HIP role | Publish lab, discharge, Rx as shareable records | ABDM Gateway — HIP | ✓ |
| HIU role | Request patient history from other providers | ABDM Gateway — HIU | ✓ |
| HFR / HPR registration | Facility + professional identity in national registry | Facility & Provider Registry | ✓ |
| Consent management | Patient consent before any record moves | Consent & Privacy Ledger (DPDP 2023) | ✓ |
| FHIR R4 record format | National-standard resource generation | FHIR R4 engine across clinical modules | ✓ |
Most of the delay in ABDM rollouts sits in the registry and approval steps, not the software itself — HFR and HPR registration can take longer than expected if the facility's paperwork isn't in order, so it's worth starting those in parallel with the technical integration rather than after it.
It means the system can create and link ABHA health IDs, register the hospital and its clinicians in the HFR/HPR registries, and exchange health records in the national FHIR R4 format with patient consent — playing both the HIP (provider) and HIU (user) roles.
A Health Information Provider (HIP) generates and holds records — lab reports, discharge summaries, prescriptions — and makes them shareable. A Health Information User (HIU) requests and views a patient's records from other providers. A full hospital system needs both. OneCity plays both roles.
The NABH 6th edition, effective 1 January 2025, strongly emphasises EMR and ABDM integration. It is not an absolute bar in every element, but hospitals with ABDM linkage score materially higher on the digital-health standards.
Yes. OneCity generates FHIR R4 resources across clinical modules — the EMR produces FHIR-compliant records, the lab exports diagnostic reports in ABDM format, and radiology packages imaging as FHIR ImagingStudy resources.
Sandbox integration and testing typically runs a few weeks once the software's HIP/HIU gateway is built. Moving from sandbox to production requires NHA approval of the facility's ABDM integration, which is a separate step from the software being technically ready — ask any vendor to show a live sandbox session, not just a slide, before signing.
Nothing moves. ABDM's entire architecture is consent-first — a HIU cannot pull a patient's records from a HIP without an explicit consent artefact tied to that specific request. A patient who declines is treated and billed normally; only the cross-facility record exchange is skipped.
See ABHA linkage, a HIP publish and an HIU fetch run end to end on a live demo.
