[Category: Overall XML Syntax]CDA Hierarchical StructureThe 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 ExampleThis 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 PropertiesThe 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 AttributeThe
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 AttributeAnother 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