Context Conduction

See also: Context Conduction in RIMBAA Applications.

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).

MnM Meeting April 16, 2009 - Las Vegas

Discussion based on Powerpoint by Gregg Seppala.

1. Need notes in context conduction that conduction flows in serialized models, and therefore must be interpreted from the perspective of "navigable" direction. Terms:
   • conductible context is the portion of the context of a given Act (a sub-set of its Act Relationships and Participations) that may be conducted to descendant Acts, depending upon the contextControlCode and contextConductionInd of the relevant associations.
   • descendant class is the one being navigated to in the ActRelationship or Participation
   • ancestor is the class from which serialization is proceeding in the association.
2. Description changes adopted:
   1. Description of contextConductionInd in ActRelationship should be "An indicator determining whether associations in the ancestor act are to be conducted across the ActRelationship to the child act."
   2. Description of contextControlCode in ActRelationship the phrase "contributes to the conductible context of the current Act" should be to "the conductible context of the "ancestor Act" ... "propagated to further descendant Acts"
   3. Description of contextControlCode in "Participation" should read "The manner in which this Participation contributes to the conductible context of the current Act, and whether it may be propagated to descendant Acts whose associations allow such propagation (see ActRelationship.contextConductionInd)."
3. It has been suggested that attribute values from the ancestor can conduct to descendant Acts (CDA specifically includes languageCode and confidentiality Code behave this way)." If this is done, it should be limited to those attributes that have "isDocumentCharacteristic='true'" (AKA "record characteristic")
4. It has been suggested that a first and fundamental simplification would be to split contextConductionCode into two attributes - one the code for the ancestor (overriding) codes, and one for the descendant impact (propagating). Further these could be simplified as a "tri-state" Boolean from data types rather than being encoded.

RESOLUTIONS:

1. Take 2005 Charlie Bishop document Context Conduction edit it mildly (per above changes) and embed it in Core Principles so that this evolution can occur in the context of the ballot.
2. Propose to change RIM Attributes for contextConduction at least "Required", perhaps "Mandatory" - This forces people to take them into account and forces older designs to deal with it. We also need to document the perils.

MnM Conference Call, June 12, 2009

Started by (again) getting our arms around the issue:

1. "Where does it matter?" - When your are placing this in a data store and want to query on it, then it begins to matter. In a single message, it is probably less critical. It is clear that Oracle is seeking to do this. BUT also just seeking an UNAMBIGUOUS instance forces one to ponder context.
2. Consider seriously Lee Coller's simplificiation of limiting to selected participation types. author, data enterer, responsible party, location subject, record target (CDA - legal authenticator, informant); act relationships - reason, component (of an encounter)
3. Should not every context of a "component" parent propagate to the components?
4. Are there not things that implicitly conduct (ie parts of a prescription) - call this inheritance - a natural thing, as opposed to an explitily stated conduction.
5. How do we identify these "natural" inheritance as opposed to documented conduction? You and I may understand it, but will we expect our software developers to do so?
6. Discussed example of representing a prescription for a drug at the top level that is handled (administered) differently in two components of that prescription. This appears to make it harder to find a "natural" inheritance.
7. Suggest that the core design (CDA-R2 sect 4.4, RX) define what it perceives to be "natural" conduction and then use contextConduction to over-ride that.
8. The notion of "natural" conduction could/should? start with a specific set of Participation types, and ActRelationship types

Core Qusetion (?):

Which ActRelationship types are most "important" or sensitive to context conduction. AND which Participations.

Alternative (lm):

What really messes up is idea of conduction. What if in a given model, there is a certain set of associations that we want to apply in "many/most" places in a model. And then build an id/idRef mechanism to bind these where needed? Candidate locales for id sets and ref sets are defined at design time.

Consensus Summary:

(Unanimously approved, moved by Woody, seconded by Gregg)

1. We should document current contextConduction in Core Principles, as noted in April meeting (based on Charlie Bishop document) and also seek a list of ActRelationship types where context conduction appears most needed/important/sensitive/relevant. (Also need clear examples here.)
2. Then, we use the "How to Query Acts" document that has been requested, but never developed, as a vehicle to understand the TRUE requirements for Context Conduction.