Structured Reporting Content and Transport

From IHE Wiki
Revision as of 10:45, 6 September 2016 by Kho (talk | contribs)
Jump to navigation Jump to search

Proposed Workitem: Structured and Coded (Synoptic) Radiology Report Content Profile

  • Proposal Editor: Teri Sippel Schmidt/Karos Health teri.sippel@karoshealth.com and Kinson Ho/McKesson with RSNA RIC committee members, Cancer Care Ontario, and other SIIM Members (see below)
  • Editor: Kinson Ho (McKesson) and Teri Sippel Schmidt (Karos Health)
  • Domain: Radiology

The Problem

Quite often, there is a need to share an imaging study between hospitals. Sharing of imaging study via DICOM is well established, however, it is not the same for sharing of diagnostic reports that are associated with the study, even in the case that there already exists a shared infrastructure like a centralized archive. XDS / XDS-I is a solution to the problem, however, in practice, there are still many more hospitals connected via regular DICOM and HL7 only and there is no immediate plan to move to XDS / XDS-I.

The intent of this profile proposal is to provide a consistent mechanism to share diagnostic reports of imaging study such that the reports can be shared along with the corresponding imaging study consistently such that the receiving system can interpret and present the study and reports to the user reliably. This involves two independent and inter-related problems:

  • How to transport the report from one system to another? Ideally the report can be queried/retrieved like an imaging study?
  • How should the report be formatted such that there is a basic understanding of the content regardless of the originating reporting system?

Benefit of structured content in diagnostic reports:

Today, radiology reports, unlike pathology and some cardiology reports, are typically text blobs sent in an HL7 v2 ORU or a text blob wrapped in a CDA. They are not structured nor coded such that a computer system can act upon them and make them searchable. The intent of a coded and structured report is to create a better report for the ordering physician and make the reports actionable by a computer.

Finally, RSNA, ECR, and CCO have put a substantial amount of money, time, and effort into the following structured templates initiatives:

  • radreport.org - repository of expert structured rad report templates in MRRT format
  • open.radreport.org - location to submit new rad report templates
  • IHE RAD MRRT profile
  • T-Rex report template editor


Value Statement: Please see: RSNA Reporting Initiative

Key Use Case

Clinical Use Case - Sharing of study and report:

  • The PACS, based on some configured rules, identify relevant prior studies from the central archive for the upcoming scheduled order. The identified studies have associated diagnostics reports. These studies and reports are not yet in the PACS.
  • The PACS issues a retrieve request to retrieve these identified studies and associated reports
  • Later, the radiologist, review the foreign study and reports using the PACS workstation.
  • The PACS presents the study and reports

Clinical Use Case - Reading a Radiology Study:

  • The radiologist, reviewing a study at an image viewing system, instantiates the reporting tool- voice recognition or key entry (data entry method irrelevant).
  • Hopefully, but not required, a structured and coded report template is displayed. (meant to integrate with MRRT, but not required)
  • The radiologist completes the report and electronically signs the report.
  • The content of the report is exported to an EMR and/or HIE in DICOM Part 20 format to be ingested in structured format.
  • Because the report is structured and coded, the EMR is able to act upon the report to facilitate additional workitems being placed on worklists such as Actionable Findings Follow-ups.

Standards and Systems

Report communication

For report communication, there are a number of feasible options available today, each has its pros and cons:

  • FHIR - it provides a DiagnosticReport resource as well as a full suite of RESTful API for store, query and retrieve. The challenge is that it is still relatively new and the underlying standard may still be changed, although the DiagnosticReport resource has reached FHIR maturity level of 3, which means the specification is stable and a number of implementations are available.
  • DICOM Encapsulated CDA - it provides a DICOM wrapper to capture CDA content. The DICOM wrapper allows the reports to be store, query or retrieve using the existing DICOM communication, the same mechanism as the imaging study. The challenge is to find the appropriate Study Instance UID if the report is received ahead of the imaging study
  • DICOM Encapsulated PDF - it provides a DICOM wrapper to capture rendered report in PDF format. The DICOM wrapper allows the reports to be store, query or retrieve using the existing DICOM communication, the same mechanism as the imaging study. The challenge is to find the appropriate Study Instance UID if the report is received ahead of the imaging study
  • DICOM Structured Report with Template CID 2000 - it provides a DICOM wrapper to capture simple text report content (e.g. from HL7 ORU). The DICOM wrapper allows the reports to be store, query or retrieve using the existing DICOM communication, the same mechanism as the imaging study. The challenge is to find the appropriate Study Instance UID if the report is received ahead of the imaging study
  • HL7 ORU - de facto standards to communicate reports, even in some cases across hospitals. The challenge is that there is no query/retrieve mechanism. That means when the imaging study is retrieved from the central archive, such study retrieval has to server as a trigger event to send the associated report out via ORU.
  • XDS / XDS-I - This option is listed here for completeness although this is not the prime candidate, as the problem statement stated that the scope is to find a solution for non-XDS environment. XDS / XDS-I has already provided a consistent mechanism for any content, including imaging study manifest and reports.

Report content

In this 2016 proposal, this profile has been limited to the identification of the 5 sections of the CDA report as defined in Part 20. A named Option will be specified to be able to include the Actionable Findings section. Other Use Cases (such as Radiology Recommendations, Quantitative (and coded) Measurements, etc.) will be not be specified currently, however, the intent is that a framework has been put into place to add additional named Options for the other CDA sections and entries in the future, after we have gained more experience and evaluated vendor uptake.

This profile will further refine ("profile") DICOM/HL7 Part 20, but be fully DICOM/HL7 Part 20 (HL7 v3 CDA) compliant.

  • A CDA Level 1 report will not be accepted.
  • CDA Level 2 (sections identified and coded appropriately) will be the minimum acceptable level.
  • Two of the actors will be: Document Creator and Document Consumer. These actors will be grouped with other actors for transport.
  • Transport mechanisms will be specified and may include HL7 v2.x ORU w/ CDA payload, FHIR, DICOM Encapsultated CDA, or XDS.b.
  • The only Named Option for content will be Communication of Actionable Findings. The other DICOM Part 20 CDA Sections and Entries will remain unspecified in this version.
  • There may be Named Options for transport mechanisms, in addition to a single defined/required transport mechanism.

Discussion

IHE is the correct venue for this profile for several reasons:

  • In many deployments, communication of diagnostic reports require a separate discussion given the lack of consistent standard, especially when sharing across hospitals. This problem should be solved once and for all.
  • There has been much discussion about how radiology (radiologists) need to demonstrate value and how the radiologists' product is the report. (See Paul Nagy's Dwyer SIIM 2015 presentation). And, yet, IHE Radiology does not address the radiologists' key product.
  • DICOM/HL7 Part 20 (CDA) is fairly complex and not easy to read. Having an IHE Profile including Named Options would give radiology, rad administrators, vendor product managers, and vendors sales people a common and more understandable language to be able to communicate consistently and in a meaningful way.
  • Profiling DICOM Part 20 would provide an entre into the IHE Connectathon for interoperability testing between vendors, which does not exist in any way today.
  • Given the interest by ECR, CCO, and RSNA, this is clearly of international interest and IHE provides an international venue.

Technical Approach

Report communication

Select one mechanism among the several options listed above or another option. The main discussion would be which mechanism is preferred. The specific mechanism is quite well understood.

Report content

CDA Content based on DICOM/HL7 Part 20.

Specifically, see DICOM Part 20 section 7 for the high level list of CDA Sections. These include:

    • Clinical Information (history and clinical information) - may be text-only section (optional section)
    • Current imaging Procedure Description (information about the study which was just performed) - requires Study Inst UIDS, (section required)
    • Comparison Studies - may be text section only (optional section)
    • Findings - may be text-only section (optional section)
    • Impressions - may be text-only section (section required); would include a named Option for Communication of Actionable Findings in this section
    • Addendum - may be text-only section (optional section)

Specifically, see DICOM Part 20 section 9.8.10 for the "Communication of Actionable Findings" section which would be a named Option within this profile.

Existing actors

Report Repository Report Reader

Content Creator Content Consumer

Standardcloud.png


New actors

No new actors, but depends on transport mechanisms possibly.

Existing transactions

Intent is to reuse existing transport transactions wherever possible.

New transactions (standards used)

Need to determine transport methods which will be included, but could be:

  • HL7 v2.x ORU wrapped CDA
  • DICOM Encapsulated CDA, PDF or SR
  • XDS.b encapsulated CDA (exists already)
  • FHIR Diagnostic Report Resource

Impact on existing integration profiles

Compliments existing profiles, not intended to change them.

New integration profiles needed

This would be a new profile. The exact name could either mirror Part 20, or close.

Support & Resources

Contributors/reviewers who have already agreed to assist and allot time for clinical and technical reviews:

  • Chuck Kahn, MD, HUP
  • Paul Nagy, Johns Hopkins
  • Eliot Siegel, MD, UMD
  • Justin Cramer, MD, Nebraska
  • Marta Heilbrun, MD, U of Utah

Risks

  • CDA might be new to the IHE TC members.
  • FHIR might be new to IHE TC members if FHIR is chosen as the transport mechanism and/or the DiagnosticReport resource is chosen as the content specification.
  • Someone may consider this as competing with XDS / XDS-I

Open Issues

  • IHE Rad TC may not be very familiar with CDA description or FHIR transaction.
  • This profile has some overlap with Foreign Study Management - Direct Import proposal.

Tech Cmte Evaluation

White Paper including a section with two examples on how we could profile using part 20 Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • xx%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel and Kinson Ho
Retrieved from "http://wiki.ihe.net/index.php?title=Structured_Reporting_Content_and_Transport&oldid=97024"