Imaging Diagnostic Report - Proposal

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Workitem: Imaging Diagnostic Report

  • Proposal Editor: Kevin O'Donnell (inspired by Kinson's work)
  • Editor: Kevin O'Donnell & Kinson Ho
  • Domain: Radiology

Summary

There is significant interest in the possibility of migrating reporting infrastructure to use FHIR-based data exchange in the hopes of improving imaging interpretation, communication of results, and subsequent clinical workflows and analysis.

Imaging Diagnostic Reports have significant domain-specific semantics, and specialized structure and conventions associated with their use. FHIR provides a framework of roughly a dozen relevant resources (see below) that is intended, in principle, to support such semantics, structure, and usage.

Focused effort is needed by medical imaging domain experts to document current and forward-looking requirements, validate relevant FHIR Resources and propose revision as needed, and create an implementation guide covering how reports are created, managed, presented, and processed.

Depending on the rate of progress, this cycle may, in addition to capturing/organizing/documenting the use cases/requirements, produce a Content Definition spec, and associated transactions. Reporting workflow and clinical workflow profiles may be addressed in subsequent proposals but are outside the scope of this one.

Several existing initiatives have the potential to be valuable collaborators (see below). In particular, DICOM WG-20 has already put significant work into the FHIR ImagingStudy and ImagingSelection resources, and mapping some SR components into Observation resources. Radelement CDEs would fit very well into this framework. The RSNA Reporting Informatics Committee is exploring forward-looking use cases that would drive advanced reporting.

The effort estimation describes the proposed work in more detail.

2. The Problem

EMR vendors and users express interest in using FHIR to eventually supplant HL7v2 messaging for the storage and exchange of EMR content. The most significant piece of EMR content for imaging is the Diagnostic Report. Significant analytic work was involved in determining how to represent such reports in DICOM SR and later in CDA (see PS3.20), similar work needs to be completed for a FHIR representation.

FHIR has a DiagnosticReport Resource (Maturity: 3). It is a "base" resource intended to provide the basis for addressing all forms of diagnostic reports in the enterprise (lab specimen analysis results, pathology, toxicology, imaging, etc.). Initial work primarily focused on lab results and imaging results that are assay-oriented (like a bone densitometry value).

To ensure the specification supports typical imaging usage, it would be helpful to assemble imaging report expertise and do further design analysis of the current resource with respect to the requirements for encoding the range of content typically present in diagnostic reports for medical imaging procedures.

The primary goal would likely be a specialized ImagingDiagnosticReport that is able to capture the results of the imaging interpretation process, support efficient communication of those results, and feed subsequent analysis and clinical workflows.

Note: to encourage adoption it will be important to identify/highlight the benefits of re-implementing something that "already works".

3. Key Use Case

The profile should address imaging-based reports for Radiology, Cardiology, OB/Gyn, Oncology, Pathology and Optometry. There may be domain-specific details that we need to recruit expertise to address properly. Consider all major imaging modalities, and in particular whether they have additional/differing/divergent needs.

The Profile will focus on content NOT workflow. So imaging acquisition workflow and reporting workflow are not addressed. Incorporating the report into the EHR/medical record will be addressed. Full encoding of all reported observations should be supported, but is not required/assumed.

There are several "stages" to the lifecycle of a report. Each interacts with the content and metadata of the encoded resource(s).

Report Creation: A Report Creator encodes the report content.

Consider how the content of the diagnostic report is created, organized and encoded. Specifically consider how sections are used to structure/organize content, and the metadata needed for management of progressive stages of completion of a report (e.g. for interaction between resident, attending, etc and perhaps handling of discrepancies), and references to relevant prior reports. Also consider importation/encoding of potentially coded content like patient history.

Report Storage & Distribution: A Report Creator provides reports to a Repository which makes them available (push & pull?)

Consider how reports are stored, routed, searched/retrieved, …

Report Presentation: A Report Display presents the content of the diagnostic report to users performing clinical tasks.

Consider whether to emphasize narrative content vs coded content, and the use of summarizations, perhaps highlighting of key information. Imaging reporting conventions, like sections, conclusion/impressions should be addressed. Presentation may also involve the use of hyperlinks to trigger presentation of associated images and measurements (see IMR).

Report Processing: A Report Reader extracts details from diagnostic reports for its own purposes.

Consider how the content of the diagnostic report is parsed by machines for analysis, decision support, and other process automation. There may be more emphasis on the code-based, machine readable, discrete pieces of information (e.g. Observations/Findings). Consider harmonization with CDE (Common Data Elements)

4. Standards and Systems

The primary systems would be Report Creators, Repositories, and Displays. Generic Reader & Updater actors might be considered to cover decision support, analysis, and workflow automation systems but explicit management of the related reporting and clinical workflows is not addressed.

The Imaging Diagnostic Report Profile is expected to be based on the following FHIR resources. Some might be specialized as indicated. Current Maturity Levels of the base resources are shown in parentheses. While levels of 4 & 5 are not yet definitively stable, they are likely quite solid. Levels of 3 and lower would add increasing degrees of uncertainty.

  • Patient (N)
  • Organization (3)
  • Encounter? (2)
  • Practitioner (3)
  • Practitioner Role (2) & CareTeam? (2)
  • Imaging Service Request (2)
  • Imaging Procedure (3)
  • Imaging Diagnostic Report (3)
  • Imaging? Observation (N)
  • Imaging? Composition (2)
  • ImagingStudy (4)
  • ImagingSelection (1)
  • Communication? (2)
  • ClinicalImpression? (0)
  • FamilyMemberHistory? (2)
  • AdverseEvent? (0)

Potential Collaborative Groups

  • DICOM WG-20
  • Breast Radiology Report IG
  • German FHIR Report
  • Contact Marc K. and Marco E.
  • CDE (Common Data Elements)
  • https://radelement.org
  • defining standard sets of data elements to capture observations about specific imaging "targets" like a lung nodule, or an ovarian cyst, or pneumonia
  • think of a CDE Set as a "chunk" of a radiology report (some reports might only have one chunk)
  • Argonaut / Smart Imaging Access Project
  • RSNA Radiology Informatics Committee
  • likely source of concrete clinical use case details and the expertise of tech-savvy clinicians
  • working on identifying use cases for how elements from imaging reports should better support/influence patient care beyond the referring physician reviewing the report.
  • Automation/CDS for followup on recommendations/findings/incidental findings
  • Information prescriptions for patients to help them understand and process details of the report
  • Longitudinal compilation and framing of multiple related reports/results; in it's basic form, things like tumor tracking
  • ...
  • RadReport (RSNA)
  • New chair??
  • ACR Commission on Informatics
  • OHDSI (Odyssey - Observational Health Data Sciences and Informatics)
  • https://www.ohdsi.org/
  • https://github.com/OHDSI/CommonDataModel
  • at a technical level, defines the OMOP (Observational Medical Outcomes Partnership) Common Data Model
  • intended to support many use cases: data aggregation for population health and outcomes research, data access abstraction to support sending algorithms for data analysis or AI training to hospitals for local execution on their data.
  • potential source of use cases, technical data concepts, and collaborators
  • OIDM (Open Imaging Data Model)
  • US CDI (United States Core Data for Interoperability)

5. Discussion

It would be useful for IHE Radiology to bring expertise in imaging reports and the reporting process to refining the DiagnosticReport and other associated Resources.

The large scope will be a challenge. What are approaches to constraining the scope of this cycle?

  • Start with one imaging domain (e.g. radiology) and add more later?
  • Consider if some FHIR resources can be de-scoped for later work?
  • Do a whitepaper to tackle the use case and concepts first while the standards mature?
  • ... ???

Past experience has indicated that within radiology reporting lurks layers of complexity, lack of fully standardized practices (i.e. lots of local variation), and significant proprietary implementations. It will likely make sense to publish as an Experimental Draft (also considering the varied maturity of the Resources involved). Based on feedback and experience with the Experimental Draft, a second cycle will likely be proposed to nail down the profile.

Q. How much do we get into mapping the transcoding of DICOM source data into observations? This represented a lot of what Part 20 covered (demonstrating the potential complexities for implementers, and profilers) and WG-20 is working on this already.

Q. How do we properly handle "Impressions" which represent a kind of conclusion somewhere between an observation and a diagnosis? How do we handle recommendations?

Q. Should we describe/mandate how to export such a FHIR Imaging Diagnostic Report into an HL7 V2 message?

Side Note: Maybe avoid constraining cardinality and types in FHIR resources unless it is dysfunctional as is.

Q. Does DiagnosticReport encompass interventional imaging procedures as well as diagnostic imaging procedures? What if a procedure is mixed/transitions?

Q. How can we identify use cases that represent "inflection points" in the diagnosis/care process. These are treatment-changing findings that have an outsized positive impact on outcomes. Need to better identify the best next step in treatment and handle the hand-off to the group that is best able to provide that treatment. (Link Dr. Steinberger & RIC Use Case work)

Q. Are there "contextual linkages" from the Report to EMR content beyond the resources described above that we should consider?

See Breakdown of Tasks details in the 2022-23 Evaluation Worksheet

Retrieved from "http://wiki.ihe.net/index.php?title=Imaging_Diagnostic_Report_-_Proposal&oldid=130797"