Imaging Diagnostic Report - Proposal
1. Proposed Workitem: Imaging Diagnostic Report
- Proposal Editor: Kevin O'Donnell (inspired by Kinson's work)
- Editor: TBA
- Domain: Radiology
2. The Problem
EMR vendors and users appear to have an 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.). However, the work to date has 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: for 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. It should list consider all major imaging modalities, and in particular whether they have additional/differing/divergent needs. Consider that there may be domain-specific details that we need to recruit expertise to address properly.
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 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: 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: Consider how reports are stored, routed, searched/retrieved, …
Report Presentation: Consider how the content of the diagnostic report is presented to clinical users. There may be more emphasis on the narrative content, but also summarizations, and 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: 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).
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)
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.
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 maturity of some 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. Does DiagnosticReport encompass interventional imaging procedures as well as diagnostic imaging procedures? What if a procedure is mixed/transitions?
Side Note: Maybe avoid constraining cardinality and types in FHIR resources unless it is dysfunctional as is.