We have been discussing CP 460 (XDS-I) in our team (formerly Forcare) as it has come up in our test efforts for Carequality and RSNA Image Share. Reading the CP we like to question the need for the proposed change. This specifically addresses the extension of a RAD-69 transaction such it includes multiple study contexts and multiple home communities. We do agree the change that an Imaging Consumer only issues one RAD-69 request to the Initiating Gateway instead of differentiating between intra-community retrieves and cross-community retrieves.
The suggested change in the sequence diagram where a XDS Imaging Document Consumer issues one Image Retrieve request (RAD-69) to an Initiating Imaging Gateway doesn’t seem to provide a clear advantage over a scenario where the Consumer would be issuing multiple RAD-60 requests (one for each study/community combination).
Given the fact that the XDS Imaging Document Consumer has done a cross-community discovery prior to the Retrieve Imaging Document request, it “possesses” a list of XDSDocumentEntries that each reference (in an XDS-I scenario) one study/community combination since each XDS-I DocumentEntry references one KOS document that, by definition, only include references to a single study in one (imaging) repository only. In order to create the proposed RAD-69 transaction this Consumer would have to select multiple document entries (either by manual effort of a user, or by an automated approach, for example, a prefetch algorithm), and combine information from the selected documentEntries before it can issue the (new) RAD-69 transaction. As a result the Consumer has to wait until all study/images are retrieved by the Initiating Gateway before it can start processing the retrieved images. This would mean that the “slowest” responding gateway would determine the overall performance of the image retrieve (RAD-69) transaction.
In our solution we have implemented a scenario where an XDS-I Consumer always issues its RAD-69 transaction to the Initiating Gateway. The gateway then, based on the home community id in the request, determines whether to retrieve the images from an imaging document source inside the affinity domain. Or whether it forwards the RAD-69 transaction (as a RAD-75) to a remote responding gateway. The benefit of this is that in a scenario where there is a need for a “batch” retrieve of studies multiple retrieve transactions can be processed in parallel, increase the overall performance.
To cut a long story short:
1 – can you explain the (real-world) use-case that drive the need for this CP as we fail to find one.
2 – would you agree that extending RAD-69 to include multiple studies&communities is not necessary as it can be achieved by issuing multiple RAD-69 transaction each including one study&community. Doing so would mean that none of the existing XDS Imaging Document Consumer have to change their current behavior.
Looking forward to your reply.
Senior Product Manager
Cloud & Serviceability
Philips Interoperability Solutions, Laan van Vollenhove 2931, 3706 AK Zeist, The Netherlands