HL7 Europe Imaging Report R4, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-eu/imaging-r4/ and changes regularly. See the Directory of published versions

Use Cases

This page explains the use cases supported by this specification, describes the different actors that participate, and how obligations on data elements are utilized.

Use cases based on actors

A set of actors and use cases has been identified as the minimum functional scope needed to support the EHDS Imaging Report specification. These use cases are shown in the figure below.

The diagram also shows how these use-case actors relate to the system actors described on the actors-and-transactions.html page. Note that the displayer and processor roles are grouped into a single consumer actor, because user-interface display requirements and constraints are highly implementation-specific. As the variety of consumer needs makes it very difficult if not impossible to determine a generic rule for this, no generic obligations can be defined for those roles.

System actors

• Producer: creates and publishes imaging reports using clinical and technical source data.
• Accessor: searches and retrieves reports for patients or healthcare professionals.
• Processor: extracts and processes structured and narrative report content for downstream use.
• Displayer: presents imaging reports to end users in static or dynamic user interfaces (for images display refer to IHE-MADO).

Use-cases details

Producer use cases

• Create report: needs to verify patient and date/time context, use available source data (including DICOM header information when applicable), consider the clinical question/reason, produce the report in the assigned system and make it available to the EHDS ecosystem.

Accessor use cases

• Search reports: search for reports using patient and report criteria in both patient and healthcare-professional workflows. Most search parameters are shared, but patients are limited to their own studies, while healthcare professionals can search across patients using identification parameters.

Processor use cases

• Extract & process data: process structured findings, impressions, and other coded data; optionally analyze narrative text (for example registries, AI tools, decision support). Displaying the report on a user interface is not required.

Displayer use cases

• Render static report: display pre-rendered report formats (for example PDF, HTML).
• Populate dynamic UI: extract and present report narrative and coded sections, findings, and measurements in local UI components.

Obligations

Systems are expected to handle specific data elements according to the role (actor) they play in the EHDS Imaging Report ecosystem. In this specification, these expectations are defined as FHIR Implementation Obligations, following EHDS shared practices and are listed in the Artifacts section.

Following this guidance, for Producers SHALL/SHOULD/MAY:able-to-populate obligations are added indicating the required capability of the Producer to populate a field. For Consumers SHALL/SHOULD/MAY:process obligations are used to express what fields a Consumer is required to process. Note that no display related obligations are used and the variety of Consumers makes it very difficult if not impossible to determine a generic rule for this.

How obligations are assigned in this guide

Every element flagged as Must-Support (MS) carries an obligation. Where the Xt-EHR (EHDS) logical model defines an obligation for the mapped source element, that obligation is used; where the model defines none, this guide defines its own obligation using codes from the FHIR obligation code system. Every mandatory (1..1) element carries a SHALL:populate obligation, since a required element must be populated when its value is known.

Obligations are stored in dedicated <Resource>Obligation… profiles and are derived from the Xt-EHR mapping. When more than one source element maps to the same target element, the strongest obligation applies (SHALL > SHOULD > MAY), and the contributing Xt-EHR source elements are recorded in the obligation's documentation. This guide does not lower an obligation below the level defined by the Xt-EHR model.

Interpretation of the obligation codes

The obligation codes used in this guide are interpreted as follows:

Obligation code	Applies to	Interpretation
SHALL:populate	Producer	The producer SHALL populate the field. Every mandatory (1..1) element carries a SHALL:populate obligation — a required element cannot be optional to populate.
SHOULD:populate-if-known	Producer	If the system has access to this information it needs to populate it; it is not required to provide input means for it.
SHALL/SHOULD/MAY:able-to-populate	Producer	The producer SHALL/SHOULD/MAY be able to populate the field when the information is available/known to it. A reporting application cannot document what it does not know and is not required to source or reconstruct data it never received (e.g. prior comparisons viewed only in PACS and not communicated discretely to the RIS).
SHALL/SHOULD/MAY:process	Consumer	The consumer SHALL/SHOULD/MAY process the field (e.g. store it, act on it, or make it available to the reader).

Note that no display related obligations are used: the variety of Consumers makes it very difficult if not impossible to determine a generic display rule. Where a field is important to surface to the reader (such as the releasing organization), the expected consumer behaviour is described as narrative guidance rather than as a display obligation.

The SHALL/SHOULD/MAY:able-to-populate comes from the Xt-EHR Imaging Logical Model and is taken as is in this IG.

Imaging report and related specifications

IHE Imaging Diagnostic Report (IHE-IDR)

The IHE-IDR is a technical framework developed by the IHE Radiology Technical Committee. It aims to standardize the reporting of imaging studies and is based on the FHIR (HL7® FHIR® Standard) model, targeting the upcoming FHIR R6 release. The main target of this specification is to ease the inclusion of structured data and allow for reuse of structured data from previous reports.

The intent of this specification is to align with IHE-IDR so that an instance that conforms to this specification also conforms to the IHE-IDR specification. But as both specifications are still under development, slight non-conformities are inevitable. In order to mitigate these, the team working on the HL7eu Imaging Report is in regular contact with IHE-RAD to resolve any incompatibilities.

Imaging Manifest (IHE-MADO)

The European imaging specifications consist of the imaging manifest and the imaging report. The report represents the report as is written by the clinician. The manifest (IHE-MADO) provides a summary of the data available in the DICOM study. It is represented as a FHIR Bundle simultaneously to the imaging report. This allows it to be distributed in the same (IHE-MHD) infrastructure as is defined by EU Health Data API.

The sequence diagram presented below presents a typical use case in which both specifications are used.

The Clinician searches for documents. Select the document to inspect and downloads it.

After inspection of the document, it searches for the manifest related to the report, downloads it and determines which images/series to view.

Using the URL, the Clinician download the relevant DICOM images and renders them.

The Clinician searches for documents.

GET DocumentReference?category=http://loinc.org 85430-7&subject=Patient/1234

Select the document to inspect and downloads it.

GET <DocumentReference.content.attachment.url>

After inspection of the document, it searches for the manifest related to the report using the StudyInstanceUID identifier of the ImagingStudy.

GET DocumentReference?category=http://loinc.org 18748-4&subject=Patient/1234&identifier=<StudyInstanceUID>

The manifest is downloaded.

GET <DocumentReference.content.attachment.url>

After inspecting the information available in the study, the requested DICOM images/series are downloaded and rendered using the URL.

Bidirectional lookup between report and manifest

The same linkage model supports both directions:

• Report to manifest: start from an imaging report and query for the associated manifest.
• Manifest to report: start from a manifest and query for the associated report(s).

The primary anchors for this linkage are:

• StudyInstanceUID (study-level relation);
• accession-number (order/request-level relation).

Example reverse lookup from manifest to report using accession-number:

GET DocumentReference?category=http://loinc.org 85430-7&subject=Patient/1234&identifier=<accession-number>

Example reverse lookup from manifest to report using StudyInstanceUID:

GET DocumentReference?category=http://loinc.org 85430-7&subject=Patient/1234&identifier=<StudyInstanceUID>