Open Issue 16: require docshare code for OrganizationAffiliation

[lukeaduncan]

In section 1:46.8.2,
we say that a hierarchy formed by Organization.partOf implies federation of (i.e. connectivity to) child
organizations. Should we? We believe this is what is done in practice. The downside is that
there would be no way to represent a hierarchical relationship that does not imply routing.
An alternative proposed design would require OrganizationAffiliation with a code
of “DocShare-federate” to be explicitly related to any parent-child relationship to imply connectivity.
We did not choose this because its impact on existing directory structures would be substantial.

[JohnMoehrke]

@jlamy I thought we agreed to remove this 'feature' of partOf. Using only OrgAff for these kinds of relationships.

[lukeaduncan]

See comments on issue #49

[jlamy]

Example org hierarchy:

• Organization OrgA
  • Endpoint: FHIR REST
  • Organization OrgB: .partOf=OrgA
    • Organization OrgC: .partOf=OrgB

If you do a query against OrgA’s endpoint, should info from OrgC be:

• Allowed (MAY)
• Forbidden (SHALL NOT)
• Expected (SHALL)
• Encouraged (SHOULD)
• Not encouraged (SHOULD NOT)
• (No position taken by FHIR Core, i.e. no documentation)

We want the IHE mCSD interpretation to be:

• Forbidden unless there is an OrgAff with federation code

Given that, what position should we want FHIR Core to take? We are thinking one of the following:

• Allowed (MAY)
• (No position taken by FHIR Core, i.e. no documentation)

We will ask FHIR Core via an issue for HL7 Patient Administration to address. We will also explain how we use OrgAff to convey connectivity, so they realize that we aren't saying there would be no way to get into for OrgC.