Organization.partOf Should Not Imply Technical Connectivity

[slagesse-epic]

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

1:46.8

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

Currently, section 1:46.8 is written to imply that of Organization A has Organization.partOf pointed at Organization B and Organization B has endpoints defined, then data held by Organization A can be requested from Organization B, and messages directed to Organization A can be transmitted to Organization B as an intermediary.

Organization.partOf should be used purely as a means to represent business hierarchies and therefore technical communication between the two Organizations should not be assumed.

For example, if Organization A were acquired by Organization B, then Organization A is part of B, but they might remain on a separate IT system.

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.

Organization.partOf should not imply technical connectivity. It should be required that technical connectivity, if any such connectivity exists, be represented by a document sharing hierarchy.

Priority:

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

[jlamy]

Ok, I understand the point. Let me steelman it:

• Since a business partOf relationship doesn't have a code to describe it, there's no way to tell the difference between a purely business relationship and one that conveys connectivity.
• If we are going to lengths to define a "DocShare-federate" code on OrgAff, why not always use it?

Let's separate out two things that I combined in the definition for connectivity (and DocShare-federate):

• When querying, can expect to see content from child organizations (let's call this passive connectivity)
• When there's a federation targeting mechanism such as intendedRecipient, can target child orgs (let's call this active connectivity)

Here are the counters:

• I'm guessing if you were to ask most implementers: if they saw an Org with an Endpoint in a directory, with child Orgs via partOf (that didn't have Endpoints themselves), that they would expect at least the first definition to hold, or that it should be allowed without further definition.
• Current usage in directories (eHealth Exchange and Carequality at least) supports this interpretation.

So I would propose this solution:

• partOf MAY imply passive or active connectivity, and a given directory could issue policy making this a SHALL for passive, active, or both.
• A "DocShare-federate" code on OrgAff SHALL denote passive and active connectivity.

This would allow directories to adopt this new capability as needed.

[slagesse-epic]

I'm not completely sure I understand your definitions of "passive connectivity" and "active connectivity".

That being said, I do think this should be completely specified at the mCSD level and not left to policy. Leaving this to policy means that implementers of the mCSD actors can't assume that partOf does or does not imply connectivity. Furthermore, asserting that partOf does not imply connectivity does not prevent a particular ecosystem to institute a policy that says that children with a partOf relationship shall be reachable through the parent, it simply means that relationship needs to be explicitly declared via DocShare-federate OrgAff. Conversely, requiring that partOf imply connectivity prevents document sharing ecosystems from allowing business partOf relationships that don't provide connectivity.

I understand that many existing directories today are designed such that partOf implies connectivity. I think this design will make it challenging to transition to a model where business relationships need to be represented without connectivity if that ever becomes a need in those ecosystems.

[jlamy]

Here's where we agree:

• partOf should not mean "SHALL have connectivity"
• OrgAff with DocShare-federate should mean "SHALL have connectivity"

And here's where we may disagree, but I'm not really sure we do:

• I say partOf should mean "MAY have connectivity".
• You seem to be saying partOf should mean "SHALL NOT have connectivity unless accompanied by an OrgAff with DocShare-federate".

Because otherwise (i.e. you mean partOf should imply nothing about connectivity) you wouldn't object to this:

• I say a given directory should be able to assert in policy that partOf means "SHALL have connectivity".

I agree that a directory that adopts this policy is making it harder for themselves to transition to a model where business relationships need to be represented without connectivity. I'm just not conditioning their adoption of mCSD on your suggestion.

[jlamy]

Joe to link this to mCSD_13

[jlamy]

Committee: connectivity must be conveyed via OrgAff with a code.

[lukeaduncan]

Closed because it's in the Open Issue #100