Structured Reporting Content and Transport: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older edit
Terisippel (talk | contribs)
675 edits
Kho (talk | contribs)
611 edits
 
(43 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Proposed Workitem: Structured and Coded (Synoptic) Radiology Report Content Profile==
==Proposed Workitem: Structured Reporting Content and Transport Profile==




*Proposal Editor: Kinson Ho/McKesson and Teri Sippel Schmidt/Karos Health  teri.sippel@karoshealth.com with RSNA RIC committee members, Cancer Care Ontario, and other SIIM Members (see below)
*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)  
*Editor: Kinson Ho (McKesson) and Teri Sippel Schmidt (Karos Health)  
*Domain: Radiology
*Domain: Radiology
Line 9: Line 9:
== The Problem==
== 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.


== Note:  This profile proposal has been modified in two ways since the 2015 profile proposal:  1.)  the scope (number of use cases) has been severely limited (to two) and 2.) transport method(s) have been added.
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?


The intent of this profile proposal 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.   
'''Benefit of structured content in diagnostic reports:'''


DICOM Part 20 does not address transport mechanisms of the CDA, but transport mechanisms (XDS, FHIR, DICOM wrapped pdf and/or HL7 v2 ORU) would be included in this profile.
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.


'''Clinical problem statement:'''
Finally, RSNA, ECR, and CCO have put a substantial amount of money, time, and effort into the following structured templates initiatives:
 
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.  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.
 
Additionally, 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  
:* radreport.org - repository of expert structured rad report templates in MRRT format  
:* open.radreport.org - location to submit new rad report templates
:* open.radreport.org - location to submit new rad report templates
Line 28: Line 27:




Value Statement:  Please see: [https://www.rsna.org/Reporting_Initiative.aspx RSNA Reporting Initiative]


Value Statement:  (Taken directly from: [https://www.rsna.org/Reporting_Initiative.aspx RSNA Reporting Initiative]
==Key Use Case==


'''Radiology Reporting Initiative'''
Clinical Use Case - Sharing of study and report:


What is the radiology reporting initiative?
:* 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


'''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.'''
Clinical Use Case - Reading a Radiology Study:


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.  
:* The radiologist, reviewing a study at an image viewing system, instantiates the reporting tool- voice recognition or key entry (data entry method irrelevant).
:These report templates:
:* Hopefully, but not required, a structured and coded report template is displayed. (meant to integrate with MRRT, but not required)
:* Create uniformity and improve your communication with referring providers
:* The radiologist completes the report and electronically signs the report.
:* Enable your practice to meet accreditation criteria
:* The content of the report is exported to an EMR and/or HIE in DICOM Part 20 format to be ingested in structured format.
:* Help your practice earn pay-for-performance incentives
:* 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.


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


==Key Use Case==
'''Report communication'''


:* The radiologist, reviewing a study at an image viewing system, instantiates the reporting tool- voice recognition or key entry (irrelevant).
For report communication, there are a number of feasible options available today, each has its pros and cons:
:* 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.


:* 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.


==Standards and Systems==
'''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.
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.
:* A CDA Level 1 report will not be accepted.
:* CDA Level 2 (sections identified and coded appropriately) will be the minimum acceptable level.
:* CDA Level 2 (sections identified and coded appropriately) will be the minimum acceptable level.
:* This will be a content only profile, no transactions.
:* Two of the actors will be:  Document Creator and Document Consumer.  These actors will be grouped with other actors for transport.
:* There will be two actors:  Document Creator and Document Consumer.
:* Transport mechanisms will be specified and may include HL7 v2.x ORU w/ CDA payload, FHIR, DICOM Encapsultated CDA, or XDS.b.
:* 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 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.
:* 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.
:* There may be Named Options for transport mechanisms, in addition to a single defined/required transport mechanism.
:* 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==
==Discussion==


IHE is the correct venue for this profile for several reasons:
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.
:* 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.
:* 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.
:* 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.
:* 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'''


==Technical Approach==
CDA Content based on DICOM/HL7 Part 20. 


Base on DICOM/HL7 Part 20.   This would be a Content Profile only.
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 sections 9 and 10 for a list of all of the Sections and Entries.
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===
===Existing actors===
Report Repository
Report Reader


Content Creator
Content Creator
Line 95: Line 113:
===New actors===
===New actors===


No new actors.
No new actors, but depends on transport mechanisms probably.


===Existing transactions===
===Existing transactions===


No transactions other than standard cloud diagram above.
Intent is to reuse existing transport transactions wherever possible.
In other sections, mention possible methods of transferring data, but none are required.


===New transactions (standards used)===
===New transactions (standards used)===


No new transactions.  
 
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===
===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. 
Reference Cardiology DRPT as a base, which currently supports capturing reports using DICOM Encapsulated PDF or Encapsulated CDA, and support DICOM, XDS and ITI RID for accessing the reports. It currently mandates the the Report Creator to encapsulate the report in DICOM as the first step. Also DRPT currently uses HL7 MDM instead of ORU.
 
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.
Compliments existing profiles, not intended to change them.


===New integration profiles needed===
===New integration profiles needed===


This would be a new profile.  The exact name could either mirror Part 20, or close.
This would be a new profile.
 
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==
==Support & Resources==


Contributors/reviewers who have already agreed to assist and allot time for clinical and technical reviews:
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
:* Chuck Kahn, MD, HUP
:* Paul Nagy, Johns Hopkins
:* Paul Nagy, Johns Hopkins
:* Eliot Siegel, MD, UMD
:* Eliot Siegel, MD, UMD
:* Justin Cramer, MD, U of Utah
:* Justin Cramer, MD, Nebraska
:* Harry Solomon, GE
:* Marta Heilbrun, MD, U of Utah
:* Marta Heilbrun, MD, U of Utah
* See clinical list above, but they are busy people.


==Risks==
==Risks==


*Radiologists/clinicians do not arrive at consensus as to what should be identified as Named Options.
:* CDA might be new to the IHE TC members.
*The list of Named Options could get out of control and not be managable/meaningful/decipherable.  May need to group.
:* 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.
*To be done properly, MRRT needs additional work.
:* Someone may consider this as competing with XDS / XDS-I
* It would be almost critical to also get some time from Harry Solomon to review.
:* SDC might be new to IHE TC


==Open Issues==
==Open Issues==


* Summary section from template is missing
:* IHE Rad TC may not be very familiar with CDA description or FHIR transaction.
* Standards and System section is missing systems and not listing some standards
:* This profile has some overlap with Foreign Study Management - Direct Import proposal.
* Breakdown of tasks should include the MRRT CPs, integration with XDS.b, updates to TCE and Code Mapping Whitepaper mentioned elsewhere.


:* Consider HL7 Structured Data Capture (SDC) initiative.
:* There are two flavors, IHE SDC and FHIR SDC
:* SDC addresses both transport (HL7 and FHIR) and content
:* another alternative may be to have the SDC content be another named Option for Report Content


:* The FHIR DiagnosticReport resource seems to be compatible with the CDA content. So technically it is feasible.
:* The challenge is that FHIR is new to most existing install base


* 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.
:* the report content can be as named options. So the baseline is simple text report. Structured report content or SDC can be named option, for example.
:* 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?
:* Should this profile be integrated into FEM-DI proposal?
:* If they are not known, does this feel like it should start with a whitepaper?
:* Prefer to stay separate. FEM-DI focus on existing systems and the problem domain is more mature. This profile focus on report which is less 'stable'. Also the stakeholders are different.
:* This profile is intended to be more forward looking.


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


Responses to Issues:
Responses to Issues:
Line 228: Line 183:


Candidate Editor:
Candidate Editor:
: Teri Sippel
: Teri Sippel and Kinson Ho

Latest revision as of 10:07, 29 September 2016

Proposed Workitem: Structured Reporting Content and Transport 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


New actors

No new actors, but depends on transport mechanisms probably.

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

Reference Cardiology DRPT as a base, which currently supports capturing reports using DICOM Encapsulated PDF or Encapsulated CDA, and support DICOM, XDS and ITI RID for accessing the reports. It currently mandates the the Report Creator to encapsulate the report in DICOM as the first step. Also DRPT currently uses HL7 MDM instead of ORU.

Compliments existing profiles, not intended to change them.

New integration profiles needed

This would be a new profile.

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
  • SDC might be new to IHE TC

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.
  • Consider HL7 Structured Data Capture (SDC) initiative.
  • There are two flavors, IHE SDC and FHIR SDC
  • SDC addresses both transport (HL7 and FHIR) and content
  • another alternative may be to have the SDC content be another named Option for Report Content
  • The FHIR DiagnosticReport resource seems to be compatible with the CDA content. So technically it is feasible.
  • The challenge is that FHIR is new to most existing install base
  • the report content can be as named options. So the baseline is simple text report. Structured report content or SDC can be named option, for example.
  • Should this profile be integrated into FEM-DI proposal?
  • Prefer to stay separate. FEM-DI focus on existing systems and the problem domain is more mature. This profile focus on report which is less 'stable'. Also the stakeholders are different.
  • This profile is intended to be more forward looking.

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):

  • 30%

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=97579"