Radiology Imaging Report Content Profile - Detailed Proposal - 2012-2013
1. Proposed Workitem: Radiology Imaging Report Content Profile
- Proposal Editor: Michel Pawlicz / Karos Health, Teri Sippel-Schmidt / Karos Health
- Editor:
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
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.
5. Discussion
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.
<DO NOT EDIT THIS FILE DIRECTLY. See Templates for instructions on using templates.>
This Delta Proposal Template is for expanding copy of a Brief Proposal into a Detailed Proposal. This template and the Detailed Proposal Template should be updated in sync.
- Paste this text into a copy of your Brief Proposal
- Move the Summary section to the end of Section 1
- Expand details in the Use Case Section
- Distribute material in the Discussion Section into the other bottom sections.
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.">
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