CP for MHD homeCommunityId and retrieveLocationURI support

28 views
Skip to first unread message

John Moehrke

unread,
Nov 5, 2025, 5:31:44 PMNov 5
to IHE ITI Technical Committee
Please find in the incoming folder a CP to add support to MHD for homeCommunityId and retrieveLocationURI with search parameters similar to what was added to XCA in "Target Communities" Option. This CP is submitted by IHE-EU, Founda, NHS.net, and IHE-Radiology. 


I have also crafted a Pull-Request for prototyping to see the impact
John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

John Moehrke

unread,
Nov 6, 2025, 1:10:37 PMNov 6
to IHE ITI Technical Committee
Note, I recognized that I had incorrectly referred to a retrieveLocationURI, that is actually repositoryUniqueId. In fixing that, I also updated the mapping that I had failed to update.

The CP document has been updated, as was the Pull-Request.

Looking forward to discussing this next week Tuesday on the CP call.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

Spencer LaGesse

unread,
Nov 18, 2025, 4:01:34 PMNov 18
to IHE ITI Technical Committee
I am not sure I am following the reason why the repositoryUniqueId needs to be exposed in MHD. Looking at RAD-160, it seems it only needs HCID and RetrieveLocationUID, where  RetrieveLocationUID seems to come from a DICOM manifest object and so would not be a part of standard XDS metadata. 

-Spencer

John Moehrke

unread,
Nov 18, 2025, 5:06:05 PMNov 18
to Spencer LaGesse, IHE ITI Technical Committee
Spencer,

I think your suspicions are correct. It was explained to me Rick Rusbridge that there was some confusion. His mention of RetrieveLocationUID, I had interpreted as the XDS repositoryUniqueId; where he was referring to an element in the DICOM Imaging Study Manifest.

So it would seem this extension can be removed from the CP.

Andries, can you confirm that your use-cases don't need the repositoryUniqueId? I am not fully sure that your use-case didn't have a need for this value.

Charles, can you confirm this?

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

--
You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ititech/21766392-5fde-4adc-80d4-e9b116e9140bn%40googlegroups.com.

Andries Hamster

unread,
Nov 19, 2025, 2:52:38 AMNov 19
to John Moehrke, Spencer LaGesse, IHE ITI Technical Committee
Hi John and Spencer,

There was indeed confusion (caused by me) about the retrieveLocationUID. This attribute should be derived from a manifest (XDS-I (KOS), future MADO (KOS extended) or its FHIR equivalent). However, both the homeCommunityId and the repositoryUniqueId are requested to be added to the MHD DocumentReference such that it matches an ITI-18/ITI-38 response, and a document consumer can use both to construct a request to retrieve the actual document payload in case there is a proxy/gateway component (e.g. NCP, etc.) in the network path between the consumer and the repository that holds the document. 

The current MHD profile isn't very specific where to put the repositoryUniqueID. Below is a snapshot from the "Mappings for XDS and MHD Mapping (XDS)" table that defines an ambiguous reference to the attachment.url as the attribute to contain either the repositoryUnique or a URI. 

image.png

Hence, the CP to add the repositoryUniqueId as documentReference attribute.

Best regards,

Andries Hamster

P.S. @John Moehrke is it possible to rename the homeCommunityIds to targetCommunityIdList to make it the same as defined in the XCA-I profile? 

To view this discussion visit https://groups.google.com/d/msgid/ititech/CACDGQjvGrGQtD%2BCVeFznAoSmOnJztTWV26jOJNPF-BDOJZZNTQ%40mail.gmail.com.

Spencer LaGesse

unread,
Nov 19, 2025, 10:11:30 AMNov 19
to IHE ITI Technical Committee
Andries,

The intent in MHD is that the repository ID is not exposed to the MHD Document Consumer, but is encoded in the attachment.url such that the Document Responder can determine what it needs to retrieve the document from an internal XDS community. It can do this by direct encoding or by having an internal mapping. I agree with this design decision - the Document Consumer should not need to concern itself with the internal workings of the XDS community behind the MHD Document Responder. Thus, I think we should keep the repository ID out of an explicit representation in MHD DocumentReference. 

Thanks,

Spencer

John Moehrke

unread,
Nov 19, 2025, 10:18:16 AMNov 19
to Spencer LaGesse, IHE ITI Technical Committee
I agree with Spencer. Without a use-case justification, I think the repositoryUniqueId should continue to not be exposed in MHD. Simply exposing it because it is exposed in XDS is not a use-case justification.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

To view this discussion visit https://groups.google.com/d/msgid/ititech/fb4acfd7-b5fb-4630-84d5-20041d7950aen%40googlegroups.com.

Mark Sinke

unread,
Nov 24, 2025, 5:20:39 AMNov 24
to John Moehrke, Spencer LaGesse, IHE ITI Technical Committee
I also agree that repository unique ID is not required. I also discussed this with Andries.

To retrieve the manifest, you'd "just" follow the attachment URL which could encode the repositoryUniqueId if there is an XDS/XCA backend. Adding it separately will not change that URL construction or rewrite logic.
Once the manifest is retrieved, only home (profiled in this CP) and the retrieve location UID for the images (from the manifest) matter.

In neither case would the repository unique ID as a separate entity be necessary.

Regards, Mark.


To view this discussion visit https://groups.google.com/d/msgid/ititech/CACDGQjuX8Vdfmf4X2miVP0tnvZfL23WVxAZuqty6ogrUbkJo2g%40mail.gmail.com.

cha...@interopehealth.com

unread,
Nov 24, 2025, 6:21:24 AMNov 24
to Mark Sinke, John Moehrke, Spencer LaGesse, IHE ITI Technical Committee

Mark,

 

Glad to hear from you.

 

A little clarification:  I added Retrieve URL (you should not imply that a Retrieve Location UID is required to exist.  In Mado we clearly identify that either addressing mode from the Manifest may be used.  There, if I may I suggest clarifying your statement by:

Once the manifest is retrieved, only home (profiled in this CP) and the retrieve location UID or Retrieve URL for the images (from the manifest) matter.

Regards

Charles

 

De : iti...@googlegroups.com <iti...@googlegroups.com> De la part de Mark Sinke
Envoyé : lundi 24 novembre 2025 11:20
À : John Moehrke <johnm...@gmail.com>
Cc : Spencer LaGesse <slag...@epic.com>; IHE ITI Technical Committee <iti...@googlegroups.com>
Objet : Re: [ititech:9976] Re: CP for MHD homeCommunityId and retrieveLocationURI support

 

I also agree that repository unique ID is not required. I also discussed this with Andries.

To retrieve the manifest, you'd "just" follow the attachment URL which could encode the repositoryUniqueId if there is an XDS/XCA backend. Adding it separately will not change that URL construction or rewrite logic.
Once the manifest is retrieved, only home (profiled in this CP) and the retrieve location UID for the images (from the manifest) matter.

In neither case would the repository unique ID as a separate entity be necessary.

 

Regards, Mark.

 

On Wed, Nov 19, 2025 at 4:18 PM John Moehrke <johnm...@gmail.com> wrote:

I agree with Spencer. Without a use-case justification, I think the repositoryUniqueId should continue to not be exposed in MHD. Simply exposing it because it is exposed in XDS is not a use-case justification.

 

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

 

 

On Wed, Nov 19, 2025 at 9:11 AM 'Spencer LaGesse' via IHE ITI Technical Committee <iti...@googlegroups.com> wrote:

Andries,

 

The intent in MHD is that the repository ID is not exposed to the MHD Document Consumer, but is encoded in the attachment.url such that the Document Responder can determine what it needs to retrieve the document from an internal XDS community. It can do this by direct encoding or by having an internal mapping. I agree with this design decision - the Document Consumer should not need to concern itself with the internal workings of the XDS community behind the MHD Document Responder. Thus, I think we should keep the repository ID out of an explicit representation in MHD DocumentReference. 

 

Thanks,

 

Spencer

On Wednesday, November 19, 2025 at 1:52:38 AM UTC-6 andries wrote:

Hi John and Spencer,

 

There was indeed confusion (caused by me) about the retrieveLocationUID. This attribute should be derived from a manifest (XDS-I (KOS), future MADO (KOS extended) or its FHIR equivalent). However, both the homeCommunityId and the repositoryUniqueId are requested to be added to the MHD DocumentReference such that it matches an ITI-18/ITI-38 response, and a document consumer can use both to construct a request to retrieve the actual document payload in case there is a proxy/gateway component (e.g. NCP, etc.) in the network path between the consumer and the repository that holds the document. 

 

The current MHD profile isn't very specific where to put the repositoryUniqueID. Below is a snapshot from the "Mappings for XDS and MHD Mapping (XDS)" table that defines an ambiguous reference to the attachment.url as the attribute to contain either the repositoryUnique or a URI. 

 

John Moehrke

unread,
Nov 24, 2025, 8:18:36 AMNov 24
to cha...@interopehealth.com, Mark Sinke, Spencer LaGesse, IHE ITI Technical Committee
I will remove the repositoryUniqueId, the XDS concept. All the other discussion of retrieve location UID is discussion for within IHE-RAD about the WADO processing. 


John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

John Moehrke

unread,
Nov 24, 2025, 10:21:42 AMNov 24
to cha...@interopehealth.com, Mark Sinke, Spencer LaGesse, IHE ITI Technical Committee
I have uploaded CP-ITI-1326-01.docx with the repositoryUniqueId removed, and the search parameter renamed to be more similar to the XCA search parameter.  A few other wording things as well.
https://docs.google.com/document/d/1Z4lMaeUmtarO6W6_6gXt3VfL5xg7zEpf/edit?usp=drive_link&ouid=111566682979991899107&rtpof=true&sd=true

The CP branch build is also updated

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security

Reply all
Reply to author
Forward
0 new messages