Structured and Coded (Synoptic) Radiology Report Content Profile - Proposal

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

Proposal Editor: Teri Sippel Schmidt/Karos Health teri.sippel@karoshealth.com
Editor: Teri Sippel Schmidt/Karos Health with RSNA RIC committee members, Cancer Care Ontario, and other SIIM Members (see below)
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiology

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

David Kwan, Cancer Care Ontario
Jon Zammit, Cancer Care Ontario
Curt Langlotz, MD, Stanford Univ
Chuck Kahn, MD, HUP
Paul Nagy, Johns Hopkins
Eliot Siegel, MD, UMD
Justin Cramer, MD, U of Utah
Harry Solomon, GE
Marta Heilbrun, MD, U of Utah

2. The Problem

The intent of this supplement is to profile DICOM/HL7 Part 20 (Sup 155) for structured reporting.

RSNA, ECR, and CCO have put a substantial amount of money, time, and effort into the following 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
DICOM/HL7 Part 20 (prev DICOM Supplement 155) (Radiology Reports in CDA format)

Value Statement: (Taken directly from: RSNA Reporting Initiative

Radiology Reporting Initiative

What is the radiology reporting initiative?

The clinical report is an essential part of the service you provide to your patients. As a tool that communicates information to referring physicians, records that information for future use and serves as the legal record that documents the episode of care, it is of the utmost importance that the report be uniform, comprehensive, easily managed and "readable" to humans and machines alike.

The RSNA radiology reporting initiative is improving reporting practices by creating a library of clear and consistent report templates. These templates make it possible to integrate all of the evidence collected during the imaging procedure, including clinical data, coded terminology, technical parameters, measurements, annotations and key images. Twelve subcommittees of subspecialty experts have created a library of best-practices radiology report templates. They are free and not subject to license restrictions on their reuse.

These report templates:

Create uniformity and improve your communication with referring providers
Enable your practice to meet accreditation criteria
Help your practice earn pay-for-performance incentives

Through this initiative, RSNA is encouraging reporting vendors to develop software products that enable radiologists to create high-quality radiology reports more efficiently.

3. Key Use Case

The radiologist, reviewing a study at an image viewing system, instantiates the reporting tool- voice recognition or key enter (irrelevant).
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.
Because the report is structured and coded, research can be more easily conducted such as further analysis on the accuracy of "Radiology Recommendations", as just one example of many research examples.
Because the report is structured and coded, Cancer Care Ontario can analyze the discrete data elements for report completeness compared to standardized cancer imaging report templates; populate patient diagnostic imaging clincial data to cancer registries for cancer staging and present population based cancer data for incidence and prevalence to public health registries.

4. Standards and Systems

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.
This will be a content only profile, no transactions.
There will be two actors: Document Creator and Document Consumer.
The method used to export/send the report will not be identified, but examples will be given (HL7 v. 2 ORU w/ CDA payload or XDS being two such examples).
The key will be the Named Options and identifying which of the Part 20 CDA sub-sections will be brought to the forefront as named options.
The discussion as to which DICOM Part 20 CDA sub-sections should become named options will begin with the reviewers listed above for clinical input prior to the Nov/Dec initial Tech Comm meeting.

5. Discussion

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

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) are fairly complex and not obvious 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.

5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA