HL7 FHIR integration: legacy silos versus modern data exchange

It is the extra click, missing accession number, delayed prior study, and failed interface that lands on someone’s desk at 7:42 p.m.

The usual vendor answer is predictable: modernize the stack, expose the data, add cloud access, sprinkle in AI. The hospital answer is less glamorous. Keep the HL7 v2 interfaces running. Keep DICOM moving images. Keep the RIS and PACS from disagreeing about whether an exam exists. Then somehow add a clean REST API without turning the integration layer into a museum of one-off exceptions.

That is the practical case for HL7 FHIR integration in radiology workflow. FHIR does not replace DICOM, and it does not magically dissolve legacy infrastructure. It provides a structured way to connect orders, studies, clinical context, and applications while DICOM and DICOMweb continue doing the work of moving and serving imaging data.

The distinction matters. Confusing metadata exchange with pixel transport is how an interoperability project begins with a polished architecture diagram and ends with a queue of angry modality supervisors.

The legacy bottleneck: HL7 v2 and DICOM point-to-point constraints

Traditional radiology infrastructure is not one system. It is a collection of systems that have learned, over time, how to tolerate one another.

The RIS handles scheduling, orders, status, and reporting. The PACS stores and distributes studies. The EHR carries the broader clinical record. Modalities consume worklists and send images. Interface engines translate messages, route events, and occasionally become the only people in the building who understand why a study is stuck.

The historical division of labor is straightforward:

• HL7 v2 carries administrative and clinical messages, including orders and results.
• DICOM carries imaging objects, study metadata, and the operational details required by modalities and archives.
• RIS and PACS use these standards in different ways, with local configuration layered on top.
• EHR platforms increasingly expect modern API access rather than another point-to-point interface.

The problem is not that HL7 v2 and DICOM are useless. They are deeply embedded, widely deployed, and very good at the jobs they were designed to do. The problem is the way they are commonly connected: system A sends a message to system B, which sends a transformed message to system C, which writes a partial result into system D.

A radiology network can accumulate dozens of these paths. One handles orders. Another handles cancellations. A third maps facility identifiers. A fourth fixes patient names that were formatted differently by two applications. Somewhere in the middle, an interface engine applies a rule written years ago by someone who no longer works there.

This is the point where “interoperability” becomes a polite word for maintenance.

A conventional order workflow may depend on HL7 v2 messages such as ORM^O01 for orders and ORU^R01 for results, while DICOM manages the imaging side. That arrangement works, but it creates silos around the exact information that modern viewers, analytics systems, and AI services need to coordinate:

• What was ordered?
• Which patient and encounter does it belong to?
• Has the study been scheduled, performed, corrected, or canceled?
• Which series and instances belong to the study?
• What is the authoritative link back to the originating order?
• Which application is allowed to retrieve the images?

Without a consistent data model, every new application becomes an integration negotiation. The enterprise imaging platform wants one identifier. The EHR exposes another. The PACS has a third. The modality has faithfully preserved all of them, but not necessarily in the same field.

The old stack does not fail because it is old. It fails because every new workflow is forced to negotiate with its history.

Why point-to-point integration keeps producing friction

The operational cost appears in small failures rather than dramatic outages. A study may still arrive in PACS, but the order context is incomplete. An AI tool may receive pixel data, but not the relevant clinical indication. A cloud viewer may open the examination, but fail to launch it from the correct patient encounter.

These failures are especially expensive in high-throughput environments because the radiologist rarely sees the integration layer. They see the consequence:

• a missing prior study;
• an examination displayed under the wrong encounter;
• a report that does not reconcile cleanly with the order;
• an AI result that cannot be associated with the correct series;
• a viewer that requires a separate login and another search.

The software may be technically “working.” The workflow is not.

FHIR does not replace DICOM. It gives the workflow a spine.

HL7 FHIR integration in radiology workflow is best understood as a coordination layer. It provides standardized resources and RESTful APIs for exchanging structured information between systems. It does not turn FHIR into a new image archive.

DICOM remains responsible for imaging objects. DICOMweb extends that model for modern applications by exposing RESTful services such as WADO-RS, allowing web viewers and cloud applications to query and retrieve pixel data over standard HTTP APIs.

FHIR and DICOMweb therefore address different but connected parts of the problem:

That division is not academic. A platform that claims FHIR alone will solve image access is selling a conceptual diagram. A platform that keeps DICOM isolated from the clinical data model is preserving the silo with a newer login screen.

A workable architecture lets each standard do its job while maintaining identity and reference integrity across the workflow. FHIR provides the structured clinical and operational context. DICOM and DICOMweb provide image storage, transfer, query, and retrieval.

This is also why the phrase “DICOM and FHIR interoperability” should be treated as a design problem, not a product feature. The real question is how the two models meet at specific workflow boundaries.

Mapping ServiceRequest to the modality workflow

The most useful starting point is the order.

FHIR’s ServiceRequest resource represents a diagnostic procedure request. In a radiology workflow, that request must eventually become something the RIS, scheduling system, and modality can act on. The operational bridge is the DICOM Modality Worklist, or MWL.

The mapping is not simply a field-to-field translation exercise. It is a chain of identity and status decisions:

1. A clinician or authorized user creates a diagnostic request in the EHR.

2. The request is represented as a ServiceRequest.

3. The order is transmitted to the RIS or scheduling layer.

4. Relevant fields are mapped into the DICOM Modality Worklist.

5. The modality retrieves the worklist entry.

6. The performed study is sent to PACS or an enterprise imaging archive.

7. The resulting study is associated with the originating order.

8. A report and status update return to the clinical record.

At every stage, the system must preserve the relationship between patient, encounter, order, accession, study, and report. Break that chain and downstream systems may still receive data, but they no longer know how the pieces belong together.

The basedOn element in FHIR’s ImagingStudy resource is important here. It can maintain a reference back to the originating ServiceRequest, preserving the connection between what was requested and what was performed. That connection is easy to underestimate when looking at a single viewer screen. It becomes critical when the same study feeds a PACS, an EHR, a cloud viewer, an AI service, a research repository, and a quality reporting pipeline.

The fields that cause disproportionate damage

Radiology integration projects often focus on transport: can the message or API call get from one endpoint to another? The harder question is whether the receiving system interprets the data consistently.

A few fields repeatedly become workflow bottlenecks:

• patient identifiers and assigning authority;
• accession number;
• order identifier;
• encounter reference;
• procedure code;
• requested body site and laterality;
• study instance UID;
• series and instance identifiers;
• performing location;
• scheduling and completion status;
• references to prior studies;
• report status and authoring context.

A modern API does not fix ambiguous identity. It simply moves the ambiguity faster.

For example, a ServiceRequest may describe a requested MRI procedure, while the resulting ImagingStudy contains the study-level metadata and references to the DICOM series and instances. If the identifiers are mapped inconsistently between the EHR, RIS, and PACS, the API remains perfectly available while the clinical relationship is broken.

That is why a radiology information system data exchange project should begin with identity governance and workflow ownership, not with a demonstration of a browser viewer. The viewer is the visible part. The identifier strategy is the load-bearing structure.

ImagingStudy: useful metadata, not a replacement archive

FHIR’s ImagingStudy resource is designed to describe a DICOM study in a clinical data model. It can represent the study, its series, and its SOP instances, while retaining references to the order that initiated the examination.

This makes it valuable for applications that need to understand an examination without first behaving like a full PACS client. A clinical application may need to know that an MRI exists, what body region it concerns, when it was performed, and where the images can be retrieved. An AI orchestration service may need to identify eligible studies and route them to an algorithm. A research platform may need structured metadata before requesting the underlying image objects.

The distinction is straightforward:

• ImagingStudy describes the study and its organization.
• DICOM stores the imaging objects and their technical metadata.
• DICOMweb provides web-accessible query and retrieval mechanisms.
• The application uses references and permissions to connect description with image access.

A cloud-based MRI viewer benefits from this arrangement because it can use FHIR to obtain patient and study context, then use DICOMweb to retrieve the relevant imaging data. That workflow is cleaner than forcing every browser application to understand the full collection of legacy PACS interfaces.

It also supports more selective access. An application may need the metadata for a study before it is authorized to retrieve pixel data. Separating those operations can help enforce access policies and reduce unnecessary data movement. It is not a substitute for security architecture, but it gives the architecture clearer boundaries.

Where ImagingStudy mappings become fragile

FHIR resources are structured, but the underlying radiology environment is rarely uniform. Local codes, legacy identifiers, incomplete demographics, and inconsistent use of DICOM attributes can make the mapping unreliable.

Common failure points include:

• the FHIR request references a procedure code that does not align with the RIS catalog;
• the DICOM study contains a local accession format that the EHR does not recognize;
• a corrected or amended study creates ambiguity about which object is current;
• the ImagingStudy metadata is created before all series are available;
• a study is split or merged operationally, while downstream applications expect one stable object;
• de-identification changes identifiers without preserving the required research linkage;
• an AI service receives an image series without enough context to determine whether it is eligible for processing.

This is where implementation discipline matters more than standards enthusiasm. A resource can be valid FHIR and still be operationally useless if its references do not resolve, its status is stale, or its identifiers cannot be reconciled with the PACS.

The practical test is not whether a developer can retrieve a JSON payload. The test is whether the radiologist, technologist, researcher, and downstream application all see the same study as the same study.

Hybrid architecture: keep the legacy core, modernize the edges

Most enterprise healthcare networks will not move from HL7 v2 and DICOM to a pure FHIR-native architecture in one clean migration. Nor should they. The installed base is too large, and the clinical risk of a rushed replacement is too obvious.

The realistic model is hybrid:

• internal operations continue to use HL7 v2 for many administrative messages;
• modalities and archives continue to use DICOM;
• FHIR exposes standardized clinical and operational resources;
• DICOMweb supports browser, mobile, cloud, and application access to imaging;
• interface engines translate and route events between generations of infrastructure;
• identity, consent, auditing, and access controls operate across the stack.

This is less elegant than a greenfield architecture. It is also more likely to survive contact with a real hospital.

The hybrid approach has one major advantage: it allows an organization to modernize the access layer without pretending that the legacy core can be switched off during a Tuesday afternoon maintenance window. A cloud AI tool can consume FHIR resources and DICOMweb services while existing modalities continue to communicate through established pathways.

The catch is that the integration layer becomes more important, not less. There are now more APIs, more endpoints, more authentication flows, and more opportunities for a message to be technically accepted but clinically misinterpreted.

What the architecture has to manage

A useful enterprise imaging interoperability design usually has to account for five operational layers:

1. Identity and provenance

Patient, encounter, order, accession, study, series, and report identifiers must remain traceable across systems.

2. Workflow status

Requested, scheduled, arrived, in progress, completed, canceled, corrected, and reported are not interchangeable states. Applications need a shared understanding of what each means.

3. Image access

FHIR can point to imaging context, but DICOMweb or traditional DICOM services still provide the image objects. The handoff must be explicit and permissioned.

4. Security and audit

Cloud viewers and AI tools require authentication, authorization, logging, and data minimization. A REST endpoint is not a security strategy.

5. Operational observability

Teams need to know whether an order failed to map, an ImagingStudy was not generated, a DICOMweb request timed out, or a downstream application simply ignored the response.

That last layer is routinely underfunded. Organizations buy an integration platform and then discover that nobody can answer a simple question: where did this study disappear?

Interoperability is not achieved when every system can speak. It is achieved when the right system can find the right study, with the right context, at the right moment.

Cloud access, AI integration, and the hidden cost of convenience

The appeal of FHIR and DICOMweb is obvious. A browser-based viewer can reduce desktop dependencies. A cloud AI service can receive studies through standardized interfaces. A research environment can query structured metadata without asking the PACS team for a custom export every time.

But convenience shifts the integration burden rather than eliminating it.

A cloud viewer still needs:

• reliable patient and study matching;
• authorization tied to the clinical context;
• predictable DICOMweb query and retrieve behavior;
• support for the relevant transfer syntaxes and imaging objects;
• clear handling of incomplete, corrected, or amended studies;
• acceptable latency for large MRI examinations;
• audit records that connect the user action to the data access.

The API handshake is only the beginning. MRI studies are not small transactional records. They may include multiple sequences, series, reconstructions, and derived objects. A viewer that retrieves metadata quickly but stalls while loading the actual study has not solved workflow friction. It has merely moved the waiting room into a browser tab.

AI integration adds another layer of ambiguity. The algorithm may require specific sequences, field strengths, or acquisition parameters. FHIR can help expose the study context and DICOMweb can provide access to the images, but the orchestration layer still has to determine eligibility, route the correct series, handle failures, and return results to a place where clinicians can actually use them.

The technical architecture should therefore distinguish between:

• finding a candidate study;
• determining whether it meets algorithm requirements;
• retrieving the required images;
• processing the images;
• returning results with correct provenance;
• presenting those results inside the existing reading workflow.

If each step generates a new login, queue, or manual reconciliation task, the organization has increased click fatigue while calling it innovation.

ONC mandates and the direction of enterprise interoperability

The regulatory direction in the United States reinforces the move toward standardized APIs. The ONC final rule mandates HL7 FHIR R4 standardized APIs alongside the United States Core Data for Interoperability, or USCDI v1, for nationwide healthcare data interoperability.

That does not mean every radiology department suddenly becomes FHIR-native. It does mean that application access, data exchange expectations, and procurement requirements increasingly favor standardized interfaces over proprietary access patterns.

For imaging organizations, the implication is not simply “buy a FHIR server.” The more useful questions are operational:

• Which clinical resources will the organization expose?
• How will ServiceRequest map to existing order workflows?
• How will ImagingStudy remain synchronized with the PACS?
• Which DICOMweb services will be supported?
• How will external applications discover studies without receiving unnecessary data?
• How will consent, access control, and audit requirements be enforced?
• What happens when the FHIR representation and the PACS state disagree?

The answer will vary by architecture. A large integrated delivery network may need an enterprise integration layer that normalizes data across multiple RIS and PACS deployments. A research hospital may prioritize de-identification and cohort discovery. A teleradiology service may care most about rapid study routing, reliable priors, and report exchange across organizations.

The standard is shared. The bottleneck is local.

A practical comparison for planning

The table is not a procurement scorecard. It is a reminder that no single standard carries the whole workflow. The attractive architecture is usually the one that divides responsibilities cleanly and admits where the old systems still matter.

Where integration projects actually lose throughput

Radiology workflow optimization is often framed as a performance problem: reduce latency, increase availability, improve throughput. Those metrics matter, but integration failures usually appear as coordination defects.

A useful implementation review should follow the study rather than the product. Trace one order from request to report and ask:

1. Where is the order created?

2. Which identifier becomes the accession number?

3. How does the request reach the RIS?

4. What exactly is written to the DICOM Modality Worklist?

5. Which identifiers return from the modality?

6. When is the ImagingStudy resource created or updated?

7. How does the viewer discover the study?

8. Which service retrieves the pixels?

9. How are corrections and amendments propagated?

10. Where is the audit trail stored?

The answers expose the real integration surface. They also reveal where manual work is hiding.

If a technologist must re-enter an identifier, if a radiologist must search two systems for the prior, or if an analyst must manually reconcile de-identified research records with source studies, the architecture has a throughput cost even when the interfaces report zero errors.

The most useful metrics are therefore not limited to API uptime. They include:

• percentage of orders mapped without manual correction;
• time from order creation to modality worklist availability;
• rate of unmatched or duplicate studies;
• time from acquisition to viewer availability;
• percentage of studies with resolvable order references;
• failed DICOMweb retrievals;
• AI jobs rejected because required series were missing;
• number of manual reconciliation events per examination;
• time spent investigating interface exceptions.

These are not glamorous metrics. Neither is click fatigue. Both determine whether the system earns its keep.

The case for gradual modernization

The strongest argument for HL7 FHIR integration is not that FHIR is newer. Newness is a weak architectural principle and an excellent marketing adjective.

The argument is that radiology needs a more consistent way to expose workflow context to applications without forcing every new consumer to learn the private dialect of every RIS, PACS, and interface engine in the network.

A sensible modernization path usually begins with a narrow, measurable workflow:

• expose diagnostic orders through ServiceRequest;
• represent completed studies through ImagingStudy;
• preserve references with basedOn;
• provide DICOMweb access for authorized image retrieval;
• monitor identity matching and workflow status;
• test the complete order-to-report path before expanding the scope.

The first deployment does not need to solve every interoperability problem in the enterprise. It needs to prove that a study can be requested, performed, discovered, retrieved, interpreted, and linked back to the clinical record without adding a new manual queue.

From there, the organization can extend the pattern to cloud viewing, AI orchestration, research access, teleradiology, and cross-site exchange. Each extension should inherit the same identity and provenance rules rather than inventing another local integration dialect.

The practical conclusion is mildly unfashionable: keep the legacy systems where they are still reliable, modernize the interfaces where the workflow is breaking, and measure the result in fewer exceptions rather than more endpoints.

FHIR is not the shiny replacement for DICOM. DICOM is not the clinical data model that every application has been waiting for. Together, with disciplined mapping and DICOMweb access, they can make enterprise imaging less dependent on fragile point-to-point assumptions.

That is not a revolution. It is better: a reduction in friction that a tired radiologist can actually feel.