Inheriting context in a CDA document

[Category: Overall XML Syntax]
CDA Hierarchical Structure
The article What is the overall structure of a CDA document?, introduces the concept of the CDA Header and CDA Body. The article Clinical act statements, introduces the overall structure of the CDA Body - which is comprised of sections that contain entries with clinical act statements. The article Act relationship elements, discusses who clinical act statements can be related to each other.

Conceptually, then, a CDA document can be thought of as having a nested or hierarchical structure. At the top level of the hierarchy is the CDA Header. Within that is the CDA Body. Within that (for structured CDA documents) are sections. Within the sections are entries. Within the entries, the act relationships form a hierarchy of higher-level acts and nested (related) acts.

Context Inheritance Example
This consistent structure of every CDA document enables an important characteristic of CDA documents termed "content inheritance" or "context propagation". It's easiest to understand this via an example.

The languageCode XML element is a sub-element of many CDA elements (refer to The languageCode element, for additional information). However, typically in a CDA document there is only a single languageCode element located in the CDA Header in ClinicalDocument/languageCode. That language code is then part of the "context" of the overall document and is "inherited" by all contexts within that document.

Thus, there is only a need to introduce another languageCode elsewhere in the document if a different language code is needed for a particular sub-context. For example, if a particular section was going to use a different language.

Entries within a section that explicitly asserts a language code, use that language code (unless they explicitly override it). If (as is usually the case) no language code is explicitly asserted for a section, the entries in that section inherit their language code from the overall document context.

This principle of "context inheritance" is not unique to language code - it is what allows header information such as patient, author, informant, etc. to propagate from the CDA Header to all of the sections and entries within a CDA document.

Context Inheritance Properties
The properties of a CDA document that are inherited from the CDA Header include the following: author, confidentiality, data enterer, language, informant, legal authenticator, participant, and record target (patient/subject).

At the CDA Body level, it's possible to override language and confidentiality.

At the section level, it's possible to override author, confidentiality, language, informant, and subject.

At the entry level, it's possible to override author, language, informant, participant, and subject

The contextControlCode Attribute
The contextControlCode attribute is used to indicate how context inheritance should work for a given XML element of a CDA document. The elements for which the contextControlCode attribute is potentially relevant are the ones corresponding to the properties noted above (author, confidentiality, data enterer, language, etc.).

The CDA standard is part of a family of standards from HL7 called HL7 v3. All HL7 v3 standards derive from an underlying conceptual object model called the HL7 v3 RIM, which defines the "classes" and "properties" used to represent all of the clinical and clinically-relevant administrative data that the HL7 v3 standards deal with. In that conceptual model, there are different kinds of ways that propagation/inheritance of context can work in terms of what can be propagated and what can be overridden. In CDA, though, there is only one approach which is termed "overriding, propagating" and is abbreviated "OP".

For a given XML element, the XML attribute for indicating how propagation/inheritance works is named contextControlCode. In the XML Schema for CDA, contextControlCode it is always set to the fixed value "OP", which is also the default value. Thus, the contextControlCode attribute is not explicitly used in CDA documents - it just takes on the single default value "OP" (which is the only value allowed for it in CDA).

The contextConductionInd Attribute
Another attribute involved in context inheritance is named contextConductionInd. It is potentially used with component, entry, and entryRelationship elements.

If contextConductionInd is set to the "false", then context properties do NOT get inherited within that component, entry, or entryRelationship element.

As a practical matter, the contextConductionInd is fixed to the value "true" by the XML Schema for CDA in every context where it is relevant, except for one.

That one exception is the entryRelationship element in which the contextConductionInd attribute defaults to "true", but is not fixed. Thus, it is permissible to use the contextConductionInd in an entryRelationship element and set its value to "false". There are theoretical reasons why this might make sense, but as a practical matter it is rarely if ever done, and would likely confuse some receivers of the CDA document.

So, as a practical matter, contextConductionInd is not explicitly used in CDA documents either (although it may be used with entryRelationship) - it just takes on the default value "true".

Other CDA PRO Know Articles Referenced In This Article

• What is the overall structure of a CDA document?


• What does the CDA Header contain?


• Clinical act statements


• Act relationship elements


• What XML knowledge is needed for CDA work?


• The languageCode element


• What is HL7?


• What is HL7 v3?


• Does the order of XML elements matter in CDA?