FHIR mapping for MRI reports: a step-by-step setup

Quantitative MRI can produce a remarkably precise description of tissue, lesion burden, perfusion, diffusion, cortical thickness, or regional volume, yet much of that precision is lost when the result reaches the clinical record as a paragraph of dictated text. A radiologist may measure a value in a structured report, an algorithm may calculate it from a defined region of interest, and a clinician may still receive only a sentence that cannot be searched, compared longitudinally, or connected reliably to the original image frames.

This is the practical problem behind MRI quantitative reports and HL7 FHIR integration. The task is not to move pixels from a PACS into an EHR, nor to make FHIR replace DICOM. DICOM remains the principal language of imaging objects and the repository layer for medical image data. FHIR provides a clinical exchange model around those objects: orders, study metadata, observations, reports, terminology, and links back to the relevant images.

The distinction matters because a successful integration preserves two kinds of truth at once. The image must remain available in its native diagnostic context, while the measured finding must become usable as a discrete clinical observation. This shift allows quantitative MRI to participate in the patient’s longitudinal trajectory rather than remaining confined to a single workstation or a static report.

The architecture of a FHIR-enabled MRI workflow

A useful implementation begins with the clinical sequence rather than with the interface engine. The scan is ordered, performed, interpreted, and delivered. Each stage has a different information requirement, and FHIR resources should reflect that progression instead of being treated as interchangeable containers.

A typical workflow includes:

1. ServiceRequest captures the initial order for the MRI examination. It can carry the requested procedure, clinical indication, priority, subject, and ordering context.

2. ImagingStudy records the performed imaging study and its metadata, including identifiers, modality information, series, instances, and references to the DICOM environment.

3. Observation represents an individual clinical or quantitative finding, such as a lesion volume, ADC measurement, hippocampal volume, perfusion value, or regional cortical thickness.

4. ImagingSelection identifies the particular image frames, regions of interest, or observation nodes associated with a finding when the implementation supports that level of linkage.

5. DiagnosticReport assembles the interpreted findings for clinical delivery and references the relevant observations and imaging study.

6. Composition, where used, provides a structured or rendered clinical document that presents the report in a form suitable for the EHR or downstream document workflow.

The relationship between these resources is more important than any individual resource in isolation. A DiagnosticReport without usable Observation references can preserve a readable conclusion while losing machine-readable measurements. An Observation without a connection to the ImagingStudy can become difficult to interpret when several scans exist for the same patient. An ImagingStudy without a clear report association leaves the EHR with acquisition metadata but little clinical meaning.

FHIR should make the measurement easier to find without making the image harder to verify.

The implementation must also make an early decision about the FHIR release. HL7 FHIR R4 and R5 are both relevant to current imaging integrations, but a production environment cannot treat them as abstractly interchangeable. Resource profiles, supported elements, terminology behavior, and vendor capabilities may differ across the local EHR, PACS, VNA, interface engine, and clinical application.

Before mapping begins, document the target version and the systems that will consume the output. The question is not simply whether an endpoint accepts FHIR. It is whether that endpoint can process the particular resources, references, terminology, and imaging links that the MRI workflow produces.

Mapping DICOM Structured Reporting to FHIR resources

For quantitative MRI, DICOM Structured Reporting is usually the most valuable source for the mapping because it preserves measurements in a structured form rather than embedding them in an unparsed narrative. DICOM TID 1500, the Measurement Report template, is especially relevant to quantitative imaging workflows because it can represent measurement groups, coded concepts, numerical values, units, method information, and references to images or regions of interest.

The FHIR mapping should begin with the DICOM SR content tree and proceed outward toward the clinical resources. In practice, this means identifying what the SR actually contains before deciding how the EHR should see it.

A measurement may include several distinct components:

• The measured concept, such as lesion volume or mean diffusivity.
• The numerical value and unit.
• The anatomical site or target structure.
• The method, sequence, algorithm, or acquisition context.
• The subject of the measurement.
• The image, frame, segmentation, or region of interest to which the value refers.
• The relationship between the measurement and other findings in the same report.

These components should not be flattened prematurely. A value such as 1.24 is clinically incomplete unless the receiving system knows whether it represents milliliters, square centimeters, a diffusion coefficient, a standardized score, or another quantity altogether. It also needs to know what was measured and under which imaging or analytical context.

The DICOM SR to FHIR Resource Mapping Implementation Guide provides standardized rules for converting DICOM SR measurements into FHIR Observation and ImagingSelection resources. That guide is valuable precisely because it addresses the semantic gap between the DICOM SR content tree and FHIR’s resource model, rather than leaving every institution to invent its own translation.

A practical mapping table might look like this:

The conversion itself should be deterministic and auditable. If a DICOM SR measurement becomes an Observation, the interface should retain enough provenance to explain where that Observation came from, which study generated it, and whether any transformation occurred along the way. This is particularly important when the value later appears in a research database, a clinical decision support service, or a longitudinal neuroimaging dashboard.

Manual re-entry is the weak point to eliminate. When radiologists or analysts dictate quantitative values into free text after reviewing a structured measurement, transcription errors become possible, units can be omitted, decimal precision can change, and the connection to the original image may disappear. Mapping DICOM SR measurements directly to FHIR Observations reduces those risks by preserving the structured source through the interface layer.

That does not mean every DICOM SR can be transferred without interpretation. Enterprise environments often contain older studies, vendor-specific extensions, inconsistent coding, and proprietary private tags. The mapping strategy must define how unsupported or ambiguous elements are handled. A safe implementation should distinguish between a value that has been mapped successfully, a value retained only in the original DICOM object, and a value that requires human review.

Structuring quantitative observations with terminology

A FHIR Observation is not simply a numerical field with a label attached. It is a clinical statement, and its meaning depends on coded concepts, units, reference ranges, interpretation, anatomical context, and links to the study that produced it.

For quantitative MRI, terminology decisions should be made before production data begins to flow. LOINC and SNOMED CT can provide the coding framework for observations and clinical concepts, but the local implementation still has to decide how specific the codes need to be and how they will be governed over time.

Consider the difference between these two representations:

• A text value stating that a lesion measures 18.6 milliliters.
• A coded Observation identifying lesion volume, carrying the numerical value and unit, linking to the relevant study, and pointing to the image selection or region of interest.

Both may appear readable to a clinician. Only the second is readily available for a query that compares lesion volume across time, triggers a review of a trajectory, or supplies a research cohort definition.

The most useful Observation design usually answers several questions together:

• What was measured? The coded observation concept should be unambiguous.
• What is the value? Store the numerical result in the appropriate FHIR value type.
• In what unit? Use a recognized unit representation rather than relying on prose.
• Where was it measured? Record the anatomical site, laterality, or target structure where applicable.
• How was it measured? Preserve method, algorithm, sequence, or device context when clinically relevant.
• Which study produced it? Link the Observation to the ImagingStudy or DiagnosticReport.
• Can the source image be opened? Use an ImagingSelection reference when the workflow supports frame- or region-level linking.
• Is the result interpreted? Store interpretation separately from the raw value so the original measurement is not overwritten by a clinical judgment.

This separation is important in translational research. A quantitative value may be compared with a prior scan, normalized against a reference cohort, or reinterpreted as a patient’s cognitive reserve changes over time. If the raw measurement and the interpretive layer are fused into one sentence, later analysis becomes dependent on natural-language extraction and local reporting habits.

Units, reference ranges, and derived values

MRI measurements often look objective because they are numerical, but the number alone does not guarantee comparability. A volume may be derived from a segmentation algorithm. A diffusion metric may depend on preprocessing choices. A regional brain measure may be expressed as an absolute value, a normalized value, or a standardized score. The FHIR representation should make those distinctions visible enough for the receiving system to avoid comparing unlike quantities.

Derived values deserve particular care. If an application calculates a percentile, asymmetry index, or change from baseline after the DICOM SR is created, the derived Observation should not replace the source measurement. It should reference or remain logically associated with the original result, with method and provenance captured according to the capabilities of the implementation.

This is where the difference between clinical delivery and research reuse becomes clear. A radiologist may need a concise report for immediate care. A neuroscience study may need every measurement, unit, anatomical label, algorithm version, and acquisition parameter needed to reconstruct the analytical context. A well-designed mapping does not force the clinical report to become unreadable, but it prevents the underlying structured information from being discarded.

Connecting ImagingStudy and DiagnosticReport to clinical context

The FHIR ImagingStudy resource is often described as the bridge between FHIR and DICOM, but its role is more specific: it describes the imaging study and provides the metadata needed to locate or understand the DICOM content. It is not a replacement for the PACS, VNA, or DICOM repository, and it should not be treated as a container for the binary pixel data itself.

The ImagingStudy becomes clinically useful when it is connected to the order, report, observations, and patient context. The ServiceRequest explains the reason for the examination. ImagingStudy confirms what was performed. DiagnosticReport communicates the interpreted result. Observations expose the atomic findings. Together, these resources provide a coherent path from clinical question to measured evidence to conclusion.

The DiagnosticReport resource acts as a container for diagnostic findings and can reference atomic clinical values formatted as FHIR Observation resources or linked DICOM image instances. That container function is particularly important for quantitative MRI because the report may contain several measurements that should remain individually addressable.

A report for a neuroimaging examination could contain:

• A narrative impression intended for immediate clinical reading.
• A set of Observations representing volumetric, diffusion, perfusion, or lesion measurements.
• A reference to the ImagingStudy that contains the acquisition metadata.
• ImagingSelection references identifying relevant frames, segmentations, or regions.
• A status indicating whether the report is preliminary, final, amended, or otherwise governed by the local reporting workflow.
• A Composition resource when a fully formatted clinical document must be presented or stored in a particular document-oriented form.

The image link is not a decorative feature. Consider the implications of a longitudinal brain volume declining across several examinations. The trend may be clinically meaningful, but the person reviewing it may need to inspect the sequence quality, registration, segmentation boundary, or specific region from which the value was calculated. A machine-readable Observation is strongest when it leads back to the evidence rather than presenting itself as an isolated fact.

FHIR imaging workflows commonly use the following order of emphasis:

1. Start with the clinical order and patient identity.

2. Resolve the performed study and its DICOM identifiers.

3. Parse the structured report and identify measurement groups.

4. Create or update Observations with coded concepts, values, units, and context.

5. Link those Observations to the ImagingStudy and, where possible, to an ImagingSelection.

6. Assemble the DiagnosticReport and expose the result to the EHR.

7. Preserve the original DICOM SR and maintain provenance for audit and reprocessing.

The exact order of technical operations may vary, but the clinical relationships should remain stable. An interface engine may process the SR before the final report is signed, or it may wait for a completed DiagnosticReport. Either approach can work if status handling is explicit and downstream users can distinguish preliminary information from a finalized interpretation.

A step-by-step implementation approach

The most reliable projects are not built by starting with a single impressive quantitative MRI use case and trying to generalize later. They begin with a narrow measurement family, define its semantics, and expand only after the entire pathway has been tested from acquisition to clinical display.

1. Define the source of truth

Identify where the measurement is generated and which object is authoritative. It may be a DICOM SR produced by the scanner, a post-processing platform, an AI algorithm, or a research pipeline that writes results into the imaging archive.

Document whether the source uses TID 1500, another DICOM SR structure, private tags, or a vendor-specific representation. If the measurement exists only in a proprietary database or a rendered PDF, the integration problem is different from a standard DICOM SR to FHIR mapping.

2. Establish patient and study identity

Patient identity errors are more consequential than a failed field mapping because they can associate a valid measurement with the wrong clinical record. The implementation should define how patient identifiers, accession numbers, study instance UIDs, series instance UIDs, and report identifiers are reconciled across the PACS, VNA, RIS, EHR, and interface engine.

The ImagingStudy should remain anchored to the performed examination, not merely to the order. This distinction becomes essential when an order is rescheduled, partially performed, repeated, or supplemented by additional sequences.

3. Map the SR content tree

Do not begin by extracting only the final numerical values. First identify the structure of the SR: measurement groups, coded concepts, spatial references, anatomical sites, units, method descriptors, and relationships between findings.

A mapping worksheet is useful at this stage, particularly for recording:

• The original DICOM concept and code.
• The intended FHIR Observation code.
• The value type and unit.
• The anatomical and laterality fields.
• The relevant ImagingStudy reference.
• The possible ImagingSelection representation.
• The handling rule for missing, unsupported, or ambiguous content.

This exercise exposes semantic gaps before they become production defects.

4. Choose terminology and local governance

Map observation concepts to suitable LOINC or SNOMED CT representations where applicable, and document local extensions when no adequate standard concept exists. Avoid creating multiple local labels for the same measurement simply because different applications use different names.

Terminology governance is not a one-time task. New sequences, algorithms, and research-derived measures will appear. The organization needs a process for approving new codes, retiring obsolete mappings, and communicating changes to clinical and analytical consumers.

5. Create the Observation layer

Each clinically meaningful quantitative result should become an Observation with a value, unit, subject, status, and context appropriate to the use case. Preserve the relationship to the DiagnosticReport and ImagingStudy.

Do not force every detail into a single Observation if the result contains meaningful components. Depending on the implementation, related measurements may need grouping, component elements, or linked observations. The design should remain readable to clinical systems while retaining the structure required for later comparison.

6. Add image-level references

Where the DICOM SR identifies frames, regions of interest, segmentation objects, or other source evidence, map that relationship into ImagingSelection or the supported local imaging reference pattern.

The receiving EHR may not be able to display a region-level selection immediately. That limitation should not justify deleting the link. Preserving the reference allows a future viewer, research application, or imaging worklist to use it even if the first clinical consumer displays only the report.

7. Assemble the DiagnosticReport

The DiagnosticReport should provide the clinical frame around the measurements. It can reference the Observations, link to the ImagingStudy, and carry the final narrative interpretation.

If the health system relies on document-centric workflows, consider how Composition will present the formatted report without duplicating or contradicting the structured Observation layer. The rendered document is useful for human reading; the discrete resources are necessary for interoperability and computation.

8. Test with clinical failure modes

A mapping that works for one clean study is not yet an enterprise workflow. Test repeated examinations, amended reports, missing sequences, multiple accession numbers, different laterality, partial measurements, algorithm version changes, and studies that contain more than one quantitative analysis.

Also test the human experience. Can a radiologist understand where a value came from? Can a neurologist compare it with prior results? Can a researcher distinguish a true biological change from a change in processing method? Can an engineer trace an Observation back to the source DICOM object?

These questions reveal whether the integration preserves the patient’s trajectory or merely creates a collection of technically valid resources.

Enterprise PACS, cloud deployment, and security constraints

The interface between DICOM systems and FHIR services is rarely a single direct connection. In an enterprise imaging environment, the pathway may include a PACS, VNA, AI orchestration platform, report repository, interface engine, terminology service, EHR integration layer, and cloud-based MRI viewer. Each additional component introduces another identity boundary and another place where provenance can be weakened.

DICOM should remain the imaging repository and transport foundation for the study objects, while FHIR communicates the clinical and structured measurement context. A cloud viewer may use FHIR references to identify the patient and study, then retrieve the relevant DICOM content through an authorized imaging service. The implementation should not imply that FHIR itself stores or replaces the full binary study.

Security and privacy requirements extend beyond the obvious removal of patient names. MRI data de-identification may need to address DICOM headers, private tags, embedded identifiers, burned-in annotations, derived objects, and linkage tables used for re-identification in approved research workflows. A FHIR resource can carry identifying data even when the DICOM object has been de-identified, so the two layers must be governed together.

Access controls should reflect clinical roles and the sensitivity of the data. A research analyst may need coded measurements and limited metadata, while a radiologist may need the full image study and report context. Audit trails should capture access to both the FHIR resources and the underlying DICOM objects, particularly when an Observation opens a path to a specific image selection.

Interoperability also depends on operational discipline. HL7 FHIR is not a universal guarantee that every receiving EHR will ingest every resource automatically. Many environments still require an intermediary FHIR interface engine, adapter, profile configuration, or local transformation service. The implementation should therefore state clearly which resources are exchanged, which profiles are supported, which references are resolvable, and what happens when a consumer cannot process a structured measurement.

The role of HL7 FHIR and DICOM together

The strongest architecture is complementary:

• DICOM preserves images, series, instances, acquisition context, and structured imaging objects.
• FHIR makes orders, findings, observations, reports, and clinical references available across healthcare applications.
• Terminology services help ensure that the same quantitative concept is not represented by conflicting labels.
• Interface engines and adapters manage version differences, routing, transformation, and local system constraints.
• PACS and VNA platforms remain responsible for reliable imaging storage and retrieval.

This division is not a compromise. It reflects the different problems each standard was designed to solve. Trying to use FHIR as a complete image archive would obscure the strengths of DICOM. Treating DICOM SR as sufficient for EHR integration would leave clinical applications without a consistent resource model for discrete observations and reports.

What a durable implementation preserves

A durable DICOM-to-FHIR mapping is more than a successful conversion of fields. It preserves meaning across time, systems, and clinical roles.

For every quantitative MRI result, the receiving environment should be able to determine:

• Which patient and examination produced the result.
• Whether the measurement is preliminary or final.
• What biological or anatomical concept was measured.
• Which unit and method apply.
• Whether the value is raw, normalized, or derived.
• Which images, frames, or regions support the finding.
• Which report presents the measurement in clinical context.
• Whether the result can be compared safely with a prior examination.
• What transformation occurred between the DICOM source and FHIR resource.
• How the value should be handled if a downstream system does not support the full structure.

These details are easy to underestimate because a single value can look self-explanatory on a screen. It is not self-explanatory when it enters a longitudinal record months later, after the acquisition protocol has changed or a different software version has generated the new result.

The real test of integration is not whether the number arrives in the EHR, but whether its biological meaning survives the journey.

This shift allows quantitative MRI to move beyond a one-time reporting artifact. A structured observation can support monitoring of subtle degradation, comparison across a disease trajectory, and more careful use of cognitive reserve or regional vulnerability as part of clinical research. It can also help software developers build tools that surface changes without pretending that one biomarker can diagnose or cure a complex neurological disease.

The final design should therefore be judged in clinical time, not only at the moment of interface validation. Can the report be understood today? Can the measurement be found next year? Can the original image evidence still be reviewed when the result becomes unexpected? Can a researcher distinguish biological change from a change in protocol or algorithm?

If the answer is yes, FHIR mapping has done more than modernize message exchange. It has created a traceable bridge between the contrast seen on an MRI scan, the structured measurement extracted from that contrast, and the human decision that ultimately depends on it.