For labs & LIS Diagnostics
ABDM for diagnostic labs and LIS
A diagnostic lab is the simplest kind of ABDM participant. It produces reports, and the patient decides who sees them. The hard parts are all in the details: what counts as one record, which codes to use, where the PDF goes, and when a report should become visible.
01 The model
How an LIS maps to ABDM
Four objects your LIS already has, and the ABDM concept each one becomes. Getting this mapping right first saves most of the rework.
- Patient
-
Your patient ID, with an ABHA
Your own patient reference stays authoritative. The ABHA is attached to it, at the collection counter or later. A patient without an ABHA is still a patient: their reports simply cannot be linked yet.
- Order
-
A care context
One episode of care, with your own stable reference and the text the patient will see in their PHR app, such as “CBC and lipid profile, 7 Sep”. Its
occurred_atshould be when the sample was taken, because consent date ranges are matched against it. - Report
-
A DiagnosticReport record
The results, a conclusion, the signing pathologist and the report PDF, built as an NRCeS-profiled FHIR bundle and attached to the care context.
- Release
-
Linking, then consent
Linking makes the report visible to the patient. It reaches a doctor or another app only when the patient consents, and only within that consent’s terms.
02 The flow
From sample to the patient’s PHR app
Five calls or events per order. Your LIS sends the result fields it already stores, and the connector builds and validates the FHIR.
-
Identify the patient at collection
Scan & Share at the counter, login by OTP, or a new ABHA. Pass your patient reference and the ABHA is attached to it. The ABHA page covers each route.
-
Create the care context at order entry
POST /v1/care-contextswithhi_typeDiagnosticReport. At this stage there is no report to attach. -
Attach the report when it is signed
PUT /v1/care-contexts/{id}/recordwith the tests, the conclusion and the PDF. The response lists, for each result, whether it was coded. -
Link it to the ABHA
POST /v1/care-contexts/link. ABDM confirms asynchronously, and acare_context.linkedwebhook follows. -
Release under consent
When a doctor’s system asks, you receive
health_information.requested, and thenhealth_information.sentonce the encrypted report has gone.
PUT /v1/care-contexts/{id}/record
{
"hi_type": "DiagnosticReport",
"practitioner": {
"hpr_id": "meera.nair@hpr.abdm",
"name": "Dr Meera Nair"
},
"report_name": "Complete blood count",
"tests": [
{
"name": "Hb",
"value": 11.2,
"unit": "g/dL",
"reference_range": "13-17",
"interpretation": "low"
},
{
"name": "Peripheral smear",
"value": "Normocytic normochromic"
}
],
"conclusion": "Mild anaemia.",
"pdf": {
"data": "JVBERi0xLjcK…",
"title": "CBC report"
}
}
← 200 OK
{
"coding": [
{
"field": "tests[0]",
"source": "master",
"code": "718-7"
},
{
"field": "tests[1]",
"source": "none",
"code": null
}
]
}
03 LOINC
Coding results without guessing
LOINC codes make a result machine-readable wherever the report is opened. They are recommended, not required, and a wrong code is worse than none. The connector applies codes in a strict order and never guesses.
- 1 · Caller
-
A code you send always wins
If your LIS already maps its test catalogue, send the code with each result. Tests accept LOINC or SNOMED CT, and a report-level
report_codeaccepts LOINC only. Any other code system is refused with a 422 rather than passed through. - 2 · Master
-
Otherwise, a verified master
About 30 common tests (haemogram, glucose, HbA1c, renal function, electrolytes, lipids, liver and thyroid) are matched by name, ignoring case, dots and spacing, so
S. Creatinine,SGPTandHball match. Every code in the master was checked on the HL7 terminology server and against a second source.GET /v1/terminology/lab-tests?q=hbreturns 718-7, which is enough to build a picker for data-entry staff. - 3 · Text
-
Otherwise, plain text
Anything unmatched is sent as text, which is valid FHIR. There is no fuzzy matching. Names that are genuinely ambiguous, such as
sugar,glucose,albuminandprotein(which also name urine tests), are left uncoded on purpose.ESRandLDLget the method-less codes unless the method is named.
The rest of each result is kept faithfully. A number, or a
value like <0.5, becomes a quantity, while text such as
Positive or Nil stays text. Units are coded
in UCUM only when recognised; otherwise they stay as typed. The
original test name is always kept alongside any code. The
FHIR integration page covers the bundle
structure, and ABDM and FHIR
explains why the profiles look the way they do.
04The report PDF
Most patients and doctors will read the PDF, not the structured results, so it matters. Where it ends up depends on what comes with it:
- With test results: embedded in the DiagnosticReport as its presented form, alongside the coded values.
- Without results: filed as the report’s document. Use this for radiology and other imaging reports, because structured imaging needs DICOM media, which is not built here.
The file is checked before anything is published. It must start with
%PDF- and end with a %%EOF trailer, which
catches renamed images and uploads cut off in transit. The limit is
one PDF per record, 10 MiB decoded, sent as base64 or as a multipart
file part.
05Who signs the report
Name the reporting pathologist by HPR ID, either inline or as
practitioner_id from the facility’s roster. If no
practitioner is given, the facility itself is recorded as the
interpreting laboratory, which is valid but tells the reader less.
Pathologists who do not yet have an HPR ID can create one; the
HPR page explains how.
06Collection centres and processing labs
HFR registration is per physical facility, and every record is attributed to exactly one facility, the one named on its care context. A chain therefore has to decide, site by site and before anyone registers, which premises are facilities in their own right. Check how HFR’s facility types apply to collection-only premises, and choose deliberately which facility each report is issued from, whether that is the processing lab or the centre where the patient gave the sample.
Once that is settled, one integration and one set of API credentials reach every site. Each site is linked to the bridge once and then activated. Scan & Share works per site, so each collection counter gets its own QR. The HFR integration page covers registration.
07When a report should become visible
Linking makes a care context visible to the patient, and a care context with no report attached can be linked but cannot be sent when someone asks for it. The safe order for a lab is to create the care context at order entry, attach the record once the report is authorised, and link after that. Patients should not see an empty entry for a test that is still in progress.
An amended report is a new PUT to the same care context,
which replaces the attached record. That affects every request made
afterwards. A copy already delivered to a doctor under consent is not
recalled, so correct critical errors through your usual clinical
channel as well.
08Consent, and why a lab needs no M3
A lab publishes. The referring doctor’s EMR or a hospital HMS acts as the Health Information User. It raises the consent request, the patient approves it in their app, and the connector releases only the report types and date range that consent names. A revoked consent stops release immediately. Because the lab never requests records from anyone else, it needs M1 and M2 and not M3. The EMR side is described on the EMR page.
Send one report from your LIS
Sandbox credentials are issued on signup. Register a test lab, post a CBC with its PDF, and see which results came back coded.
FAQ Common questions