Healthcare Interoperability and the HL7 v2 Standard

A single hospital runs dozens of software systems that were never designed to talk to each other: an electronic health record (EHR), a lab system (LIS), a radiology system (RIS), an imaging archive (PACS), pharmacy, scheduling, and billing. When a patient is admitted, that one event needs to reach almost all of them.

Without a shared language, every pair of systems needs its own custom interface. Connect $n$ systems point-to-point and you head toward $n(n-1)/2$ interfaces: 10 systems is 45 connections, each separately built and maintained. That combinatorial explosion, not any single hard feature, is the real cost of a hospital's IT estate. Interoperability is the discipline of replacing those bespoke links with shared standards.

The Healthcare Information and Management Systems Society (HIMSS) defines interoperability as four stacked levels, each depending on the one below:

• Foundational. One system can send data and another can receive it. No shared meaning yet, just a working pipe.
• Structural. The two agree on format and syntax: which fields exist, how they are delimited, where a value lives in the message.
• Semantic. They agree on meaning, usually by referencing shared code systems (LOINC for lab tests, SNOMED CT for clinical terms, ICD for diagnoses) so "glucose" means the same coded concept on both ends.
• Organizational. Governance, policy, consent, and legal agreements let the exchange happen across institutions.

Most integration work lives at the structural and semantic levels. That is where the standards in this cursus operate.

Health Level Seven International (HL7) is the nonprofit standards body, founded in 1987, that publishes the messaging standards most of healthcare runs on. The name refers to layer 7, the application layer, of the OSI networking model: HL7 standardizes the meaning of the message, not the wires beneath it.

HL7 has published three major generations:

• HL7 v2 (late 1980s onward): pipe-delimited text messages. Still the workhorse for hospital-internal data exchange.
• HL7 v3 and CDA (2000s): an XML-based model. CDA (the Clinical Document Architecture) became widely used for structured documents; the broader v3 messaging model saw limited uptake.
• FHIR (2014): a web and REST based standard, covered in the next lesson.

The generations coexist. A working integration engineer touches v2 and FHIR daily.

An HL7 v2 message is plain text, built from segments, one per line, each named by a three-letter code. Every message starts with an MSH (Message Header) segment that also declares the delimiters used.

Within a segment, fields are separated by the pipe |. Fields split into components with the caret ^, components into subcomponents with &, and a field repeats with the tilde ~. The backslash escapes.

Common segments:

The message type in MSH (for example ADT^A01) tells the receiver what happened and how to parse the rest.

Here is a trimmed ADT^A01 (patient admit) message. Read it top to bottom:

MSH|^~\&|ADMIT_SYS|HOSP_A|EHR|HOSP_A|20260718103000||ADT^A01|MSG00001|P|2.5
PID|1||100457^^^HOSP_A^MR||DUBOIS^MARIE^L||19820304|F|||12 RUE DU LAC^^LAUSANNE^^1003^CH
PV1|1|I|3WEST^301^A|||||^HOUSE^GREGORY^^^DR

• MSH: the message came from ADMIT_SYS, is type ADT^A01, uses HL7 version 2.5, and defines ^~\& as its encoding characters.
• PID: patient Marie L Dubois, medical record number 100457, born 4 March 1982, female, with an address.
• PV1: an inpatient visit (I) in room 3WEST-301-A, attending Dr House.

That is the entire idea. A receiver splits on the delimiters, walks to the field it needs by position, and acts.

The reason standards matter becomes obvious when you draw the wiring. On the left, five systems wired directly need many bespoke interfaces. On the right, each system speaks one standard to a central hub, and the count collapses to one interface per system. That hub is the integration engine of lesson 3; the shared language on every line is HL7.

HL7 v2 is over 30 years old and still carries the bulk of hospital-internal traffic. It endures for unglamorous reasons: an enormous installed base, decades of tooling, and a format simple enough to read by eye and parse with basic string handling.

Its weaknesses are the flip side of that age. The standard is famously permissive: most fields are optional, and sites bend it to fit local needs. Vendors add custom Z-segments (segments starting with Z, outside the standard) to carry data v2 never modeled. The result is that two systems can both be "HL7 v2 compliant" and still not understand each other without mapping work. That gap between the standard and reality is exactly what an integration engineer is paid to close.

Healthcare interoperability is a durable, in-demand technical niche. Hospitals, labs, health-tech vendors, payers, and government health systems all need people who can make clinical data move correctly and safely between systems. The role goes by several names: integration engineer, interface analyst, interoperability engineer, or HL7 developer.

The skill set is learnable and stacks cleanly: the HL7 v2 message model you just met, the FHIR resource and REST model in the next lesson, and an integration engine plus some SQL and JavaScript in the third. It sits close to, but distinct from, clinical roles like medical billing and coding: those people manage the meaning of codes, while integration engineers move the messages that carry them. The next lesson steps into the modern, web-native side of the field: FHIR.