Healthcare Equipment Interoperability: Understanding DICOM, HL7, and FHIR

Truway Health | Medical Technology, Digital Infrastructure & Healthcare Innovation

Modern medical equipment does more than collect clinical information. Increasingly, its value depends on how effectively that information moves between devices, electronic health records, imaging archives, and healthcare professionals.

In a connected hospital, an ultrasound machine may capture diagnostic images, a radiology system may coordinate an examination, and an electronic health record (EHR) may make the resulting report available to a physician.

But these systems do not necessarily communicate using the same technical language.

Three standards play particularly important roles in healthcare interoperability: DICOM, HL7, and FHIR.

Although related, these technologies serve different functions. Understanding their capabilities—and their limitations—can help hospitals, clinics, imaging centers, and medical equipment purchasers avoid costly integration problems.

This Truway Health guide explains how the standards work, where they overlap, and what healthcare organizations should verify before investing in connected medical technology.

1. What Is Healthcare Equipment Interoperability?

Healthcare interoperability refers to the ability of different information systems, applications, and medical devices to exchange information and use it appropriately.

Consider a typical diagnostic imaging workflow.

A physician requests an ultrasound examination. The scheduling system registers the appointment, the ultrasound machine acquires the images, an imaging archive stores the study, and the EHR makes the findings available to the care team.

If the systems are properly integrated, information can move through this workflow with fewer manual steps.

Successful interoperability can support:

More efficient clinical workflows.
Reduced duplicate data entry.
Better access to diagnostic images and reports.
Improved patient and examination identification.
More consistent documentation.
Greater flexibility when integrating equipment from different manufacturers.

However, purchasing equipment advertised as network-ready or DICOM-compatible does not automatically establish end-to-end interoperability.

Actual integration depends on supported interfaces, configuration, software licensing, security, and compatibility testing.

2. DICOM: The Standard for Medical Imaging

DICOM stands for Digital Imaging and Communications in Medicine.

It is a widely adopted international standard for representing, storing, exchanging, and managing medical imaging information.

DICOM is especially relevant to equipment such as:

Ultrasound systems.
CT scanners.
MRI systems.
Digital radiography equipment.
Fluoroscopy and C-arm systems.
Certain cardiology imaging systems.
Digital pathology equipment.

Unlike an ordinary image file, a DICOM object may contain both imaging data and structured information describing the patient, examination, acquisition equipment, and image characteristics.

DICOM and PACS

A Picture Archiving and Communication System, or PACS, stores and manages medical images.

DICOM provides standardized mechanisms that help imaging devices communicate with compatible archives and viewing systems.

Common DICOM capabilities include:

Storage: Sending imaging studies to a compatible archive.

Query and Retrieve: Locating and accessing previously stored studies.

Modality Worklist: Retrieving scheduled examination details from a compatible workflow system.

Modality Performed Procedure Step: Communicating information about the status of certain performed examinations.

Why DICOM matters for ultrasound purchasing

Imagine a clinic purchasing a new color Doppler ultrasound system.

The device may produce high-quality diagnostic images, but that alone does not establish compatibility with the clinic's existing PACS.

The purchasing team should determine whether the actual system configuration supports the required DICOM storage functions, network services, worklist capabilities, and image formats.

A manufacturer-provided DICOM Conformance Statement is an important document for evaluating those capabilities.

It identifies which DICOM functions the manufacturer declares the product supports.

Even with a conformance statement, the buyer must verify compatibility with the receiving system.

3. HL7: Connecting Clinical and Administrative Systems

HL7 stands for Health Level Seven, the organization responsible for developing several widely used healthcare information exchange standards.

When healthcare professionals refer to traditional HL7 interfaces, they often mean HL7 Version 2 messaging.

HL7 v2 is extensively used to exchange clinical and administrative information among hospital systems.

Common applications include patient registration, laboratory orders, examination orders, and results reporting.

Understanding common HL7 v2 messages

Message family	Typical function
ADT	Admission, discharge, transfer, and patient demographic events
ORM	General order messaging in traditional HL7 v2 workflows
OML	Laboratory order messaging in supported implementations
ORU	Observation and result reporting
SIU	Scheduling information

These messages enable systems to share information without requiring staff to manually reenter every data element.

Practical example: Radiology orders

A physician enters an imaging order through an EHR.

The hospital's integration infrastructure may transmit an HL7 v2 order message to the radiology information system.

The radiology system then makes scheduling and examination information available to imaging equipment through the appropriate workflow interfaces, potentially including DICOM Modality Worklist.

After the examination, clinical results may be returned to the EHR through HL7 messaging or another supported interface.

Importantly, HL7 v2 ordinarily handles the patient, order, and result information rather than serving as the primary format for transferring full diagnostic image datasets.

HL7 and DICOM therefore complement each other rather than compete as interchangeable technologies.

4. FHIR: A Modern Approach to Healthcare Data Exchange

FHIR stands for Fast Healthcare Interoperability Resources.

Developed by HL7 International, FHIR provides a structured framework for exchanging healthcare data.

FHIR is often associated with web-based application programming interfaces, or APIs.

These interfaces allow authorized software applications to request and exchange information using widely adopted web technologies.

FHIR supports different exchange approaches, but RESTful APIs and JSON data representations are especially familiar to modern application developers.

What is a FHIR resource?

A FHIR resource represents a defined category of information.

Examples include:

FHIR Resource	Purpose
Patient	Patient identity and demographic information
Observation	Measurements and clinical observations
DiagnosticReport	Diagnostic reports and associated findings
ServiceRequest	Requests for examinations or clinical services
ImagingStudy	Metadata describing DICOM imaging studies
Device	Information describing a device
Encounter	Information about a patient encounter

Resources can reference one another to represent connected clinical information.

For example, a diagnostic report may reference a patient, an order, and an imaging study.

How FHIR differs from traditional HL7 messaging

Traditional HL7 v2 integrations frequently exchange event-driven messages between established healthcare systems.

FHIR makes it possible to implement standardized APIs through which authorized applications access supported resources.

Both technologies can support clinical workflows, and both continue to be used.

FHIR does not automatically replace existing HL7 v2 systems.

Many healthcare environments employ both.

SMART on FHIR

SMART on FHIR is an application integration framework that uses FHIR APIs alongside authorization and application-launch conventions.

It can help approved applications connect to compatible EHR systems without requiring a completely separate custom integration for every implementation.

However, SMART support, permissions, API scope, and the available data resources must be confirmed for each environment.

5. DICOM vs. HL7 vs. FHIR: What's the Difference?

The simplest way to understand these standards is to consider the type of information each primarily manages.

Feature	DICOM	HL7 v2	FHIR
Primary role	Imaging data and imaging workflows	Clinical and administrative messages	Structured healthcare information exchange
Typical information	Images, studies, imaging metadata	Admissions, orders, results	Patients, observations, reports, orders
Common systems	Imaging modalities, PACS, viewers	EHRs, LIS, RIS, interface engines	EHR APIs, apps, health information platforms
Exchange approach	DICOM network services and DICOMweb	Message-based interfaces	APIs, messaging, documents, and other patterns
Main purchasing consideration	Supported DICOM services and objects	Supported messages and interface profiles	Supported FHIR version, resources, profiles, and security

The standards answer different questions:

DICOM: How can medical imaging information be represented and exchanged?
HL7 v2: How can healthcare systems communicate patient, order, and result events?
FHIR: How can healthcare information be modeled and exchanged through standardized modern interfaces and other supported mechanisms?

6. DICOMweb: Bringing Medical Imaging Into Web-Based Workflows

Traditional DICOM network services remain important, but DICOM also includes web-based capabilities known collectively as DICOMweb.

Three widely recognized transactions are:

QIDO-RS: Search for imaging studies and associated information.

WADO-RS: Retrieve DICOM studies, series, instances, or supported representations.

STOW-RS: Store DICOM objects using web-based services.

These capabilities can support browser-based imaging systems, enterprise viewing applications, and integration with modern healthcare platforms.

However, DICOMweb is not automatically supported by every DICOM-compatible device or archive.

Buyers must verify the specific services implemented.

How DICOMweb and FHIR can work together

FHIR's ImagingStudy resource can describe a DICOM imaging study and reference an endpoint for accessing the underlying images.

The actual image objects may remain in a PACS or another DICOM-compatible repository.

This distinction is critical: FHIR ImagingStudy is not a replacement for the complete DICOM imaging dataset.

FHIR can help applications discover relevant clinical and imaging information, while DICOM services provide the imaging-specific retrieval functions.

7. A Connected Ultrasound Workflow: How the Standards Work Together

Consider a hospital implementing a diagnostic ultrasound system.

A possible integrated workflow consists of six stages.

Step 1: Examination ordering

A healthcare professional requests an ultrasound examination in the EHR.

The order may be communicated to a radiology information system through HL7 v2 or another supported integration.

Step 2: Scheduling and worklist management

The radiology system prepares the examination details.

A compatible ultrasound system may retrieve the relevant patient and examination information through DICOM Modality Worklist.

Step 3: Image acquisition

The ultrasound equipment acquires images and, if supported, creates appropriate DICOM objects.

Step 4: Image storage

The ultrasound system transmits the study to a configured PACS using supported DICOM services.

Step 5: Clinical interpretation

An authorized clinician reviews the images and prepares a diagnostic report.

The reporting system communicates findings to the EHR through its supported interface.

Step 6: Clinical information access

A compatible application may retrieve authorized report information or imaging-study references through a supported FHIR API.

Actual imaging access may require separate DICOMweb or PACS services.

This illustrates a potential architecture, not a universal plug-and-play configuration. Each connection must be individually implemented and tested.

8. Why Interoperability Matters When Purchasing Medical Equipment

Healthcare purchasing decisions often emphasize imaging quality, diagnostic performance, accessories, and purchase price.

Connectivity deserves comparable attention.

A sophisticated medical device may create additional operational costs if it cannot exchange information with the facility's systems.

Possible consequences include:

Manual reentry of patient information.
Difficulty transferring imaging studies.
Delayed availability of diagnostic results.
Additional integration software costs.
Increased cybersecurity management requirements.
Dependence on proprietary file formats.
Difficulty migrating information to future systems.

What should purchasers request?

Before ordering network-connected equipment, request clear documentation addressing:

Supported standards: Determine exactly which DICOM, HL7, or FHIR capabilities are implemented.

Software licenses: Confirm whether connectivity features are included or require separately purchased options.

Network configuration: Identify the required Ethernet, Wi-Fi, server, and other infrastructure.

Interface documentation: Obtain relevant conformance statements, implementation guides, and API descriptions.

Compatibility testing: Establish whether the equipment can exchange the required data with the facility's existing systems.

Service arrangements: Determine who is responsible for installation, configuration, testing, upgrades, and maintenance.

This documentation is particularly important for hospitals and government procurement projects where technical acceptance requirements should be defined before equipment delivery.

9. Medical Device Cybersecurity and Data Protection

Greater connectivity can also introduce additional cybersecurity exposure.

Medical devices and the systems they interact with may process sensitive patient information.

Healthcare organizations should evaluate:

User authentication and access controls.
Network segmentation.
Encryption for applicable data transfers.
Security logging and auditability.
Manufacturer software updates.
Vulnerability management.
Backup and recovery procedures.
Data retention and secure disposal.
Applicable privacy and security requirements.

Support for DICOM, HL7, or FHIR does not by itself establish that a product is secure or compliant with healthcare privacy regulations.

Security safeguards must be assessed across the complete system, including network infrastructure, connected applications, cloud services, and operational policies.

10. Why Standards Compliance Does Not Guarantee Compatibility

One of the most important procurement lessons is that standards support and practical interoperability are not the same thing.

Two devices may support the same broad standard but implement different capabilities.

For example:

One ultrasound system may support DICOM Storage but not Modality Worklist.
Another may support traditional DICOM networking but lack DICOMweb services.
Two software systems may use different HL7 v2 versions or custom message profiles.
Two FHIR servers may expose different resources, profiles, API permissions, or supported operations.

Interoperability depends on matching the relevant implementation details, not simply finding the same acronym in two product brochures.

Recommended acceptance testing

Before final commissioning, purchasers should consider documenting successful tests for:

Correct patient matching.
Order and worklist exchange.
Image transmission and retrieval.
Accurate study and report association.
Handling of communication failures.
User permissions and security controls.
Data export and system recovery.
Compatibility with the intended production environment.

Acceptance criteria should reflect the equipment's intended use and the purchasing organization's workflow.

11. Interoperability and the Future of Healthcare Technology

Healthcare technology continues moving toward more connected and data-driven environments.

Important areas of development include enterprise imaging, cloud-based archives, clinical decision support, remote monitoring, and artificial intelligence.

For medical imaging, DICOM and DICOMweb provide important mechanisms for working with standardized imaging data.

HL7 v2 remains deeply embedded in operational healthcare messaging.

FHIR supports modern applications that need structured access to clinical information.

Together, these technologies can provide important foundations for future innovation.

However, emerging applications—including AI-assisted analysis and digital twins—require additional attention to data quality, validation, provenance, clinical safety, and governance.

Interoperability makes information exchange possible. It does not automatically establish the accuracy of a downstream algorithm or the clinical effectiveness of a technology.

12. Truway Health: Evaluating Connected Diagnostic Equipment

Truway Health offers medical equipment across diagnostic imaging, patient monitoring, and other clinical technology categories.

For healthcare organizations evaluating new equipment, interoperability requirements should be established early in the procurement process.

Featured equipment: Truway Health SUN-906A Ultrasound System

The Truway Health SUN-906A 3D/4D Color Doppler Ultrasound System is listed with convex, linear, and transvaginal probes.

Facilities evaluating the system for institutional imaging workflows should request confirmation of its installed connectivity options, image export capabilities, software licensing, and intended PACS environment.

Important: DICOM functionality has not been verified for this specific unit. Its product listing instructs purchasers to obtain manufacturer documentation and confirmation of any installed DICOM options before specifying system integration.

Explore Truway Health SUN-906A Ultrasound System

Additional products can be explored in the Truway Health Diagnostic Equipment Catalog.

Frequently Asked Questions

Is DICOM the same as HL7?

No. DICOM focuses on medical imaging information and associated workflows. HL7 develops standards for exchanging a broader range of clinical and administrative healthcare information.

Is FHIR replacing HL7?

FHIR is itself an HL7 standard. It does not automatically replace HL7 v2 messaging, which remains widely deployed in healthcare environments.

Does an ultrasound machine need DICOM?

Not every ultrasound workflow requires DICOM. However, facilities planning to integrate an ultrasound system with a PACS should carefully evaluate the required DICOM capabilities and the equipment's actual implementation.

Can FHIR transmit medical images?

FHIR can represent imaging-study information and references to image repositories. Imaging data can be accessed through appropriate services, often including DICOM-based retrieval mechanisms.

What is the difference between DICOM and DICOMweb?

Traditional DICOM networking uses imaging-specific communication services. DICOMweb provides standardized web-based mechanisms for querying, retrieving, and storing imaging objects.

How can a hospital verify interoperability before purchasing?

The hospital should obtain manufacturer documentation, identify required interfaces, confirm supported configurations, and complete compatibility testing against its actual clinical information systems.

Conclusion: Connected Equipment Requires More Than a Network Connection

DICOM, HL7, and FHIR are complementary foundations of healthcare interoperability.

DICOM supports medical imaging exchange. HL7 v2 supports established clinical and administrative messaging. FHIR provides modern approaches to structured healthcare information exchange.

Understanding their roles helps healthcare organizations avoid expensive integration assumptions and evaluate medical equipment more effectively.

The future of healthcare technology depends not simply on connected devices, but on systems capable of exchanging useful, accurate, and appropriately protected information.

Plan Your Next Medical Equipment Purchase with Truway Health

Evaluating diagnostic imaging equipment, patient monitoring systems, or specialized clinical technology?

Explore Truway Health's equipment catalog and identify the technical capabilities required for your healthcare environment.

Explore Diagnostic Equipment at Truway Health

For institutional procurement inquiries, include your desired equipment configuration, supported interface requirements, facility infrastructure, and installation specifications.

Technical References and Further Reading

Technical disclaimer: This publication is intended for general healthcare technology and procurement education. Device compatibility, security, regulatory obligations, and interoperability must be evaluated for the specific system configuration and intended application.

Oct 18th 2026 Truway Health