CP-1301 - Parameter homeCommunityId in [ITI-18] with patient id

[Gianluca Pavan]

Hi Sarah,

I see that the CP-1301 is now stated as "Completed" in the spreadsheet "IHE IT Infrastructure CP Tracking" and ready for the future Ballot 64.

But during the call in the F2F week we discussed with the committee that the rationale is fine but the changes proposed need to be modified (with Option on the Initiating Gateway actor and a note for the Document Consumer).

So the correct status should be "Assigned", to me or Diletta (this is not a problem), in order to edit the proposed changes as discussed with the committee.

Regards, 

Gianluca

--

Gianluca Pavan

Area Testing & Standard | Arsenàl.IT

Business Analyst

M. +39 366 7863239

gpa...@consorzioarsenal.it

[Bell, Sarah]

Hi Gianluca, thanks for catching that! I was too quick with my notes and copy+paste. Will update the spreadsheet now.

 

Sarah Bell, MA | She/Her Pronouns | Senior Informatics Specialist | T  312.915.9524

 

From: Gianluca Pavan <gpa...@consorzioarsenal.it>
Sent: Monday, May 13, 2024 5:18 AM
To: Bell, Sarah <Sarah...@himss.org>; John Moehrke <johnm...@gmail.com>; Oliver Egger <oliver...@ahdis.ch>; Luke Duncan <ldu...@path.org>
Cc: IHE ITI Technical Committee <iti...@googlegroups.com>; Diletta Babato <dba...@consorzioarsenal.it>; Gregorio Canal <gca...@consorzioarsenal.it>
Subject: CP-1301 - Parameter homeCommunityId in [ITI-18] with patient id

 

Hi Sarah, I see that the CP-1301 is now stated as "Completed" in the spreadsheet "IHE IT Infrastructure CP Tracking" and ready for the future Ballot 64. But during the call in the F2F week we discussed with the committee that

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This email originated from outside of HIMSS. Do not click links or open attachments unless you recognize the sender and know the content is safe     Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

[andries]

Hi Gianluca,

Your message drew my attention to your CP. What is the reason for this "limitation":  Each query request can have at most one homeCommunityId value. Multiple individual query requests can be used to retrieve data associated with different homeCommunityIds.

At Philips/Forcare (now Founda Health) we added a custom parameter to the ITI-18 transaction long time ago to include a list of homeCommunityIds allowing an XDS Document Consumer to "suggest" an Initiating Gateway which remote communities to forward a document query (ITI-38) to. We've built this since the number of Reponding Gateways can become quite extensive in large networks. 

We debated whether or not to use the homeCommunityId in the <AdhocQuery id="…" home="urn:oid:1.2.3" … > element. As the original text of the XCA profile wasn't clear whether or not it was allowed to use this slot, and the fact that is must contain a single value we decided to use a custom slot. 

<Slot name="$PhilipsISHomeCommunityIdList">

<ValueList>

<Value>('1.3.6.1.4.1.21367.13.20.1000.1', '1.3.6.1.4.1.21367.13.20.2000.2')</Value>

</ValueList>

</Slot>

Our XCA gateway (forBridge) evaluates this slot and if it includes homeCommunityIds that match any of the configured remote communities it will only forward the query to these. 

Hence, if we could extend the CP and remove the abovementioned limitation and allow 0,1 or * values for the  $homeCommunityId parameter it would allow us to get rid of this custom slot. 

Best regards,

Andries Hamster

[Andries Hamster]

Hi Gianluca,

I just noticed your mail below is left unanswered. Yes we would favour a new slot called $homeCommunityIdList. It would allow us to deprecate our custom defined slot ($PhilipsISHomeCommunityIdList)

Thanks

Andries Hamster

On Tue, May 21, 2024 at 9:34 AM Gianluca Pavan <gpa...@consorzioarsenal.it> wrote:

Hi Andries,

I agree that having only the homeCommunityId in the "home" attribute limits the list to only one Community ID. And I don't think that the comma ";" separator could be the "best practice".

So, do you suggest to maintain the single homeCommunityId parameter in the current query (those which have the entryUUID or uniqueId), and to create a new Slot parameter (e.g. $homeCommunityIdList) for the those which should be integrated (e.g. FidDocuments, FindDocumentByReferenceId, FindFolder, FindSubmissionSet, GetAll, etc.) ?

Regards, 

Gianluca

Il giorno ven 17 mag 2024 alle ore 17:12 Andries Hamster <and...@founda.com> ha scritto:

Hi Gianluca,

Indeed, that is why we added the custom slot that includes a comma separate list of homeCommunityIds. Would we have used the existing slot other gateways or consumers would not interpret the ',' and see the comma separate list as a single sting value. Probably with errors as a consequence.

Perhaps it is better to expand the meta-data with an additional slot that specifically is used to indicate what communities to query instead of changing the interpretation of an existing slot. The latter may lead to consumers and gateways that will "choke" on a request they do not expect to receive. 

At the time we also debated internally whether or not to use the intended recipient slot that is used in XDM/XDR. For the same "we do not want to break existing stuff" we also decided not to do so.

Thanks

Andries Hamster

On Thu, May 16, 2024 at 10:28 AM Gianluca Pavan <gpa...@consorzioarsenal.it> wrote:

Hi Andries,

The limitation of 0..1 derives from the usage of the HomeCommunityId in the "home" attribute in the <AdhocQuery> node itself. 

Beacusae, in XML, one attribute cannot be repeated and cannot have multiple values. So that, the Document Consumer can express, at most, only one homeCommunityId in the query.

The sentence wants to underline what a Document Consumer can do.

Regards, 

Gianluca

--
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 on the web visit https://groups.google.com/d/msgid/ititech/9d7ed150-b080-4106-a4fc-14a7d5b0f779n%40googlegroups.com.

--

Gianluca Pavan

Area Testing & Standard | Arsenàl.IT

Business Analyst

M. +39 366 7863239

gpa...@consorzioarsenal.it

[Diletta Babato]

Hi Andries,

I have a question with respect to your statement: Our XCA gateway (forBridge) evaluates this slot and if it includes homeCommunityIds that match any of the configured remote communities it will only forward the query to these. 

In this case, do you expect that the Initiating Gateway forwards the whole query, including the parameter: $PhilipsISHomeCommunityIdList to the Responding Gateway, or do you expect that the Initiating Gateway removes this parameter from the query directed to the Responding Gateway? How does it work in your implementation?

Because by doing as described in the first case, maybe there would be a privacy issue if every Responding Gateway learned about the identifiers of other communities to which the Initiating Gateway would send the request to.

Thank you,

Diletta

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CAObSGrDGzL90yevRV5e6W-F038NOAdshOyoTLJE1sx8kmBH29Q%40mail.gmail.com.

--

Diletta Babato

Unità Testing&Standard | Arsenàl.IT

S. live:.cid.a10e0bf2810a857a

dba...@consorzioarsenal.it 

Twitter | Google Plus | LinkedIn | YouTube

[Andries Hamster]

Hi Diletta,

Good question. I don't have a detailed answer and Mark is on vacation currently.  However, based on our product documentation it is my conclusion that we don't include this  "private" slot when forwarding an ITI-18 as an ITI-38 to a responding gateway. The private slot is supported by our XDS Consumer when using an ITI-18 transaction to our XCA Initiating Gateway. 

Although I see the privacy argument it may be a bit far fetched. What knowledge could be derived from seeing the list of homeCommunities in this slot? homeCommunities are just OIDs  with no particular meaning.

When you cascade XCA gateways, or use a XCA Gateways as a proxy to fan out an ITI-38 request it may actually be useful to include the slot in an ITI-38 request as well. Not that we have had a need for this but cascading gateways are not that uncommon. 

Best regards,

Andries Hamster

[Spencer LaGesse]

All,

I want to bring up the concerns I shared during today's CP session. 

Today, in ITI-18 and ITI-38, we have the following stored queries, which are explicitly stated to use the "home" attribute on the <AdhocQuery> element to identify the responding community:

• GetDocuments
• GetFolders
• GetAssociations
• GetDocumentsAndAssociations
• GetSubmissionSets
• GetSubmissionSetAndContents
• GetFolderAndContents
• GetFoldersForDocument
• GetRelatedDocuments

In the current specification, it is unclear what the expectation is if the "home" attribute is specified on the stored queries that specify a patient ID. Those stored queries are:

• FindDocuments
• FindSubmissionSets
• FindFolders
• FindDocumentsByReferenceId

Some implementations treat the home attribute similarly to how it is used in the other 9 stored queries, while others ignore it entirely in this case. 

With CP-ITI-1301, we would have these four stored using a completely different mechanism for specifying the target responding community, a $homeCommunityIdList slot, while the original 9 continue to use the "home" attribute on the <AdhocQuery> element. This leads to a strange inconsistency in how HCIDs are specified in ITI-18/38, and it leaves the definition of the "home" attribute on the four stored queries with patient IDs undefined. 

I am also not sure how common a use case where there is a need to target multiple communities is, since in many cases the patient ID will be community specific. 

I think to account for this inconsistency, we should:

• Make sure to define the meaning of the home attribute on the 4 stored queries with patient identifiers. We would probably need to allow both of the common existing behaviors - ignoring the parameter, and using it to route the query to a specific community as is done with the other 9 stored queries. 
• Define 3 new stored queries with the $homeCommunityIdList slot to be supported by actors that implement the new option. These queries would be:
  • FindDocumentsFromSpecificCommunities
    • This would have the $XDSDocumentEntryReferenceIdList slot as optional so that it can be used for both the original FindDocuments and newer FindDocumentsByReferenceId use cases
  • FindSbumissionSetsFromSpecificCommunities
  • FindFoldersFromSpecificCommunities

This would also mean that clients would know whether the $homeCommunityIdList slot would be respected, since if not supported then the stored query ID would be unrecognized. I would also suggest explicitly forbidding the population of the "home" attribute on these new stored queries, to prevent questions about what it means for both the "home" attribute and $homeCommunityIdList slots to be populated. 

Thanks,

Spencer

[Andries Hamster]

Hello Spencer, et. al.

I seem to have missed the "live" discussion. Let me hence respond by email.

You mention: "I am also not sure how common a use case where there is a need to target multiple communities is, since in many cases the patient ID will be community specific. ". 

Actually this is a pretty common situation in networks where there is shared patient identifier in use. In quite a few places there is a national (or provincial) patient identifier that is used by multiple (home)communities as their main patient identifier to be addressed by. In the Netherlands for example, it is even mandated by law that you must use the national patient identifier for all cross-enterprise communication. Hence, just in the Netherlands we have over 80 communities that all use the same patient identifier as key search parameter. However, apart form that there may be multiple reasons not to query all possible communities that can be accessed. Please note that there is not such thing as TEFCA/QHIN outside the US context where you can make use of a combination of XCPD and XCA to first find a correct patient identifier, and then query a QHIN using XCQ. Assume a large network of independent XCA communities where, for different reasons, there is no desire to query all XCA communities but only query a few.  I wrote a blog recently (https://www.foundahealth.com/resources/blog/xds-affinity-domains-and-xca-communities) about the different ways XCA gateways can  be (and are) used in our installed base. 

As i mentioned in some mails ago we've built this "homeCommunityList" upon request from customers that need the ability to select what communities to query. Hence, it is not an attribute that is filled in by a responding gateway, it is, on our case, use to tell an initiating gateway which remote (responding) gateways to "target". 

Although I am not against it, I would strongly prefer not to expand the list of StoredQuery as you suggest for the simpel reason that each of the current FindXXXX StoredQueries already differentiates between mandatory and optional attributes. Optional attributes can be safely ignored by gateways that do not claim support for those. Adding new StoredQueries to the list result in much more (development) work to modify existing gateways (and document consumers). Adding an addition option element will not cause many problems in most cases with existing gateways. 

Perhaps it is better to name the parameter "targetCommunityList"  to reflect the fact its intend. Somewhat similar as the "intendedRecipient" attribute defined for SubmissionSet metadata

With respect to the 4 store queries that do not include a home attribute do so because, as I recall, the home attribute in only part of the response to such stored query. The GetXXXX stored queries do have a home attribute since these need to specify from what community a document (or folder or submissionset) should be retrieved from by include the home attribute an use the value the came back with a FindXXXX store query. This is defined in the XCA profile (https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html and https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html#3.38.4.1.2.1)

Best regards,

Andries Hamster

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/387935cb-d7e2-468b-94db-739cbfe408bdn%40googlegroups.com.

[Spencer LaGesse]

Andries,

 

Thanks for the response and for the blog post. I think it does a good job at explaining the different community architectures.

 

The reason I suggest making a new stored query is because that is what we have done in the past and how FindDocumentsByReferenceId came about. Again, it seems weird and inconsistent that we would have one option (Reference ID) that specifies a new stored query (FindDocumentsByReferenceId, which is really just a copy of FindDocuments with the $XDSDocumentEntryReferenceIdList slot added) while another option  (homeCommunityId in [ITI-18] with patient identifier) that specifies support for a new optional slot on existing queries. It seems we should be consistent with how we add new slots to our queries in ITI-18/38.

 

I think the conclusion I am coming to is that the most important issue we need to address is what it means to specify the home attribute on all of the queries that don’t specify it, and if we are going to allow it on queries that have the new slot, what it means when both are specified.

 

I agree that calling the new slot “targetCommunityList” is clearer.

 

Thanks,

 

Spencer

 

From: Andries Hamster <and...@founda.com>
Sent: Friday, July 19, 2024 2:24 AM
To: Spencer LaGesse <slag...@epic.com>
Cc: IHE ITI Technical Committee <iti...@googlegroups.com>; Diletta Babato <dba...@consorzioarsenal.it>; Mark Sinke <mark....@founda.com>
Subject: Re: [ititech:9691] Re: CP-1301 - Parameter homeCommunityId in [ITI-18] with patient id

 

External Mail. Careful of links / attachments. Submit Helpdesk if unsure.

[Diletta Babato]

Thank you everyone for the important details given.
I agree with Andries regarding the patient id and that is common that it is the same across the community. Anyway, if the communities do not work with the same patient id, the patient id expressed in the ITI-18 will fit only one of the other communities reached by the ITI-38. Moreover, it is expressly defined that it is the Initiating Gateway that shall put an effort to determine the correct patient id (https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html#3.38.4.1.2.2).

I think that with regard to the possibility to introduce new stored queries, this option would have effects not only to the Initiating Gateway, but also the Responding Gateway and the Registry of the community to which the request ITI-18/ITI-38 is directed to.
On the other hand, the introduction of the slot parameter in existing queries would impact only the behavior of the Initiating Gateways that support the new option. In fact, since it is an optional parameter, the Registry of the responding community would decide to ignore it.
Moreover, this parameter does not require further effort on Registry at all compared to the ReferenceIdList parameter for which a new type of query has been introduced.
Further, by doing so, the Document Consumer would decide which community to query, and the Responding Gateway would not be involved by the use of this parameter, which should behave only as a “filter” for the Initiating Gateway to identify the communities to which direct the request to.
Therefore, the addition of new query types demands the Responding Gateway and the Registry to add effort to support the new query types only to receive a new parameter that is useless for them.

Thus, adding new types of query demands to the Responding Gateway and to the Registry to put effort to support new types of query only to receive a new parameter that does not require anything to them.

Regarding the attribute “home”, while in queries that do not require a patientId in https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html#3.38.4.1.3 it is specified what is expected from the actors Initiating Gateway and Responding Gateways, for queries that require a patient Id it is not specified what is expected from the actors about the attribute “home”. So, the introduction of the parameter would not lead to inconsistencies with what is already expected, because it would require to the Initiating Gateway an implementation conformed to what it is defined in the technical framework. And for now, beside the evaluation, or not, of the attribute "home" in queries that require a patient Id, one should expect that for these types of queries the Initiating Gateway would send the ITI-38 to all the communities.

Anyway, I agree with you that the name “targetCommunityList” for the slot parameter would be more appropriate as it would not create ambiguity with the “home” parameter.

Thanks,

Diletta

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/LV8PR17MB71105CA69C8747CD45B55470B3AD2%40LV8PR17MB7110.namprd17.prod.outlook.com.

[Spencer LaGesse]

I don’t think there is any way to avoid affecting the Responding Gateway with this new functionality. A Responding Gateway may serve multiple communities as specified in Appendix E and Andries blog post. So any solution must allow the Responding Gateway to respect the new parameter as well.

 

A new stored query type does not have to affect a Registry. Nothing prevents an Initiating or Responding Gateway from translating the query to one of the existing stored queries when they are performing an ITI-18 against a Registry. It is always the Initiating/Responding Gateway’s responsibility for determining how to interact with the systems within its community.

 

“for queries that require a patient Id it is not specified what is expected from the actors about the attribute “home”. So, the introduction of the parameter would not lead to inconsistencies with what is already expected, because it would require to the Initiating Gateway an implementation conformed to what it is defined in the technical framework.”

 

IMO, this is a problem that the CP should solve. The expectation for the home attribute should be defined on all query types. This becomes even more important if we introduce a new parameter to support multiple HCIDs.

 

Thanks,

 

Spencer

[Diletta Babato]

Hello everyone,

By considering the ideas discussed in the previous email, I think that the introduction of new transactions in which the query parameter "$targetCommunityIdList" is included, would require new implementations and an extra effort to the Document Consumer.

Using the parameter in queries that still exist would introduce an Option that should be supported only by Document Consumer, Initiating Gateway and Responding Gateway Actors that declare to support the Option.

Consider also that for example there are cases in which, despite the FindDocumentsByReferenceId type of query is defined, implementers use the "$referenceIdList" query parameter in ITI-18 FindDocuments and the Registry matches the metadata by using also this parameter as a filter. 

So, to conclude the analysis, I think that regarding the CP a solution should be:

• Introduce the optional parameter "$targetCommunityIdList" in queries which require a patientId, to indicate the communities to which the Initiating Gateway should direct the request to. By using these parameters many implementers will have the possibility to address the query to multiple communities by using only one transaction. 
• Initiating Gateway and Responding Gateway (can serve multiple communities) may support the use of this query parameter in ITI-18/ITI-38 queries by supporting a specific Option.

Moreover, I agree with the fact that the CP should explicit that the Document Consumer that supports the Option shall not use the "home" attribute in queries where the parameter "$targetCommunityIdList" is specified.

Regards,

Diletta

Il giorno gio 25 lug 2024 alle ore 09:45 Mark Sinke <mark....@founda.com> ha scritto:

Hi folks,

Jumping in after my holidays.

If I read the trail correctly, here's where we are:

* the current query set for XCA assumes that the Initiating Gateway has an out-of-band way to determine which Responding Gateways to query based on the patient identifier (including the domain); the exception is queries with no patientId; there the home attribute on the AdhocQueryRequest carries the target community ID

* we recognize that it is useful for the Document Consumer to be able to target specific communities for queries directed to the Initiating Gateway.

For practical implementation we have options:

* extend the home attribute to somehow allow multiple values (feels to me like a hack, honestly)

* adding a query parameter to existing queries (homeCommunityIdList or targetCommunityIdList)

* adding new query types carrying the new parameter

And then we need to consider on the impact to Gateways. We all agree Document Consumer can choose to use the parameter or not (that's the whole purpose of the CP), and that the Gateways can handle the parameter and translate to whatever the Registries need. So the only impact would be on Gateways. In fact, only on Initiating Gateways and - as Spencer correctly points out - Responding Gateways that front more than one domain. I.e., the gateways that would need to implement the "routing" logic.

I think this is concrete enough to put a CP together, introducing an Option for the IG/RG. Within the CP process, we can hammer out the details.

Regards, Mark.

[Mark Sinke]

Hi Diletta,

That sounds like a good summary. I like the simplicity of the approach.

Regards, Mark.

[Andries Hamster]

Agreed

[John Moehrke]

Reminder we have our CP call starting now. Please join

Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3aPi8eAzQkSYTx4LnSKGnKDT7NMNUeljRK7_Yxk_H9kF41%40thread.tacv2/1660833730129?context=%7b%22Tid%22%3a%2202a9376b-a4f9-4a63-a240-52c43ebf9a89%22%2c%22Oid%22%3a%226459fea4-110a-4d17-85f0-00587211a0c0%22%7d> Meeting ID: 225 786 389 138 Passcode: xeDyHt

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CH3PR17MB710070093AF0237A1D4B5102B3AA2%40CH3PR17MB7100.namprd17.prod.outlook.com.