Interactive Multimedia Report (IMR)
1.1.0 - Trial-Implementation
Interactive Multimedia Report (IMR)
1.1.0 - Trial-Implementation
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
| Page standards status: Informative |
IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Radiology Public Comment form.
As issues are submitted they will be managed at IMR GitHub Issues, where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).
IHE invites comments on the following issues.
| # | Question |
|---|---|
| 1 | Q: Is it reasonable to require the Report Creator to separate findings and impressions as two set of observations? IMR defines some general report content organization based on FHIR DiagnosticReport and other dependent resources (See Mapping of Attributes in Diagnostic Report for details). This includes common attributes like Finding and Impression and Indication. These sections are common in radiology reports, but they are common communicated inside a single text block in an ORU OBX segment instead of separated by each section. A: Findings and impressions are recorded in DiagnositcReport.text instead of Observation. There is an experimental design of Observation resource. IHE Radiology is looking for feedback how this is used in different context. |
| 2 | Q: Should IMR constraint further details on how to encode findings and impressions using IMR Observation? Currently regarding Report Content Organization, IMR allows all findings to be put together in one IMR Observation as one large string, or separate each finding as a separate IMR Observation. Same is true for impressions. IMR only recommends but not mandates separation of each finding / impression as separate IMR Observation. Main rationale for the current design is to ease adoption. A: Findings and impressions are recorded in DiagnositcReport.text instead of Observation. There is an experimental design of Observation resource. IHE Radiology is looking for feedback how this is used in different context. |
| 3 | Q: Is using <span> instead of <imr-ref> acceptable? DiagnosticReport.text.div attribute is explicitly limited in FHIR to only allow a small subset of HTML4 elements. This means no HTML5 custom elements or data-* HTML5 custom attributes are allowed. The IG Publisher / sushi will fail validation. Switching to <span> retains all existing design features, including support for different resource types, as well as not affect any consumer as they will just ignore the tag if there is no given style. |
These issues have been decided and documented in the publication.
| # | Question |
|---|---|
| 1 | Q: How to reduce redundant information across referenced resources? A: Each referenced resource should be self-contained as they can be standalone and used outside the context of a DiagnosticReport. They can be searched independently. So using references, the redundant information is basically referencing the same common references, not duplicated. Resources may contain duplicate information because context does not flow across resources. Also resources may be used in many different contexts. An implementation is free to use a deduplicating algorithm behind the scenes if there is a concern about resource size. |
| 2 | Q: IMR does not currently impose any constraint on Patient, Organization, Practitioner and PractitionerRole. Should there be any constraints or leave it to the deployment to impose any profiles on these resources? A: Do not constraint in IMR. Let the deployment decides if any profiles on these resources should be imposed. |
| 3 | Q: What level of structure should IMR impose on the diagnostic report? Currently IMR focus on Report Content Structure. A: IMR should continue to focus on Report Content Structure. It will not address Report Content Encoding Structure because this is highly varied for each specialty. Implementation can support encoding structure and consider using IHE Management of Radiology Report Template (MRRT) and/or RSNA RadReport.org, and use the additional optional attributes in FHIR DiagnosticReport and referenced resources to encode the result. |
| 4 | Q: Can other systems other than the Report Creator add other rendition of the reports and append to the DiagnosticReport.presentedForm? A: This is out of scope of IMR. In IMR, there is no separate Report Renderer actor. From the IMR perspective, this other system is considered as part of Report Creator. Furthermore another system may query, retrieve and provide an update to the server for the resource. It is the server responsibility to implement controls if updating by another system is a concern to its business process. |
| 5 | Q: Should the Report Creator supports RAD-144 Retrieve Rendered Diagnostic Report? It is possible for the Report Creator to include a rendered report in DiagnosticReport.presentedForm using a URL link instead of embedded. This is the case if the Report Creator host the report on its own. In this case, should the Report Creator require to support RAD-144? A: Currently the Report Repository is required to be able to retrieve the report from Report Creator and then embed the rendered report. The expectation is that the Report Repository is design to host these reports and support API to query/retrieve reports or distribute the reports. Such behavior is normally not expected from a Report Creator. |
| 6 | Q: Should IMR use ImageSelection to specify how multimedia content can be referenced in an Observation? In FHIR R5, a new ImageSelection resource is available, which allows more sophisticated reference to a study, with the additional capability to include imageRegion. This is a good match for IMR, but currently in draft. A: A note is added that it is the intention for IMR to support ImageSelection once it becomes available in R5 release. Instead of inventing something temporary and discarded later, currently inline image reference only support single reference. When ImageSelection becomes available, then set of image references as well as ROI will be supported. |
| 7 | Q: Should IMR permit the Origin Server to support FHIR resources in JSON only? Currently the Origin Server is required to support both XML and JSON format and the User Agent can choose which format to use. A: No. The Origin Server is required to support both XML and JSON, which is consistent with all other IHE profiles that use FHIR (e.g. ITI MHD). |
| 8 | Q: Should all the Resource References in DiagnosticReport always defined as standalone identifiable resources and then referenced in DiagnosticReport, instead of inline them as Contained Resources? A: Yes. Standalone identifiable resources are generally more useful. They can be access, searched, referenced in other resources. Contained resources are more limited. Currently there is no situation identified that standalone identifiable resources cannot be done and required to use contained resources instead. |
| 9 | Q; Should comparison study be supported in the base DiagnosticReport rather than as an IMR extension? A: A FHIR JIRA ticket FHIR-36858 is filed. |
| 10 | Q; Should indication be supported in the base DiagnosticReport rather than as an IMR extension? A: A FHIR JIRA ticket FHIR-31552 is filed. |
| 11 | Q: Will there be cases that a DiagnosticReport has no referenced ServiceRequest (or Order)? For example, in ED cases, will report be created before an order exist? A: IMRServiceRequest is optional in DiagnosticReport to handle cases where a service request may not exist. |
| 12 | Q: For query in RAD-143, should IMR require the Responder to support both HTTP GET and HTTP POST request? A: Yes, both HTTP GET and HTTP POST are required for the Responder. |
| 13 | Q: Should there be any constraints on the DiagnosticReport.status? The base ValueSet has a rich set of status that may or may not apply to radiology reporting. Currently IMR constrains the value set to be just partial, preliminary, final, amended, corrected, appended and cancelled. In other words, the status registered, entered-in-error and unknown are excluded. A: IMRDiagnosticReport no longer imposes any constraint on the DiagnosticReport.status. |
| 14 | Q: Should IMR support draft status for the DiagnosticReport? Are there cases that a DiagnosticReport resource is created to capture a draft report? This is common status for a trainee or attending to use in the reporting system and the report is not yet accessible to clinicians in EMR. If so, should draft be coded as partial, or a new status is required? A: When a report is flagged as draft, the reports stay within the Report Creator and not send out to other systems yet. The report is sent out when the report is updated as preliminary or final, which has a corresponding report status. In the rare occasion that the Report Creator needs to send a draft report out, it can communicated to other system using the report status partial. |
| 15 | Q: To query report [RAD-143], should support of query by anatomic region / body part be required for the Responder? A: No. Body Part query is not required. |
| 16 | Q: For DiagnosticReport.effective[x], should Period data type be also supported in addition to DateTime? Period defines a period of time the report is valid. Is having an expiry time for a radiology diagnostic report a useful concept? : No more constraint on DiagnosticReport.effective[x] in IMR. This attribute is optional for DiagnosticReport. |
| 17 | Q: Will creating an addendum interferes with FHIR events and subscription? A FHIR resource such as DiagnosticReport can be used as an event. Subscribers can be setup to receive notification when event happened. In normal case, there may be subscription created to receive resource update notifications. However, for DiagnosticReport, a common practice is rather than updating the report, a new addendum will be created. This means a subscription expecting to receive notification when reports are updated may not get notification because the DiagnosticReport resources are not being updated. Will this immutability semantics cause any problem with FHIR events and workflow? A: Not expected to be a concern. One can setup a subscription on reports for a patient rather than a subscription on the DiagnosticReport resource itself. |
| 18 | Q: Should the Report Creator be required to create a default rendered report, or leave it as an option? The presentedForm is required to be fully ready-to-display by the Rendered Report Reader. This means all image references are required to be rendered as some rendered format, whether it is WADO-RS with Rendered Image, or other rendered format supported by the browser. This means the Report Creator is required to understand what image rendering method is support in the system and how to specify them for the given image references. A: Decided to keep the requirement for the Report Creator to generate a HTML rendered report. Most reporting systems have this or a similar capability. |
| 19 | Q: For RAD-143, should IMR impose any requirements on the Responder to support FHIR search result parameters in FHIR query? DiagnosticReport resources include many references to other resources such as Patient, IMR Observation, IMR ServiceRequest, etc. By default, a query result will not include those referenced resources and they are only returned as references in the DiagnosticReport in the response. The client will need to issue subsequent FHIR API calls to retrieve those resources. The following search result parameters may be useful in IMR: _include: the servers that support this parameter, if requested, will include all referenced resources in the same response. This simplifies the work for the client since there is a single request to get all information, but it will increase the payload of the response significantly. _elements: the servers that support this parameter, if requested, will return only the attributes explicitly requested instead of the full resource. This minimizes the payload of the query response. This may be helpful for the client to populate a list, for example, which does not require the full content. _sort: the servers that support this parameter, if requested, will return the query responses sorted in the attribute(s) specified. This may be useful if a query result is expected to include many responses. _count: the servers that support this parameter, if requested, will return only the specified number of responses regardless of how many actual matching results are there. A: Added requirements for Responder to support _include, _sort, _count, _summary, but not _elements. Responder may suport additional search results parameters. |
| 20 | Q: Should IMR defines any presentation of the report content explicitly (See Report Presentation for details)? Currently there is no explicit presentation requirement for the Report Reader. In other words, it is up to the Report Reader to present all the contents in DiagnosticReport and referenced resources in a reasonable way. Note that report presentation will be more appropriate using FHIR Composition which is currently in the process of being integrated with FHIR DiagnosticReport. A: Decided that presentation of the report content is out of scope for IMR. |
| 21 | Q: To simplify the client when finding diagnostic reports, should the Responder support search by Chained Parameters, Reverse Chaining, and/or Composite Search Parameters? Query can be complicated. Sometimes searching for diagnostic reports based on referenced resource is necessary (e.g. search for DiagnosticReport for accession number 12345. In this case, accession number is located in the IMRServiceRequest referenced in DiagnosticReport.basedOn). A: Decided to leave these more advanced query capability as optional for the Responder. Consulting with existing FHIR implementations and generally prefer multiple simple direct queries rather than one complex queries. |
| 22 | Q: Can Report Creator request to create organizational resources such as Patient, Organization, Practitioner or PractitionerRole (which are referenced by DiagnosticReport and included in the transaction bundle) when sending the Store Multimedia Report request? Normally one would expect that these organizational resources already exist and therefore known to the Report Creator when the DiagnosticReport resource is created. This may be true in the general sense, but these resources may not exist yet in the Report Repository (e.g. the IMR Report Repository is new and has not yet backfilled with existing patient, organization and practitioner data). It may be necessary to use ifNoneExist attribute in Bundle.request to specify conditional create. A: Decided that organizational resources are expected to already exist and they should be referenced by the resources in the bundle, but not created as part of the bundle. Note that this may be revised later when IMR also addresses inter-enterprise use cases. |
IG © 2021+ IHE Radiology Technical Committee. Package ihe.rad.imr#1.1.0 based on FHIR 4.0.1. Generated 2024-06-20
Links: Table of Contents |
QA Report
Version History |
|
Propose a change