Define codes for OrganizationAffiliation.code from Topologies Whitepaper

[jlamy]

Section Number Artifacts Summary

Issue We walked through and identified a handful of needed codes to support the cases in the IHE Topologies Whitepaper, but have not normatively defined them. See section 6.2.1. These mechanisms are being incorporated by HL7 National Directory, and they have had to define these codes themselves.

Proposed Change Define normative codes in mCSD for OrganizationAffiliation.code.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

[jlamy]

One case I'm not sure we have thought all the way through is a federated Initiating Gateway.

In section 4.4.5, I think communities 1.2.7 and 1.2.6 can call each others' endpoints directly (e.g. 1.2.7 can call https://community_one_two_six.org), by virtue of both having HIEInitiator relationships to Lower Network A. But they also have an Initiating Endpoint they can use (https://lower_network_a.org/lower) attached to their HIEInitiator OrgAffiliations. I think this Initiating Endpoint is ambiguous:

• Is it an internal central service inside Lower Network A to aggregate data from its members? So 1.2.7 could call it instead of calling 1.2.6 directly, and get 1.2.6 plus whatever other members of Lower Network A there are?
• Is it an initiating gateway inside Lower Network A to aggregate data from its members and the members of Upper Network?

I realize I used both concepts in section 5.1.8:

• The endpoints in Valley HIE Central Services just aggregate data from members of Valley Region HIE to each other in a single MPI and XDS RegRepo
• The endpoints in Valley BigHx Internal Initiating Gateway use XCPD and XCA to aggregate data from members of Valley Region HIE plus Big Health Exchange to members of Valley Region HIE

I guess the clients could tell them apart by whether they are cross-community profiles, but I'm uncomfortable with that being the only differentiator. Am I missing something?

[slagesse-epic]

The purpose of the Endpoint on an OrganizationAffiliation with code HIEInitiator is, at minimum, to provide an endpoint for .participatingOrganization to access .organization's Initiating Gateway to access resources from outside of the network.

The code HIEResponder's definition implies that it should be the endpoint that is available to other network members:

"This code is used to indicate that the Organization linked in .participatingOrganization is a member of the network headed by the Organization in .organization, and it has an Endpoint that accepts requests from other members of the network that have an HIEInitiator relationship with the network governing Organization**. In this case, OrganizationAffiliation.endpoint contains endpoints used by other network members to send requests to .participatingOrganization**. "

The algorithm defined in section 4.2.4.2 would prefer "https://community_one_two_six.org" over "https://lower_network_A.org/lower", though I'll admit that the word "satisfactory" is carrying a lot of weight there. The point is to say that if the endpoint is one that community 1.2.7 can communicate directly, it should use that, otherwise it should continue the algorithm (the next endpoint returned is https://lower_network_A.org).

As defined, I think HIEResponder precludes the hub and spoke model some networks use. But if we ignore that, the endpoint that 1.2.7 should use to access 1.2.6 really depends on whether or not it considers 1.2.6's HIEResponder endpoint "satisfactory". That in turn would presumably be configuration based on Lower Network A's network policy. And presumably, if Lower Network A's network policy requires a hub and spoke type model, we would expect their Initiating Gateway to return results from other network members.

I'll also note that we proposed the DocShare-federate-int code to define whether or not federation was available to other network members. Presence of that code indicates that other members of the same network can get access to data via the Initiating Gateway, while absence of the DocShare-federate-int code implies that the Initiating Gateway does not federate requests internally to that .participatingOrganization. So, I think that code removes the ambiguity, though it does look like we forgot to include consideration for this case in the algorithm provided in section 4.2.4.2.

So, TLDR:

• I don't think it is ambiguous whether the Initiating Gateway federates requests to other internal network members, this is defined by the docShare-federate-int code on OrganizationAffiliation. In this case, Community 1.2.7 cannot access Community 1.2.6 via the Initiating Gateway because Community 1.2.6 does not have a DocShare-federate-int relationship with Lower Network A. However, Community 1.2.6 can access Community 1.2.7 via the Initiating Gateway because Community 1.2.7 does have a DocShare-federate-int affiliation with Lower Network A.
• Community 1.2.7 should be able to expect to be able to use "https://community_one_two_six.org" and Community 1.2.6 should be able to expect to be able to use "https://community_one_two_seven.org" due to the definition of HIEResponder. This is potentially overly restrictive.
• I think the algorithm in section 4.2.4.2 needs to be updated to consider the DocShare-federate-int code.

[jlamy]

Thanks Spencer, I think I follow. I have a few follow ups:

• I think we agree on the meaning of HIEResponder + Endpoints on that same OrgAff.
• I think we agree on the meaning of DocShare-federate-ext + Endpoints exposed by the parent Org to the outside world.
• I think we agree that DocShare-federate-int means there is some way the .org aggregates internal data from .participatingOrgs to each other.
• But that's where I get stuck.
• (my bolding) You said "The purpose of the Endpoint on an OrganizationAffiliation with code HIEInitiator is, at minimum, to provide an endpoint for .participatingOrganization to access .organization's Initiating Gateway to access resources from outside of the network." - I don't see how that follows from this, from 4.2.2: "HIEInitiator - This code is used to indicate that the Organization linked in .participatingOrganization is a member of the network headed by the Organization in .organization, and it has permission and intent to request data from other members of the network.". This is the nub of my question. It isn't clear to me at all how an OrgAff between Lower Network A and its members says anything about the availability of data from higher level networks to which Lower Network A belongs. My diagram in 5.1.8 shows a set of PDQ/XDS endpoints that only aggregate data from inside Valley Region HIE, and another set of XCPD/XCA endpoints that also aggregate data from Big Health Exchange. I'm asking if our model can differentiate between them.
• "I think HIEResponder precludes the hub and spoke model some networks use" - yes, it would preclude an explicit hub and spoke model like TEFCA, but not an implicit hub and spoke model like eHx, where each network participant has their own endpoints that just all happen to go through Hub proxies (like Figure 4.2.3.3-1).

[slagesse-epic]

Okay, I think I understand the question now. I think when making that statement about "HIEInitiator", the intent was to imply that the Initiating Gateway is itself a member of the network, and thus .participatingOrganizations are allowed to make requests of it. And I think it is implied that the Initiating Gateway provides access to external networks, since that is how we've defined the purpose of an Initiating Gateway. In your diagram, I think the profile is the only programmatic way to distinguish between internal and external communication. This doesn't seem completely inappropriate to me - the profile is also used in other cases where the client needs to select between several different endpoints (patient query vs document query, for example). In this case, the fact that different profiles are used for internal vs external communication would be a property of how clients are supposed to interact with the Initiating Gateway/central infrastructure. Thanks, Spencer From: Joe Lamy ***@***.***> Sent: Monday, August 19, 2024 8:26 PM To: IHE/ITI.mCSD ***@***.***> Cc: Spencer LaGesse ***@***.***>; Comment ***@***.***> Subject: Re: [IHE/ITI.mCSD] Define codes for OrganizationAffiliation.code from Topologies Whitepaper (Issue #155) External Mail. Careful of links / attachments. Submit Helpdesk if unsure. Thanks Spencer, I think I follow. I have a few follow ups: * I think we agree on the meaning of HIEResponder + Endpoints on that same OrgAff. * I think we agree on the meaning of DocShare-federate-ext + Endpoints exposed by the parent Org to the outside world. * I think we agree that DocShare-federate-int means there is some way the .org aggregates internal data from .participatingOrgs to each other. * But that's where I get stuck. * (my bolding) You said "The purpose of the Endpoint on an OrganizationAffiliation with code HIEInitiator is, at minimum, to provide an endpoint for .participatingOrganization to access .organization's Initiating Gateway to access resources from outside of the network." - I don't see how that follows from this, from 4.2.2: "HIEInitiator - This code is used to indicate that the Organization linked in .participatingOrganization is a member of the network headed by the Organization in .organization, and it has permission and intent to request data from other members of the network.". This is the nub of my question. It isn't clear to me at all how an OrgAff between Lower Network A and its members says anything about the availability of data from higher level networks to which Lower Network A belongs. My diagram in 5.1.8 shows a set of PDQ/XDS endpoints that only aggregate data from inside Valley Region HIE, and another set of XCPD/XCA endpoints that also aggregate data from Big Healoth Exchange. I'm asking if our model can differentiate between them. * "I think HIEResponder precludes the hub and spoke model some networks use" - yes, it would preclude an explicit hub and spoke model like TEFCA, but not an implicit hub and spoke model like eHx, where each network participant has their own endpoints that just all happen to go through Hub proxies (like Figure 4.2.3.3-1). - Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/IHE/ITI.mCSD/issues/155*issuecomment-2297789552__;Iw!!BJMh1g!_A5wZKOf1t-uHhG0PAF0V9L0Pe0vLHZoQebB5sI9W4216w4_dq2AhyTcDexev2T42VrNAbgdHxXsafcv9sQzDg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AQLZHQOAOSMMAKDGB3BEUJDZSKLJPAVCNFSM6AAAAABMTFCGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJXG44DSNJVGI__;!!BJMh1g!_A5wZKOf1t-uHhG0PAF0V9L0Pe0vLHZoQebB5sI9W4216w4_dq2AhyTcDexev2T42VrNAbgdHxXsafeLtRpo6g$>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>