Before and After Phoenix Context conduction

Charlie Bishop: “Context Conduction is essentially a mechanism for avoiding repetition of certain data that may apply to multiple classes in a message” Charlie offers a definition based on the end-result: reduced message-size

Ballot rationale: “In a patient's medical record, humans will infer the report deals with the patient, even without a direct reference to the patient on the form” “computers have substantially more difficulty making such inferences” The ballot does not give a definition of context conduction itself, but offers an rationale based on intuition

Parent Child1 Child2 Child3 Child3a Context and hierarchy Intuitively: context flows from parent to child Nesting is only present in RMIM’s, HMD’s and messages on the wire In reality: it flows from element to element in the serialization tree I’ll come back to this subtle difference: not every nested element is a logical child.

Parent Child1 Child1a Child1b Child2 Origins of Context Context = Context from children + existing context coming from parent Context flows “up” from ActRels to define parent’s context, then flows down from parent to child. Note: children ALWAYS add context to the parent, the only difference is between “Adding” and “Overriding” Propagation by a parent is controlled both by the association bringing context in from a child (up) and the association propagating context down to the children (down) Confusing? Pure technically, as seen in a serialization hierarchy, it is.

A more intuitive perspective Order Author Child1 Child2 Author1 Author2 Serialization trees invite you to see the world in terms of up or down But logically, children can be more like “properties” of the parent. Please keep in mind: context only propagates down over an ActRelationship! An “overriding” conduction only overrides the parent’s context, not context from its siblings.

Order Protocol Author Child1 Child2 Author1 Author2 Conducting ActRels More confusing: context coming IN from ActRelationships. Participations always feel like “properties”, ActRelationships might relate to true “children” or acts that feel like “properties” When seen as a “property”: the ActRel would probably forbid context propagating FROM the parent. When seen as a “child”: the ActRel would probably not propagate (AN/ON) any further than the parent (so not to its sibling Acts, if any) The visio editor does not really facilitate drawing Acts as children. They all look like “properties”. But exactly WHAT context are we bringing in to a parent Act?

What is conducted? “Conducted ActRelationships behave as though the Act being navigated to is treated as though it had the same association(s) as the Act being navigated from” “Conducted Participations behave as though the Act being navigated to is treated as though it had the same association(s) as the Act being navigated from” ActRelationships and Participations are virtually “copied” to descendant acts when they are conducted. So you “repeat” the ActRel and Participation and all information content belonging to it to another Act.

The pharmacy order (2) is interpreted as having the patient (4) from the composite order (1), and having two authors (the one from the composite order, and the one on the pharmacy order itself). The labtest components of the composite order would have the CompositeOrder’s Diagnosis as reason The diagnosis for the pharmacy order relationship (9) would be the only diagnosis specified on the pharmacy order (2), not the one specified on the composite order (6). The dispense event (10) would carry the patient from the composite order (4) and the diagnosis from the pharmacy order (9), but no author. The drug protocol (11) would not be associated with a patient, diagnosis or author.

It all changed in Phoenix From the formal recommendation: Context conduction has been known to be either "broken", "impossible to understand" or "unable to meet known use-cases" almost since it was introduced. Major points of discussion in Phoenix: Conduction control: “all-or-nothing”, “up/down” It is already too difficult, so don’t add features

Conducting and Blocking Conducting relationships: Participations: all but _ParticipationAncillary ActRelationships: all but COMP, OUTC, SEQL The Participation.typeCode and ActRelationship.typeCode now determine whether the Part/ActRel conducts This is a static definition, stated in the vocab, and is determined by the “nature” of the type. Does it feel like a “property”? Every ActRelationship specifies which ActRels and Parts are blocked, otherwise they are allowed to propagate They are always “AP”, so additive. To replace a certain type of ActRel/Part you have to block & re-introduce.

The new Proposal Deprecate contextControlCode and contextConductionInd Create two attributes on ActRelationship: actRelationshipNonConducting : SET<CS>, participationNonConducting : SET<CS> Only certain Participations/ActRels conduct. We will add a concept property to indicate this. For types that conduct, they always conduct and are always additive Conduction still works by following the serialization of models actRelationshipNonConducting, participationNonConducting: No static models can prohibit the use of these attributes. Disallowing a code also disallows its subsumed codes. Always additive: (to override, you need to block and redefine). Redefinition is required if negationInd is true - and redefine participation.negationInd.

Comments? Contact me: Ewout Kramer, e.kramer@furore.com