Re: IHE RAD CP 460

[Lynn Felhofer]

Hello Andreis

I will preface this note with an observation that your post to the RAD Tech mailing list coincided with the release of IHE RAD CP Ballot 2021C containing CP-RAD-460-11, and comments on the CP will be welcomed until 21-May.   IHE RAD hopes this CP prompts input from implementers like your team, and especially from those who have real-world experience with XCA-I.     I hope that Philips will provide a ballot comment using your ideas below.

My second general comment is that as IHE RAD Tech discussed the changes in this CP, we intended to *improve*  the language and to *clarify* the original intent in both XCA-I Vol 1 and in the RAD-69 and RAD-75 transactions used by XCA-I actors.      This CP did not intend to expand the requirements for any XCA-I actor.     RAD Tech found many places where the text was unclear or incomplete, and thus the text could potentially be interpreted in different ways by different readers. 

I have added a few specific comments below.   These mine only; others on the IHE RAD Technical Committee may have other input.   

In the end, it is the comments/votes on the CP Ballot that will provide the input that IHE RAD in order to ensure that the Technical Framework is clear and accurate, and that the XCA-I profile addresses the use case of cross-community retrieve of imaging studies.

Lynn

On Apr 21, 2021, at 11:38 AM, Hamster, Andries <andries...@philips.com> wrote:

Hi Lynn and Steve,

 

I trust this mail finds you well. It has been a while since we spoke 😊

 

I am not sure if I have permission to post in the ihe-rad-tech google group. Hence my mail to you. I trust you can forward to the group.

 

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.

LYNN:  As I mentioned above, RAD Tech didn’t intend to **extend** RAD-69 in this CP.   In discussions, committee members believed that an IIG should **be able to** proxy a single request from a Consumer to multiple destinations (local Img Doc Source and one or more RGs).   

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).

LYNN:  The profile does not prohibit an Imaging Doc Consumer from issuing multiple RAD-69s, right?    The sequence diagram helps to illustrate the case where the IIG must contact multiple destinations based on one RAD-69 from the Consumer.

 

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.

LYNN:  Yes. Prior to any XCA-I RAD-69/RAD-75 retrieve transaction, the Imaging Document Consumer has already done the work to query/retrieve the DICOM Manifest(s) (KOSs) representing the study(ies) it wants to retrieve for the patient.  

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.

LYNN:  In the scenario where the Consumer wants to retrieve more than one study, potentially that reside on different Imaging Doc Sources, he CP did not intent to *mandate* that the Consumer make a single, combined RAD-69 request to the IIG.    

The updated language does clarify that, if the IIG receives such a request, that it be able to proxy the request to a local Img Doc Source and/or remote RIGs.  I believe this is the requirement that you think is unnecessary.

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.

 

LYNN:  For the Imaging Doc Consumer and IIG, this is compliant with XCA-I, before and after the current CP, right?

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.

LYNN:  CP ballot comments might determine that requiring an IIG to be able to proxy a RAD-69 request to multiple destinations is not needed (or not desirable).

 

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.