Report - Context Conduction in HL7 V3 (Version 2.1)

Context Conduction in HL7 v3 An Overview

Version 2.1 (Issued)

cc Clarion Consulting Limited Burnbreck House Ash Lane Costock Loughborough LE12 6UX

Tel: +44 (0) 1509 856924 Context Conduction in HL7 v3 An Overview

www.ccClarion.com

Version 2.1 (Issued) ii Context Conduction in HL7 v3 An Overview

Document Control Title Context Conduction in HL7 v3 An Overview

Version 2.1 Status Issued Author Charlie Bishop Date 24 May 2005

Version 2.1 (Issued) 3 of 11 Context Conduction in HL7 v3 An Overview

Change History

Version Date Details 0.1 2.4.05 Initial Draft 1.0 4.4.05 Minor updates for publication 2.0 27.4.05 Added participation.negationInd and minor technical corrections 2.1 24.5.05 Resolved some of the issues around the use of participation.negationInd

Contents

Change History 3 1 Introduction5

2 Attributes 6 2.1 actRelationship.contextConductionInd 6 2.2 participation.contextControlCode 6 2.3 actRelationship.contextControlCode7 2.4 participation.negationInd 7 3 Illustrations 9 3.1 Example 1 – Simple Encounter 9 3.2 Example 2 – Blood Pressure 9 3.3 Example 3 - Encounter 10

1 INTRODUCTION

This document looks at the practical working of Context Conduction within HL7 v3 messages. It is based on my personal understanding from reading the material available in the HL7 v3 Ballot Pack. Context Conduction is essentially a mechanism for avoiding repetition of certain data that may apply to multiple classes in a message. A mechanism is provided so that the data that is applied can be varied for specified parts of the message structure. An example of how this could be used is: A patient encounter is initially conducted by a clinician who assesses the patient and records his findings and diagnosis. A nurse then assists with some initial treatment before the patient is passed on to another clinician for further specialist treatment. Context conduction allows the involvement of each participant to be stated just once and conducted to all of the other activities that they were involved in. Thus the initial clinician may be stated as the ‘author’ of the overall encounter and does not need to be explicitly restated as the author of the assessment results, findings and diagnosis. There are 4 attributes that govern how and when context is conducted. These are:  actRelationship.contextConductionInd  participation.contextControlCode  actRelationship.contextControlCode  participation.negationInd These are detailed and discussed below.

ATTRIBUTES

1.1 actRelationship.contextConductionInd When set to “true”, all context of the parent act that is marked as ‘propagating’ is conducted to the associated child act. When set to “false”, no context is conducted to the associated child act. Note: The direction in which context is apparently ‘conducted’ is not necessarily consistent.  The ‘parent’ and ‘child’ are determined by the direction in which the association is traversed (ie. the direction that it has been walked to serialise the model). Context conduction between acts is thus driven by the direction of traversal.  The ‘source’ and ‘target’ are determined by the direction of the arrow. An act relationship is considered to be part of the ‘source’ and thus always has the same context as the source act.

1.2 participation.contextControlCode Provides a mechanism for specifying how participations contribute to the context of an act and whether the context may be conducted to associated child acts. The example in the Introduction is an example of how context conduction can be used with participations. This attribute is a two character code that specifies 2 aspects of the conduction behaviour: a) How this participation relates to any participation(s) of the same type that have been conducted from the act’s parent. This is represented by the first character of the code and can take one of the following values:  ‘A’ (Additive) – the association adds to any context that has been conducted from the parent act.  ‘O’ (Overriding) – the association replaces any context of the same or more specific type that has been conducted from the parent act. b) Whether this participation may be conducted to the act’s children (subject to the value of the contextConductionInd). This is represented by the second character of the code and can take one of the following values:  ‘N’ (NonPropagating) – the association applies only to this act and any context provided by the association will not be conducted to any child acts.  ‘P’ (Propagating) – the association is conducted to all child acts where the ActRelationship.contextConductionInd is set to “true” These 2 characters can be used in any combination (AN, AP, ON, OP) but note the following: ‘AN’ – the association is only added to the context of this act and is not conducted to any child acts.

‘AP’ – the association is added to the context of this act and may be conducted to any child acts. ‘ON’ – any association(s) of the same or more specific type that are conducted from the parent are replaced by this association and this association is not conducted to any child acts. ‘OP’ – any association(s) of the same or more specific type that are conducted from the parent are replaced by this association and this association may be conducted to any child acts. Note: Where an act has multiple overriding associations of the same type, they are added together to form the new context of the act (and do not override each other). Note: It is not possible to restrict different participations to only conduct across different act relationships. Either all propagating associations conduct or nothing conducts across each act relationship. Note: When an act has a combination of additive and overriding associations of the same type, then context of this type conducted from the parent is overridden and replaced with the new context provided by both the overriding and additive associations.

1.3 actRelationship.contextControlCode Specifies how a child act contributes to the context to the parent act. If context is conducted to other child acts, then this attribute also specifies whether the context provided by the child is conducted to other children. The following is a simple example of how this attribute could be used: A blood pressure is represented by a Battery that has 3 child acts – Patient position, Systolic pressure and Diastolic pressure. The context provided by the Patient position needs to be conducted to both the Systolic and Diastolic pressures but the individual pressure readings do not need to be conducted to the Patient position as they provide no appropriate context. The values and meanings of the contextControlCode for an act relationship are the same as those for participations. Note: The context provided by a child act is not conducted across the act relationship that links it to its parent act. (This does not appear to be explicitly stated but if it was conducted, it would provide context to itself and if it was then further conducted to its own children it would seem that a potentially complex recursive context could result.)

1.4 participation.negationInd This attribute is defined by HL7 as having two primary uses: “(1) To indicate that a particular Role did/should not participate in an Act. (2) To remove a participant from the context being propagated between Acts.” On the face of it this attribute provides a simple means of managing situations where different sub-sets of the overall context of the parent need to be conducted to each child act. This could be achieved by setting all of the contextControlCode

values to ‘Propagating’ and all values for contextConductionInd to “true” and then using negated participations to remove those items of context that are not required for each specific child act. However, care needs to be taken with this approach as follows:  A negated Overriding participation replaces all participations of the same type and states explicitly that this participation was not involved with the act.  A negated Additive participation of the same type as one conducted from the parent will remove that type of participation from the act  A negated Additive participation of a type not conducted from the parent will state explicitly that this participation was not involved with the act.  A negated Additive participation where more than one participation of the same type is conducted from the parent needs particular care as it may not be clear which actual participation should be removed. (see first Issue below) Issue: It is not clear whether a negated Additive participation should have the same target role, entity and other subsidiary associations and classes as the conducted participation that is being negated. If this is a requirement, then there is a potential overhead on a receiving system to perform this check and if it is not required, then the situation outlined in the last bullet point above becomes impossible to resolve. Note: This approach is only allowed for participations and will not work for act relationships, so there is some inconsistency in the approach to managing different types of context.

ILLUSTRATIONS

The following diagrammatic representation of instances illustrate the way in which context conduction works. To keep things as simple as possible, only one type of participation is shown. Solid arrows represent explicitly stated associations while dotted arrows show associations that are implied by context conduction.

1.5 Example 1 – Simple Encounter This is based on the encounter example outlined in the Introduction.

Figure 1 - Simple Encounter

 The participation of Clinician A in the Encounter is set to Override (‘O’) a participation conducted from the parent of Encounter and may Propagate (‘P’) to all children of the Encounter.  All context of Encounter is conducted to its child acts as the contextConductionInd of all act relationships is set to “true”  The participation of the Nurse in Procedure 1 is Added (‘A’) to the implied participation of Clinician A, indicating that they both had a participation of the same type.  Although the participation of Clinician A is conducted to Procedure 2, it is Overridden (‘O’) by the participation of Clinician B, indicating that only Clinician B was involved.

1.6 Example 2 – Blood Pressure This illustrates the Blood Pressure example outlined in the ActRelationship.contextControlCode section.

Figure 2 - Blood Pressure

 The relationship of PatientPosition to BloodPressure may Propagate (‘P’) to all other children of BloodPressure.  The relationships of SystolicPressure and DiastolicPressure will Not Propagate (‘N’) to the other child acts.  contextConductionInd of all act relationships is set to “true”, so any context that is set to Propagate is conducted.

1.7 Example 3 - Encounter This illustration combines examples 1 & 2 to show how the combined context is conducted.

Figure 3 - Encounter

Version 2.1 (Issued) 11 of 11