HL7 and FHIR: How Medical Systems Exchange Data

The short version: what is the difference

HL7 (Health Level Seven) is a family of standards for exchanging medical data. In practice two of them show up most often:

The two are not mutually exclusive: many projects receive HL7 v2 from the lab and work with FHIR internally.

What HL7 v2 looks like

A message consists of segments (lines); a segment consists of fields separated by |, and a field of components separated by ^. The message type reflects the event: ADT^A01 is a patient admission, ORM^O01 an order, ORU^R01 a result.

MSH|^~\&|LAB|CLINIC|MIS|CLINIC|202601151030||ORU^R01|MSG00001|P|2.5
PID|1||123456^^^CLINIC^MR||Karimov^Aziz||19850312|M
OBR|1||LAB7781|58410-2^CBC panel^LN
OBX|1|NM|718-7^Hemoglobin^LN||142|g/L|130-170|N|||F

• MSH: header with sender, receiver, type and version;
• PID: patient data;
• OBR: the test order;
• OBX: a single observation with code, value, units, reference range and flag.

The receiver replies with an ACK. The main difficulty of HL7 v2 is dialects: each vendor fills fields differently and adds custom Z-segments, so an interface specification is agreed for every pair of systems.

How FHIR works

FHIR models data as resources with an address and standard REST operations. The core resources for a clinic are Patient, Practitioner, Encounter, Appointment, ServiceRequest, Observation, DiagnosticReport, Coverage and Claim.

GET /fhir/Observation?patient=Patient/123&category=laboratory

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [{ "system": "http://loinc.org", "code": "718-7", "display": "Hemoglobin" }]
  },
  "subject": { "reference": "Patient/123" },
  "valueQuantity": { "value": 142, "unit": "g/L", "system": "http://unitsofmeasure.org", "code": "g/L" }
}

FHIR's strengths are consistent search rules, profiles for national and project-specific requirements, subscriptions to changes, and OAuth 2.0 authorisation for apps via SMART on FHIR. The specification is published by HL7 at hl7.org/fhir.

Typical clinic integrations

• Laboratory: a test order from the clinic system goes to the lab information system, and the result comes back into the patient record. Often HL7 v2.
• Analysers and devices: results straight from instruments, usually through middleware.
• Medical information system (MIS): exchanging patients, schedules and visits with the website, call centre and mobile app.
• Insurers: policy checks, pre-authorisation of services, billing.
• Government systems: sending data to national platforms on their terms; the format is defined by the platform operator.

What to plan before connecting

1. System inventory: what each side supports, whether HL7 v2, FHIR, a proprietary API or files only.
2. Code sets: how tests, services and diagnoses are coded (LOINC, ICD-10 or internal codes) and who maintains the mapping table.
3. Patient matching: which key links records so you do not create duplicates or mix people up.
4. Integration layer: a broker or integration engine that receives messages, transforms formats and queues them, instead of point-to-point links between every pair of systems.
5. Errors and retries: what happens when the receiver is down; a message log and manual resend.
6. Security and compliance: encrypted channels, authentication, access logs and compliance with personal and medical data rules.
7. Testing: a test environment and a set of realistic anonymised scenarios, including edge cases.

Common mistakes

• Assuming "supports HL7" means ready compatibility; the dialect still has to be agreed.
• Storing test codes as free text.
• Connecting systems directly with no queue or log, so a lost message can never be traced.
• Using real patient data in the test environment.