Fwd: comments on IHE RAD CP 460

Skip to first unread message

Lynn Felhofer

Apr 21, 2021, 5:21:57 PM4/21/21
to IHE Radiology Technical Committee
...forwarding these comments to ihe-rad-tech list on behalf of Philips...   

This applies to the XCA-I CP-RAD-460 released earlier today in RAD CP Ballot 2021C:

Begin forwarded message:

From: "Hamster, Andries" <andries...@philips.com>
Subject: IHE RAD CP 460
Date: April 21, 2021 at 11:38:37 AM CDT

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.
Best regards,
Andries Hamster
Senior Product Manager 
Cloud & Serviceability
Philips Interoperability Solutions, Laan van Vollenhove 2931, 3706 AK Zeist, The Netherlands
Tel: +31 6 5582 3289, Email: andries...@philips.com

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

Reply all
Reply to author
0 new messages