Which HL7 version should I use?
The most useful HL7 version is not automatically the newest one. That feels odd if you come from web APIs, where the latest version often means better security, better tooling, and fewer old mistakes. HL7 v2 does not behave like that. In real interfaces, the best version is usually the version named in the implementation guide, the version the receiver already tests, and the version that carries the data you actually need without filling the message with fields nobody reads.
If you control both sides of a simple interface, and MSH-12 can honestly say 2.3.1, there is nothing embarrassing about that. HL7 v2.3.1 is easier to look at, easier to explain, and often perfectly adequate for ADT, basic orders, basic results, scheduling notifications, and simple document feeds. Moving that same feed to v2.8, v2.9, or v2.9.1 just to feel current can add noise without adding useful meaning.
The version number is a promise about the message grammar. It is not a trophy. If the receiver expects v2.3.1, send v2.3.1. If your national pathology guide says v2.4, use v2.4. If a US public health program says v2.5.1, use v2.5.1. If a vendor says "we support 2.9" but the feed still only uses PID, PV1, ORC, OBR, and OBX in an older shape, ask what the newer version is actually buying you.
The Short Answer
| Situation | Version I would start with | Why |
|---|---|---|
| A local or national implementation guide names a version | Use that exact version | The receiver will validate against that guide, not against your sense of what is modern. |
| A simple private ADT, order, result, document, or scheduling interface | v2.3.1, or the oldest version both sides already support comfortably | It is simpler, widely understood, and usually carries the core data cleanly. |
| Australian or New Zealand pathology/radiology style messaging | Usually v2.4 in the public diagnostics standards | Those local standards build their rules around HL7 v2.4 rather than the newest v2 line. |
| US public health lab reporting, immunization, and several Meaningful Use era workflows | Usually v2.5.1 | Many of the public US implementation guides were written around v2.5.1. |
| Radiology workflow using IHE profiles | Match the IHE profile: older SWF-style v2.3, or SWF.b-style v2.5.1 | Radiology often follows profile behavior more than a generic country-wide preference. |
| Someone asks for v2.9 or v2.9.1 | Use it only if the implementation guide or receiver really needs it | Later versions add a lot of available fields. Available does not mean useful. |
Country And Program Signals
There is no single worldwide answer, and often there is not even one answer for a whole country. The version is normally chosen by a national program, a specialty program, a public health guide, an IHE profile, or the receiving product. Still, public guidance gives us a useful pattern.
| Jurisdiction or profile | Version signal | Practical meaning |
|---|---|---|
| United States public health - immunization | CDC and AIRA recognize HL7 v2.5.1 Release 1.5 as the current immunization messaging standard. | If you are sending VXU, QBP, RSP, or ACK style immunization messages to a US IIS, do not invent your own version choice. Start with the CDC/AIRA guide. |
| United States public health - electronic lab reporting | CDC public health guidance lists HL7 v2.5.1 for electronic laboratory reporting to public health. | ELR feeds are profile-heavy. The local state guide may add constraints, but the base version is commonly v2.5.1. |
| Australia - pathology and diagnostic imaging | AS 4700.2-2012 describes pathology and diagnostic imaging messages using HL7 v2.4. | For Australian diagnostics, especially pathology and imaging orders/results, v2.4 is the important local anchor. |
| Australia - diagnostics and referral messaging | HL7 Australia guidance describes pathology and radiology requests and reports using the HL7 v2.4 protocol, with flagged later-version localizations where needed. | This is a good example of why "latest" is the wrong instinct. A country can choose v2.4 and then localize carefully. |
| New Zealand - pathology and radiology | HISO 10008.2:2024 is based on HL7 v2.4 for pathology and radiology orders and results. | For NZ lab and radiology-style messaging, the public signal is v2.4, not the newest HL7 v2 release. |
| Canada - Ontario laboratory repository | Ontario's OLIS HL7 v2 Standard is governed as its own local standard package. | Canada is a good reminder to look for provincial or program-specific standards. Do not assume one base version covers every Canadian workflow. |
| United Kingdom - national pathology messaging | NHS Digital's public pathology messaging page describes HL7 v3, notes limited adoption, and points toward EDIFACT and FHIR paths for pathology. | If you are in the UK, ask which NHS, regional, local, or vendor specification applies. The answer may not be HL7 v2 at all. |
| IHE Radiology Scheduled Workflow | IHE SWF.b made HL7 v2.5.1 mandatory for HL7-based transactions, while the original SWF profile was built around older v2.3 behavior. | Radiology version choice is often profile-driven. RIS, PACS, modality worklist, and reporting flows may care more about IHE profile conformance than the raw HL7 release number. |
That table is not meant to be a universal law. It is a warning label. Different countries and verticals choose different baselines, and some do not publish one simple national v2 answer at all. The safe move is always to find the implementation guide for the receiving program and make that your source of truth.
Latest Is Not Automatically Best
HL7 v2 was designed to be extended and adapted. Later versions add fields, segments, trigger events, data types, and conformance machinery. That can be valuable when the workflow needs it. It can also make everyday messages harder to read. A v2.9-style schema can show you a long tail of fields that are legal, obscure, conditional, withdrawn, or only useful in a niche profile. If you are trying to debug a patient registration feed at 2am, more legal fields is not the same thing as more clarity.
Older HL7 versions also carry a lot of production trust. v2.3.1 and v2.4 are familiar to interface teams, vendor products, and older departmental systems. Many receiving systems were built, tested, and certified around those versions. They may tolerate later messages, but that does not mean they understand the later fields the way you hope they do.
HL7 v2.9.1 is useful standards work, and it matters when a guide actually depends on it. But in day-to-day interfacing, a clean v2.3.1 message that accurately sends the patient, visit, order, result, appointment, or document is better than a noisy later-version message where half the fields are empty and nobody knows which ones are authoritative.
How The Version Is Declared
The message itself declares its version in MSH-12, the Version ID field. That field uses the VID datatype in later versions, and it is the first place tools and engines look when deciding how to interpret the message. If MSH-12 says 2.3.1, you should expect v2.3.1 field definitions. If it says 2.5.1, you should expect v2.5.1 definitions.
In practice, MSH-12 is an important clue, not the whole contract. I have seen plenty of feeds that claim v2.5.1 while behaving like older v2.3.1 messages because the sender upgraded a setting without changing the message content. I have also seen older-looking feeds that rely on one later field because a local guide pre-adopted it. That is why the implementation guide matters. HL7 describes implementation guides as the place where use cases, profiles, conformance claims, and message constraints become specific.
HL7 Soup Web follows the practical workflow here: open the message, read the version from the message header, and inspect the fields against the appropriate version-specific schema. That is exactly how people should think about HL7 versions. Start with the message you have, not the message you wish everyone had upgraded to.
How Medical Verticals Use Versions Differently
Patient administration feeds are often the most forgiving. ADT messages commonly need MSH, EVN, PID, PV1, sometimes NK1, AL1, DG1, GT1, and insurance. If you are just moving patient identity, visit, location, and admit/discharge/transfer events, older versions often work beautifully. The hard parts are usually identifiers, merge logic, and local visit rules, not the HL7 version number.
Lab and pathology are much more profile-heavy. A basic ORU_R01 result can be simple, but once you add public health reporting, LOINC, SNOMED CT, specimen detail, microbiology, abnormal flags, ask-at-order-entry answers, and reportable-condition rules, the implementation guide takes over. In the US that often points to v2.5.1. In Australia and New Zealand, public diagnostics standards point strongly to v2.4. Same broad lab world, different local baseline.
Radiology and ultrasound often look like lab from a distance: orders go out, results come back. The details are different. RIS, PACS, modality worklist, accession numbers, study identifiers, requested procedure IDs, report status, and image links all affect the interface. Some radiology workflow is shaped by IHE profiles, where older v2.3-style Scheduled Workflow and later v2.5.1 SWF.b expectations can both appear in the real world. For ultrasound specifically, do not guess from the modality. Ask whether you are implementing a local diagnostics standard, a RIS vendor feed, an IHE workflow, or a plain order/result interface.
Immunization is another place where version choice is program-led. In the US, modern IIS interfaces usually follow CDC/AIRA v2.5.1 guidance for VXU submissions, QBP queries, RSP responses, and ACK handling. The vaccine data itself lives in RXA, often with RXR, OBX, and patient/guardian details. If the IIS says v2.5.1, do not send a "simpler" v2.3.1 feed just because it feels cleaner.
Pharmacy, billing, and documents vary by country and product. Some medication workflows are HL7 v2. Some are NCPDP, FHIR, proprietary, or local. Some billing workflows use HL7 DFT/FT1. Some do not. Some document workflows use MDM/TXA/OBX; others use CDA, FHIR DocumentReference, PDF exchange, or national document infrastructure. Here again, the version follows the receiving ecosystem.
When v2.3.1 Is The Better Choice
I would happily choose v2.3.1 when both systems support it, the receiving profile allows it, and the workflow is straightforward. A clean ADT feed, basic ORM order feed, basic ORU result feed, or simple SIU scheduling notification does not automatically need the later HL7 machinery.
The advantage is not nostalgia. It is readability. v2.3.1 messages tend to be shorter, the common segments are well known, and many vendor systems have been handling them for decades. If the data transfers correctly, the receiver can process it, and the implementation guide permits it, there is no prize for making the message harder to read.
The exception is when the workflow needs a later structure. Modern lab orders may need SPM specimen handling or OML_O21. Public health may require v2.5.1 conformance. A newer profile may use later fields for identity, facility, ordering, acknowledgment, or vocabulary. In that case, use the later version because it solves a real problem, not because it is newer.
What An Interface Engine Should Do
An interface engine should make version differences manageable instead of pretending they do not exist. In Integration Soup, the useful pattern is to treat the incoming version as part of the contract: route by sender, message type, trigger event, profile, and version; validate against the agreed shape; and transform only the parts that need to change for the receiver.
That means you can accept a v2.3.1-style feed from an older PAS, normalize identifiers and codes, and send a v2.5.1-shaped feed to a downstream public health or repository endpoint when that is what the receiver needs. Or you can do the reverse: consume a richer feed and strip it down to a clean older shape for a legacy receiver, while keeping the important data in logs or side stores. The engine gives you flexibility, but the interface specification still needs to say what is allowed.
The dangerous move is silently changing versions without changing meaning. If you rewrite MSH-12 from 2.3.1 to 2.5.1, but leave the message otherwise unchanged, you may only be hiding the real contract. If you truly convert versions, document what changed: fields, data types, code systems, repeating behavior, acknowledgments, and validation rules.
A Practical Version Checklist
- Find the receiving implementation guide before choosing the version.
- Check whether the guide is national, regional, specialty-specific, vendor-specific, or project-specific.
- Look at MSH-12, but do not trust it more than the actual message content and written profile.
- Use the simplest version that carries the required data and is accepted by the receiver.
- Do not upgrade just to be current. Upgrade when a later field, segment, data type, or conformance rule is genuinely required.
- Test with real variants: create, update, cancel, merge, correction, preliminary/final result, no-show, deletion, retry, and error ACKs where relevant.
- Keep the version visible in logs and support screens. Support people should not have to guess which schema was used.
- Use HL7 Soup Web to inspect messages against the version they actually declare.
- Use Integration Soup when you need to receive one version, validate it, transform it, and send another version cleanly.