FHIR and LOINC, for people who don't build EHRs
Two acronyms decide whether a health record can travel between systems or stays stuck in the one that made it. A plain-language guide to what they are and why an interpretation layer depends on them.
Most medical data is born as a document: a lab PDF, a scanned discharge letter, a photo of a prescription. People can read those. Software mostly cannot — not reliably, and not in a way another system can pick up. Two standards do most of the work of turning documents into data that travels.
LOINC: one name for one test
Labs name the same test differently: “Hb”, “Haemoglobin”, “HGB”, in any language. LOINC gives each laboratory and clinical observation a code, so that 718-7 means haemoglobin mass concentration in blood regardless of which lab printed it or what it called it. Without a shared code, a trend across two labs is a guess about whether two lines are the same test.
FHIR: one shape for the record
FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for how health data is structured and exchanged. It breaks a record into resources with agreed shapes: a Patient, an Observation for each result, a DiagnosticReport that groups them, a Condition, a MedicationStatement. Any system that speaks FHIR can read what another wrote.
Why an interpretation layer needs both
- Trends need LOINC: the same marker from different labs has to be recognised as the same marker.
- Context needs FHIR: diagnoses, medications and history have to sit next to the results in a shape the reasoning can use.
- Integration needs FHIR: a lab, clinic or app can take the output into its own systems without a custom format.
Vitrubo turns every uploaded document into FHIR R4 resources with LOINC-coded results, and exposes the same through its API. How documents become one record is on Medical records.
This article is general information, not medical advice. Talk to a clinician about your own results.
