ihe / iti.topologies Goto Github PK

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

Open Issue mCSD_27

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

I think this could be useful. Some HIEs generate documents that aggregate all of the data from their children. In this case, it would be useful to know if querying the HIE provides data directly sourced from the children, or if the data provided has been processed (aggregated/deduplicated) by the HIE first.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Define multiple OrganizationAffiliation types for "data aggregator", "request gateway", etc.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Grouping of actors is mentioned in section 1:46.8.3.
Does Karen's Cross apply here? If so, how? Should OrganizationAffiliation be required?

Karen's Cross
(see 3.0 Interaction Patterns. Also described here)
is a mapping table defined by the Direct Project (not by IHE),
that tells how to get to and from different flavors of IHE Document Sharing "Push" (XDR, XDM) and the Direct Protocol.
It was done at a "whiteboard" level of detail, and resulted in specific requirements for transforming
messages more or less isomorphically from one flavor to another. Later, additional requirements
were added for encoding Direct addresses in XDR SubmissionSet.intendedRecipient. It should be noted
that the Cross is incomplete; neither Direct nor IHE has any analogous requirements for transforming,
say, an XCA Query and Retrieve response into an XDM file. XCDR and MHD Push and Pull are also missing.
That said, IHE Document Sharing profiles (not counting Direct) are generally considered similar enough that
transformations should be obvious.

So, when would Karen's Cross (or an expanded version) apply? Potentially anywhere two systems
need to translate between different Doc Sharing actors, but it's really only needed if transformations
are not obvious. Maybe it needs to be documented by IHE (especially if it's between IHE actors).
We'll look into this in a second.

But first, OrganizationAffiliation shouldn't be required, because it's orthogonal
to whether translation is needed. For example: In the directory, Org A has two Endpoints:
an MHD Document Responder and an XDS Document
Registry/Repository. Behind the scenes, the MHD actor is an adapter over the XDS actors.
This is simply two APIs to the same organization. The HCID and any other
organization or author identifiers are simply copied; there is no translation needed.

Now let's consider the other cases where there's federation to other organizations/entities
not directly reachable. OrganizationAffiliation is just one case:

• An Org allows access to others related with partOf
• An Org allows access to others related with OrganizationAffiliation
• An Org allows access to Practitioners related via mCSD links

In these cases, there might be a translation layer behind the exposed Endpoint to get to those
other entities, or there might be some other proprietary mechanism: internal EHR messaging,
direct DB access, etc.

So would Karen's Cross (or an expanded version) potentially apply? Yes, but likely only in making
sure that addressing of federated organizations/entities is clear. We have that as issue mCSD_18.

Add the gen-html file to the repo

Also rename existing async codes to WSAAsync

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

Currently, there are two profiles for Endpoint - mCSD Endpoint and mCSD Endpoint for Document Sharing.

Since ihe-endpointspecifictype is 0..*, do we need both of these, or should we consolidate them?

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Create one Endpoint profile that satisfies both needs.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

mCSD Endpoint Document Sharing Types ValueSet

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

The top level codes in this ValueSet would not be suitable for the Endpoint Specific Type extension value.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Can we include only the level 1 codes in this value set?

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

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:

1. 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.
2. 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.

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?

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

CodeSystem mCSD Endpoint Types

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

The following codes should be added to this code system:

XCPD ITI-56
Codes for PIX version 3 (existing codes are version 2)
Codes for PDQ version 3 (existing codes are version 2)

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Add codes for ITI-44, ITI-45, ITI-46, ITI-47, ITI-56

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

Open Issue mCSD_25

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

Karen's Cross, which deals with metadata mapping in document sharing profiles, does not seem relevant to this integration profile.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

update date to expected publication date, remove erroneous figure title, change * to - for bullet points, review for any other needed updates

Currently there is one code in mCSD Organization Affiliation Types. Should there be at least two, one for transparent federation vs opaque federation?
The expectations would be different: with transparent federation, federated identifiers would be
preserved in responses and respected in requests. With opaque federation, identifiers would be
consolidated/overwritten with the identifiers of the "parent" organization.

Probably, but the implications of opaque federation are complex. Some aspects may be consolidated
(e.g. golden patient record) while others are not (separate documents). Perhaps we could limit scope
to whether federated communities (Organizations with an ID of type HCID) are addressable in
requests and responses. Seeking input from reviewers.