Last Updated | June 6, 2026
Healthcare has largely shifted to digital records, with more than 96% of US hospitals now using Electronic Health Record (EHR) systems. Yet one of the biggest challenges begins after the data is created. Devices like pulse oximeters or CT scans generate a high volume of data, studies that can span gigabytes. Getting that information into the patient’s record is where the hurdle lies. Medical devices, EHRs, & healthcare applications rely on different standards to exchange data. The three standards that handle most of this communication include DICOM, HL7, and FHIR. Understanding what each is designed to do, where it fits, and how it interacts with the others is often the difference between a smooth implementation and costly integration issues.
How DICOM Structures Imaging Data
DICOM, or Digital Imaging and Communications in Medicine, was first published in 1993 as a standard used to store, transmit, and display medical images. Even today, every CT scan, MRI, ultrasound, X-ray, and mammogram produced in a US hospital is saved as a DICOM file.
A DICOM file is more like a container where the image is saved alongside a metadata header that carries the patient’s name, study date, imaging modality (CT, MR, US), referring physician, and dozens of other attributes defined by the DICOM standard. This metadata lives in standardized tags that any DICOM-compliant viewer or system can parse.
This structure is what makes DICOM useful in practice. When a radiologist opens a study in their PACS (Picture Archiving and Communication System), they are not viewing raw pictures, but an image tied to a patient, a visit, and a clinical context, all encoded in the file itself.
DICOM Limitation
DICOM does not handle clinical orders, lab results, patient demographics updates, medication lists, or any of the other data types that move through a hospital every day.
A CT scanner communicates in DICOM, but a bedside vital signs monitor does not. This boundary gets misunderstood more often than you’d expect. DICOM owns medical imaging; however, everything else (vitals, labs, ADT, scheduling) travels through HL7 or FHIR.
What Is HL7 & How HL7 v2 Messaging Works
HL7 stands for Health Level Seven, a reference to the seventh layer (application) of the OSI network model. HL7 v2, and the refined versions 2.1 to 2.9, are the most widely deployed clinical messaging standards in the world.
HL7 v2 uses a pipe-delimited text format. Each message starts with an MSH (Message Header) segment that identifies the sending system, receiving system, message type, and timestamp.
Below the header sit data segments: PID for patient demographics, OBR for observation requests, OBX for observation results. The segments follow a defined sequence, and each field within a segment occupies a designated position.
A stripped-down HL7 v2 ADT message looks like this:
- MSH|^~\&|MONITOR|ICU|EPIC|HOSPITAL|202506011200||ADT^A01|MSG001|P|2.5
- PID|||12345^^^MRN||DOE^JOHN||19800515|M
That message tells the receiving system that a new patient admission occurred for John Doe, MRN 12345, male, born May 15, 1980. Every hospital information system in the US that exchanges ADT, order, or result messages with an EHR does so using some version of this format.
Why HL7 v2 Still Runs Most Hospitals
HL7 v2 remains the dominant standard for clinical data exchange within hospital networks because of the installed base. Tens of thousands of interfaces have been built on HL7 v2 over three decades. Lab systems, pharmacy systems, radiology information systems, bedside monitors, and blood gas analyzers all communicate using v2.
Replacing that infrastructure would cost millions per hospital and carry operational risk that most health systems refuse to accept.
HL7 v3 was supposed to replace v2. It introduced an XML-based reference information model (RIM) that was more rigorous but far more complex to implement. v3 never gained real traction in the US. Most hospitals skipped it entirely and are now moving from v2 to FHIR for specific use cases, one interface at a time.
As healthcare organizations modernize these integrations, many rely on interface engines to connect legacy HL7 systems with newer interoperability frameworks, detailed in 7 Best HL7 Interface Engines. Health systems using Epic often manage many of these HL7 connections through Epic Bridges.
How FHIR Resources and the FHIR API Work
Fast Healthcare Interoperability Resources comes from HL7 International, the same organization behind HL7 v2 and v3. It was first published as a draft in 2014 and reached normative status (R4) in 2019.
FHIR takes a different approach than HL7 v2. Instead of sending complete messages between systems, FHIR defines individual resources (Patient, Observation, Condition, MedicationRequest, Encounter, and about 150 others) that each represent a single clinical concept. These resources are expressed in JSON or XML and accessed through a RESTful API.
With HL7 v2, a system pushes a message to another system and hopes it arrives. With the FHIR API, a system requests specific resources from another system’s endpoint using standard HTTP methods (GET to read, POST to create, PUT to update).
This is the same architectural pattern behind every modern web API, which explains why FHIR has gained adoption faster than any previous healthcare standard.
The 21st Century Cures Act, through ONC’s final rule, requires certified EHR vendors to support FHIR R4-based APIs for patient data access. This is not optional. Epic, Oracle Health (Cerner), and MEDITECH all expose FHIR endpoints today.
What is SMART on FHIR
SMART on FHIR is a framework built on top of FHIR that handles authorization and app launch. SMART stands for Substitutable Medical Applications, Reusable Technologies.
SMART on FHIR defines how a third-party application authenticates with an EHR, gets permission to access specific patient data, and launches within the EHR’s clinical workflow. It uses OAuth 2.0 for authorization and OpenID Connect for identity. If you’ve ever authorized a third-party app to access your Google account, the pattern is similar. SMART on FHIR applies that same model to clinical data.
This is what makes the growing EHR app system work. Epic’s App Showroom, Oracle Health’s marketplace, and similar platforms all require SMART on FHIR compliance for third-party applications.
DICOM vs HL7 vs FHIR
DICOM |
HL7 v2 |
FHIR |
|
First published |
1993 | 1987 | 2014 (draft), 2019 (R4) |
Primary data type |
Medical images + imaging metadata | Clinical messages (ADT, orders, results, charges) |
Any clinical data as discrete resources |
Data format |
Binary file with metadata header | Pipe-delimited text segments | JSON or XML |
Transport method |
DIMSE (DICOM network protocol) or DICOMweb (HTTP) | TCP/IP via MLLP or file-based |
RESTful HTTP API |
Communication model |
Push (store) or query/retrieve | Push (event-triggered messages) | Request/response (pull) or subscription (push) |
Typical hospital use |
Radiology, cardiology imaging, pathology | Lab results, ADT events, pharmacy orders, vitals from bedside devices |
Patient-facing apps, clinical decision support, third-party integrations |
Regulatory mandate |
Industry standard for imaging by practice | Required by most interface specifications |
Required by 21st Century Cures Act for patient access APIs |
Relationship to Epic |
Epic receives DICOM via PACS integration | Epic Bridges processes HL7 v2 inbound/outbound |
Epic exposes FHIR R4 endpoints via Epic on FHIR |
DICOM, HL7 & FHIR: When to Use Which Standard
The standard is determined by what type of data you’re moving and where it needs to go:
Medical images or imaging metadata: DICOM
No hospital imaging workflow runs on HL7 or FHIR for the actual image payload.
Clinical events from older systems: HL7
The interface is point-to-point, typically through an HL7 integration engine like Decode Health by Folio3, Mirth Connect, or InterSystems HealthShare.
New or patient-facing apps/modern REST-capable devices: FHIR
It’s where new development is heading, and it’s what the Cures Act mandates for patient data access.
How DICOM, HL7 & FHIR Work in a Single Data Flow
These standards coexist in every hospital, each handling a different part of the same clinical workflow.
- A radiologist orders a CT scan that originates in Epic and moves to the radiology information system as an HL7 v2 ORM message.
- The CT scanner performs the scan and stores the images as DICOM files in the PACS.
- The radiologist reads the study in the PACS viewer and dictates a report, which returns to Epic as an HL7 v2 ORU message containing the results.
- Later that evening, the patient opens MyChart on their phone and views the radiology report through a FHIR API call.
One clinical event, all three standards are used. Each handles the segment of the workflow it was built for.
Check out our Case Study: HipLink
Which Standard Carries Which Device Data Into an EHR
Medical device integration projects fail most often at the standard-selection stage. Teams assume every device should connect through FHIR because it’s newer, or they try to route imaging data through HL7 interfaces that were never designed for it.
The mapping is more straightforward than it seems once you sort devices by data type:
- Imaging devices (CT scanners, MRI machines, ultrasound systems, digital X-ray units, endoscopy cameras) produce DICOM output. Their data flows into a PACS, which connects to the EHR through HL7 v2 messages for orders and results. Some newer workflows use DICOMweb and FHIR ImagingStudy resources for metadata access, but the image payload itself stays in DICOM.
- Bedside and departmental devices (vital signs monitors, ventilators, infusion pumps, point-of-care lab analyzers, blood gas machines, fetal monitors) typically produce HL7 v2 output or proprietary formats that a medical device integration gateway translates into HL7 v2. These send ADT, ORU, or device observation messages to the EHR through an integration engine.
- Wearables and patient-facing devices (continuous glucose monitors, remote blood pressure cuffs, pulse oximeters used at home, cardiac event monitors paired with a smartphone app) increasingly connect through FHIR. The device’s companion app acts as the FHIR client, writing Observation resources to the EHR’s FHIR endpoint, often using SMART on FHIR for authorization.
- Hybrid devices are becoming more common. A portable ultrasound might store images in DICOM format but transmit device-level metadata (battery status, usage logs, calibration data) through a REST API mapped to FHIR resources. These dual-standard devices need an integration layer that handles both protocols.
Epic Integration with Folio3 Digital Health
Epic has shown dominancy in the healthcare market and there is a huge demand to connect it to third party apps/devices and legacy software. This is where Epic Vendor Services members like Folio3 Digital Health make a difference. Our expertise build stronger FHIR-standard solutions through Epic Integration Services. Epic device integrations are typically a six-figure investment; however, Folio3 Digital Health’s Epic Integration Services offer pre-built connectors that reduce the spend significantly.
Closing Note
DICOM, HL7, and FHIR are not competing standards. They solve different interoperability challenges within the same healthcare system. DICOM manages medical imaging, HL7 continues to standardize clinical messaging in most hospitals, and FHIR enables modern applications, connected devices, and patient-facing experiences.
Successful medical device integration depends on selecting the right standard for the right type of data. As healthcare organizations expand connected care, remote monitoring and AI-powered diagnostics, with the use of AI, understanding how DICOM, HL7, and FHIR work together becomes increasingly important.
Frequently Asked Questions
What is interoperability in healthcare?
Interoperability in healthcare is the ability of different systems, devices, and applications to exchange data and use it in a coordinated way. HIMSS defines four levels:
- Foundational (system-to-system transport)
- Structural (standardized message format)
- Semantic (shared meaning of the data)
- Organizational (governance and policy alignment)
What is the difference between FHIR and HL7?
FHIR is a product of HL7 International, the same standards body that created HL7 v2. HL7 v2 uses pipe-delimited messages pushed between systems over persistent TCP connections. FHIR uses JSON-based resources accessed through RESTful HTTP APIs. HL7 v2 is event-driven (something happens, a message fires). FHIR supports both event-driven subscriptions and on-demand queries.
Is HL7 v2 being replaced by FHIR?
No. HL7 v2 interfaces are too embedded in hospital infrastructure. Labs, pharmacy, radiology, and bedside devices all depend on them. New integrations and patient-facing use cases get built on FHIR while existing HL7 v2 interfaces keep running. Most hospitals run both standards in parallel today.
Does DICOM work with FHIR?
Yes. The IHE (Integrating the Healthcare Enterprise) profiles define how DICOM imaging studies can be referenced through FHIR resources, specifically the ImagingStudy resource. DICOMweb, the HTTP-based version of DICOM networking, pairs well with FHIR architectures. The image data stays in DICOM format while FHIR provides the metadata layer that makes imaging studies discoverable alongside other clinical data.
What standard do wearable medical devices use?
Most consumer and clinical wearables that connect to EHR systems (glucose monitors, remote BP cuffs, cardiac monitors) use FHIR through the device’s companion app. The app writes Observation resources to the EHR’s FHIR endpoint. Some clinical-grade wearables still use HL7 v2 through a device gateway, especially in inpatient settings. At the transport layer, many Bluetooth-connected devices use IEEE 11073, with a gateway translating that data into FHIR or HL7 for the EHR.
About the Author
Abdul Moiz Nadeem
Abdul Moiz Nadeem specializes in driving digital transformation in healthcare through innovative technology solutions. With an extensive experience and strong background in product management, Moiz has successfully managed the product development and delivery of health platforms that improve patient care, optimize workflows, and reduce operational costs. At Folio3, Moiz collaborates with cross-functional teams to build healthcare solutions that comply with industry standards like HIPAA and HL7, helping providers achieve better outcomes through technology.
