FHIR vs. HL7 v2: What Your Radiology Department Needs for DICOM Interoperability

Imagine you are the IT director at a mid-sized hospital. Your radiologists are frustrated: every day they must log into three different systems to see a patient’s imaging history. The PACS shows the CT, the EHR has the report, and the lab system holds the pathology. You’ve heard FHIR is the future, but your legacy HL7 v2 interface has been stable for a decade. Should you rip it out? Probably not. But here’s the real question: how do you make your imaging data actually flow — not just as a PDF, but as structured, queryable information? The answer isn’t choosing between HL7 v2 and FHIR; it’s knowing when each works, and then layering FHIR on top of your DICOM and v2 backbone.

The Problem: Your Imaging Data Is a Black Box

Let’s walk through a typical morning. A patient arrives for a follow-up on a lung nodule. The radiologist pulls up the prior CT from a year ago. The images display, but the report is a scanned PDF from the old system. The nodule’s size is buried in prose. The clinician wants to compare it with the current scan, but the system can’t extract the measurement. This is the classic interoperability gap. Your PACS speaks DICOM for images, but the structured report is stuck in an HL7 v2 message that only the EHR can parse. HL7 v2, first published in 1987, is still used by more than 95% of U.S. healthcare organizations (HL7 International). It’s the workhorse for high-throughput legacy workflows, but it’s not designed for modern, developer-friendly data access. FHIR, on the other hand, represents clinical concepts as discrete resources like Patient, Encounter, and Observation that can be independently queried and updated (HL7 International). That’s what you need to turn a report into a number you can trend.

Why Not Just Replace HL7 v2 with FHIR?

Some vendors will tell you to modernize everything with FHIR. Don’t fall for it. HL7 v2 is deeply embedded in your ADT feeds, order scheduling, and result routing. It’s reliable and fast. FHIR is favored for developer-facing, mobile, and cloud-native applications (HL7 International). But FHIR R4, the version most U.S. implementations use, was only published in December 2018 (HL7 FHIR Version History). It’s still maturing — R5, published in March 2023, is a Standard for Trial Use (HL7 FHIR Version History). Trying to replace v2 overnight is a recipe for downtime. Instead, the smart move is to keep v2 where it works, and use FHIR to expose the data that clinicians and apps need to query in real time. That’s the pragmatic path.

Mapping DICOM to FHIR: The Missing Link

Now here’s where it gets concrete. Your imaging department lives on DICOM. The DICOM standard is the international standard to transmit, store, retrieve, print, process, and display medical imaging information (DICOM Standard). It’s free and integrates devices from different manufacturers. But DICOM doesn’t carry the clinical narrative. That’s where HL7 v2 messages come in — they carry the report text, but often as a blob. To make the nodule measurement queryable, you need to structure it. That’s where FHIR’s Observation resource shines. You can create a FHIR Observation that references the DICOM study and the specific image, and store the measurement as a value. To do that, you must map the DICOM study instance UID to a FHIR ImagingStudy resource. The US Core Implementation Guide, based on FHIR R4, defines the minimum constraints for US Realm profiles, but it doesn’t yet cover imaging deeply (US Core Implementation Guide). So you’ll need to extend it. It’s doable, but it requires planning.

A Step-by-Step Field Plan

Let’s say you want to build a simple “prior comparison” view for your radiologists. Here’s how you’d approach it, using only what’s in the fact base. First, you keep your existing HL7 v2 ADT feed to register patients — don’t touch that. Second, you implement a FHIR server that can store and expose ImagingStudy and Observation resources. You’ll map each DICOM study to a FHIR ImagingStudy resource, and each structured report element (like “nodule size”) to a FHIR Observation. Third, you use LOINC codes to identify the observation type. LOINC is the international standard for identifying health observations, measurements, and documents (LOINC). For a lung nodule, you’d use a LOINC code like “nodule size” (you’ll need to pick the right code from the LOINC database). Fourth, you ensure your FHIR server is secured per HIPAA. The HIPAA Security Rule requires technical safeguards, including access control (45 CFR 164.312) (eCFR). You’ll need to encrypt data in transit and at rest, and log access. Finally, you test with a real scenario. Pull up a patient with two CTs from different years. The FHIR server should return both ImagingStudy resources, and the Observations should show the nodule size trend. If it works, you’ve just made your radiologists’ day.

The Security and Penalty Minefield

Before you roll this out, understand the stakes. HIPAA violations can be costly. As of January 28, 2026, the maximum penalty per violation is $73,011 for Tiers 1-3, and up to $2,190,294 for Tier 4 willful neglect not corrected within 30 days (Federal Register 2026 HIPAA CMP Adjustment). And the calendar-year cap is now $2,190,294 (same source). That’s not a fine you want to risk. The HIPAA Privacy Rule’s “minimum necessary” standard requires you to limit uses and disclosures to the minimum necessary for the intended purpose (45 CFR 164.502(b)) (eCFR). So when you expose FHIR APIs, make sure you’re not exposing more data than needed. Also, remember the information blocking rules: the Cures Act made sharing electronic health information the expected norm, and information blocking is a practice likely to interfere with access, exchange, or use of EHI (ONC Information Blocking). If you deliberately make your FHIR API hard for a patient app to use, you could face OIG investigation. So build it right.

Comparison: HL7 v2 vs. FHIR for Imaging Workflows

Quick tip: When you map DICOM to FHIR, don’t forget to include the DICOM study UID in the ImagingStudy resource’s identifier — that’s the key that links images to the report.

Bottom Line

Don’t abandon HL7 v2 — it’s the backbone of your hospital. But for imaging interoperability, the best move is to build a FHIR layer that exposes structured observations from your DICOM studies. Use LOINC codes to label the measurements, secure it under HIPAA’s technical safeguards, and you’ll give your clinicians the data they need without a rip-and-replace. It’s the pragmatic path to real interoperability.

Sources

• ONC / HHS (Health IT) - https://www.healthit.gov/topic/health-it-basics
• HL7 International - https://www.hl7.org/fhir/
• HL7 FHIR (Version History) - https://www.hl7.org/fhir/history.html
• HL7 V2 Product Brief - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
• DICOM Standard - https://www.dicomstandard.org/
• LOINC - https://loinc.org/