Key takeaways
-
HL7 v2 moves messages between hospital systems, FHIR exposes health data through modern web interfaces, and DICOM handles medical images. They solve different problems and usually coexist.
-
"We support FHIR" is a claim about capability, not compatibility. Two FHIR systems can still fail to exchange useful data.
-
If you're building for the NHS, FHIR fluency and DSPT alignment will come up early. Knowing the vocabulary helps you run those conversations rather than survive them.
If you work anywhere near health technology, these three acronyms follow you into every partnership conversation, NHS meeting and vendor pitch. Most explanations of them are written by standards experts for other standards experts. This one is for people who need a working understanding: enough to know which standard matters for their product, and to spot when a vendor's claims deserve a closer look.
Why healthcare needed data standards at all
A hospital is hundreds of software systems from different decades and different vendors, all holding pieces of the same patient's story. The lab system knows the blood results. The radiology system holds the scans. The admission system knows the patient arrived on Tuesday.
Without shared rules, every pair of systems would need a custom translation built from scratch, and hospitals learnt in the 1980s that this doesn't scale. Standards emerged so that systems could agree, in advance, on how to describe a patient, a test result or an image. Three of them dominate healthcare today.
HL7 v2: the workhorse
HL7 version 2 has been moving messages between hospital systems since 1989, and it still carries most hospital traffic worldwide. When a patient is admitted, a message goes out. When a lab result is ready, a message goes out. Any system that cares, listens.
The format looks ancient, lines of text with fields separated by pipe characters, and in fairness it is. But it's everywhere, it's fast, and every hospital integration engine on earth speaks it. If your product needs data out of an established hospital system, there's a good chance HL7 v2 is how you'll get it.
Its weakness is flexibility. The standard allows so much local variation that an HL7 feed from one hospital rarely matches the feed from another. Integrating with five hospitals means five conversations about their particular dialect.
FHIR: the modern interface
FHIR (pronounced "fire") is HL7's modern successor, built on the same web technology as the apps on your phone. Instead of listening to a stream of messages, your software can ask a FHIR server a question: give me this patient's medications, or their latest observations, and get back a structured answer.
That request-and-response model is why FHIR has become the default for new digital health products, and why the NHS has built its recent APIs on it. If your product is new and needs patient data, FHIR is almost certainly the interface you'll be offered.
Two cautions. First, FHIR adoption is newest where the data is oldest, so many hospitals expose only a fraction of their information over FHIR while the rest still travels over HL7 v2. Second, FHIR's building blocks, called resources, allow optional fields and local extensions. Two systems can both "support FHIR" and still disagree about where a piece of information lives. The standard narrows the negotiation; it doesn't remove it.
DICOM: the imaging world
DICOM is the standard for medical images: X-rays, CT scans, MRIs, ultrasound. It defines both the file format and the network protocol for moving images between scanners, archives and viewing workstations.
A DICOM file is more than a picture. It carries the patient's identity, the equipment settings, the position of every slice in a scan, all embedded in the file itself. That context is what lets software reconstruct a 3D model from hundreds of slices, which is why DICOM matters so much to anyone working with surgical planning, patient-specific implants or diagnostic AI.
Like HL7, DICOM allows vendor variation. Every scanner manufacturer populates the standard slightly differently, so software that consumes DICOM from many sources has to handle those differences deliberately. Teams building imaging workflows discover this in their first week.
Which standard applies where
Most real products touch at least two of these. A surgical planning tool might receive DICOM images and report results back over FHIR. A monitoring product might consume HL7 feeds in one hospital and FHIR APIs in another.
Red flags when a vendor says they "support" a standard
Support is a spectrum, and the word alone tells you little. Questions worth asking:
Which version, and which parts? FHIR has several releases and dozens of resource types. Supporting two of them is technically support. Read, write, or both? Plenty of systems will happily send you data over a standard but accept nothing back. Where's it running today? A standard implemented for a certification exercise behaves differently from one exchanging live data in production. Ask for a named deployment. What happens to fields that don't fit the standard? The honest answer involves extensions or custom mapping. "Everything just works" is not an honest answer.
A vendor with real interoperability experience will answer these in specifics. Vagueness here predicts pain later.
If you're building for the NHS
The NHS runs one of the more structured technology assessment regimes anywhere, and standards competence is woven through it. Expect FHIR to be the assumed interface for new integrations, and expect questions about how patient data is protected in transit and at rest, which is where the Data Security and Protection Toolkit (DSPT) enters the conversation.
The practical implication: interoperability decisions you make early, like how your product stores and exposes clinical data, are hard to reverse once you're in an assessment process. Getting the architecture right before your first NHS pilot is considerably cheaper than reworking it during one. Compliance questions around patient data flows come up in the same conversations, and we've covered those separately in our guide to EHR data integration.
ULAM LABS builds healthcare integrations to established standards, HL7, FHIR and DICOM among them, rather than custom workarounds that break when systems update. We've delivered DSPT-aligned connections into NHS infrastructure and imaging workflows for MedTech companies across the UK and EU. If you're designing a product that has to exchange clinical data and want the architecture right first time, talk to us, you'll speak to an engineer on the first call. More on how we work: our integrations page.
