HL7 Europe Imaging Report R5
0.1.1-build - ci-build 150

HL7 Europe Imaging Report R5, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.1-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-eu/imaging-r5/ 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 are obligations on data element utilizied.

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. Without a more detailed categorization of system types, no generic obligations can be defined for those roles.

Consumer actor(Patient or Healthcare Professional) Accessor Processor DisplayerSearch reportsAccess reportAccess imaging study *Extract & process dataRender static reportPopulate dynamic UITranslate language of coded elementsTranslate narrative *Create report ProducerOut of Scope for this IGThis is addressed in the IHE MADO profileOut of Scope for this IGAccessor, Processor, and Displayerare grouped as one Consumer actorfor obligations in this IG. direct access(e.g., unique identifier) «include» «extend» «extend» «extend» «extend» «extend» «extend» «extend»
Figure: EHDS Imaging Report Functional Use Cases


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.

At present, these obligations are defined directly in this IG. In the future, they are expected to be defined in the Xt-EHR logical models and inherited by this IG’s resources and elements.

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

Imaging report and relaed 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 a instance that conforms to this specification also conforms to the IHE-IDR specification. But as both specifications are still under development slight unconformities are inevitable. In order to mitigate these, the team working on the HL7eu Imaging Report is in regular contact with 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 a 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.

ClinicianClinicianDocumentAccess ProviderDocumentAccess ProviderImaging SourceImaging Sourcesearch imaging reports<report summeries>Inspect the summaries and select one to view in detail.request report<report>Review the report and determine if the associated images are needed.search for manifestations<manifest summaries>Inspect the summaries and select one to view in detail.request manifest<manifest>Review the manifest and determine what images are needed.wado-rs request<images>Review the images.
Figure: Use case describing report and manifest use


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 image/serie 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.