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

Design Considerations

The sections in this chapter elaborate on the design considerations and decisions that drove important parts of the modelling in this guide.

FHIR representation of the report

This guide is part of the HL7 EU suite of report related implementation guides that also includes HL7 EU Laboratory Reports, HL7 EU Hospital Discharge Reports and HL7 Europe Patient Summary.

This implementation guide follows the approach taken by those specifications in that a Imaging Study Report is:

• represented by one DiagnosticReport and and Composition resource.
• the DiagnosticReport will always point to a Composition.
• the referred Composition:
  • defines the report structure, often just a single section;
  • provides a mean for assembling the report as a document (i.e. as a Bundle of type 'document')
• the document Bundle represents the legally signable report and it includes all the data defining the report.

Related to document bundles, the following guidelines are taken over:

• the document bundle SHALL include any resources that are part of the graph of resources that reference or are referenced from the composition set, either directly or indirectly (e.g. recursively in a chain)

classDiagram
    class ImDiagnosticReport
    class ImComposition
    ImDiagnosticReport --> ImComposition: composition
    ImComposition --> ImDiagnosticReport: extension[diagnosticReport-reference]

Data entrypoints

This IG describes a large set of different resources. Using FHIR search operations, there are many different ways to search for specific information.

The goal of this IG is to provide information on Imaging Reports and Imaging Studies. Although it will allow for other ways to access information, the main "data entrypoints" are the resources that represent these resources.

Each imaging study is represented by a single ImagingStudy resource.
Each imaging report is represented by a DiagnosticReport resource. There might be more than one instance of the DiagnosticReport, when the status of the report changes. All of these will have the same identifier. The DiagnosticReport points a Composition resource that holds a structured representation of the contents of the report.

classDiagram
  class ImImagingStudy{ 
    <<ImagingStudy>> 
    identifier: studyInstanceUid
  }
  class ImDiagnosticReport{ 
    <<DiagnosticReport>> 
    identifier
  }
  class ImComposition{ <<Composition>>}
  
  ImDiagnosticReport --> ImImagingStudy: study
  ImDiagnosticReport --> ImComposition: composition
  ImComposition --> ImDiagnosticReport: extension[diagnosticReport-reference]

  note for ImDiagnosticReport "entry point for report"
  note for ImImagingStudy "entry point for study"

When modelling the IG, it is assumed that information related to the report will be gathered by starting at the DiagnosticReport and information related to the imaging study from the ImagingStudy.

All information related to the report will referred to from the Composition. All important structured information used for searching will be referred to from the DiagnosticReport. The structure of the Composition is subject to change and less formal on the meaning on referred to resources. When possible, such references will be made from the DiagnosticReport.

Representing Healthcare Proffessionals

When referring to healthcare professionals, the eHN Imaging Studies and Reports guidelines include information on the professional as well as on the organization the professional is associated with (e.g. information recipient, author, resultValidator, etc.). In FHIR a healthcare professional is represented as a Practitioner. As a healthcare professional can be employed by multiple organizations, a different resource,PractitionerRole models the relationship between the healthcare professional and an organization.

classDiagram
    class SrcResource
    class ImPractitioner { 
        <<Practitioner>>
        identifier MS
        name MS
        telecom MS
        address MS
    }
    class ImPractitionerRole{ 
        <<PractitionerRole>>
        organization MS
        practitioner MS
        period MS
    }
    class ImOrganization {
        <<Organization>>
        active MS
        name MS
    }

    SrcResource --> ImPractitionerRole
    ImPractitionerRole --> ImOrganization: organization
    ImPractitionerRole --> ImPractitioner: practitioner

The source resource (SrcResource) will always point to ImPractitionerRole when referring to a healthcare professional. The ImPractitionerRole requires support for the organization and practitioner fields.

On ImPractitioner and ImOrganization the fields present to identify the healthcare professional are labeled as must support.

OPEN ISSUE: Are there requirements related to ImOrganization.period?

Actor requirements and obligations

This section describes the approach taken in the specification related to obligations placed on the different actors.

The specification recognizes the following actors:

• ImManifestProvider - provides the imaging studies manifest.
• ImReportProvider - provides the imaging studies report.

Provider obligations

The ImProvider provides the information. In this case this means that it has to provide the information defined in the eHN Guidelines that are further refined by Xt-EHR in the Xt-EHR logical model.

All data elements in the Xt-EHR model are mapped onto one or more FHIR elements (see the mapping section in the spec). In order to ensure that the provider populates these data elements, a requirement/obligation is placed on each FHIR element referred to in the mapping.

The obligation used has the following fields: | code | SHALL:populate-if-known | | actor | ImManifestProvider or ImReportProvider | | documentation | list of XtEHR paths that map on this obligation |

This means that the provider SHALL populate these fields it has the information.

Using obligations in resources

The obligation extensions will be placed in the profiles. In order to make the profiles clear and concise, for each profile with obligations, sub-profiles will be created.

The main profile will have the structural constraints. The actor specific sub-profile will only hold the obligations placed on the actors.

For ImProvider based profiles, the obligations will in the 'documentation' field, indicate the source Xt-EHR requirement the obligation was derived from.

Report and Manifest

The imaging specification has to provide access to both imaging study information and reports.

Information from the IHE cross-border-working group

Challenges associated with having a distinct manifest versus embedding manifest information in a report.

Background: Today in MCWG Recommendations, the approach to imaging study and report linkages is

• to use a linkage with metadata attributes such as Study UID, Accession Numbers (with registration ID), etc
• The Manifest Metadata includes: One Study UID, one or more Accession # and one or more Order Placer #. Report contains One or more Study UID, one or more Accession # and one or more Order Placer #.
• As a result of this approach, one may:
• Query/Search by Study UID returns all reports associated to a given Study.
• Query/Search by Accession # returns all reports and studies associated to an given (RIS) imaging request.
• Query/Search by Order Placer # returns all reports and studies associated to a given order.

Proposed Resolution of Issue: the information about the images being reported included in the report makes clinical traceability sense. However, we should not confuse identification of these images (Study UID/Series UID/Instance UID) and the referencing by location.

So far MCWG has tried to avoid inclusion of a Manifest (with locations) in a report. Why ?

Analysis:

Given that the Study manifest (that includes location of image data) always exists and is distinct from report, should we in addition allow the manifest content (especially the location information) to be copied within the report:

Pros (for only a separate Manifest document and no location information within the imaging report) :

1. A Study may exist without a related report (creating an “empty report is not a clean approach”). So having a manifest only in that case makes sense.
2. A report may interpret one or more imaging studies (in some countries it may not be allowed). Multiple Reports on the same imaging study. It could be accommodated but adds to the complexity in case of location updates.
3. The imaging study may evolve in some cases, so updates are simpler to update only the manifest (otherwise report signature becomes challenging)
4. One shall include in the report the ability to reference image instances (without location) so that there is traceability and if “policies” allow for shared image deletion, the imaging report may include references to image instance(s) that are no longer accessible with the updated manifest. Note: the use of an “IOCM object” to virtually delete the pointed image objects should be possible, but is not explicitly required. See plazn to create a CP on this)
5. The production of the imaging study (Modality/PACS) involves different technology/systems than the production of the imaging report (RIS).

Cons (for only a separate Manifest document and no location information within the imaging report):

1. In the case a report and a study are shared, accessing the report (that includes the manifest) support access in a single step. If location is only in Manifest it would require a second step to access the manifest (only if the goal is to retrieve the DICOM Instances, otherwise a server-side URL would give a single step for viewing the images).
2. It would require some alignment in term of access rights between the report and the manifest (It seems that some countries have aligned this for policy reasons and clinical use cases).

The Pros clearly outweigh the Cons.

Additional considerations

The study information is represented in an imaging-manifest. It represents the information that is stored in a PACS. The report is typically stored in the RIS and/or EHR. Separating the two concepts allows both systems to appropriately represent the data they have without being forced to include information they typically do not have access to.

In order to access the data, the URL's of the WADO/viewer endpoints are needed that provide access to the content, These URL's might change depending on the scope in which the data is accessed (within the healthcare provider, from outside the healthcare provider or cross border). During the life-cycle of an imaging study, it typically moves between different system. Starting in the main PACS and moving in and out of long term storage depending on the need. If we include the data access URL's in the report, each change might break the report signature. Placing these in the manifest prevents this and also allows for the situation where the same study data can be accessed from multiple locations.

Conclusion

Decision: There will be a imaging-manifest documenting the information typically stored in a PACS that holds the Endpoint resources with the URL's that allow access to the content.

Decision: There will be a imaging report documenting the radiology report which is not required to include the URL's to access the content.

Composition structure

One of the choices made in the IG is the structure of the Composition resource. Multiple approaches to defining the structure exists. The ones considered are:

• Leave it open for users of the implementation guide.
• Follow the structure of the presented form (rendered document).
• Follow the structure of the eHN Imaging Studies and Reports guidelines.
• Adopt the structure defined in IHE-IDR.

Linking the structure of the composition of the presented form will cause difficulties as it requires importers of such documents to understand and properly represent such structure which might place undue burden on such import process.

Consistency in rendering of radiology reports will make it easier for healthcare professionals to locate and understand the important sections. Based on that rationale, this specification will define a required structure.

Regarding the structure to support, this implementation guide taps into earlier work on that topic, i.e. IHE-IDR, and will adopt the suggested section division defined in the preliminary specification.

Linking to body-sites

THe eHN Imaging Studies and Reports guidelines requires that information is added that defines the body site of the imaging procedure (section A.5.1.6). This information consists of a set of different data elements:

• body location
• laterality

In FHIR body locations can be represented in two ways: as a coded value or as a reference to a BodyStructure resource. The coded value is used when a code is sufficient. The BodyStructure is used when more information is needed such as laterality or to indicate morphology. Additionally, as is specified in DICOM-SR-2-FHIR the information such as the DICOM tracking id (see DICOM-SR-2-FHIR body structure). The DICOM tracking id is used to track similar features across DICOM studies and reports.

References to a body site are used in ImOrder (what part of the body is to be studied), ImProcedure (the body site the procedure is performed on) and ImagingStudy.series (the body site the series is imaging). In FHIR R5 both ImOrder and ImagingStudy allow references to BodyStructure. Procedure only supports a coded value.

In the specification there are different approaches that can be taken towards representing body sites:

1. Use code when code is sufficient, BodyStructure when additional information is required,
2. Prefer BodyStructure over body site.
3. Always include both, if allowed

The first option might cause issues with searching as in some situations, the code resides on the source resource and when a reference to BodyStructure is used, on BodyStructure. These are covered by two search parameters and would require more complex search operations.

The second option is not feasible in all cases as both options are not supported on all resources.

The third option is allows for searched but does allow to specify further information if needed. But does require definition of resources that are not providing additional information.

CHOICE:: when referring to a body site on a resource that allows both a reference as a coded value, always populate the coded value.

CHOICE:: when referring to a body site and more information is available (such as tracking id or laterality), include both a code as well as reference.

Radiation Dose Summary

Background information:

• Background - Radiation Dose Summary for Diagnostic Procedures on FHIR v0.1.0

DICOM - templates (from https://build.fhir.org/ig/HL7/fhir-radiation-dose-summary-ig/background.html#minimal-radiation-information)

• TID 2008 Radiation Exposure and Protection Information
• Radiopharmaceutical Radiation Dose SR IOD Templates
• X-Ray Radiation Dose SR IOD Templates
• Radiopharmaceutical Radiation Dose SR IOD Templates

The radiation dose IG uses two observations, one (Radiation Summary Report - Radiation Dose Summary for Diagnostic Procedures on FHIR v0.1.0) stating a summary of the radiation, the other Indication Observation - Radiation Dose Summary for Diagnostic Procedures on FHIR v0.1.0 holds information on the indication for the radiation. Based on the requirements from XtEHR, only the first is required.

As this Radiation Dose IG is still draft, based on an earlier FHIR specification, and is unlikely to be published in the near future, it cannot be referred to. This mitigated by copying the relevant parts of the IG to this implementation guide.

In this process, also some changes where made in line with FHIR R5, these include:

• The observation identifier referred to the SOPInstanceUID, this is replaced with a reference to ImagingSelection.
• Adding slices on Observation.component for the different numeric values.

Procedure Phases

Dataset A5.1.9 relates to the inclusion of additional procedure details. The description states: "Additional information pertaining imaging procedure, such as imaging phase. e.g., without contrast, arterial phase, venous phase, delayed phase. Only some types of studies have phases."

The imaging phase relates to certain studies such and radiation therapy and nuclear medicine. These procedures go through different phases, typically a phase represents a time frame after a tracer has been provided to the patient (e.g. Abdominal CT: Urogram).

Just stating that the procedure included these phases does not seam to add a lot of value. The added value is linking results from the procedure to each stage.

These results include imaging series and instances and possibly findings.

Leave it in DICOM

Do not include this information in FHIR and the healthcare professional has to look at the DICOM image in order to detect the phase.

Findings (Observations) are linked to an ImagingSelection the phase is derived from the code.

Use child procedures

One way of modelling such a procedure would be to use child procedures.

classDiagram
  direction DT

  class Finding { <<Observation>>}
  MainProcedure <-- ProcedurePhase1: partOf
  MainProcedure <-- ProcedurePhase2: partOf
  MainProcedure <-- ProcedurePhase3: partOf
  
  ProcedurePhase2 <-- ImagingSelection: extension[procedure]
  ProcedurePhase2 <-- Finding: partOf

Each phase is represented by a separate Procedure. The results of each phase will be point to the sub-procedure.

This will work for findings (Observations), it is slightly more cumbersome for DICOM series and instances as these are hosted in the ImagingStudy resource and not as a separate resource. One way of referring to each serie or instance is to use ImagingSelection. In that approach, an Extension on ImagingSelection will point to the corresponding sub-procedure.

Findings point to the sub-procedure representing the phase. This model introduces a large set of additional resource and references,including requirements on timing, not sure whether this is justified for this information.

Observations mark results of a phase

The phase is represented as an Observation.

classDiagram
  direction TD
  class Phase{
    <<Observation>>
    code: phase
    valueCodeableConcept: identifies phase
  }
  class Finding{ <<Observation>> }
  Procedure <-- Phase: partOf
  Phase --> ImagingStudy: derivedFrom
  Phase --> ImagingSelection: derivedFrom
  ImagingSelection --> ImagingStudy: derivedFrom
  ImagingSelection <-- Finding: derivedFrom

An observation is created for each phase, the code states it represents a phase, the partOf field points to Procedure, and derivedFrom to ImagingStudy and ImagingSelection, the valueCodeableConcept identifier what phase it is.

Findings point to the ImagingSelection representing the part of the study they relate to. The phase can be deducted through the link from the Phase Observation. Alternatively, it could be encoded in the Finding.code as well.

This will work from but using Observation to observe a phase in an procedure is somewhat awkward.

Represent a phase as a Task

The procedure phase could also be represented as a Task, documenting that results of the phase.

classDiagram
  direction TD
  class Task{
    code: identifies phase
  }
  class Finding{ <<Observation>>}
  ServiceRequest <-- Task
  ServiceRequest <-- Procedure
  Task --> ImagingSelection: output
  Task --> ImagingStudy: output
  ImagingSelection --> ImagingStudy: derivedFrom
  Task --> Finding: output
  ImagingSelection <-- Finding: derivedFrom

The task is modelled as part of the execution of a ServiceRequest. The output field in the Task points to the ImagingSelection that represents the instance or serie that is the result of the phase.

Findings link to the phase Task and ImagingSelection.

This approach does not link the phase to the Procedure but the ServiceRequest (order).

Add an extension on ImagingSelection

Another way encode such information would be to add an extension to ImagingStudy, ImagingStudy.serie and ImagingStudy.serie.instance that states the phase this part of the study was retrieved in as a coded value.

classDiagram
  direction TD
  class ImagingStudy{
    serie.extension[phase].valueCodeableConcept
    serie.instance.extension[phase].valueCodeableConcept
  }
  class ImagingSelection
  class Finding{ <<Observation>> }
  
  Procedure <-- ImagingStudy : partOf
  Procedure --> Finding: partOf
  ImagingSelection --> Finding: derivedFrom
  ImagingStudy <-- ImagingSelection: derivedFrom

Using ImagingSelection to represent a Phase

An ImagingSelection resource is used to represent the results of the study from a phase. ImagingSelection.category will be used to mark it as a phase. The ImagingSelection.code will mark the phase it represents.

classDiagram
  direction TD
  class Finding { <<Observation>> }
  class ImagingSelection{
    category = #phase
    code = code for the phase
  }
  ImagingStudy <-- ImagingSelection
  ImagingSelection <-- Finding: derivedFrom

Findings will point to the ImagingSelection as normal.

Evaluation

Although the different options all make sense in some way. The last option has the smallest impact on the model and does not require additional extensions.

CHOICE: Procedure phases will be represented as ImagingSelections.

Adverse reaction (Adverse reactions manifested during imaging investigation.)

Dataset A5.3 relates to the register of adverse events that occurred during or due to imaging procedures. This includes both allergy-caused reactions as well as non-allergic ones.

Three resource types can be used to encode the required data: AdverseEvent, AllergyIntolerance, and Condition. In this IG, adverse reactions are recorded using the AdverseEvent resource. If the reaction is due to an allergy, it is also recorded using the AllergyIntolerance resource. Consumer systems will likely use this resource type to populate the allergy flags.

• Model

classDiagram
  class ImAdverseReaction {
    <<AdverseEvent>>
    code MS
    category MS
    resultingEffect MS
    seriousness MS
    occurence MS
    suspectEntity.causality.entityRelatedness MS
    suspectedEntity.instance MS
    contributingFactor.item MS
    note MS
    extension.ImAdverseEventCriticality MS
  }

  class AllergicReaction{
    verificationStatus MS
    criticality MS
    reaction.extension.allergyCertainty MS
    reaction.substance MS
    reaction.manifestation MS
    reaction.severity  MS
    reaction.onset MS
    type MS
    note MS
  }

  class ImProcedure{
    <<Procedure>>
  }

  ImAdverseReaction --> ImProcedure: suspectEntity.instance
  ImAdverseReaction --> AllergicReaction: contributingFactor.item

Rationale and other choices for modeling

AdverseEvent resource

The decided modeling choice in this IG to represent an adverse reaction.

• Pros:
  • it can point to a Procedure. It represents widely both types of reactions (allergic and non-allergic).
  • It can point to an AllergyIntolerance resource, for the cases in which that pathogenic mechanisms is suspected or confirmed.
• Cons:
  • it lacks some of the allergy-specific elements required (i.e. criticality, verification status).
  • The resource focuses mainly is on the registration and monitoring of adverse events.
  • The link to the rest of the model is done through AdverseEvent.SuspectedEntity.ImProcedure, which is probably not the best way of referencing it, as it needs a reverse include to query adverse events happened in a given procedure.
  • A custom extension is required to encode the criticality data point.

AllergyIntolerance resource

The decided modeling choice in this IG to represent an allergic condition.

• Pros:
  • This resource provides off-the-shelf data elements to convey severity, criticality, propensity and a standard extension is available for the certainty element.
• Cons:
  • Although it has a .reaction element, the focus of the resource is on establishing allergic states, not on capturing events.
  • There is not a straightforward way to reference to or from a Procedure resource, so it can be linked to the main model. It could be achieved through .encounter, but that resource might not be exchanged in the Bundle, thus the reference would be lost.

Condition resource

• Pros:
  • It can be linked directly to a Procedure resource through Procedure.complication.
• Cons:
  • It encompasses all types of conditions, thus it defines too broadly the kind of event that this use case requires.

Representation of Key Images

Key images can be represented in two ways:

• ImagingSelection
• DocumentReference

ImagingSelection if more DICOM oriented and only relates to DICOM identifiers. DocumentReference is more image oriented and also contains information on the size, duration, etc. aspects of the image.

The eHN Imaging Studies and Reports guidelines requires information on the size, format, duration etc., data elements that are provided on the Attachment field on DocumentReference. If these fields are critical, DocumentReference fits more closely. In US Core the R4 Media resource is used to represent key images. This resource later merged into the FHIR R5 DocumentReference.

As this IG has an FHIR R5 and R4 representation, DocumentReference is an easy fit but in other sections of this specification, ImagingSelection is used (e.g. to state that an image can from a Procedure Phase).

The ImagingSelection resource points to a DICOM data. The DICOM instance data also holds the data required by the eHN Imaging Studies and Reports. So the client can retrieve the information from the DICOM source data.

The eHN Imaging Studies and Reports guidelines also requires access to the imaging data. It refers to access the data directly or using an web based image viewer. A scenario that can be supported based on ImagingSelection as such mechanism require access to the DICOM identifiers and a WADO endpoint. Although not discussed yet, it is anticipated that a web based endpoint can operate based on similar data fields.

DocumentReferences refer to the data source directly (included in the Attachment or referred to it). It does not carry the DICOM identifiers, although these can be added to DocumentReference resources (identifier or extensions).

Another aspect, although unlikely, is that the report mey refer to key images (charts, pdf's, …) not stored in a DICOM PACS, DocumentReferences would allow this.

There is a point to be made for both resource types.

CHOICE: Key images can be represented by ImagingSelection or DocumentReference resources.

CHOICE: When using DocumentReference to represent a DICOM data element, it will carry an identifier corresponding the serie or instance it represents.

That leaves the question in what way are these resources linked into the overall infrastructure.

classDiagram
    direction TD
    class ImKeyImagingSelection{ 
        <<ImagingSelection>>
        studyUid
    }
    class ImKeyImagingInstanceSelection{ 
        <<ImagingSelection>>
        studyUid
    }
    class ImKeyImagingSerieSelection{ 
        <<ImagingSelection>>
        studyUid
        instance.uid
        instance.sopClass
    }
    class ImKeyImageDocumentReference{ 
        <<DocumentReference>> 
        modality
    }
    class ImKeyImageInstanceDocumentReference{ 
        <<DocumentReference>>
        identifier: SOP Instance UID
    }
    class ImKeyImageInstanceSerieDocumentReference{ 
        <<DocumentReference>>
        identifier: SerieInstanceUID
    }
    class ImComposition{ 
        <<Composition>>
        section[keyimages]
    }
    ImComposition --> ImKeyImageDocumentReference: section[keyimages].entry
    ImComposition --> ImKeyImagingSelection: section[keyimages].entry

    ImKeyImageDocumentReference --> ImageData: content.attachment.url
    ImKeyImageDocumentReference <|-- ImKeyImageInstanceSerieDocumentReference
    ImKeyImageDocumentReference <|-- ImKeyImageInstanceDocumentReference
    ImKeyImagingSelection <|-- ImKeyImagingSerieSelection
    ImKeyImagingSelection <|-- ImKeyImagingInstanceSelection
    

Image data access and endpoints

Besides access to the imaging report, the eHN Guidelines also requires access to the imaging data.

Existing (non-FHIR) systems use a variety of mechanisms to support searching for imaging studies. Examples include DICOM DIMSE, DICOMweb QIDO, querying for KOS objects andst the imaging study manifest. Typically they allow for a range of query options such as querying on codes and SOPclass.

The IG will focus on a FHIR based approach to searching for imaging studies.

The specification will not dictate the mechanism to access the imaging data but will focus on describing the available mechanisms and endpoints to retrieve (part of a) study. This will be done by defining profiles for Endpoint resources.

Endpoint profiles will be defined for at least the following image access mechanisms:

• DICOMweb WADO
• DIMSE
• Launch a DICOM viewer

The specification assumes that search is done on ImagingStudy and related resources.