Context Conduction

Overview

At the moment, there are two attributes (contextConductionCode and contextConductionInd) which are used to convey the intended behavior of a data-model in terms of conducting context. For a detailed discussion of context conducttion and description of how it works see http://lists.hl7.org/read/attachment/72199/1/Context%20Conduction%20in%20HL7%20v3%20An%20Overview%20v2.1.doc

However there are several issues associated with context conduction, and they are discussed below.

Issue with inability to say "Add and don't conduct"

The definition for the ContextControlCode "AN" in the Vocabulary section of the ballot appears to conflict with the example given in the RIM section of the ballot for this attribute. Vocabulary: [The association adds to the existing context associated with the Act, but will not propagate to any descendant Acts reached by conducting ActRelationships (see contextControlCode). Examples: If an 'Author' Participation were marked as "Additive, Non-Propagating" it means that the author will be added to the set of author participations that have propagated from ancestor Acts for the purpose of this Act. However only the previously propagated authors will propagate to any child Acts that allow context to be propagated. ]

RIM: [A composite order is created containing a pharmacy order as well as requests for several lab tests. The composite order has participations for patient and author, and an act relationship to a diagnosis, all marked as "additive, propagating". The "component" association between the composite order and the pharmacy order is marked as conductive (contextConductionInd is TRUE). The pharmacy order has an author participation marked as "additive, non-propagating" (AN), and a reason relationship to a diagnosis, marked as "overriding, propagating" (OP). The order further has a relationship to a dispense event, marked as conductive, and an association to a drug protocol marked as non-conductive (contextConductionInd is FALSE). The meaning would be as follows: The pharmacy order is interpreted as having the patient from the composite order, and having two authors (the one from the composite order, and the one on the pharmacy order itself). The diagnosis for the pharmacy order would only be the diagnosis specified on the pharmacy order, not the one specified on the composite order. The dispense event would carry the patient from the composite order and the diagnosis from the pharmacy order, but no author. The drug protocol would not be associated with a patient, diagnosis or author. ]

The example states that the dispense event would have no author participations. I presume the reason for this is that the author participation on the pharmacy request is AN and therefore, neither the author for the composite order (AP), nor the author for the pharmacy order (AN) would be propagated to the dispense event. However the vocabulary domain value definition states that "previously propagated authors will propagate to any child Acts that allow context to be propagated". I interpret this to mean that the author for the composite order (AP) would be propagated to the dispense event, but not the author for the pharmacy order (AN). Can someone please clarify this?

The definition or description needs to be fixed. There needs to be a way to say "add this author to the current context, and then don't propagate any", but at the moment we can't do that.

Definition of "OP" needs to make clear that 'overriding' nature does not propagate

Question: I understand that ContextControlCode "OP" overrides an association with the same type code. As in the above example, where the pharmacy order has only a single reason relationship to a diagnosis, due to the OP on the relationship against the pharmacy order. That is, the reason relationship on the composite order is not conducted down to the pharmacy order. However, what would happen if the dispense event had it's own reason relationship to a diagnosis with ContextControlCode = AP? Would the dispense event then have 2 reason relationships (one inherited from the pharmacy order and one on the dispense event itself)? Or would the reason relationship on the pharmacy order (OP) override the reason relationship on the dispense event? To put it another way, is the 'overriding' part of 'overriding-propagating' conducted down from the parent act to the child act?

Lloyd response: The "overriding" vs. "additive" nature affects the context of the current node. The "propagating" vs. "non-propagating" determines whether it conducts to the next node. "overridingness" does not affect child nodes.

Need to address propagation of attributes

Some attributes such as languageCode and confidentialityCode have propagation like behaviors. However, no rules are yet defined for them

Conduction in a model with multiple entry points

There are examples of where there is a common context that is required for all entry points into the model. In particular this is the case for the patient care allergies and adverse reactions model, and is likely to be the case for other "clinical fragment" models that involve symoptoms, diagnosis, and clinical action that follows. Currently the only way to create the context is to provide a choice box as the entry point and to hang the inherited associations off the choice. This maybe ok, but does seem a bit cluncky and counter-intuitive, and has not been used by the committee, where the context is only asserted for one entry point.

How do 'mandatory', 'conformance' and 'cardinality' and other 'ad hoc' constraints relate to context conduction

For example if 3 repetitions of an association conduct with override to a class where the overridden association has a cardinality of 0..1, what happens? If context conducts to a class that has a mandatory association, is it ok to ommit the association in the child class because it propagates?

Propatation 'Up'

At the moment, propagation only occurs 'down' when navigating through a serialized model. However, there are circumstances where it would be useful to propagate 'up'. For example, if you have an Order which is a component of an encounter which in turn has a recordTarget pointing to the patient, it would be reasonable to infer that the Order had the same recordTarget (at least in some circumstances).

Possible Resolutions

1. Need to document that when performing message processing, there are three processing steps that occur before actually "processing" the instance: a) WIRE - Initial 'over-the-wire' content b) DEFAULT - Content after substitution of defaults and fixed values c) RESOLVED - Content after performing context conduction

2. Rules are as follows:

• 'required' applies at WIRE - if you need to support it, you need to support it everywhere
• 'mandatory' applies at RESOLVED
• 'cardinality' applies at WIRE
• 'ad hoc' constraints apply at RESOLVED

3. To manage different conduction, we need to be able to 'group' elements within a context and indiction for each conducting ActRelationship what groups conduct and how.

Discussion

LeeColler 19 Jul 2007:Context Conduction as it stands is far too complicated, people have a hard time grasping how it works. The proposals above do nothing to simplify the situation, and there's a lot here that will complicate the mechanism. We need to take a step back, look at the primary cases where it truly makes sense, and approach it from that direction. I know there are a lot of you that disagree, but we are running into issues where it is not understood, and it drastically needs to be simplified. I suggest as a starting point that context conduction should only ever be applied to certain participations (author/data enterer, record target, subject).