Multiple OrganizationAffiliation Types

[slagesse-epic]

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.

[slagesse-epic]

Thinking more about this ..... do we need a way to represent that federation applies only to certain types of communication channels. For example, an Organization that provides federation to participatingOrganizations via MHD but whose XDR interface does not have said federation?

[jlamy]

If we take this to its logical conclusion, it might be simplest to handle. Just define a set of codes that call out each kind of federated routing, for example:

IHEFederationCodes

• MHD-intendedRecipient: ITI-65 can route to participatingOrganization by intendedRecipient
• XDR-intendedRecipient: ITI-41 can route to participatingOrganization by intendedRecipient
• XCDR-HCID: ITI-80 can route to participatingOrganization by HCID
• XCPD-include: ITI-55 results include participatingOrganization
• XCA-include: ITI-38 results include participatingOrganization
• MHD-include: ITI-66, ITI-67 results include participatingOrganization
• XCPD-include-opaque: ITI-55 results include information from participatingOrganization, but consolidated, not identifiable as such
• XCA-include-opaque: ITI-38 results include information from participatingOrganization, but consolidated, not identifiable as such
• MHD-include-opaque: ITI-66, ITI-67 results include information from participatingOrganization, but consolidated, not identifiable as such

We could leave out codes that would require future profiling, or add as comments:

• XCPD-target: ITI-55 can target request to participatingOrganization
• XCA-target: ITI-38 can target request to participatingOrganization
• MHD-target: ITI-66, ITI-67 can target request to participatingOrganization
• etc.

[jlamy]

Thinking about it more, we might need to split up the intendedRecipient codes:

• MHD-intendedRecipient-organization: ITI-65 can route to participatingOrganization by intendedRecipient, passing Organization.identifier
• MHD-intendedRecipient-practitioner: ITI-65 can route to practitioner within participatingOrganization by intendedRecipient, passing Practitioner.identifier

Not sure if any profiling would be needed or if mCSD already has enough breadcrumbs for what would go in the directory.