For EMR & clinic software Product teams
ABDM for EMR and clinic software
A clinic EMR touches ABDM at three points: identifying the patient at check-in, publishing what the doctor wrote, and showing what other providers wrote, with the patient’s consent. Here is what each takes, in terms of the screens you already have.
01 The product surface
Four screens change, and none is replaced
ABDM does not ask an EMR for a new workflow. It asks for a few calls at moments your product already has: the patient arriving, the visit closing, the doctor opening a chart.
- Front desk
-
Check-in knows the ABHA
Find, verify or create the patient’s ABHA and store it against your own patient id. ABHA is voluntary, so the ordinary registration path has to keep working for patients who do not have one or do not want one.
- Visit close
-
The note becomes a record
Complaints, vitals, diagnoses, medicines and advised tests go out as an OP consultation the patient can see in their PHR app, without your team writing FHIR.
- Chart
-
History from elsewhere
A consent request from the consult screen, and, if the patient approves, their records from other hospitals and labs arrive as FHIR bundles for the doctor to read.
- Signature
-
A registered doctor on the record
Each record names its author by HPR ID. A prescription without a prescriber is refused, because the national FHIR profile requires one.
02 Check-in
Pick the route by what the patient brought
There are several ways to identify a patient at the front desk, and only some need an OTP. A clinic with a queue should offer the one that fits the patient in front of it.
| The patient | Route | What your EMR calls |
|---|---|---|
| Has an ABHA app on their phone | Scan & Share: they scan the counter QR and read out a token | GET /v1/facility/scan-share-qr, then GET /v1/profile-shares |
| Has their phone, no app | Login by OTP, using ABHA number, address, mobile or Aadhaar | POST /v1/abha/login, then …/verify |
| Has no phone to hand | Find ABHA by mobile or Aadhaar, then a fingerprint or iris capture | POST /v1/abha/search, then …/biometric |
| Has no ABHA yet | Create one with an Aadhaar OTP or a mobile OTP | POST /v1/abha/enrolment/aadhaar |
Three things to design around. Find ABHA returns
masked numbers, which let the receptionist confirm the person but must
never be saved as an identifier. The biometric route needs a
UIDAI-certified capture device, and NHA must enable the method for your
client id. And ABDM v3 has no call that confirms an existing ABHA
against a name and year of birth, so do not build a screen that promises
one. Pass your own patient_reference on any of these routes
and the ABHA is linked to your patient record. A patient already linked
to a different ABHA is refused rather than silently re-pointed.
03 Visit close
Publishing the consultation
One visit is one care context. Your EMR sends the note in the fields it already stores. The connector builds the NRCeS-profiled bundle, validates it, and codes what it can.
-
Record the episode
POST /v1/care-contextswith your patient reference, a reference for the visit, the text the patient will see in their PHR app, andoccurred_at. Consent date ranges are matched against when the care happened, not when you uploaded it. -
Attach the note
PUT /v1/care-contexts/{id}/record. UseOPConsultationfor the visit note andPrescriptionfor a prescription issued on its own. A retry replaces the record, so it is safe. -
Link it to the ABHA
POST /v1/care-contexts/link. ABDM confirms later, and you receive acare_context.linkedorcare_context.link_failedwebhook. If you have no ABHA address on file,POST /v1/patients/{reference}/invitesends the patient an SMS link so they can link the visit themselves. -
Answer when someone asks
When another provider requests the record under the patient’s consent, the connector releases only what that consent covers, then sends you
health_information.sent.
PUT /v1/care-contexts/{id}/record
{
"hi_type": "OPConsultation",
"practitioner": {
"hpr_id": "ravi.kumar@hpr.abdm",
"name": "Dr Ravi Kumar"
},
"chief_complaints": ["Fever for 3 days"],
"vitals": {
"temperature_f": 100.4,
"pulse": 96,
"spo2": 98
},
"diagnoses": [
{
"name": "Hypertension",
"code": "I10",
"code_system": "icd10"
}
],
"medications": [
{
"name": "Paracetamol 500 mg tablet",
"frequency": "1-0-1",
"duration": "5 days"
}
],
"investigations_advised": ["CBC"],
"follow_up": {
"in_days": 7
}
}
← 200 OK
{
"care_context": {
"reference": "CC-2001",
"hi_type": "OPConsultation"
},
"coding": [… what was coded, per item]
}
The doctor’s shorthand survives. 1-0-1,
BD, HS and 5 days are kept word for
word and also structured, so a PHR app can render them. Implausible
vitals, such as a weight in grams or a temperature typed into the pulse
field, are refused rather than published. The
FHIR integration page covers how the
bundle is built.
04 The consult screen
History from other providers, with consent
This is the M3 half. Your EMR acts as a Health Information User. The patient decides in their own app, which can take minutes or days, so the design has to cope with a request that is still pending when the patient leaves.
- Ask
-
A narrow request, from a named doctor
POST /v1/consentswith the HI types and date range the clinical question needs,requester_nameandrequester_identifier, which is the doctor’s registration number. ABDM shows both to the patient, and rejects the request if the identifier is missing. Patients are more likely to approve a focused request. - Wait
-
A webhook, not a spinner
consent.granted,consent.deniedorconsent.expiredtells you what the patient decided. Show the request as pending on the chart and let the doctor carry on. - Fetch
-
Records arrive as FHIR bundles
POST /v1/health-informationagainst the granted consent. Records arrive asynchronously, andhealth_information.receivedtells you when. List them withGET /v1/recordsand open one with…/content, a read that is logged against your credential. - Forget
-
Received records carry an erase-by date
Each record comes with
erase_afterand is purged when that date passes. If the patient revokes consent, access stops immediately. Do not copy the bundle into your own chart tables, or you take on the obligation to delete it yourself.
Encryption is handled for you. Displaying the records is your job. Records travel encrypted with Fidelius: Curve25519 ECDH, HKDF-SHA256 and AES-256-GCM, with fresh keys for each transfer, and the connector decrypts and validates them. How a lab report or a discharge summary from another hospital looks in your consult screen is a product decision, and a real one. See the HIU integration page for the request lifecycle in full.
05Doctors and HPR
A doctor’s HPR presence has two parts, and EMR teams often mix them
up. The HPR ID is an identity: a number, an address
such as name@hpr.abdm, and a login. The professional
record holds the council registration, qualifications and
place of work, and the council and the facility verify it separately,
which can take days.
For signing records you need the identity. Add each doctor to the
clinic’s roster with POST /v1/practitioners,
which looks them up in HPR. After that a record can name the author by
practitioner_id instead of repeating the HPR ID and name.
Check verified on the roster entry: HPR refuses ID lookups
from some integrations, and an entry kept without HPR’s confirmation
is marked as unverified. The HPR integration
page covers creating the ID and submitting the professional record.
06Clinics and HFR
Every clinic that shares records needs its own entry in the Health Facility Registry, whatever its size. For a single-doctor practice that is one registration. For a chain it is one per physical site, because records are attributed to the facility that produced them. Someone at the clinic signs in with an HPR login to register it.
Registering is not the last step. The facility must also be linked to the bridge of the software making the ABDM calls. Until that link exists, the facility authenticates normally and every linking call is rejected, with no ABDM error that names the cause. The connector can make the link itself, and it activates a facility only once the link is made or declared done in the HFR portal.
07If your EMR is SaaS
Build the integration once and turn it on for each clinic. Every clinic is its own facility, with its own HFR ID, roster and care contexts, and one API credential reaches all of them. The ABHA routes do not depend on a facility. Scan & Share and record publishing do, so onboarding a clinic means registering its HFR entry and its doctors, not changing code.
The same API serves hospital systems. If your product is closer to an HMIS, the HMIS vendor page is the better fit. For how the provider and user roles differ, read HIP vs HIU.
08Certification
Before production access, the software that makes the ABDM calls must pass NHA’s exit process for each milestone it claims. That means functional testing by an NHA-empanelled agency, a security audit by a CERT-In empanelled auditor, and committee review. Building on this connector removes the protocol work. It does not remove the certification, which nobody can do for you. The sandbox guide covers what to have ready before you book the testing agency.
Publish one consultation this week
Sandbox credentials are issued on signup. Register a test clinic, send one OPD note, and see it appear in the sandbox PHR app.
FAQ Common questions