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

From IHE Wiki
Jump to: navigation, search

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


The Problem

== Note: THIS PROFILE IS CHANGED TO A WHITE PAPER.

The purpose of this white paper is to define 3-5 USE CASES and illustrate them. The Use Cases will be defined with input from the "Supporting Cast" below. The white paper will include two examples of profiling Part 20 AS EXAMPLES, not as profiles. Note that many of the sections included in the Supplement template will not be included in the white paper. The level of estimate below represents the White paper, not the profile.==


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.

Today, radiology reports, unlike pathology and some cardiology reports, are typically text blobs sent in an ORU or a text blob wrapped in a CDA. The reports are not structured to ensure that they are complete for the end user, for billing, population health analysis, radiation exposure monitoring, etc. They are not 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.

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

Standardcloud.png


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)

Structured format:

  • Links: ability to include and use links
  • Tables
  • Coded Observation
  • Quantity Measurement

Clinically relevant Sections:

  • 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
  • Procedural Medication
  • Image Quality
  • Procedure Technique

Breakdown of tasks that need to be accomplished

  • 0.) Work out use cases and options with the radiologists/clinicians at the December TC meeting.
  • 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.) Build out high level use cases including: (Most of these would be represented as a Named Option)
  • send Report from Reporting system to EMR
  • send report with Actionable Finding
  • send report with coded content
  • send report with Radiology Recommendation
  • 5.) Review Named Options to verify they address cancer registry submission, REM registry submission, etc. Other analytics. Update as needed.
  • 6.) Review TCE profile. Determine what/how much needs updating. Draft updates.
  • 7.) Review IHE Rad Code Mapping White Paper. Determine what/how much needs updating. Draft updates.
  • 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

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
  • See clinical list above, but they are busy people.

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.
  • It would be almost critical to also get some time from Harry Solomon to review.

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, integration with XDS.b, updates to 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.
  • The outgoing transport for report is important but Radiology does not have a transaction for it. Perhaps it is time to create one for XDS and non-XDS environment
    • For XDS, should this structured report content simply be using the 'CDA Imaging Report with Structured Headings' formatCode or we need to create yet another specific formatCode indicating that the content is compliant to Part 20?
  • 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

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

  • 35%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel