XDS Radiology Report Handling and Formatting
1. Proposed Workitem: XDS Radiology Report Handling and Formatting
- Proposal Editor: David Heaney
- Editor: <Name of candidate Lead Editor for the Profile, if known>
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
remove this tag [[Category:DomainAbbreviation]] remove this tag too
2. The Problem
The existing XDS-I.b Profile mandates that an Imaging Document Source shall support shared reports in at least one of the following 2 different formats: • CDA wrapped Text, or • PDF
The problem is that it is not very clear on exactly what such a report is (is it only final reports or all 'reports') or how to handle reports that are in DICOM SR format. If a report is received as a DICOM SR then is the Source supposed to just publish a reference to it in the Manifest, or convert it to a 'ready-for-display format', or both? If it only has to convert 'final' reports to a displayable format then how is the XDS-I Source or XDS Document Source supposed to distinguish between 'final' reports and other related documents (i.e. SR Procedure Reports)?
The ambiguity in the Standard is often raised as an implementation issue and affects connectivity. It is also raises issues for customers as they cannot be certain what the behavior of a conformant application will really be and whether it will suit their needs without further investigation.
3. Key Use Case
XDS-I Source goes to publish content. It could have a mix of 'reports' that it has received in several different formats (DICOM SR, PDF, HL7 v2.x Text, CDA, etc.). How should these various types of reports be published in a conformant manner? Even if we recognize that some flexibility should be permitted, what should the baseline behavior be and how much flexibility should be mandatory?
4. Standards and Systems
XDS-I.b CDA
5. Discussion
This issue could perhaps be addressed in a CP. It really depends upon how far we want to address the topic of radiology report formats, and the possible impact these changes could have in making current implementations non-conformant.