HL7 Evolution: From Pipes to APIs
The Reader's Dilemma
Dear Marilyn,Our hospital has been using HL7 v2 messages for decades. Now everyone is talking about FHIR and REST APIs. I'm drowning in pipe characters and segment names like MSH, PID, and OBX. How did we get here, and why should I care about the evolution?
Marilyn's Reply
The history of healthcare data exchange is a fascinating journey from chaos to order. In the 1980s, every hospital system spoke its own language. A lab system couldn't talk to a pharmacy system, which couldn't talk to the billing system. It was the Tower of Babel, but with patient lives at stake.
The Spark: Understanding HL7's Journey
The Birth of HL7 (1987)
Health Level Seven (HL7) was born from necessity. The "7" refers to the seventh layer of the OSI model—the application layer. A group of healthcare IT pioneers gathered to create a standard way for systems to exchange clinical data.
# Example HL7 v2.x Message
MSH|^~\&|LAB|HOSPITAL|EMR|HOSPITAL|20240115120000||ORU^R01|MSG00001|P|2.5 PID|1||12345^^^HOSP^MR||DOE^JOHN^A||19800101|M OBR|1|12345|67890|CBC^Complete Blood Count|||20240115100000 OBX|1|NM|WBC^White Blood Cell Count||7.5|10*3/uL|4.5-11.0|N|||F
Look at those pipe characters (|) and carets (^). This is the language of HL7 v2.x—a format that has been the backbone of healthcare interoperability for over 35 years. Each segment (MSH, PID, OBR, OBX) tells a specific part of the story.
The Segments Decoded
| Segment | Name | Purpose |
|---|---|---|
| MSH | Message Header | Identifies sender, receiver, message type, and encoding |
| PID | Patient Identification | Contains patient demographics (name, DOB, MRN) |
| OBR | Observation Request | Details about the order or test being reported |
| OBX | Observation Result | The actual test results with values and units |
| EVN | Event Type | Describes the trigger event (admit, discharge, transfer) |
| PV1 | Patient Visit | Information about the patient's visit or encounter |
The Problem with v2.x
Despite its success, HL7 v2.x has significant limitations:
- Optionality Hell: Most fields are optional, leading to wildly different implementations between vendors.
- Z-Segments: Custom segments (Z-segments) allow vendors to add proprietary data, breaking interoperability.
- Point-to-Point: Each integration requires custom mapping, creating an N×N problem.
- No Web Native: Designed for TCP/IP sockets, not modern REST APIs.
Enter FHIR (2014)
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") was designed to solve these problems. It combines the best of HL7 v2, v3, and CDA with modern web standards:
- RESTful APIs: Standard HTTP verbs (GET, POST, PUT, DELETE) for all operations.
- JSON & XML: Human-readable formats that developers already know.
- Resources: Well-defined building blocks (Patient, Observation, Medication) with clear structures.
- Profiles: Constrain resources for specific use cases while maintaining interoperability.
// Same data as FHIR JSON
{
"resourceType": "Observation",
"id": "wbc-result",
"status": "final",
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "6690-2",
"display": "White Blood Cell Count"
}]
},
"subject": {
"reference": "Patient/12345"
},
"valueQuantity": {
"value": 7.5,
"unit": "10*3/uL",
"system": "http://unitsofmeasure.org"
},
"referenceRange": [{
"low": {"value": 4.5},
"high": {"value": 11.0}
}]
}The Gauntlet: Test Your Knowledge
Quick Check
What does the '7' in HL7 refer to?
Quick Check
Which HL7 v2.x segment contains patient demographics like name and date of birth?
Quick Check
What is a major limitation of HL7 v2.x that FHIR addresses?
Quick Check
What format does FHIR use for data exchange?
Quick Check
What does FHIR stand for?