Difference between revisions of "Radiology Imaging Report Content Profile - Detailed Proposal - 2012-2013"

From IHE Wiki
Jump to navigation Jump to search
Line 52: Line 52:
 
The proposed content profile shall be based on HL7 CDA as the document content format.
 
The proposed content profile shall be based on HL7 CDA as the document content format.
  
==5. Discussion== REDISTRIBITE
+
Old 5. Discussion REDISTRIBUTE
  
 
The proposed content profile leans on effort underway as part of Canada Health Infoway's Standard Collaborative Working Group 10 (Diagnostic Imaging). Aligning this work with other national initiatives in the UK and Denmark, among others, by IHE Radiology saves effort and improves overall coordination and guidance. Ultimately leading to better and consistent exchange and access to DI Reports.  
 
The proposed content profile leans on effort underway as part of Canada Health Infoway's Standard Collaborative Working Group 10 (Diagnostic Imaging). Aligning this work with other national initiatives in the UK and Denmark, among others, by IHE Radiology saves effort and improves overall coordination and guidance. Ultimately leading to better and consistent exchange and access to DI Reports.  

Revision as of 04:20, 23 October 2012


1. Proposed Workitem: Radiology Imaging Report Content Profile

  • Proposal Editor: Michel Pawlicz/Karos Health, Teri Sippel Schmidt/Karos Health
  • Editor:
  • Contributors: Teri Sippel Schmidt/Karos Health, Michel Pawlicz/Karos Health, Kinson Ho/Agfa Healthcare
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

Summary

<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

2. The Problem

In many countries and jurisdictions efforts are underway to exchange imaging data across healthcare enterprises using XDS. While initially the focus of these exchanges was on achieving filmlessness, for example in Canada, the need to distribute Diagnostic Imaging (DI) results to primary care physicians is only now becoming a requirement.

In Canada, one of the key goals of the Infoway DI Program is to provide access to imaging health records to authorized care providers from anywhere and anytime regardless where the images were acquired and reports created. This includes access from simple EMR applications used at the physician offices and clinics. Access to imaging health records and in particular the DI report must be provided using standard-based protocols to facilitate EHR-EMR interoperability. However, there is no standard-based protocol defined and implemented to access imaging reports from the EMR applications.

As the countries and jurisdictions move forward with their EMR programs the distribution of hospital reports, including DI reports, is seen as a key benefit of EHR-EMR interoperability to providers. As such, they are looking for architectural guidance and on the use of standards for access to DI reports.

DI reports fall into the wider universe of clinical documents including discharge summaries, care summaries and referral notes, which follow common workflow patterns when viewed from the perspective of a primary care provider.

There is a strong business driver for a common approach to integrating structured documents into the EHR that would simplify integration of consumer systems with the EHR.

Canada, UK and Denmark among others have adopted HL7 CDA as the document content format to standardize DI Reports and have started to document and provide guidance for implementing DI Reports based on CDA. This proposal to IHE Radiology is to ensure international coordination on DI Report Content and to align already existing international efforts with the overall goal to accelerate exchange and access to DI reports from consumer systems used by primary care physicians.


3. Key Use Case

DI reports fall into the wider universe of clinical documents including discharge summaries, care summaries and referral notes, which follow common workflow patterns when viewed from the perspective of a primary care provider. Users, in particular primary care physicians, want access to DI Reports from within their EMRs regardless where the images were acquired and reports created. With the emerging availability of XDS based exchange networks common and standardize access to DI Reports must be provided for. The use case for accessing DI Reports is is similar for accessing any clinical documents and results from tests that the primary care physician has requested for his/her patient. Within XDS the user is using therefor an XDS consumer to access the DI Report that displays the information in a consistent and human readable manner, regardless which application created the report or where the report was created.


4. Standards and Systems

The proposed content profile should be aligned with existing work done in Patient Care Coordination (e.g. MS and SD). The scope of this proposal will be to review these and similar profiles and analyze what additional diagnostic report header data is needed to facilitate useful interchange. This may include attributes such as patient ID and assigning authority, accession number, procedure type, etc.

The proposed content profile should be aligned with existing work done in Cardiology (e.g. CIRC and CRC). It should be noted, however, that the cardiology reports are very discrete data intensive and focus on a single organ/single disease/single report template. Radiology, conversely, represents multiple organs/many diseases/many report templates with less discrete data, so the Cardiology examples are useful, but not a precise analogy.

The proposed content profile provides guidance for distribution and access to DI Reports aligned with XDS/XDR/XDM.

The proposed content profile shall be based on HL7 CDA as the document content format.

Old 5. Discussion REDISTRIBUTE

The proposed content profile leans on effort underway as part of Canada Health Infoway's Standard Collaborative Working Group 10 (Diagnostic Imaging). Aligning this work with other national initiatives in the UK and Denmark, among others, by IHE Radiology saves effort and improves overall coordination and guidance. Ultimately leading to better and consistent exchange and access to DI Reports.

Existing content formats used in Radiology such as DICOM SR fail to satisfy the requirements of access by simple EMRs used by primary care physicians. In addition, adoption and consistent use of DICOM SR by Radiology vendors is lacking providing significant practical implementation challenges. Alternatively PDF could be used but this doesn't leave the opportunity for structured content and future alignment with lexicon, terminology standards and report templates based on the work done by RSNA. For these reasons HL7 CDA has been chosen by Canada, Denmark and UK and is proposed as the document content format for this proposed content profile.

The scope for the coming year might only be on providing the content for the header and body and a template for basic/common DI report, however future work might include alignment with the reporting effort underway by RSNA and provide structured content based on the RSNA Report Templates project. Future effort will also ensure proper specifications of mappings for RadLex codes, although the use of RadLex codes will remain optional.

As content profile this proposal would create a new content creator and content consumer actor.

A lot of effort/work has been done by other domains that should be leveraged. Additionally, because over 35 CDA-based content modules have already been tested at the Connectathons, it is hoped that the adoption rate for this profile at the North American Connectathon in January of 2014 will be very high.

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

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

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

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