slagesse-epic
commented
1 year ago There's a lot here. Let me try to unpack it:
The use-case that you are trying to solve is not explained as a use-case that you are trying to solve. I think the Use-cases are:
- Given that XCPD can be us to discover patients across a complex topology of federated communities and results in a patient identifier at a HCID, there is a need to understand the organization of that the HCID identifies. Descriptive, purpose, etc.
- Given that one wants to push content directly to a given organization, there is a need to find the technical mechanism and pathway to send the content.
The goal here was to have section 2 cover this by describing example scenarios where a problem exists. But it seems the connection between the scenarios and the interoperability challenges was not clear. I've updated Section 2 to draw this connection and lay out the following problem statements:
Problem 1
How can an EMR discover the existence of outside organizations it does not have a direct trust relationship with? How can a route to request information from that organization be discovered?
Problem 2
How can Dr. Suwati's EMR discretely correlate the received documents by authoring organization? How can they be associated with the list of organizations in the organization directory that Dr. Suwati has access to?
Problem 3
How can an EMR discover the message transmission route to send a message to a provider at an outside organization which which it does not have a direct trust relationship?
Problem 4
How can a pushed message be addressed to an individual or organization within a community?
.
Note that these use-cases are very different in that one is a Query/Retrieve use-case, and another is a Push. I understand that some nationwide networks are trying to do both of these interaction models, but not everyone is. The needs of these two use-cases are very different. in the (1) case there is no need to get technical details, in the (2) case there is no need for anything but technical details. For someone trying to solve only one of these, they are not helped by the conflating of them.
I'm not quite sure I am following here. I agree that these are different use cases, and that different environments might care about only the first, only the second, neither, or both. But I am not sure how we are conflating. I think they are similar where in both cases the crux is the need for a directory that makes the network topology clear. And I am not sure that I see one as necessarily more technical than the other.
I think you should ONLY focus on XCA (i.e. not XDS alone, or MHDS alone). That is to say your problem only exists when there are multiple Communities. You do say this in 1.1, but then go on later to cover it. I think this is true of both use-cases. A single domain can use mCSD without needing to read this whitepaper. A single domain does have a need for a degenerate form of the use-cases, but it is a far more obvious problem and a far more obvious way to solve and manage it.
I agree that in the trivial case of a single community, this paper is not needed. However, I think there is value in starting by explaining the simple, trivial cases first, since the more complext cases must build on top of that. Perhaps what is needed here is simply to make it more clear what has already been explained elsewhere.
"gateway" alone should never be used, only Initiating Gateway, Responding Gateway, or Initiating/Responding Gateway.
I think the problem here is that I think we want the paper to be a little more generic than the XCPD/XCA/XCDR case, but the concepts of "initiating gateway" and "responding gateway" are only defined for those integration profiles. Right now, the word "gateway" alone and with lowercase "G" is intended to convey the general role of a system that provides access to different network levels rather than a system that behaves as any particular IHE Actor.
Other troubling uses of words: organization, domain, community.
Regarding "domain", I don't see that word being used by itself, only with "affinity domain" (used in the XDS sense), "patient identifier domain" (intended to be used in the patient linking profile sense) and to describe the ITI domain within IHE.
I am not seeing where use of the word "community" is problematic; it seems to be used with the same definition as is provided in XCPD.
I am especially troubled at the strange and implied use of "organization". It is sometimes meaning a data publishing organization, it sometimes is a data consuming organization, it sometimes is a business entity, it is sometimes a consulting/service organization, it is sometimes seems to be a home community id managing organization, it is sometimes an XDS Affinity Domain managing organization, etc.
Yes, "organization" is currently used as a general term that encompasses all of those things. I see that usage to be appropriate, and the genericness of the term matches the definition provided in the Organization FHIR resource:
A formally or informally recognized grouping of people or organizations formed for the purpose of achieving some form of collective action. Includes companies, institutions, corporations, departments, community groups, healthcare practice groups, payer/insurer, etc.
That is to say, I do not see what is troubling you here.
The current text defines basic XDS Affinity Domain, yet uses different description and different diagrams. This is normal XDS.
The current text defines a basic XDS Affinity Domain being connected using XCA, yet uses different text description and different diagrams. This is normal XCA.
The current text defines a basic XCA connecting to a organization, yet uses different text and descriptions and different diagrams. The ability for an organization to host XCA endpoints and not be and XDS Affinity Domain is normal XCA.
This paper should focus on topologies BEYOND these basic single XCA Community models. The use-case problem happens when the network gets bigger than the horizon, and you can't see what is beyond the horizon (to use a metaphor). I think if you simplify to BEYOND these basic single community models, then you can just use Community. I think everything ends up at HCID community idea. The fact that a Community might 'contain' multiple distinct business entities might need some mention, but essentially this is just nested communities regardless of if they are explicit, implicit, or hidden.
Like we discussed on the call, I agree we need to do a better job at identifying concepts that have been explained before, such as in the HIE White Paper, vs concepts that are novel to this white paper. I do think there is value in reminding the reader of how things work in the simple case before trying to build up the more complex cases.
Ultimately you never get to describing network topologies. We might not need to do this except to explain that topologies for these communities of communities might be Bus Topology, Ring Topology, Star Topology, Mesh Topology, Tree Topology, but will most likely be a hybrid Topology. Getting people to understand that there is no single topology, and that all attempts to have a single kind of topology are well intended but not likely to happen as the network grows. THIS is why solving the use-cases is needed.
I think perhaps this is hinted at but maybe not well explained. I agree something is missing here that needs to be addressed. The idea being that an individual network might start with some "pure" topology (most likely Mesh or Star) but once networks start becoming interconnected the result will be hybrid.
Message Delivery -- I don't think we use this term, do we? I think what you are defining is Push. right?
Yes, the HIE white paper simply calls this "push". I will change Message Delivery to "push" for consistency with the HIE white paper.
JohnMoehrke
The use-case that you are trying to solve is not explained as a use-case that you are trying to solve. I think the Use-cases are:
Note that these use-cases are very different in that one is a Query/Retrieve use-case, and another is a Push. I understand that some nationwide networks are trying to do both of these interaction models, but not everyone is. The needs of these two use-cases are very different. in the (1) case there is no need to get technical details, in the (2) case there is no need for anything but technical details. For someone trying to solve only one of these, they are not helped by the conflating of them.
I think you should ONLY focus on XCA (i.e. not XDS alone, or MHDS alone). That is to say your problem only exists when there are multiple Communities. You do say this in 1.1, but then go on later to cover it. I think this is true of both use-cases. A single domain can use mCSD without needing to read this whitepaper. A single domain does have a need for a degenerate form of the use-cases, but it is a far more obvious problem and a far more obvious way to solve and manage it.
The current text does not use precisely words that have meaning. "gateway" alone should never be used, only Initiating Gateway, Responding Gateway, or Initiating/Responding Gateway. Other troubling uses of words: organization, domain, community. I am especially troubled at the strange and implied use of "organization". It is sometimes meaning a data publishing organization, it sometimes is a data consuming organization, it sometimes is a business entity, it is sometimes a consulting/service organization, it is sometimes seems to be a home community id managing organization, it is sometimes an XDS Affinity Domain managing organization, etc.
The current text defines basic XDS Affinity Domain, yet uses different description and different diagrams. This is normal XDS.
The current text defines a basic XDS Affinity Domain being connected using XCA, yet uses different text description and different diagrams. This is normal XCA.
The current text defines a basic XCA connecting to a organization, yet uses different text and descriptions and different diagrams. The ability for an organization to host XCA endpoints and not be and XDS Affinity Domain is normal XCA.
This paper should focus on topologies BEYOND these basic single XCA Community models. The use-case problem happens when the network gets bigger than the horizon, and you can't see what is beyond the horizon (to use a metaphor). I think if you simplify to BEYOND these basic single community models, then you can just use Community. I think everything ends up at HCID community idea. The fact that a Community might 'contain' multiple distinct business entities might need some mention, but essentially this is just nested communities regardless of if they are explicit, implicit, or hidden.
Ultimately you never get to describing network topologies. We might not need to do this except to explain that topologies for these communities of communities might be Bus Topology, Ring Topology, Star Topology, Mesh Topology, Tree Topology, but will most likely be a hybrid Topology. Getting people to understand that there is no single topology, and that all attempts to have a single kind of topology are well intended but not likely to happen as the network grows. THIS is why solving the use-cases is needed.
Message Delivery -- I don't think we use this term, do we? I think what you are defining is Push. right?