HL7 Europe Imaging Report R4
1.0.0-ballot - qa-preview 150

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

Patterns and Guidelines

Presentation format of the document

As is discussed in the Data Formats section there are two formats of the imaging reports. When presenting the content to the user two different presentation forms are used:

  • For imaging reports with minimal metadata the presented form is the pdf attached to the DiagnosticReport.
  • For Regular imaging reports the presented form is the html Narrative of the Composition resource, stored in Compostion.text and Compostion.section.text.

Representing unstructured text (dictated notes)

These are stored in DiagnosticReport.note and in Composition.section.extension[note]. Based on this content the section.text and DiagnosticReport.text and Composition.text are populated.

Inclusion of tables

The annotations are entered as markdown which allows inclusion of tables

Support of IHE-RAD-IMR

IHE-IMR defines a mechanism that allows inclusion multimedia content in the report. Use of these mechanisms is encouraged but not required.

This can be done using the links defined in IHE-IMR.

As is specified in the FHIR specification (and made more explicit in FHIR R6), the narrative text of resources allows the inclusion of hyperlinks. A hyperlink can refer to structured data that is included in the report as is shown in the example below.

...
The diameter of the lesion is <a href="Observation/kjiewoj">11 mm</a>.
...

The href field of the link holds a relative reference to the referred resource. When rendering this narrative, a click on this link SHOULD open a rendered version of the referred resource.

These links can be included in the text (Narrative) using the mechanism described in the previous section. This does require that the ImagingStudy/Observation resource representing the finding/prior is included in the document.

Missing Data

This page provides general rules for handling missing data. Not all of these rules apply to this version of the guide.

The content of this page is adapted from the HL7 International Patient Summary Implementation Guide (IPS) and HL7eu core.

Optional Data Elements (cardinality of 0..1 or 0..*)

If a content creator does not have data to be included in the resources, the data element is omitted.

Note: a content creator may have no data to be included in the resources, either because there are no data, the data cannot be shared, or the available data are not pertinent within the scope of the context of use.

Required Data Elements (cardinality of 1..1 or 1..*)

If a content creator does not have data to be included in the resources, the reason for the absence SHALL be specified as follows:

  1. For non-coded data elements, use the Data Absent Reason Extension in the data type. Example: Patient resource where the birthDate is not known (note that since birthDate is a date primitive datatype, in JSON the _birthDate sibling property is used for the extension). Other required properties of Patient resource are omitted (shown by …) in the simplified example below.

    {
  "resourceType" : "Patient",
  ...
  "_birthDate": {
    "extension" : [
      {
        "url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode" : "unknown"
      }
    ]
  },
  ...
}

    Example: Procedure resource where the performed value is not known. The performed[x] is a choice type, although any performed[x] choice element can be used to include the data absent reason extension, in this case performedDateTime is Must Support and hence a good choice (note that performedDateTime is a dateTime primitive datatype, in JSON the _performedDateTime sibling property is used for the extension). Other required properties of Procedure resource are omitted (shown by …) in the simplified example below.

    {
  "resourceType" : "Procedure",
  ...
  "_performedDateTime": {
    "extension" : [
      {
        "url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode" : "unknown"
      }
    ]
  },
  ...
}

  2. For coded data elements:

    • example, preferred, or extensible binding strengths (CodeableConcept datatypes):
      • if the source system has text but no coded data, only the text element is used.
      • if there is neither text nor a code representing actual (i.e., non-exceptional) concepts:
        • use the appropriate exceptional concept code from the element's binding value set, if available; or
        • use the appropriate concept code from the Data Absent Reason Code System.
    • required binding strength (CodeableConcept or code datatypes):
      • use the appropriate exceptional concept code from the element's binding value set

    Example: Observation Results - Laboratory/Pathology resource where the code is not allowed to be shared (e.g. suppressed), the code element contains the data-absent-reason extension. Other required properties of Observation resource are omitted (shown by …) in the simplified example below.

    {
  "resourceType" : "Observation",
  ...
  "code": {
    "coding" : [
      {
        "system" : "http://terminology.hl7.org/CodeSystem/data-absent-reason",
        "code" : "masked"
      }
    ]
  },
  ...
}

Indicative Date Information: Period of Life Extension

When only indicative temporal information is known (e.g., "during adolescence"), the period of life extension can be used to convey this information.

For elements with multiple datatype choices ([x]), dateTime SHOULD be used as the preferred datatype when representing date/time information.

Example fragment (Immunization): exact occurrence date is unknown, but the period of life is known.

{
  "resourceType": "Immunization",
  ...
  "_occurrenceDateTime": {
    "extension": [
      {
        "url": "http://hl7.eu/fhir/base/StructureDefinition/periods-of-life",
        "valueCodeableConcept": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "263659003",
              "display": "Adolescence"
            }
          ]
        }
      }
    ]
  },
  ...
}

What terminology use in the report

The specification focusses first on the infrastructural aspects and marks the terminology related this as extensible. We are conservative in placing terminology requirements on findings and interpretations are there currently is not a widespread consensus on what terminology is used.

Support for addendum documents

These are separate documents; separate imaging reports. The relationship of the addendum to the source document should be represented in the Composition.relatesTo field, as is illustrated below.

...
  "relatesTo" : [
    { "code": "appends",
      "targetIdentifier": { "system": ..., "value", ...} 
    }
  ]
...

Relation with DICOM-SR reports

DICOM-SR reports can be accessed and referred using ImagingSelections as they are stored as instances in the PACS. In the case that the report is a DICOM-SR report,

Can there be multiple reports on a single study and can a report report on multiple studies?

Yes, there can be multiple reports referring the same study. A study can refer to more than one study. See semi-structured example.

Inclusion of images/drawings that are not stored in DICOM objects

These can be included as Media and are referred from the Composition.section[finding] and DiagnosticReport.media. It is RECOMMENDED to:

  • Use DocumentReference when the information is not present in the PACS (e.g. screenshots, photo's, …)
  • use Basic-ImagingSelection to refer to information in the PACS.
  • Prefer DocumentReference over Binary as DocumentReference is patient scoped and Binary is not. Binary SHOULD only be used for images in Narratives that are included as contained resources.
  • In the case both are possible, systems SHOULD use Basic-ImagingSelection.

Support for digital pathology

Currently not in scope.

AI results are stored as DICOM-SR documents which can be accessed as DICOM instances using the manifest. Optionally, the source system has the option to reflect the content of these DICOM-SR documents in FHIR using the DICOM-SR-2-FHIR IG. When elements from the AIR reports are included in the imaging report, it is RECOMMENDED to use the format specified in DICOM-SR-2-FHIR.

Inclusion of date-time values for which the time-zone is unknown

Some of the source data for imaging report comes from DICOM. Although DICOM recommends to include time-zone information there will be situations that the timezone is not included in the DICOM data and cannot be derived from the context. In this case the document creator SHALL include the date-time value as is and add the Uncertain period Extension to indicate the uncertainty period of the datetime value.

...
  "started" : "2015-02-07T13:28:17-05:00"
  "_started" : {
    "extension" : [
      { "url": "http://hl7.org/fhir/StructureDefinition/uncertainPeriod",
        "valuePeriod" : {
          "start": "2015-02-07T13:28:17-12:00",
          "end": "2015-02-07T13:28:17+12:00"
        }
       }
    ]
  }
...