WADO-WS Extensions for XDS-I.b and XCA-I

1. Proposed Workitem: WADO-WS Extensions for XDS-I.b and XCA-I

Proposal Editor: Dave Franken
Editor: Dave Franken
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiology

2. The Problem

DICOM has specified two extra WADO-WS transactions over SOAP besides RetrieveImagingDocumentSet which is already profiled as RAD-69: RetrieveRenderedImagingDocumentSet and RetrieveImagingDocumentSetMetadataRequest. However, these have been deprecated by DICOM with no replacement.

WADO-URI allows the consumer to specify extra parameters to retrieve a prerendered version of the image, allowing for bandwidth and end device capability optimizations. There is currently no SOAP alternative in the IHE Radiology framework, only RAD-69 exists as a very basic alternative to WADO-URI. This means that in order to obtain a prerendered image, WADO-URI is still used mixed with regular XDS-I.b transactions; or if RAD-69 is in fact used, the original large images are transferred and they have to be rendered by Imaging Document Consumers which may not have the same capabilities as the Imaging Document Source.

Another important aspect is that RAD-69 has a Cross Community variant with RAD-75. The Cross Community problem has been not yet been properly addressed by REST based alternatives, such as WADO-RS / MHD-I. Adding RetrieveRenderedImagingDocumentSet and RetrieveImagingDocumentSetMetadataRequest to IHE Radiology will allow them to get an XCA-I variant as well. In various countries, such as The Netherlands, XCA-I is an important profile and adding the two missing WADO-WS transactions will make it more successful and useful.

3. Key Use Case

As a user, I want to be able to see prerendered images on my device with limited capabilities and be able to see images originating from other communities. Performance is important, I do not wish to wait long for all images to have been transferred. As there is already an XDS-I.b / XCA-I ecosystem in place, I would like to take advantage of it.

4. Standards and Systems

Systems that are involved are radiology systems implementing either the Imaging Document Consumer, Imaging Document Source, Initiating Imaging Gateway or Responding Imaging Gateway actor.

The added transactions originate in DICOM where they are now deprecated, the last supported version is found here: http://dicom.nema.org/medical/dicom/2017b/output/html/part18.html#sect_6.4

5. Discussion

Discussion has been held in the Google Group: https://groups.google.com/forum/#!topic/ihe-rad-tech/Itfvw4EfVA0

As the transactions are deprecated in DICOM, but certainly still useful, IHE would be the right place to incorporate them

The transactions can be added as new transaction options for existing actors