HL7 is four standards, and none of them has been retired

Three answers, all correct

Ask three engineers in a hospital what HL7 is and you will get three answers. One will describe pipe-delimited text streaming over a socket. One will describe an XML clinical document. One will describe a JSON REST API. All three are right, and all three are describing different standards, built decades apart, that happen to share a name.

This is why "we support HL7" in a vendor deck carries almost no information, and why "migrating to HL7" could mean a two-week interface or a two-year programme. The useful model is generational. HL7 International has shipped four major product families, and none of them has been retired.

The 1987 one still carries the most traffic. The 2005 one is what United States regulation requires for clinical documents. The 2011 one is what every new project starts with. Only the 1997 one can fairly be called a failure, and even that one left a thriving descendant behind.

Accretion, not replacement

The history here is additive. Each generation solved a problem the previous one handled badly, and each left the previous one running, because hospitals do not rip out working interfaces. All three survivors have had a substantive release in the last two years.

A roadmap that assumes a migration away from v2 or CDA is planning for a world that has not arrived and shows no sign of arriving.

v2 on the wire

A v2 message is a sequence of segments, one per line, each beginning with a three-character identifier. Segments hold fields, fields hold components, components hold subcomponents, and fields may repeat. Five delimiter characters carry the whole structure, and the message declares them in its own first line: the fourth character of the message is the field separator, and the field after it lists the other four.

Two details separate a working parser from a fragile one. First, delimiter characters legitimately appear in clinical text, so v2 defines escape sequences for each of them plus a hexadecimal form. A naive split on the pipe character will corrupt any address that contains one. Second, position is identity. There are no field names on the wire, PID-7 is the date of birth because it is the seventh field, and an off-by-one in a hand-rolled parser silently files birthdays as sexes. Use a library.

The MSH header segment is the routing envelope, the version declaration and the acknowledgement contract in one line. It also holds the single fact that best introduces the real character of v2: MSH-3 through MSH-6, the sending and receiving application and facility, are optional. The four fields on which essentially every production interface engine makes its routing decisions are not required by the standard. What the standard describes is a very loose envelope, and the industry has filled it in by convention and negotiation.

Three framing bytes, and no security

v2 travels over TCP inside the Minimal Lower Layer Protocol, which is a start byte, the message, an end byte and a carriage return. There is no length prefix, no checksum, no compression and no encryption. Retry policy, ordering, delivery guarantees and transport security are all the deployment problem, which is why every hospital owns an interface engine.

HL7 is explicit about the last of those.

If security is an issue, additional protocols or technologies will have to be layered on top of MLLP to achieve these goals.

The acknowledgement contract sits in the same header. MSH-15 and MSH-16 declare what the sender expects, always or never or on error or on success, and the reply echoes the original control id back so the sender can correlate. Enhanced mode splits the answer in two: a commit acknowledgement for "I received and stored it" and an application acknowledgement for "my application accepted it". A receiver that acknowledges when it should not, or fails to when it should, produces retry storms and silent message loss.

The optionality problem

Here is the part nobody explains on day one. Two systems can both implement v2 correctly, both pass any conformance test you can devise against the base standard, and still fail to exchange a single usable message.

Take one clinical fact: Jane Doe has medical record number 4417, issued by Mercy Hospital. One vendor puts all of it in the patient identifier list, using the field the standard intends, with the assigning authority and the identifier type code in their proper components. Another duplicates the number into the deprecated PID-2 and into PID-3, and pushes the assigning authority into a locally invented Z-segment. Both messages are conformant v2.5.1. Neither system can read the other without bespoke mapping.

That is not a criticism from outside. It is the position of the standard, stated in Chapter 1 of every modern release.

HL7 Version 2.5.1 is not, in itself, a complete systems integration solution. There are several barriers ... that makes it difficult, if not impossible, for HL7 to create a complete "plug-and-play" solution.

The barriers the standard names come down to one thing: healthcare delivery has no consistent underlying process to model, so the specification has to accommodate every variation. Accommodating every variation means optional fields, and optional fields mean negotiation between vendor and customer over what is actually implemented. That is why a v2 interface is a project rather than a configuration, and why an integration analyst’s real skill is reading someone else’s message specification rather than reading the standard.

Z-segments are the same problem with a name on it. The standard reserves segment identifiers beginning with Z for local use, specifically so that local extensions do not collide with future versions. It is a sensible provision that has produced an enormous quantity of unportable data, because a Z-segment means something only to the two parties who agreed on it. HL7 puts it plainly: the meaning of these extensions is opaque without prior manual explanation by the sender.

The one you will meet in imaging is ZDS, which carries the DICOM Study Instance UID in an order message. It is so ubiquitous in radiology that most people assume it is part of the standard. It is not, and it shows how these things ossify. v2.5.1 added the IPC segment, whose third field is a proper Study Instance UID field, and the industry carried on sending ZDS anyway.

The fix nobody used

HL7 saw the problem and built the answer. A conformance profile constrains a base message definition down to something unambiguous: which segments and fields are actually used, tightened cardinality, bound value sets, fixed lengths, narrowed data types. The usage codes are the heart of it, with R for required, RE for required but possibly empty, C for conditional, X for not used with this trigger event, and O, the base standard default, as the source of the whole problem. A profile is declared in MSH-21, the methodology is an ANSI-approved standard in its own right and was reaffirmed in July 2025, and NIST maintains authoring and testing tooling for exactly this.

It works. It solves the problem it was designed to solve. And the assessment HL7 wrote into the FHIR specification is one sentence long.

The HL7 V2 mechanism has not been widely used.

A standards body describing its own conformance mechanism as unused is about as candid as this industry gets. Where profiles have been used they work well: immunisation registries, laboratory results interfaces under Meaningful Use and public health reporting all run on profiled v2 with published implementation guides, and those interfaces are markedly less painful than general-purpose ones. The rule for a project is short. If an implementation guide exists for your use case, adopt it. If not, write a profile before you write code.

The road not taken

By the mid-1990s HL7 understood the weakness precisely. There was no underlying model, so every message was a negotiated local agreement. Version 3 was the answer: rather than defining messages directly, it would define one Reference Information Model covering all of healthcare in six core classes, and derive every message from it by constraint. Get the model right and interoperability follows.

It is a genuinely elegant idea and it did not work. Because the model had to cover everything, the constrained artefacts multiplied, and the ambiguity was relocated rather than removed. The clearest illustration is HL7’s own: at the international level there are ten different reusable model fragments for the concept of "Patient". An implementer facing ten valid ways to say "patient" is no better off than one facing an optional field.

What survives is substantial. The RIM is still an ANSI and an ISO standard. Structured Product Labeling, which the Food and Drug Administration mandates for drug labelling, is v3. The MLLP transport specification is formally a v3 document, despite carrying all of the v2 traffic in the world. And CDA is v3-derived and thriving. v3 messaging failed; the v3 data model did not.

CDA has not been replaced

Messages describe events. A great deal of clinical information is not an event but a document: a discharge summary, a consultation note, an operative report, something a clinician wrote, signed and is accountable for. The Clinical Document Architecture is the answer to that shape of problem, and it defines a clinical document by six characteristics: persistence, stewardship, potential for authentication, context, wholeness and human readability.

The last of those carries the weight. A CDA document must be renderable and readable by a human, and the human-readable narrative is what the author attested to. Coded entries sit alongside the narrative, derived from it rather than the other way round. The document stays legally and clinically meaningful even when no system can process its codes, and no API standard has replicated that property.

One question is worth asking before scoping any CDA work: which level. Level 1 is a header wrapped around a body that may be a PDF. Level 2 codes and identifies the sections. Level 3 puts coded entries inside them. A Level 1 document is perfectly valid CDA and machine-useless, and promising anyone that you can extract problems and medications from an inbound document before checking its level is a good way to lose a sprint.

"CDA is dead, FHIR replaced it" is wrong on the evidence. Consolidated CDA reached Edition 5 in June 2026, the approved version advanced through the United States standards advancement process in both 2025 and 2026, and the regulatory baseline at 45 CFR 170.205(a)(4) has no expiry. HL7’s own comparison of the two standards describes coexistence, and documents the bridge: a CDA document travels inside a FHIR DocumentReference as a binary attachment. A detail of the current edition captures the relationship exactly. C-CDA Edition 5 is authored with FHIR tooling while still publishing CDA R2 XML.

FHIR, and the regulation that carried it

FHIR is deliberately ordinary software: modular resources with stable identities and URLs, a REST API, JSON on the wire, ordinary HTTP status codes. Around 150 resource types cover the clinical and administrative ground, and four exchange paradigms mean it can do what v2 does and what CDA does as well as the API work it was built for.

The design decision that matters most is the extension. A base resource carries only the elements most implementers everywhere will use, and everything else goes in an extension identified by a URL that resolves to its own definition. A receiver that does not recognise an extension can look it up, or ignore it safely. Set that beside the Z-segment. Both mechanisms let a site add local data; only one of them tells a stranger what the data means, and that difference is most of what FHIR learned from thirty years of v2.

FHIR did not win on technical merit alone. The 21st Century Cures Act required certified health IT to publish APIs usable without special effort, the 2020 final rule turned that into a certification criterion, and that criterion names five specifications by version number: FHIR 4.0.1, US Core, SMART App Launch, Bulk Data Access and USCDI. Every certified electronic health record in the United States ships a FHIR API or loses its certification. No standards body could have produced that adoption curve on its own.

It also settles which release to build on. Regulation names 4.0.1. US Core reached STU 9 in May 2026 and still builds on R4. R5 adoption is thin and R6 is not published. Newest is not the same as current.

Part 4 of this series takes FHIR on its own: the resource model, search, profiling, terminology, and why the API is the part of the work that costs least.

Three dates belong in any plan that touches this: certified health IT moves to US Core 7.0.0 by the end of 2026 and to 8.0.1 by the end of 2027, and four payer-facing FHIR APIs become mandatory on 1 January 2027 under CMS-0057-F. One caution against reading the ratchet as one-directional. In December 2025 the federal technology policy office withdrew the non-finalised provisions of its HTI-2 proposed rule, citing burden, clarity and the availability of newer standards. Proposed is not finalised, and across 2025 and 2026 that distinction had teeth.

Why v2 is not going away

The "legacy" framing leads teams into bad architectural bets, so it is worth being precise. v2 persists for four reasons, and inertia is only part of one of them.

• It works, at volume, cheaply. A v2 interface is a socket and a parser. It moves millions of messages a day on modest hardware with a latency budget measured in milliseconds. Nothing about that is improved by wrapping it in HTTP.
• The problem it solves is push, not pull. REST is a client asking a server for something. Admitting a patient is a fact that has to reach fifteen systems immediately, whether or not any of them thought to ask. FHIR has messaging and subscriptions, but v2 was built for this case and is already installed.
• Replacement has no business case. A working interface generates no complaints and no revenue, so nobody funds replacing one. New capability gets built on FHIR; existing capability stays where it is.
• It is still maintained. v2.9.1 was ANSI-approved in September 2024 and the conformance methodology was reaffirmed in July 2025. This is not an abandoned standard.

The realistic architecture for the next decade is FHIR at the edges and v2 in the core, with a translation layer between them. That is why HL7 maintains a v2-to-FHIR mapping project, and why every interface engine vendor now sells a FHIR facade. Read that mapping guide carefully before budgeting against it: it is real, it is published, it is at STU 1, and its own pages are marked informative. It is a well-built starting point for writing your own mappings, not a drop-in converter.

The seam with DICOM

Imaging is the one department where HL7 is not the only standard in the room, and the boundary is simpler than it looks. HL7 owns the patient and the order; DICOM owns the study. Registration and the order arrive as v2 messages, the radiology system hands the modality its worklist, the modality acquires and stores in DICOM, and the report comes back into the record as v2 or as a CDA document.

The Study Instance UID has to cross that line, and early v2 had nowhere to put it, which is where ZDS came from. Reporting has a mirror-image split. DICOM Structured Reports carry machine-derived measurements linked to the pixels they came from, and CDA documents carry the attested, human-readable report that leaves the imaging chain for the medical record. The standard that bridges the two is published by DICOM rather than HL7, as PS3.20.

Part 2 of this series covers the profile that specifies that handoff, actor by actor and identifier by identifier.

Choosing for the job

The question is never which standard is best. It is which job you are doing, and the answers are mostly settled.

1. Something happened and people need to know now. v2, if you are connecting to existing hospital systems, because that is what they speak. FHIR messaging or subscriptions if you are building both ends from scratch.
2. A clinician wrote something and signed it. C-CDA, and in the United States frequently by regulation rather than by choice.
3. An application needs to read a patient record. FHIR R4, profiled by US Core, with SMART on FHIR for launch and authorisation. This is the case the standard was designed for and the case regulation now mandates.
4. Analytics across a whole population. FHIR Bulk Data Access. Not a million REST calls, and not a v2 feed parsed into a warehouse when a bulk export exists.
5. Reporting to a public health authority. Whatever the receiving authority’s implementation guide specifies, which is usually profiled v2. This is a case where you do not get to choose.
6. Exchanging with a payer. FHIR, using the Da Vinci implementation guides, with the January 2027 deadline as the planning anchor.
7. Anything involving images. DICOM for the study, HL7 for the patient and the order.

One question is worth asking any vendor before any of the others: which HL7 standard, which version, and is there an implementation guide or message specification we can read? The answer separates a two-week integration from a two-quarter one, and it takes ten seconds to ask.

Part 1 covers the imaging standard on the other side of that seam. The full 24-page paper dissects the message header field by field, walks the trigger event families you will actually meet, and sets out nine mistakes that are all cheaper to avoid than to discover in testing.