What is ABHA in ABDM?

A health account number the patient owns, not the clinic. It is how the same person is recognised at a clinic in Prayagraj and a hospital in Noida without either of them sharing a patient database.

What is The Consent Manager in ABDM?

An app the patient chooses, which holds their credentials and issues consent. No provider — including us — ever sees those credentials. This is the part most people expect to be a login and is not.

What is HIP — Health Information Provider in ABDM?

The role a clinic system plays when it holds records someone else has been granted. It must publish care contexts, verify the artefact, and hand over exactly what was consented to and nothing adjacent.

What is HIU — Health Information User in ABDM?

The same system in reverse: requesting a patient’s history from elsewhere and presenting it as one record. A clinic is usually both, on different days.

ABDM & interoperability

Where we actually stand.

ABDM is a consent protocol, not a file transfer. Most of the work is not in moving records — it is in proving you were allowed to.

For a clinic owner

What ABDM asks of an EMR.

Four terms do most of the work. They describe the protocol itself, which is public architecture — not our conformance to it, which is the table further down.

ABHA: A health account number the patient owns, not the clinic. It is how the same person is recognised at a clinic in Prayagraj and a hospital in Noida without either of them sharing a patient database.
The Consent Manager: An app the patient chooses, which holds their credentials and issues consent. No provider — including us — ever sees those credentials. This is the part most people expect to be a login and is not.
HIP — Health Information Provider: The role a clinic system plays when it holds records someone else has been granted. It must publish care contexts, verify the artefact, and hand over exactly what was consented to and nothing adjacent.
HIU — Health Information User: The same system in reverse: requesting a patient’s history from elsewhere and presenting it as one record. A clinic is usually both, on different days.

Self-assessed

Milestone by milestone.

ABDM milestones and our current engineering state against each
Milestone	What it requires	Where we are	Status
M1 — ABHA & identity	Create and verify an ABHA, discover a patient by it, and link that identity to the clinic’s own record.	Registration and patient reconciliation are built. ABHA linkage is not.	Planned
M2 — Health Information Provider	Create care contexts after a consult, answer discovery, verify consent artefacts, and return encrypted FHIR records to an authorised requester.	The FHIR R4 boundary mapper is implemented and tested offline. Consent-artefact verification and care-context linking are not yet built.	In progress
M3 — Health Information User	Request consent, fetch records from other facilities across the network, and present them to the clinician as one history.	Designed against the same mapper. No implementation yet.	Planned
M4 — Claims via NHCX	Exchange digital insurance claims over the National Health Claims Exchange.	Not part of the Phase 1 product.	Out of scope

The centrepiece

How a record actually moves.

01
The patient

Holds an ABHA and a Consent Manager app of their choosing. A request to view their records arrives there, naming who is asking, for what, and for how long.
02
Consent Manager

The patient grants or refuses. On a grant, the Consent Manager issues a signed consent artefact scoped to a purpose, a date range and an expiry.
Signed consent artefact
03
Medveda, as HIP

Verifies the artefact, resolves it to the care contexts it covers, and refuses anything outside its scope. Credentials stay with the Consent Manager; we never see them.
Encrypted FHIR R4 bundle
04
The requesting facility

Receives the bundle it was granted and nothing else. Every exchange leaves a row in an append-only audit log on our side, whether or not it succeeded.

No record moves without a signed consent artefact, and Medveda never sees the patient's ABHA credentials — the Consent Manager holds them.

Conformance

The boundary mapper.

The record is stored relationally and projected to FHIR at the boundary — not stored as FHIR. That keeps the clinical model ours and the wire format theirs, so an implementation guide version bump is a mapping change rather than a migration.

Consult encounter Composition · OPConsultRecord
Coded examination finding Observation
Diagnosis Condition
Composed prescription line MedicationRequest
Patient record Patient
Practitioner Practitioner

Lossy by design — the projection carries what the profile requires and nothing more.

What we hand over OPConsultRecord

Format: FHIR R4 document bundle
Profile: Supplied at deployment Not yet configured
Subject: The patient record the consult belongs to

Sections in the bundle

Chief complaints
Physical examination
Medications

HFR & HPR

Who registers what.

The most common misunderstanding in ABDM integration: software is assessed once, but every facility and every practitioner registers separately, and no vendor can do it for them.

The software — our side

Passes the NHA sandbox milestone walkthroughs for the roles it implements.
Holds its own application credentials, never a facility’s.
Re-verifies when the ABDM implementation guide version moves.

The clinic — your side

Registers itself in the Health Facility Registry and holds its own HFR ID.
Each practitioner registers in the Healthcare Professionals Registry, using their own council registration.
Remains the data fiduciary for its patients’ records. We process on its instruction.

Why it is a separate process

One deployable carries the ABDM surface.

Certification, re-certification when the implementation guide version moves, and audit are all dramatically easier when the ABDM surface is one small deployable. That was decided before any of it was written, not retrofitted.

edge-bff The clinician’s browser talks only to this.
core-api Clinical domain and the record itself.
worker Documents, delivery, scheduled work.
ai-svc Assistive inference, off the clinical write path.
abdm-gw Every ABDM call, in and out. Nothing else lives here. ABDM surface

Five deployables in Phase 1. Every ABDM call — in or out — crosses abdm-gw and nothing else, so the surface that gets certified is one process rather than the whole product.

Present tense

What is true today.

Stated as of today, including the rows that are not finished. A posture table with no unfinished rows has not been written honestly.

Security and residency posture, with how each is established
Control	State	How it is established
FHIR R4 boundary mapping	Implemented	Projection table in `libs/abdm`, covered by offline tests. No network dependency.
ABDM gateway isolation	Implemented	`abdm-gw` is a separate deployable; module boundaries are enforced by a CI lint rule.
Gateway configuration	Planned	No endpoint, client id or profile URI exists in our codebase. The config reports its own absence rather than defaulting.
Append-only audit log	Implemented	Every record access writes a row that cannot be updated or deleted; a CI check proves it.
Tenant isolation	Implemented	Row-level security in Postgres, with a cross-tenant read test that must fail to pass.
Data residency — India only	Authored, not deployed	An Organizations SCP keyed on `aws:RequestedRegion`, plus a multi-region CloudTrail and an alarm on denied out-of-region calls. CI fails if any non-Indian region is named anywhere in the infrastructure code. Not yet applied — no production account exists.
Safe-to-Host certificate	Planned	Requires an audit by a STQC or CERT-In empanelled agency. Not yet commissioned; no date is claimed.

Questions from NHA or an integration partner.

We will answer specifics about scope, architecture or timelines directly, and we will say when we do not know something.

Get in touch