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

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

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

Additional contributors/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

The Problem

The intent of this supplement is to further profile DICOM/HL7 Part 20 (Sup 155) for structured reporting. This would include identifying Actors, Transactions, and Named Options, etc. The intent is to be able to test Part 20 at an IHE Connectathon.

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.

Key Use Case

The radiologist, reviewing a study at an image viewing system, instantiates the reporting tool- voice recognition or key entry (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.

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.

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.

Technical Approach

Base on DICOM/HL7 Part 20. This would be a Content Profile only.

Specifically, see DICOM Part 20 sections 9 and 10 for a list of all of the Sections and Entries.

Existing actors

Content Creator Content Consumer

New actors

No new actors.

Existing transactions

No transactions other than standard cloud diagram above. In other sections, mention possible methods of transferring data, but none are required.

New transactions (standards used)

No new transactions.

Impact on existing integration profiles

The key question here is MRRT. For DICOM/HL7 Part 20 to be truly integrated with MRRT, there are several MRRT CPs which need to be completed, the most complex of which is CP#308 - Add Business Names to MRRT template format. There are currently 5 outstanding MRRT CPs, but there are also several MRRT CPs recently submitted for additional formatting options.

Integration with XDS.b would be discussed, but no additional changes.

Teaching File and Clinical Export (TCE) probably needs updating.

The Code Mapping White Paper needs updating to match Part 20.

New integration profiles needed

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

No Actor Groupings required.

There are pros and cons to raising the bar on the current DICOM Part 20 spec.

Pros: Arguably, IHE could raise the bar and create the possibility that EMRs would operate better if Actionable Findings were required to be coded. Cons: The higher the bar is raised, the less participation will occur. CDA is already new to most reporting systems which are used to HL7 v2 ORUs, however, EMR systems can usually ingest CDA (but not necessarily act upon these coded elements).

Possible Named Options include: (probably 90% complete list)

Links: ability to include and use links
Tables:
Sections separated: Clinical Information, Comparison Study, Findings (today, you could throw all of this into Impressions legally, just ugly)
Request (Order) Info
CDS Info
Complications
REM
Key Images
Fetus Findings
Communication of Actionable Findings
Radiology Recommendation
Coded Observation
Quantity Measurement
Procedural Medication
Image Quality
Procedure Technique

Breakdown of tasks that need to be accomplished

1.) Decide whether MRRT is updated with this profile or not.
2.) Decides whether or not IHE will raise the bar on DICOM/HL7 Part 20 requirements.
3.) Decide on which Part 20 CDA Sections, Sub-sections should be included as Named Options. Need radiologists (see list above) input on this.
4.) High level use cases would need to be built out, including: send Report from Reporting system to EMR, send report with Actionable

Finding, send report with coded content, send report with Radiology Recommendation, etc. Most of these would be represented as a Named Option. It is the intent that these use cases and options are worked out in advance with the radiologists/clinicians of the December TC meeting.

5.) Need to verify that the Named Options we work out will somehow work for cancer registry submission, REM registry submission, etc. Other analytics.
6.) Need to verify what/how much needs updating in TCE profile.
7.) Need to verify what/how much needs updating in IHE Rad Code Mapping White Paper.
8.) A coding scheme would not be identified.
9.) Most necessary codes (e.g., Section headers) are already specified in the DICOM Part 20.

Support & Resources

See clinical list above, but they are busy people.
It would be almost critical to also get some time from Harry Solomon to review.

Risks

Radiologists/clinicians do not arrive at consensus as to what should be identified as Named Options.
The list of Named Options could get out of control and not be managable/meaningful/decipherable. May need to group.
To be done properly, MRRT needs additional work.

Open Issues

Summary section from template is missing
Standards and System section is missing systems and not listing some standards
Breakdown of tasks should include the MRRT CPs, updates to XDS, TCE and Code Mapping Whitepaper mentioned elsewhere.

What is the focal problem(s) to be addressed. Current statement of the root Problem is that someone published Sup155 and the secondary problem is that RSNA, ECR, and CCO have put substantial money, time, and effort into some reporting initiatives.

Reading between the lines, there is a long list of candidate problems
Problem: Current reports are not uniform, not comprehensive, not easily managed, not efficiently produced, communicate poorly to referring providers, are not machine readable, do not easily meet accreditation criteria do not easily meet pay-for-performance incentives
Related problems: actionable findings are often not followed up, it is difficult to analyze the accuracy of Radiology Recommendations, it is difficult to do research/analysis on report contents, autopopulate cancer registries, or evaluate report completeness against standardized cancer imaging report templates.
Need to determine which items on the above list will be goals of the Profile.
Expand Breakdown task 4 to address each of the goals considered in-scope. Add reviewing the data elements and requirements to achieve each of the selected goals.

What technologies does the profile intend to include (i.e. which do you intend the Profile to require the Doc Creator to support and which the Doc Consumer to support (to reliably achieve the list of goals).

Currently lists clinical data, coded terminology, technical parameters, measurements, annotations and key images, actionable findings, analysis of accuracy of recommendations, radreport.org, MRRT, Radlex Playbook, Radlex Lexicon, Sup155, TRex Editor
The effort estimate should correlate with the number of technologies being incorporated/profiled

Which of the listed goals will require the actor to have external information and given there will be no transactions, how do you envision the actor accessing that information?

The outgoing transport of the report is being left open but it might be useful to discuss how the incoming data transactions will work.

Will MRRT be directly included/referenced in this profile
What is the "minimal level" for compliance? ie., do we raise the bar above what is required by DICOM/HL7 Part 20?
Will the 18-ish sections and subsections of Sup155 be individually packaged into Named Options?

What IHE Profile currently has the largest number of named options and has it been confusing?
Might be better to have a family of profiles that share a common core instead of named options (which aren't exposed well).

Will you mandate any behavior on the receiver for each of the Options?

i.e. will it directly address the related goals, or enable but not specifically address

If the answers to the above questions are known or can be concluded in short order, do you think this feels like one profile or several?

If they are not known, does this feel like it should start with a whitepaper?

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:

Teri Sippel