IHE Radiology Technical Committee Change Proposal (CP) Ballot 2021C - Deadline May 21, 2021

[Nichole Knox]

IHE Radiology Technical Committee,

 

The IHE Radiology Technical Committee will be accepting votes and comments on Change Proposal (CP) Ballot 2021C for Radiology Profiles until May 21, 2021.

 

The Change Proposal (CP) and the details are linked here, https://drive.google.com/drive/folders/1Lkp3K2YNQvp5wqJ6yePYdHzHiBKtflS3 and listed below.

 

• CP-RAD-460: XCA-I Clarify IIG and RIG behavior with local community and remote communities

 

Submit your vote and comments: Votes and comments will be accepted using Google Forms. Click here to complete the form. Please note items starred (*) are mandatory.

 

Edit your responses: If necessary, you may edit your responses or forward the link to co-workers to complete your organization’s vote by multiple participants on or before May 21, 2021.  Please right click the “Edit your response” link you will receive in the confirmation notice, then copy the shortcut for use at a later time.

 

If your organization is an IHE International member, participating in this ballot will help you acquire or maintain voting rights.

 

Please contact i...@ihe.net with questions.

 

Thank you.

 

Nichole Knox

 

Radiological Society of North America
820 Jorie Blvd, Oak Brook, IL 60523
TEL 1-630-571-2670
FAX 1-630-571-7837

RSNA 2021 Annual Meeting
November 28 to December 2
Join us in-person at McCormick Place, Chicago

[Didi Davis]

Greetings all,

I promised Lynn to get some “real-world” input submitted for consideration by the committee as you deliberate on this CP.  I am contributing this information as known behavior in the US for the Carequality Community. (https://carequality.org/members-and-supporters/).  There are 29 networks live in production, exchange 150 million clinical documents monthly in the US. This input relates to exchange of CDA documents that are retrieved 1-10 documents at a time to avoid latency issues for the clinical users by all the implementers.. There are 600,000+ physicians, 50,000+ Clinics and 4,200+ Hospitals that are customers of the 29 networks in production today.  The link in the first sentence above shows the 29 live implementers and the 20 implementers in process of moving into production in the future. .  

• XCA -I Retrieve allows for the definition of multiple image IDs. In practice, this does seem not seem to be used very often (possibly due to image sizes.  There are 5 networks in process of becoming implementers to exchange DICOM Radiology images, but they are not live yet.  Please note the 5 imaging use case implementers are Ambra, Hyland, Life Image, Nuance and Phillips.  I would be happy to connect you to their technical folks to provide further input, but I have confirmed with each that they plan to limited retrieval of images in much the same manner as the other networks do with documents.   

Please let me know if I can provide further input or if you have any further questions. 

Brendan Keeler  3:46 PM

On a different topic: XCA Retrieve allows for the definition of multiple document IDs. In practice, this doesn't seem to be used very often (possibly due to document size and associated latency already being a fairly common problem with just one document per retrieve). Are people commonly retrieving multiple documents in one XCA retrieve?

Nimish Telang  3:59 PM

Yep, we do.

Nimish Telang  3:59 PM

I think we’ve found that at most 10 docs at a time is broadly supported

2 replies

Last reply 11 months agoView thread

Spencer LaGesse  4:04 PM

We only ever request one document at a time but we definitely see inbound requests for more than that (we have a max limit of 10). I'd be careful with that...some documents can be quite large and so if you request too many documents at once the messages can get too large to manage effectively. Also consider that if the document are generated on demand, requesting multiple documents can have an impact on the response time of the responding system.

Nimish Telang  4:06 PM

Our logic was that it’s better to have 1 exchange for 10 docs vs 10 exchanges for 1 doc each as it saves the overhead. Latency is not such a huge deal but # of outstanding connections can be

Brendan Keeler  4:08 PM

Right, but you're abstracting the synchronous nature away from the end user (where others might not be doing so)

4:09

If it's synchronous to the end user, latency becomes more pressing, I'd imagine

Nimish Telang  4:26 PM

yes, so it makes sense in that case to only request 1 doc per request when latency is an issue. I think it’s best to allow the requestor to determine the batching behavior, up to a limit. It’s also possible to hack something by chunking the response back but that’s a tricky part of the http spec

Joe Athman  6:13 PM

we support more than one but always recommend to anyone we work with to just do one so that we are able to return each document as soon as it’s available versus having to wait for the slowest one in the group

May 15th, 2020

Brendan Keeler  3:46 PM

On a different topic: XCA Retrieve allows for the definition of multiple document IDs. In practice, this doesn't seem to be used very often (possibly due to document size and associated latency already being a fairly common problem with just one document per retrieve). Are people commonly retrieving multiple documents in one XCA retrieve?

Nimish Telang  3:59 PM

Yep, we do.

Nimish Telang  3:59 PM

I think we’ve found that at most 10 docs at a time is broadly supported

2 replies

Last reply 11 months agoView thread

Spencer LaGesse  4:04 PM

We only ever request one document at a time but we definitely see inbound requests for more than that (we have a max limit of 10). I'd be careful with that...some documents can be quite large and so if you request too many documents at once the messages can get too large to manage effectively. Also consider that if the document are generated on demand, requesting multiple documents can have an impact on the response time of the responding system.

Nimish Telang  4:06 PM

Our logic was that it’s better to have 1 exchange for 10 docs vs 10 exchanges for 1 doc each as it saves the overhead. Latency is not such a huge deal but # of outstanding connections can be

Brendan Keeler  4:08 PM

Right, but you're abstracting the synchronous nature away from the end user (where others might not be doing so)

4:09

If it's synchronous to the end user, latency becomes more pressing, I'd imagine

Nimish Telang  4:26 PM

yes, so it makes sense in that case to only request 1 doc per request when latency is an issue. I think it’s best to allow the requestor to determine the batching behavior, up to a limit. It’s also possible to hack something by chunking the response back but that’s a tricky part of the http spec

Joe Athman  6:13 PM

we support more than one but always recommend to anyone we work with to just do one so that we are able to return each document as soon as it’s available versus having to wait for the slowest one in the group

May 15th, 2020

Brendan Keeler  3:46 PM

On a different topic: XCA Retrieve allows for the definition of multiple document IDs. In practice, this doesn't seem to be used very often (possibly due to document size and associated latency already being a fairly common problem with just one document per retrieve). Are people commonly retrieving multiple documents in one XCA retrieve?

Nimish Telang  3:59 PM

Yep, we do.

Nimish Telang  3:59 PM

I think we’ve found that at most 10 docs at a time is broadly supported

2 replies

Last reply 11 months agoView thread

Spencer LaGesse  4:04 PM

We only ever request one document at a time but we definitely see inbound requests for more than that (we have a max limit of 10). I'd be careful with that...some documents can be quite large and so if you request too many documents at once the messages can get too large to manage effectively. Also consider that if the document are generated on demand, requesting multiple documents can have an impact on the response time of the responding system.

Nimish Telang  4:06 PM

Our logic was that it’s better to have 1 exchange for 10 docs vs 10 exchanges for 1 doc each as it saves the overhead. Latency is not such a huge deal but # of outstanding connections can be

Brendan Keeler  4:08 PM

Right, but you're abstracting the synchronous nature away from the end user (where others might not be doing so)

4:09

If it's synchronous to the end user, latency becomes more pressing, I'd imagine

Nimish Telang  4:26 PM

yes, so it makes sense in that case to only request 1 doc per request when latency is an issue. I think it’s best to allow the requestor to determine the batching behavior, up to a limit. It’s also possible to hack something by chunking the response back but that’s a tricky part of the http spec

Joe Athman  6:13 PM

we support more than one but always recommend to anyone we work with to just do one so that we are able to return each document as soon as it’s available versus having to wait for the slowest one in the group

May 15th, 2020

Warmest regards,

Didi Davis
VP, Informatics, Conformance & Interoperability

The Sequoia Project® - Connected we stand!

________________________________________________________________________________________

Office: +1-865-671-1624
dda...@sequoiaproject.org | sequoiaproject.org | Twitter: @dididavis

Connect with us: Twitter | LinkedIn  | YouTube

Email Confidentiality Statement
This e-mail and any attachments transmitted with it are proprietary and confidential and legally protected from disclosure. If you are not the intended recipient, or agent of the intended recipient, you are hereby notified that any reading, use, disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message or its attachments is strictly prohibited. If you received this message in error, please notify the sender immediately and delete or destroy all copies of the message and any attachments thereto.

-- 
You received this message because you are subscribed to the Google Groups "IHE Radiology Planning Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-rad-plan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-rad-plan/CY4PR16MB162114C535779764639A8D85DC479%40CY4PR16MB1621.namprd16.prod.outlook.com.
<CP-RAD-460-CM.pdf><CP-RAD-460-CM.docx>