FHIR gets introduced often enough as “the new HL7” that an engineer new to healthcare integration can be forgiven for treating it as a straight upgrade: same job, newer format. It isn’t. FHIR is a resource-and-REST model for exchanging clinical data, closer in shape to a modern web API than to HL7 Version 2. V2 is message-based, and HL7 calls it one of its most widely adopted standards, prominent in inpatient settings throughout the world.
For an imaging product team, the practical question is narrower than “do we support it.” It’s where FHIR’s boundary with DICOM actually sits, because DICOM, not FHIR, moves the pixels. Get that boundary right and a FHIR integration scopes down to a specific, bounded piece of work. Get it wrong and it looks like an open-ended commitment to a second standards stack.
What a FHIR Resource Actually Is
Every piece of exchangeable content in FHIR is a resource. The specification states it directly: “The basic building block in FHIR is a Resource.” A resource is a structured, typed unit of clinical or administrative data, built from reusable datatypes and carrying a common set of metadata: an id, a version, and who last changed it. Most resource types also pair a human-readable narrative with those structured fields, an inheritance from DomainResource that every resource except Bundle, Parameters and Binary picks up.
For an imaging integration, the resources that come up repeatedly are a small set:
- Patient: who the study is for
- Encounter: the visit or episode the study belongs to
- ServiceRequest: the order that triggered the study
- ImagingStudy: the study itself
- DiagnosticReport: the signed report on that study
- Observation: a discrete finding
None of these resources describes pixel data directly. They describe the clinical facts around it: who it’s for, what was ordered, what happened, and what was found. FHIR’s modeling philosophy is to build a base set of resources that, alone or combined, cover most common use cases. A built-in extension mechanism covers the rest, rather than every clinical scenario getting its own bespoke structure.
How Resources Reference Each Other
A single resource is rarely useful alone. The specification is explicit about why: “Many of the defined elements in a resource are references to other resources. Using these references, the resources combine to build a web of information about healthcare.” An ImagingStudy references a Patient (or occasionally a Device or Group) as its subject, and a DiagnosticReport can reference the ImagingStudy it was written against.
Two details about how those references behave matter for an integration built around them. First, a reference points one direction, from the resource that holds it to the resource it names. The reverse relationship exists logically but isn’t stored on the target: finding every DiagnosticReport that references a given ImagingStudy means searching for it through the API, not reading it off the study.
Second, references aren’t transitive. If a Procedure references a Patient as its subject and a Condition as its reason, nothing guarantees the Condition shares that subject. Each resource establishes its own facts directly, which keeps a graph of linked resources predictable but also means context never flows automatically from one resource to the next.
FHIR’s RESTful API Model
FHIR resources are almost always exchanged over a defined RESTful API, built around a consistent set of operations applied to each resource type. A client can read a resource, search a resource type by filter criteria, create a new one, update or patch an existing one, and retrieve its version history.
A server also exposes a capabilities interaction, and the specification requires it: “Servers SHALL provide a Capability Statement that specifies which interactions and resources are supported.” That document is the actual, checkable answer to “does this system support FHIR,” as opposed to a claim on a website. It states which resource types a server exposes, which operations it implements for each, and which FHIR version it is running.
Worth being precise about the “RESTful” label itself. FHIR describes its own conformance plainly: “FHIR is described as a ‘RESTful’ specification based on common industry level use of the term REST.” In practice the core specification supports Level 2 of the REST maturity model: resource-oriented URLs and standard HTTP verbs, rather than the hypermedia-driven Level 3 some web APIs aim for. REST also isn’t the only way to move FHIR content, since messaging and document paradigms exist too, but for most real integrations “a FHIR integration” means this RESTful API.
FHIR and HL7 Version 2: Two Standards Doing Different Jobs
HL7 Version 2 is not going away, and FHIR did not arrive to replace it overnight. V2 is event-driven and message-based: a sending system pushes a message built from reusable segments to a receiving system to communicate an event, an admission, an order, a result. The specification’s own comparison says v2 “uses messages composed of re-usable segments to communicate healthcare-related information between a sending and receiving system as well as to invoke particular behavior (patient transfers, lab orders, etc.)”
FHIR’s resources look superficially similar to v2 segments; both are reusable chunks of structured data. The difference is addressability: a v2 segment only exists inside the message that carries it and can’t be independently read, updated, or queried. A FHIR resource is a first-class object with its own identity, URL, and history, reachable directly through the REST API regardless of which message created it. That is a meaningful shift for anything beyond one-way delivery, such as an EHR-facing app that looks up a study on demand instead of waiting for the next message in a feed.
In practice, both standards coexist inside the same deployment more often than either replaces the other. HL7 v2 typically carries the order and scheduling feed that gets an exam into a RIS in the first place, the step covered in Where a Radiology Information System Ends and PACS Takes Over. FHIR shows up downstream of that feed, giving a different consumer, a patient portal, a referral network, a mobile app, a resource-oriented way to reach the same clinical facts without parsing a message stream.
Where FHIR and DICOM Meet: ImagingStudy Is the Seam
The resource that actually connects FHIR to imaging is ImagingStudy, and its own definition states the relationship outright: “Representation of the content produced in a DICOM imaging study.” The resource mirrors DICOM’s own structure: a study made of one or more series, each series made of instances. It also maps its elements to the same DICOM attributes an imaging system already carries, so a study’s identifiers translate cleanly between the two standards.
What ImagingStudy does not do is hold the images. The specification is direct about that limit: “The DICOM instances are not stored in the ImagingStudy resource; use of a DICOM WADO-RS server or other storage mechanism is needed.” The resource carries an endpoint reference pointing at wherever the pixel data actually lives; it exists to describe a study, not to contain it.
The specification is equally direct about the other side of the boundary: “ImagingStudy provides access to significant DICOM information but will only eliminate the need for DICOM query (e.g., QIDO-RS) in the simplest cases.” Beyond a simple lookup, a client still needs the actual DICOM retrieval mechanism behind the resource.
That mechanism is worth naming, because it’s easy to conflate with FHIR’s REST API and it isn’t the same thing. DICOM defines its own set of RESTful services, and the body that maintains DICOM describes them plainly: “DICOMweb™ is the DICOM Standard for web-based medical imaging. It is a set of RESTful services, enabling web developers to unlock the power of healthcare images using industry-standard toolsets.”
QIDO-RS queries, WADO-RS retrieves, STOW-RS stores, all separate from FHIR’s REST API and running on the DICOM side of the seam. A single integration can involve two RESTful APIs at once: FHIR’s for the clinical metadata, DICOMweb’s for the actual DICOM content. Mistaking one for the other is a fast way to misjudge how much work an integration takes.
An ImagingStudy resource can also point retrieval at a rendered image rather than a native DICOM instance, the option a web or mobile viewer typically calls for a quick preview.
Where FHIR and DICOM Stay Separate
The imaging pipeline itself stays on the DICOM side, from the scheduled procedure step through acquisition, storage, retrieval and display, with no FHIR involvement at any step. Five DICOM services carry that work: Modality Worklist and Modality Performed Procedure Step around acquisition, then C-STORE, Query/Retrieve and Storage Commitment. Presentation states and structured measurement reports belong to the same side of the line but are stored objects rather than services, defined in DICOM as information object definitions. What a PACS Actually Does, Explained for Product Teams covers that pipeline end to end, and none of it changes because a FHIR-facing system exists downstream.
For a product whose job is storing, distributing and displaying studies, that split bounds what a FHIR integration touches: publishing or consuming ImagingStudy, and often DiagnosticReport, where imaging meets the broader clinical record. The modality acquires the study and sends it; the PACS receives it as a C-STORE service class provider and serves it back on query. FHIR describes the study for whatever clinical system needs to know it exists, not the DICOM plumbing that moves it.
Profiles and Implementation Guides: the Base Spec Is Rarely the Whole Answer
The base FHIR specification is deliberately broad, and it says so about itself. It is “a common platform or foundation on which a variety of different solutions are implemented,” one that “usually requires further adaptation to particular contexts of use.” That adaptation happens through profiles and implementation guides, layered broad to narrow. The cascade runs from international base agreements to national base guides (US Core for the US market), then workflow-specific profiles (an IHE profile like MHD), down to a vendor’s or institution’s own guide.
The consequence: “supports FHIR” without naming an implementation guide is close to meaningless as a scoping statement. Two servers can both claim base support for Patient and still fail to interoperate, because a national or workflow-specific profile is what pins down which fields are required and which terminology bindings apply. The question to ask is which implementation guide a counterparty claims conformance to, not just which base version.
Version Drift: a Practical Problem, Not a Theoretical One
FHIR has shipped several major releases since its first normative content. Release 4 (R4) arrived on December 27, 2018 as that first normative content, with a technical correction, 4.0.1, following in October 2019. US Core, the national base guide for the US market, is still published against R4.
Release 4B followed in 2022 as a staging release of modifications in specific areas, leaving R4’s normative resources alone. Release 5 (R5) followed in March 2023 with 4,157 change requests behind it, 1,896 of them substantive, including renamed and removed resources. R5 is labeled trial-use, and a further release is already in ballot.
The practical result: two systems can both legitimately claim “FHIR support” while running materially different versions of the same resource, with different required elements and structures. A Capability Statement’s declared FHIR version is one of the first things worth checking before assuming two systems interoperate cleanly. A commitment to a guide like US Core carries an implicit version commitment with it. Version drift isn’t a one-time migration problem the way it can be with an internal system; it’s an ongoing fact of integrating with partners who move on their own schedule.
What This Means for a Product Team Scoping FHIR Work
Three questions do most of the work before FHIR shows up in a scope:
- Which FHIR version, and which implementation guide, does the counterparty claim conformance to?
- What does their Capability Statement actually declare, resource by resource, rather than what their integration page claims in general terms?
- Where does the DICOM and FHIR boundary sit here: exposing ImagingStudy metadata at the edge while DICOM handles storage and retrieval underneath, the common case? Or consuming and producing other FHIR resources inside an ordering or reporting workflow, a materially larger scope?
The published native DICOM surface for EBM mAIn PACS® is C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. That is the layer that moves and stores a study. FHIR is not part of what EBM offers in this market today. A partner whose FHIR-facing EHR or portal needs to reach a study stored this way would generate an ImagingStudy resource and stand up a Capability Statement, work that sits on top of that DICOM layer.
Getting this boundary right before FHIR appears in a statement of work keeps a bounded integration bounded. That means a named resource, a named implementation guide, and a clear line where DICOM’s job ends and FHIR’s begins.