Any AI vendor working in radiology will mention HL7 and FHIR in the same breath. Most department leads and imaging IT staff encounter these terms regularly but have never had a direct reason to understand the architectural difference. When you are evaluating whether an AI tool can actually connect to your PACS or RIS without a six-month IT project, understanding what each standard does and does not do becomes practically important.
This is a functional overview, not a comprehensive reference. The goal is to give a radiology operations lead or imaging IT manager enough grounding to ask the right questions during a vendor integration discussion.
HL7 v2: Still Everywhere, Not Going Away
HL7 version 2 (commonly written as HL7 v2) is a messaging standard developed starting in the late 1980s. The version 2.x series, particularly v2.3 through v2.5.1, became the backbone of clinical interoperability in the 1990s and 2000s and remains the dominant standard in hospital infrastructure today. If your RIS sends an order to your PACS when a study is scheduled, that message is almost certainly an HL7 v2 ORM (order message). If your PACS sends an ADT notification when a patient arrives, that is an ADT^A04 message in HL7 v2. If your PACS tells the RIS that a report is final, that is an ORU^R01 message.
HL7 v2 is a pipe-delimited text format. A message consists of segments (rows of data, each starting with a three-letter segment identifier), and each segment contains fields separated by the pipe character. It is not JSON, not XML, and not a modern REST API format. It was designed for the hardware and network constraints of 30 years ago and is deliberately terse. This makes it fast and efficient for high-volume event notification, and it makes it deeply unfriendly to parse without specialized tooling.
The integration model for HL7 v2 is typically peer-to-peer over a persistent TCP connection using a protocol called MLLP (Minimum Lower Layer Protocol). Your PACS and your RIS almost certainly have an HL7 v2 MLLP listener that has been running quietly for years. An AI tool that speaks HL7 v2 can subscribe to the order stream or inject messages to update worklist priority because it speaks the same language those systems already do. This is the practical reason why HL7 v2 support in a radiology AI tool matters regardless of its age: it is what the infrastructure speaks.
FHIR R4: The Modern Standard, With Caveats
FHIR (Fast Healthcare Interoperability Resources), specifically Release 4, is the current standard developed by HL7 International as a modern replacement architecture for healthcare data exchange. Where HL7 v2 is message-centric, FHIR is resource-centric. A patient is a Patient resource. An imaging study is an ImagingStudy resource. A diagnostic report is a DiagnosticReport resource. Each resource has a defined JSON or XML schema and is accessed via a RESTful HTTP API.
FHIR R4 is what the 21st Century Cures Act and CMS Interoperability Rule have been pushing EHR vendors to support. Epic's SMART on FHIR implementation and the Argonaut Project's implementation guides have made FHIR R4 the required API layer for modern EHR integration in the US. If you want to pull patient demographics or prior reports from an Epic or Cerner EHR into your AI tool, FHIR R4 is the path.
The caveat for radiology departments specifically: FHIR R4 is newer to imaging workflows than to EHR workflows. Your PACS vendor's FHIR support is likely less mature than their HL7 v2 support. The ImagingStudy resource in FHIR R4 exists and is well-specified, but the implementation depth varies considerably by PACS version. When a vendor says they support FHIR for PACS integration, it is worth asking specifically which FHIR operations they use and what PACS versions they have validated against.
Where Each Standard Fits in a Radiology AI Integration
A typical radiology AI pre-read integration touches several data flows, and different flows naturally map to different standards.
Order notification (knowing a study has been ordered and is incoming) currently happens most reliably via HL7 v2 ORM messages from the RIS. If the AI tool needs to start pre-processing a study as soon as it is ordered, the HL7 v2 order stream is the most reliable trigger mechanism in most existing radiology IT environments.
Worklist update (modifying the study priority in the PACS worklist) is typically done via HL7 v2 as well, either through ORM messages updating study priority fields or through direct DICOM Worklist (MWL) modification depending on PACS architecture. FHIR R4 can theoretically be used here if the PACS exposes a Task resource for worklist management, but this is not yet widely implemented in production PACS deployments.
Report output (getting the AI draft into the dictation system) depends heavily on your dictation system's capabilities. PowerScribe 360 and MModal Fluency Direct both have HL7 v2 interfaces for receiving pre-populated report text. Newer dictation system integrations may support FHIR DiagnosticReport resources for this purpose, but HL7 v2 ORU^R01 messages remain the practical path for most deployed dictation systems today.
EHR context retrieval (pulling relevant clinical context for a study from the EHR) is where FHIR R4 is genuinely the right choice. If the AI tool needs access to prior clinical notes, relevant lab values, or the referral indication beyond what is in the DICOM header, FHIR R4 against the EHR's API is the modern path. HL7 v2 ADT messages can provide basic patient context, but structured clinical data queries require FHIR.
DICOM Is the Third Standard You Cannot Ignore
HL7 and FHIR govern clinical workflow messaging. DICOM governs imaging data itself. Any radiology AI tool that actually processes image data receives studies via DICOM (either C-MOVE or C-GET from your PACS, or STOW-RS which is the DICOM-over-HTTP method that increasingly coexists with traditional DICOM). The DICOM standard covers not just image transfer but also DICOM Worklist (MWL), DICOM SR (Structured Reporting) for machine-readable output, and DICOM MPPS (Modality Performed Procedure Step) for study completion notification.
When an AI tool writes its output back into the clinical record, the options are HL7 v2 ORU for report text, FHIR DiagnosticReport for structured output, or DICOM SR for structured findings that live natively in the imaging environment. DICOM SR is underused in current AI deployments but is worth understanding because it allows AI-generated findings to be stored as structured objects in the PACS alongside the images, with a defined reference relationship between finding and the image region it describes.
What to Ask Your PACS Vendor and AI Vendor
For the PACS vendor: what version of the HL7 v2 standard does your MWL interface implement, and what ORM message fields are available for priority modification? Does your PACS expose a FHIR ImagingStudy endpoint, and if so, which PACS version introduced that support? What are the options for receiving DICOM SR output from third-party tools and associating it with the study?
For the AI vendor: which HL7 v2 message types does your integration layer produce and consume, and do you handle v2.3 through v2.5.1 variants given how much version variation exists in production environments? For FHIR, which FHIR R4 resources and operations do you use, and have you validated against the specific PACS and EHR versions in this department's environment? Is there a DICOM Conformance Statement for your tool?
The honest answer to the last question is often "we are working on it." DICOM Conformance Statements are a maturity indicator. A vendor that has one has gone through the discipline of specifying exactly what they send and receive. A vendor that does not yet have one has made the integration work for the environments they have tested but may encounter problems in edge-case configurations.
Integration depth is not glamorous but it is often the actual constraint on whether a pilot becomes a deployment. Asking specific questions about standards support early in the evaluation process surfaces the real integration risk before you are six weeks into a technical integration that has run into an unexpected PACS version incompatibility.