CP for MHD homeCommunityId and retrieveLocationURI support

7 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 PM (14 days ago) Nov 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 PM (2 days ago) Nov 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 PM (2 days ago) Nov 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 AM (yesterday) Nov 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 AM (yesterday) Nov 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 AM (yesterday) Nov 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.
Reply all
Reply to author
Forward
0 new messages