Picture a hospital emergency room. Patient comes in with chest pain. A triage nurse enters their name and date of birth into the EMR. Immediately, a label printer in the laboratory basement prints a barcode for blood work. Three floors up, a radiology technician sees a new chest X-ray order pop on their worklist. The billing department opens a new account automatically.
To the staff working there, this information flow feels like magic. To those of us in healthcare IT, we know what’s happening. It’s HL7.
Health Level Seven is the standard language letting different systems talk to each other. Epic, Cerner, Meditech. These companies compete fiercely. But they communicate through HL7.
Remove HL7, and healthcare stops working. You’re back to faxes, manual data entry, errors from transcription mistakes that kill people.
Developers, IT directors, and hospital administrators encountering HL7 for the first time find it confusing. It’s text-based. Pipe-delimited. Looks like something from the 1980s. That’s because it is from the 1980s.
But newer standards like FHIR exist now. They’re more modern. Yet HL7 Version 2 still runs healthcare data exchange. Ninety percent of US hospitals depend on HL7 v2 for their core clinical data exchange. Not because it’s good. Because it exists and works.
Lifepoint Informatics has been doing HL7 since 1999. They’re not learning it. They know it cold. They’ve connected data from every major EMR, LIS, and RIS system on the market. They’ve seen every version, every custom hack, every edge case that breaks other interface engines.
Part 1: The History and “Why” of HL7
The Pre-Standardization Chaos
Go back to 1987. Healthcare IT was a mess. A hospital buys a Lab System from Vendor A and an Admission System from Vendor B. They don’t talk to each other.
Hospitals had to pay vendors enormous amounts of money to build custom interfaces between systems. Just to move data between two systems. Every new system purchase meant new custom interfaces. Costs spiraled.
People had to enter data manually. A clerk types a patient’s name into the admission system. A lab tech types that same name into the lab analyzer. Typos happen. “John Smyth” instead of “John Smith.” Now the lab results don’t match the patient record. Results get lost. Patients don’t get their test results.
This wasn’t just inconvenient. It was dangerous.
Enter Health Level Seven
Someone decided this needed to stop. The name “Health Level Seven” comes from the OSI Model, specifically the seventh layer, the Application Layer. The idea was straightforward. Create a standard way for healthcare applications to exchange data.
HL7 v2 was the result. It gets called the “non-standard standard” because it tried to be a standard but stayed flexible. Vendors could adapt it to their needs. This solved the immediate problem. Systems could communicate. But it created a different problem. Vendors implemented it differently.
This is why true interoperability is still a myth. Different vendors interpret the same standard in different ways. You need partners who understand all those variations and can bridge them. That’s what Lifepoint does.
Part 2: Visualizing the Format: Pipes, Hats, and Hierarchies
HL7 v2 is plain text. No XML tags. No JSON brackets. It uses delimiters instead. Special characters that separate data. The design kept message file sizes small back when modems were slow and storage was limited.
The Delimiters: The Grammar of HL7
You need to understand the punctuation to read HL7.
The Segment Terminator is the Enter key. Each new line is a new segment.
The Field Separator is the Pipe character (|). It separates fields within a segment.
The Component Separator is the Caret or Hat (^). It separates parts of a field. Last name from first name, for example.
The Sub-Component Separator is the Ampersand (&). For complex sub-groups.
The Repetition Separator is the Tilde (~). When a field appears multiple times. Like multiple phone numbers.
The Escape Character is the Backslash (). To escape special characters within text.
These characters are the grammar. Without them, the message is meaningless.
Positional Logic: The “Counting Pipes” Problem
Position is the most critical concept in HL7. In XML, you see <name>John</name> and you know that’s a name. In HL7, the computer knows “John” is the patient’s name only because it’s in the 5th field of the PID segment. Position tells you what something is.
Look at this example: PID|||12345||DOE^JOHN
This works. Position 3 is 12345, which is the patient ID. Position 5 is DOE^JOHN, which is the patient’s name.
But what if the sender makes a mistake and adds an extra pipe: PID||||12345||DOE^JOHN
Now position 4 is 12345, which gets interpreted as the patient name. And position 6 becomes DOE^JOHN, which gets interpreted as the mother’s maiden name. The whole message is wrong.
This fragility breaks things. Generic integration engines don’t care. They accept bad messages. Corrupted data flows into patient charts silently. Nobody notices until bad data causes problems.
Lifepoint Informatics validates everything. They count pipes, yes. But they also validate the data type inside each pipe. You’re supposed to send a date in YYYYMMDD format, but send a name instead? The system catches it. Quarantines the message. Alerts your IT team before garbage data touches the EMR.
This is why they’ve been the standard since 1999. Attention to detail. Other systems let bad data through. Lifepoint stops it.
Part 3: The Anatomy of a Message – Segment by Segment
An HL7 message is a collection of segments. Each segment starts with a 3-letter code identifying its purpose. Common segments in hospital workflows:
1. MSH: The Message Header
Every HL7 message starts with MSH. It defines the rules for that specific message.
MSH-3 (Sending Application) tells you who’s talking. Epic. Cerner. A lab system.
MSH-4 (Sending Facility) is which hospital. General Hospital. Mayo Clinic.
MSH-9 (Message Type) says what this is. ADT^A01 means admission. ORM^O01 means order. ORU^R01 means results.
MSH-10 (Message Control ID) is a unique ID for tracking that specific message.
MSH-12 (Version ID) says which HL7 version. 2.3, 2.5.1, 2.7. Version matters. Ethnicity and race fields shifted positions between versions. An HL7 2.3 message looks fine to a 2.5.1 system until you hit those fields. Lifepoint’s engines handle version translations automatically. You don’t rewrite interfaces every time a vendor upgrades.
2. PID: Patient Identification
This segment matters most for patient safety. PID-3 is the Patient ID. The Medical Record Number. The MRN. This is the Golden Key linking all data together.
PID-5 is Patient Name. Formatted as Family Name^Given Name^Middle^Suffix^Prefix.
PID-7 is the Date of Birth. YYYYMMDD format.
PID-8 is Sex. M, F, U (Unknown), or O (Other).
PID-11 is the address. Street^City^State^Zip^Country.
PID-18 is the Account Number. The billing number for this specific visit.
3. PV1: Patient Visit
Context matters. A patient has existed in the system for years. PV1 tells you about their current stay.
PV1-2 (Patient Class) is I (Inpatient), O (Outpatient), E (Emergency).
PV1-3 (Assigned Location) is Nurse Unit^Room^Bed. Like ICU^101^A.
PV1-7 (Attending Doctor) is the ID and Name of the doctor in charge.
PV1-19 (Visit Number) is a unique ID for this specific encounter.
4. ORC: Common Order
When a doctor orders a test, ORC handles the logistics.
ORC-1 (Order Control) is NW (New Order), CA (Cancel), XO (Change Order).
ORC-2 (Placer Order Number) is the ID given by the EMR. The system is placing the order.
ORC-3 (Filler Order Number) is the ID given by the Lab. The system is filling the order.
The Placer/Filler Dance is one of the hardest parts of HL7. The EMR knows the order as “123” but the Lab knows it as “ABC.” The interface maintains a cross-reference table. When the result “ABC” comes back, it matches the order “123.” Lifepoint handles this ID mapping transparently.
5. OBR: Observation Request
This defines the clinical question.
OBR-4 (Universal Service ID) is the test code. Use LOINC codes like 85025^CBC for universality. Many older systems use proprietary code. Problems arise from that.
OBR-7 (Observation Date/Time) is when the sample was drawn.
OBR-16 (Ordering Provider) is the person who asked for this test.
6. OBX: Observation Result
This is the payload. The actual clinical data.
OBX-2 (Value Type) is what kind of answer:
NM (Numeric): “120”
ST (String): “Clear yellow.”
TX (Text): A paragraph of pathologist notes.
ED (Encapsulated Data): A Base64 encoded PDF or image.
OBX-3 (Observation ID) is the specific test part. Glucose. White Blood Cells.
OBX-5 (Observation Value) is the result itself.
OBX-6 (Units) is mg/dL, mmol/L, etc.
OBX-8 (Abnormal Flags) is H (High), L (Low), LL (Critical Low), N (Normal).
Part 4: The Lifecycle of a Message – A Real-World Workflow
Watch HL7 in action during a typical Orders and Results loop.
Step 1: The Admission (ADT^A01)
Patient Jane Doe walks into the hospital. Registration clerk enters her info. The EMR sends an ADT message to all downstream systems. Lab. Pharmacy. Radiology. They know she’s here.
Message Type: ADT^A01
Key Segments: MSH, PID, PV1, NK1 (Next of Kin), IN1 (Insurance).
Step 2: The Order (ORM^O01)
The doctor sees Jane and orders a Complete Blood Count. The EMR sends an ORM to the Laboratory Information System.
Message Type: ORM^O01
Key Segments: MSH, PID, PV1, ORC (New Order), OBR (The CBC Test).
Step 3: The Acknowledgement (ACK)
The Lab System receives the order. It replies instantly with an ACK message. A digital nod saying, “I received message ID 101 successfully.”
If the Lab is down or the message is corrupt, it sends a NACK (Negative Ack). The EMR retries.
Step 4: The Result (ORU^R01)
The lab analyzer runs the blood. The LIS sends results back to the EMR using an ORU message.
Message Type: ORU^R01
Key Segments: MSH, PID, ORC (referencing the original order ID), OBR, and multiple OBX segments. One for White Blood Cells. One for Red Blood Cells. One for each result component.
Part 5: Common Challenges & The “Z-Segment” Nightmare
HL7 is supposed to be a standard. Why is it so hard, then? Local customization is the answer.
Every hospital operates differently. Every vendor implements things differently. The standard tries to be flexible enough for everyone. That flexibility creates chaos.
The “Z-Segment”
HL7 allows local extensions. A hospital needs to send data that doesn’t fit standard segments. Patient’s Preferred Parking Spot. VIP Status Level. Insurance pre-authorization flags. Custom notes for specific workflows. They create a Z-segment. These start with Z. ZPV. ZPD. ZIN. ZCU.
The problem emerges fast. Vendor A’s ZPV segment looks completely different from Vendor B’s ZPV. A standard interface engine chokes on these unknown segments. Data gets lost or rejected.
Some systems just discard Z-segments and move on. “Unknown segment, ignore it.” Patient parking preference gets dropped. VIP flags disappear. Custom workflow data vanishes. The receiving system has no idea what it missed.
Lifepoint specializes in the non-standard. Their parsers are flexible. They configure engines to capture Z-segment data, map it to standard fields, or route it to custom database tables. They don’t discard data because it’s unique. They preserve it.
This matters because those custom segments often contain critical information. A hospital might track something in a Z-segment that affects care decisions. If it gets dropped, nobody knows the data existed.
Code Mapping Chaos
The EMR sends Gender as “Male” or “Female.” The Lab System expects “M,” “F.”
The Hospital uses “GLU” for Glucose. The Reference Lab requires LOINC code “2345-7.”
One system codes ethnicity as “White.” Another uses “01.” A third uses “Caucasian.” Same concept, three different representations.
Every system codes things differently. Without translation, messages fail or data is corrupted. Results are attached to the wrong tests. Allergies get lost. Critical values don’t trigger alerts.
A lab result comes back coded as “GLU,” but the EMR expects “2345-7.” The EMR system doesn’t recognize it. The glucose value sits in a queue somewhere. The doctor never sees it. The patient doesn’t get treatment for high blood sugar.
Lifepoint builds Translation Tables into the heart of interfaces. They convert codes in real-time automatically. “Male” becomes “M.” “GLU” becomes “2345-7.” These translations happen invisibly. The sending system sends what it knows. The receiving system gets what it expects. Semantic interoperability happens in the middle.
They maintain libraries of thousands of code mappings. Different hospital systems use different codes for the same thing. Lifepoint knows them all.
Part 6: HL7 v2 vs. FHIR – The Future of Interoperability
No modern HL7 discussion skips FHIR. It’s the future. Everyone talks about it.
But the future isn’t here yet. And HL7 v2 still runs healthcare.
HL7 v2 Profile
Strengths: Proven. Stable. Handles massive throughput. Millions of messages per hour. Supported by 99% of legacy systems. Works. Has worked for decades.
Weaknesses: Hard to read. Older technology. Mobile apps struggle to parse it. Looks like 1980s technology. Because it is.
Works Best For: Push workflows inside hospitals. ADT messages push admission data to all systems. Lab results are pushing from LIS to EMR.
FHIR Profile
Strengths: Web-based. RESTful API. Uses JSON and XML. Easy for modern developers. Secure with OAuth. Built for mobile. Built for the cloud.
Weaknesses: Still maturing. Not fully supported by older legacy systems. Many hospitals don’t have FHIR infrastructure yet.
Works Best For: Pull workflows. Mobile apps are pulling patient data. Patient portals. External applications querying from outside.
The Hybrid Reality
The industry doesn’t flip a switch from v2 to FHIR. That would break everything. For the next decade at least, hybrid worlds exist everywhere.
Your EMR speaks FHIR. Brand new system, cloud-native. Your old Lab Analyzer only speaks HL7 v2.3. Been running since 2010. Not upgrading.
Your hospital pharmacy system is FHIR-ready. Your billing system isn’t. Your radiology system speaks both. Your pathology system speaks neither.
Healthcare is a patchwork. Systems of different ages, different vendors, and different capabilities all coexist.
Lifepoint bridges these worlds. Their integration platform receives an HL7 v2 ADT message from an older system. It converts instantly into a FHIR JSON resource. Post it to modern cloud applications. You modernize apps without ripping out core infrastructure.
This matters because rip-and-replace costs millions. Takes years. Disrupts operations. Bridges let you transition gradually. New systems speak FHIR. Old systems speak v2. Lifepoint translates.
Why Lifepoint Informatics? The Experience Factor
Healthcare IT experience isn’t nice to have. It’s a safety requirement. Misinterpreted allergy codes kill people. Dropped lab results kill people. Corrupted patient identifiers kill people.
Since 1999, Lifepoint focused on one thing: data interoperability. Twenty-five years. Not a side project. Their entire business.
Vendor Neutrality
They’re not beholden to Epic, Cerner, or any single vendor. They work with everyone. Built interfaces for over 500 different healthcare applications. Not 50. Not 100. Five hundred.
That breadth of experience means they understand how different systems think. Epic’s philosophy differs from Cerner’s, which differs from Meditech’s. They’ve navigated all of it.
The “25-Year Archive.”
They’ve encountered systems unchanged since 2005. Systems are not supported by vendors anymore. Systems running on infrastructure nobody else remembers. They know how to talk to them.
New startups struggle to parse Meditech Magic or Siemens Invision formats. Those systems are old. Documentation is sparse. Specifications live in institutional knowledge. Lifepoint has those specs in their library, ready to deploy.
This matters when you need to connect a legacy system. You can’t wait six months for documentation. You need it working next week.
Speed to Deployment
They have thousands of pre-built connector templates. Don’t start from scratch. What takes others months deploys in weeks.
A hospital needs to connect a new lab analyzer. Typically, that’s months of development, testing, UAT. With Lifepoint, you’re running in weeks. The difference between months and weeks is the difference between your lab serving patients and sitting idle.
End-to-End Encryption
Security lives in their DNA. MLLP over TLS. VPNs. HTTPS. HL7 data is encrypted in transit and at rest. HIPAA compliant.
They don’t treat security as a feature added later. It’s foundational. Every message is encrypted. Every transmission is secure.
Mastering the Message
HL7 is old. But it’s the circulatory system of modern healthcare. When patients move between hospitals, their data moves. When doctors need critical information, HL7 delivers it. Understanding the structure matters. Segments. Pipes. Trigger events. That’s foundational.
But you don’t have to master it alone. Hospitals are connecting new analyzers. Startups ingesting clinical data. Labs are expanding to new clinics. HL7 complexity shouldn’t slow you down.
Lifepoint turns complex HL7 into a clear, reliable conversation. They handle pipes, hats, and Z-segments. You focus on patient care.
Frequently Asked Questions
What is the difference between HL7 v2 and HL7 v3?
HL7 v2 uses pipe-delimited format. Widely adopted because it’s backward compatible. HL7 v3 was an XML-based standard attempt. Academically rigorous. Practically very difficult to implement. Bloated. v3 never saw widespread US adoption. Industry moved from v2 directly to FHIR.
Is HL7 secure?
HL7 format itself is plain text. No encryption built in. Open an HL7 file in Notepad and you read patient names. Transport security is non-negotiable. Lifepoint never sends raw HL7 over open internet. Wraps messages in secure tunnels. VPNs. SSH. MLLP over TLS. HIPAA compliant.
Can I open an HL7 file in Excel?
You can, but it’s messy. Excel expects CSV or Tab-delimited. HL7 uses pipes. Import as “Text,” specify | as delimiter, ensure segments don’t mix. For professional use, dedicated HL7 Viewers or Interface Engines visualize segments in grids.
What is an ADT Feed?
ADT (Admission, Discharge, Transfer) feed is continuous HL7 messages from hospital registration. Acts as the hospital’s heartbeat. Notifies all systems when patient status changes. Labs. Dietary. Housekeeping. Billing. Building healthcare apps requires integrating ADT feeds first. It’s the foundation.
Will FHIR replace HL7 v2 completely?
Eventually yes. But eventually in healthcare means 20 to 30 years. Installed base of v2 systems is massive. Can’t rip and replace overnight. Prediction is long co-existence. v2 handles internal hospital operations. FHIR handles external, patient-facing, mobile interactions.
What is a “Trigger Event”?
Trigger Event is the real-world action causing HL7 messages. The 3-letter code in MSH-9 field. Common examples: A01 admits a patient. A03 discharges. A08 updates patient information. O01 places a new order. R01 sends the result. Every action in the hospital triggers a message.
Does Lifepoint Informatics offer custom HL7 training?
Yes. Primary focus is on handling integration for you. They believe in empowering clients. Offer consultation and support, helping internal IT teams understand data flowing through systems. Most clients prefer letting their managed integration platform handle the heavy lifting. Avoids hiring expensive dedicated HL7 engineers.
