This page is part of the IHE Interactive Multimedia Report (IMR) (v1.1.0: Publication) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

2:4.142 Display Multimedia Report [RAD-142]

2:4.142.1 Scope

This transaction is used to present the report content to someone, such as a radiologist or a clinician, in such a way that permits the user to interact with the embedded multimedia contents.

This transaction is not a typical IHE transaction between two devices; the primary focus is on the required behavior of the display rather than messaging between two actors. This can be thought of as an “informational transaction” between a display device and a user.

The specification is about the baseline display behaviors required for multimedia reports. As with many IHE specifications, the display may have behaviors in addition to those required by this transaction.

2:4.142.2 Actors Roles

The roles in this transaction are defined in the following table and may be played by the actors shown here:

Table: Actor Roles

Transaction text specifies behavior for each role. The behavior of specific actors may also be specified when it goes beyond that of the general role.

2:4.142.3 Referenced Standards

FHIR-R4 HL7 FHIR Release 4.0

2:4.142.4 Messages

Figure 2:4.142.4-1: Interaction Diagram

2:4.142.4.1 Display Multimedia Report Message

The Display presents the multimedia report to the user.

2:4.142.4.1.1 Trigger Events

A user or an automated function determines that one or more multimedia reports SHOULD be presented.

2:4.142.4.1.2 Message Semantics

The report is encoded in a FHIR IMR DiagnosticReport resource.

The Display SHALL present the IMR DiagnosticReport in one of two methods:

• Assemble from Content Elements
  • In this method, the Display examines the attributes available in the DiagnosticReport, assembles a report, and presents it
• Display Rendered Report
  • In this method, the Display either extracts the rendered report from DiagnosticReport.presentedForm.data or retrieves the rendered report from DiagnosticReport.presentedForm.url, and presents it

This transaction does not depend on how the IMR DiagnosticReport Resources were transferred to the Display. If the Display receives the reports by a profiled mechanism such as Find Multimedia Report [RAD-143], the messaging protocol is specified in that corresponding transaction. If reports are accessed by being grouped with another actor such as Report Repository, there is no messaging protocol involved.

2:4.142.4.1.3 Expected Actions (i.e., Display Requirements)

The behaviors in this section are specified as baseline capabilities. The Display may have additional or alternative capabilities that may be invoked or configured.

The Display SHALL support the display requirements as defined in Table 2:4.142.4.1.3-1, according to the actor.

Table 2:4.142.4.1.3-1 Actor Display Requirements

2:4.142.4.1.3.1 Display of Attributes from DiagnosticReport

The Display SHALL be capable of presenting the attributes from the IMR DiagnosticReport Resource and referenced resources as defined in Store Multimedia Report [RAD-141] Table 2:4.141.4.1.2.2.1-1.

The Display MAY display any other attributes available from the DiagnosticReport Resource and referenced resources.

2:4.142.4.1.3.2 Display of Observation Imaging Context from Narrative Text

For inline image references in narrative content from DiagnosticReport.text, the Display:

• SHALL substitute each <span class="imr-ref-*">…</span> element with a hyperlink

• SHALL use the text enclosed by the <span class="imr-ref-*"> element as the display text for the hyperlink

• SHALL construct the URL for this hyperlink
  • The URL SHALL be derived from ImagingSelection.endpoint.address referenced in <span class="imr-ref-*">
  • The resulting URL SHALL be a valid URL according to the contentType
• MAY add additional parameters to the URL to invoke specific functions provided by the Image Manager / Image Archive or Image Display

For example, the Display MAY retrieve a rendered JPEG or a thumbnail of the image instead of the DICOM object.

Refer to [RAD-141] Section 2:4.141.4.1.2.2.2 for details about inline image reference encoding.

Example 1: An ImagingSelection that references one or more images example

The Display can translate the ImagingSelection into the following WADO-RS URL to retrieve rendered DICOM instance.

http://my.hospital.com/dicomweb/studies/1.2.840.113747.20080222.35738167368358372924306270412538783781/series/1.2.840.113747.20080222.35738167368358372924306270412538783781.1/instances/1.2.840.113747.20080222.35738167368358372924306270412538783781.1.0/rendered

When the user clicks on the link, the Report Reader retrieves the rendered DICOM instance and displays it.

Exmaple 2: An ImagingSelection that references a specific DICOM Presentation State object example

The Display can translate the ImagingSelection into the following WADO-RS URL to retrieve rendered DICOM instances.

http://my.hospital.com/dicomweb/studies/1.2.840.113747.20080222.104120739293836151289003163903631439818/series/1.2.840.113747.20080222.104120739293836151289003163903631439818.200/instances/1.2.840.113747.20080222.104120739293836151289003163903631439818.200.0/rendered?presentationSeriesUID=1.2.840.113747.20080222.104120739293836151289003163903631439818.1&presentationUID=1.2.840.113747.20080222.104120739293836151289003163903631439818.1.0

When the user clicks on the link, the Report Reader retrieves the rendered DICOM instance with the presentation state data included and display it.

Example 3: An ImagingSelection that references a specific finding in a DICOM SR example such as a tumor diameter measurement

In DICOM SR encoding, each finding can have a unique Observation UID.

The Display can translate the ImagingSelection into the following IID URL:

http://my.hospital.com/IHEInvokeImageDisplay?requestType=SERIES&studyUID=1.2.840.113747.20080222.95946058738699434572916364657859950275&seriesUID=1.2.840.113747.20080222.95946058738699434572916364657859950275.3&imageUID=1.2.840.113747.20080222.95946058738699434572916364657859950275.3.0&viewerType=IHE_IMR&srSeriesUID=1.2.840.113747.20080222.95946058738699434572916364657859950275.1&srUID=1.2.840.113747.20080222.95946058738699434572916364657859950275.1.0&srObsUID=1.2.840.113747.20080222.95946058738699434572916364657859950275.10.1

Note 1: Using IID URL to access DICOM SR or with direct region of interest is defined in CP-RAD-474 and subject to change.

Note 2: If the Report Creator has not included one or more Observation UIDs in the DICOM SR for the relevant finding(s), then the behavior of the Display is undefined.

Note 3: WADO-RS only supports retrieve rendered objects with presentation states. It does not yet support retrieve rendered objects with other observation imaging context such as DICOM SR. If the Report Creator has created a presentation state along with the DICOM SR that captures the presentation of the findings, then the Display can still use WADO-RS with the presentation state.

When the user clicks on the link, the Report Reader launches an Image Display in the context of the specified series and image. The Image Display also retrieves the specified DICOM SR and display the content with the images.

Example 4: An ImagingSelection that provides the imageRegion directly example

The Display can translate the ImagingSelection into the following IID URL.

http://my.hospital.com/IHEInvokeImageDisplay?requestType=SERIES&studyUID=1.2.840.113747.20080222.324856729726823100954657132726086516575&seriesUID=1.2.840.113747.20080222.324856729726823100954657132726086516575.1&imageUID=1.2.840.113747.20080222.324856729726823100954657132726086516575.1.0&viewerType=IHE_IMR&graphicData=0.25,0.25,0.75,0.25,0.75,0.75,0.25,0.75,0.25,0.25&graphicType=POLYLINE&coordinateType=2D

When the user clicks on the link, the Report Reader launches an Image Display in the context of the specified series and image. The Image Display also rendered the specified region of interest with the images.

This transaction does not prescribe any specific presentation when presenting hyperlinks. For example, the Displays MAY display the hyperlinks as text or as thumbnail images.

A Display that supports the Advanced Image Viewing Option SHALL be capable of adjusting the URL to reference the series or study level accordingly to its configuration.

Note: The Display may choose to display the full study or only the referenced series, based on the current usage context or configuration.

2:4.142.4.1.3.3 Display of Rendered Report from DiagnosticReport.presentedForm

The Display:

• SHALL be capable of presenting the rendered report from DiagnosticReport.presentedForm.data with contentType “text/html”.

• SHALL be capable of retrieving and presenting the rendered report specified from DiagnosticReport.presentedForm.url. See Retrieve Rendered Multimedia Report [RAD-144] for details.

• SHALL be capable of presenting all hyperlinks from the rendered report.

Note: The Display may not be able to access the content referenced by the hyperlinks due to network and content access permission.

Displays that support the PDF Report Option SHALL be capable of presenting the rendered report with contentType “application/pdf”.

Displays MAY be capable of presenting rendered reports in other contentType.

2:4.142.5 Security Considerations

This transaction involves presenting diagnostic reports that typically constitute personal health information (PHI) to human observers who are typically clinicians. Typical access controls and audit trails in accordance with local policies would be appropriate.

2:4.142.5.1 Security Audit Considerations

This transaction is associated with a ‘Patient-record-event’ ATNA Trigger Event on the Display. See ITI TF-2: 3.20.4.1.1.1.

2:4.142.5.2 Display Specific Security Considerations

Since this transaction involves the display of PHI, it may be reasonable for the actors to implement typical access controls for patient records, such as logins for users and role-based access policies. Since this transaction involves parsing datasets generated by other systems, it may be reasonable for the actors to implement basic digital hygiene, such as sanitizing datasets to avoid malicious executable scripts that might be executed by a browser-based viewer.