Figure 2:4.141.4-1: Interaction Diagram

2:4.141.4.1 Store Multimedia Report Bundle Request Message

The Sender sends a multimedia report bundle to the Receiver. The Sender SHALL support sending such messages to more than one Receiver.

The Receiver SHALL support handling such messages from more than one Sender.

2:4.141.4.1.1 Trigger Events

The Sender determines that a multimedia report is ready to be sent. For example, a radiologist completed a dictation on a study and signed off the report. This trigger is associated with an intention that the Receiver stores the multimedia report contents and makes it available for subsequent query and retrieve requests.

2:4.141.4.1.2 Message Semantics

This message is an HTTP POST request. The Sender is the User Agent. The Receiver is the Origin Server.

The Sender SHALL initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of an IMR Bundle Resource containing the following:

• one DiagnosticReport Resource
• zero or more ServiceRequest Resources
• zero or more ImagingStudy Resources
• zero of more ImagingSelection Resources

Note: The DiagnosticReport resource depends on other critical resources such as Patient, Organization, Practitioner or PractitionerRole. These resources are not part of the bundle because they are expected to already exist in the enterprise; hence, they are referenced by the resources in the bundle, rather than created by the Sender. See Section 1:52.4.1.6 DiagnosticReport Referenced Resources for more details.

Additional considerations are needed for these referenced resources in the inter-enterprise use case. See Section 1:52.4.1.7 Inter-Enterprise Use Case for details.

The media type of the HTTP body SHALL be either application/fhir+json or application/fhir+xml.

See http://hl7.org/fhir/http.html#transaction for complete requirements of a FHIR transaction. See http://hl7.org/fhir/bundle-transaction.html for an example of a transaction bundle.

The Sender SHALL send the message to the base URL as defined in FHIR. See http://hl7.org/fhir/R4/http.html for the definition of “HTTP” access methods and “base”.

The following subsections contain additional constraints on the contents of the IMR Bundle.

2:4.141.4.1.2.1 IMR Bundle Resource

For complete information on constructing a FHIR Bundle Resource, see http://hl7.org/fhir/bundle.html.

The Sender SHALL include in Bundle.meta.profile the value of https://profiles.ihe.net/RAD/IMR/StructureDefinition/imr-store-multimedia-report-bundle. The Sender MAY include other profiles in Bundle.meta.profile.

The IMR Bundle:

• SHALL be a Transaction Bundle
• SHALL create one IMR DiagnosticReport
• MAY create one or more IMR ServiceRequest
• MAY create one or more IMR ImagingStudy
• MAY create one or more ImagingSelection

The ImagingSelection resource SHALL conform to the following additional IMR constraints:

• subject, if present, SHALL be a reference to a Patient resource
• endpoint SHALL have one or more ImagingStudyEndpoint

Note: FHIR ImagingSelection resource is in development and not defined in FHIR R4. Therefore the resource profile is specified above. Follow this announcement for the scheduled release date of FHIR R5. Once the FHIR R5 ballot is published (tentatively mid-October 2022), there will be a defined specification for ImagingSelection available with a maturity level of 1.

The Sender MAY set meta.profile of each resource to be the corresponding IMR Profile. This enables a Receiver to validate the received resource against the IMR resource profile specification.

Note: A Sender MAY choose not to set meta.profile to a specific profile, or MAY set it to multiple profiles.

The Sender SHALL create corresponding properly identifiable resources. In other words, the Sender SHALL NOT use contained resources (see http://hl7.org/fhir/references.html#contained).

2:4.141.4.1.2.2 IMR DiagnosticReport Resource

The Sender SHALL construct the IMR DiagnosticReport Resource according to the IMR DiagnosticReport StructureDefinition.

Section 2:4.141.4.1.2.2.1 contains mapping requirements.

Section 2:4.141.4.1.2.2.3 contains requirements for including a rendered report in an IMR DiagnosticReport Resource.

A complete example of an IMR DiagnosticReport Resource is available in IMR DiagnosticReport Example.

2:4.141.4.1.2.2.1 Mapping of Attributes in a Diagnostic Report

Table 2:4.141.4.1.2.2.1-1 specifies a set of attributes commonly included in radiology diagnostic reports, and how the Sender SHALL map these attributes to the IMR DiagnosticReport Resource and other referenced resources. Refer to the StructureDefinition for these resources on the Artifacts page for details.

Table 2:4.141.4.1.2.2.1-1: Mapping of Attributes in DiagnosticReport

Note 1: This transaction does not define a FHIR resource profile for the resource. An implementation MAY use other FHIR resource profiles applicable for their deployment.

In addition to the common set above, there are also a number of useful optional attributes that the Sender MAY included.

Table 2:4.141.4.1.2.1-2: Useful Optional Attributes in Radiology Diagnostic Report

Note 1: See HIMSS-SIIM White Paper: The Importance of Body Part Labeling to Enable Enterprise Imaging for the importance of body part labeling.

Note 2: The DiagnosticReport.text is required and is used to capture report content section(s) among other narrative content. Additionally, the Sender MAY include the experimental IMR Observation resource to encode atomic data items for the equivalent contents (such as findings and impressions) in various report sections.

Coded observation for radiology reporting has not been defined. IHE Radiology is interested in your feedback if you use it. Please send your feedback to radiology@ihe.net.

2:4.141.4.1.2.2.2 Observation Imaging Context in an IMR DiagnosticReport Resource

For narrative content, the Sender MAY directly embed one or more image references inline within the text.

The Sender SHALL specify each inline image reference using the <span> HTML element and the corresponding </span> end element. This <span> element SHALL have the attributes as defined in Table 2:4.141.4.1.2.3.1-1.

The display text is the text enclosed by the <span> element.

Table 2:4.141.4.1.2.2.2-1: Attributes for the <span> element

Note 1: Custom type MAY be used but they are out of scope of IMR.

Example 1: An image reference is specified with the finding, with a simple string “image” as the hyperlink display text

Trace fluid or debris is seen in the distal lumen of the stent <span class="imr-ref-ImagingSelection" id="ImagingSelection/1234">image</span>.

Example 2: An image reference is specified adjacent to the corresponding measurements, with a simple description of the series and instance number as the hyperlink display text

The imaged portion of a thyroid gland is unremarkable. Prominent or mildly enlarged mediastinal and bilateral hilar lymph node measure up to 1.2 x 0.8 cm in the right paratracheal station <span class="imr-ref-ImagingSelection" id="ImagingSelection/1234">(Series 2, Image 10)</span>.

Example 3: Multiple image references are specified adjacent to the measurements, with each measurement as the corresponding hyperlink display text

The imaged portion of a thyroid gland is unremarkable. Prominent or mildly enlarged mediastinal and bilateral hilar lymph nodes measure up to <span class="imr-ref-ImagingSelection" id="ImagingSelection/1234">1.2 x 0.8 cm in the right paratracheal station</span>, <span class="imr-ref-ImagingSelection" id="ImagingSelection/1567>2.3 x 1.4 cm in the subcarinal station</span>, and <span class="imr-ref-ImagingSelection" id="Imagingselection/1890>1.4 x 0.9 cm in the right hilar stations</span>. No significant axillary lymphadenopathy is detected.

For the examples above, each reference uses a span of class imr-ref-ImagingSelection. Each ImagingSelection resource MAY reference one or more imaging objects as well as DICOM SR, segmentation, or include region of interest directly. See ImagingSelection examples for various examples of the ImagingSelection resource, including image references as well as non-image references.

2:4.141.4.1.2.2.3 Rendered Report in IMR DiagnosticReport Resource

The Sender SHALL include in DiagnosticReport.presentedForm the report rendered in HTML format. The corresponding DiagnosticReport.presentedForm.contentType SHALL have the value “text/html”.

The Sender MAY include other renderings of the same report (e.g., PDF) in DiagnosticReport.presentedForm and SHALL set the DiagnosticReport.presentedForm.contentType with a value corresponding to the rendered report format.

The Sender SHALL encode the rendered report that is referenced by DiagnosticReport.presentedForm in one of the following ways:

• As a base64Binary in DiagnosticReport.presentedForm.data.
• As a base64Binary in a Binary Resource and this Binary Resource is referenced in DiagnosticReport.presentedForm.url.
  • The Binary Resource SHALL be in the Bundle. See FHIR Resolving references in Bundles at http://hl7.org/fhir/bundle.html#references.
• Host the rendered report somewhere and provide the url in DiagnosticReport.presentedForm.url.

The Sender SHALL populate accurate values for hash and size for the rendered report content in DiagnosticReport.presentedForm.hash and DiagnosticReport.presentedForm.size:

• Where the presentedForm is a Binary Resource instance, the .hash and .size SHALL represent the raw artifact prior to base64 encoding in the Binary.data element.
• Where the presentedForm is hosted elsewhere, not as a Binary Resource, the .hash and the .size SHALL represent the rendered report content that would be retrieved using the mime-type specified in DiagnosticReport.presentedForm.contentType.

2:4.141.4.1.2.2.3.1 Image References in Rendered Report

This section contains requirements for Senders that include observation imaging context in the rendered report in HTML format in DiagnosticReport.presentedForm

For inline observation imaging context references in DiagnosticReport.text, the Sender SHALL substitute each <span class="imr-ref-*">…</span> markup with an HTML anchor element. The href attribute SHALL correspond to the content specified in the referenced ImagingSelection resource:

• The service root for the URL SHALL derive from ImagingSelection.endpoint.
• The rest of the URL path SHALL derive from the remaining content of ImagingSelection according to the protocol specified in ImagingSelection.endpoint.connectionType.

The Sender SHALL construct the resulting URLs such that the contents returned to the Receiver upon invocation are ready to be presented, rather than contents that would require any processing by the Receiver. For example, using a WADO-RS URL with a rendered image or using an IID compliant URL to launch a viewer meet the requirements, whereas a plain WADO-RS URL to retrieve a DICOM object does NOT. In other words, the Sender SHALL NOT presume that the Receiver can download and render the linked content on its own.

2:4.141.4.1.2.2.3.2 Rendered Report in PDF Format

A Sender that supports the PDF Report Option, if configured, SHALL also include a semantically equivalent diagnostic report in PDF format in the DiagnosticReport.presentedForm attribute. The corresponding presentedForm.contentType SHALL have the value “application/pdf”.

The Sender SHALL include in the PDF report all text and linked contents as in the HTML report. The Sender MAY preserve the linked contents as hyperlinks, or substitute the linked contents with the actual rendered contents and embedded them in the PDF file.

2:4.141.4.1.2.3 Patient, Organization, Practitioner, PractitionerRole Resources

The Patient, Organization, Practitioner or PractitionerRole Resources are required resources as defined by IMR DiagnosticReport. However, IMR does not specify any FHIR resource profiles on these resources. These resources are not radiology or imaging specific. Real world deployment MAY specify constraints on these resources.

2:4.141.4.1.3 Expected Actions

The Receiver SHALL accept both media types application/fhir+json and application/fhir+xml.

On receipt of the request message, the Receiver SHALL validate the resources and respond with one of the HTTP codes defined in the response Message Semantics.

The Receiver SHALL process the transaction bundle atomically as specified in http://hl7.org/fhir/http.html#transaction.

Note: Local policy might reject bundles containing resources such as Patient, Organization, Practitioner, etc. referenced that are unknown to the Receiver. Therefore, the actual behavior is at the discretion of the Receiver Actor policy.

The Receiver SHALL retrieve any Resources referenced by absolute URLs in the FHIR Bundle Resource.

The Receiver SHALL validate the bundle first against the FHIR specification. Guidance on what FHIR considers a valid Resource can be found at http://hl7.org/fhir/validation.html.

Once the bundle is validated, the Receiver SHALL store the report and all associated resources.

The Receiver SHALL NOT send a success response until the multimedia report is completely processed and persisted as appropriate to the Receiver configuration.

If the Receiver encounters any errors or if any validation fails, the Receiver SHALL return an appropriate error.

2:4.141.4.1.3.1 Additional Expected Actions for Report Repository

The Report Repository SHALL be able to retrieve the hosted rendered report in DiagnosticReport.presentedForm.url. The Report Repository SHALL be able to embed the retrieved report in the corresponding DiagnosticReport.presentedForm.data, or substitute the corresponding DiagnosticReport.presentedForm.url with a value where the report can be retrieved from the Report Repository.

Note: This functionality is necessary in case the Sender stores the report to the Report Repository with a URL that is inaccessible to other subsequent consumers of the reports.

The Report Repository MAY extract the embedded rendered report in DiagnosticReport.presentedForm.data, store it and substitute the corresponding DiagnosticReport.presentedForm with a URL (i.e., DiagnosticReport.presentedForm.url) instead.

The Report Repository SHALL maintain the integrity of the report if the report access method is modified (i.e., from embedded to hosted, or vice versa).

Note: Multiple formats of rendered reports MAY exist in DiagnosticReport.presentedForm.

2:4.141.4.2 Store Multimedia Report Bundle Response Message

The Receiver sends a response message describing the message outcome to the Sender.

2:4.141.4.2.1 Trigger Events

The Receiver receives a Store Multimedia Report Bundle Request message.

2:4.141.4.2.2 Message Semantics

This message is an HTTP POST response. The Sender is the User Agent. The Receiver is the Origin Server.

The Receiver returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements in http://hl7.org/fhir/http.html#trules to the Sender. This enables the Sender to know the outcome of processing the FHIR transaction, and the identities assigned to the resources by the Receiver.

The Receiver SHALL construct a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry warnings such as PartialFolderContentNotProcessed. The Receiver SHALL comply with FHIR http://hl7.org/fhir/bundle.html#transaction-response and http://hl7.org/fhir/http.html#transaction-response.

To indicate success, the Receiver SHALL return an HTTP status 200. The Receiver SHALL include in the HTTP response header the location element, and the etag element if the Receiver supports FHIR resource versioning.

The Bundle.entry.response.status SHALL be 201 to indicate the Resource has been created.

If the Receiver cannot find any referenced resources in the bundle, then the Receiver SHALL return an HTTP status ‘404 Not Found’.

If the Receiver cannot handle the method for each resource in the bundle, then the Receiver SHALL return an HTTP status ‘405 Method Not Allowed’.

If the Sender is not authorized to store the bundle, then the Receiver SHALL return an HTTP status either ‘401 Unauthorized’ or ‘403 Forbidden’.

For other request related errors, the Receiver SHALL return an HTTP status ‘400 Bad Request’. For other Receiver processing related errors, the Receiver SHALL return an appropriate 5xx HTTP status.

An informative StructureDefinition is found at IMR Store Multimedia Report Bundle Message.

2:4.141.4.2.3 Expected Actions

If the Receiver returns an HTTP redirect response (HTTP status codes 301, 302, 303, or 307), the Sender SHALL follow the redirect, but MAY stop processing if it detects a loop. See RFC7231 Section 6.4 Redirection 352.

The Sender processes the results according to application-defined rules.

2:4.141.4.3 CapabilityStatement Resource

Receiver SHALL provide a CapabilityStatement Resource as described in ITI TF-2: Appendix Z.3 indicating which resources associated with an IMR report have been implemented.

2:4.141.5 Security Considerations

The Sender MAY use external URLs in presentedForm.url. In this case, the Receiver SHOULD consider validating the URL to ensure that it is a valid URL referencing a known legitimate host to avoid phishing attack.

2:4.141.5.1 Security Audit Considerations

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