DraftCheck

Editing tips and notes

Return to master table of contents

1 CDA Overview

1.1 What is the CDA

The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is documentation of clinical observations and services, with the following characteristics:

• Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document exchange expression).
• Stewardship – A clinical document is maintained by an organization entrusted with its care.
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
• Context – A clinical document establishes the default context for its contents.
• Wholeness – Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
• Human readability – A clinical document is human readable.

A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.

1.1.1 Key aspects of the CDA

Key aspects of the CDA include:

• CDA documents are encoded in Extensible Markup Language (XML). (NOTE: When alternate implementations are feasible, suitable conformance requirements will be issued so that in future the syntax may not be limited to XML.)
• CDA documents derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types Release 1.0.
• The CDA specification is richly expressive and flexible. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification (see The "A" in "CDA" and Section 4 CDA Implementation Guides .

1.1.2 Scope of the CDA

The scope of the CDA is the standardization of clinical documents for exchange. The prior notion of "clinical documents" is evolving as the use of CDA is expanding. Clinical documents is meant broadly to cover documents generated not only by clinicians, but also documents generated by patients and caregivers as well as documents generated by payers and other stakeholders who are sharing health-related content.

The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification.

CDA documents can be transmitted using a variety of techniques, E.g. HL7 2.x messages, V3.0 messages, FHIR messages, Direct and Exchange solutions, etc. While the detailed specification for such messages and solutions are outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in all of these and other contexts (see CDA Document Exchange).

The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Model in a document authoring environment, such use is not the primary purpose of the CDA specification.

Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. (For more on this, see Relationship of the CDA to HL7 Messaging Standards).

NOTE: Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions.

1.1.3 Goals and Design Principles

The goals of the CDA are:

• Give priority to delivery of patient care.
• Allow cost effective implementation across as wide a spectrum of systems as possible.
• Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
• Promote longevity of all information encoded according to this architecture.
• Enable a wide range of post-exchange processing applications.
• Be compatible with a wide range of document creation applications.
• Promote exchange that is independent of the underlying transfer or storage mechanism.
• Prepare the design reasonably quickly.
• Enable policy-makers to control their own information requirements without extension to this specification.

A number of design principles follow from consideration of the above goals:

• This architecture must be compatible with XML and the HL7 RIM.
• This architecture must be compatible with representations of clinical information arising from other HL7 committees.
• Technical barriers to use of the architecture should be minimized.
• The architecture specifies the representation of instances required for exchange.
• The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
• The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
• Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
• Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
• CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard stylesheet language, such as XSLT.
• Use open standards.

1.2 General CDA Concepts

1.2.1 Major Components of a CDA Document

This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow.

Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See Samples for a detailed conformant example).

A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see Header) and a body (see Body). The header lies between the <ClinicalDocument> and the <structuredBody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. Information provided in the header establishes context for the content contained in the document body.

The body contains the clinical report, and can be either an unstructured blob (e.g., a base-64 encoded PDF), or can be comprised of structured markup. The example shows a structured body, which is wrapped by the <structuredBody> element, and which is divided up into recursively nestable <section> elements.

A CDA document section is wrapped by the <section> element. Each section can contain a single <text> element representing the section's narrative (see Section Narrative Block). Sections can nest within other sections to logically group and organize the information in the document. Sections may contain any number of CDA entries (see Entry Acts) and external references.

The CDA narrative block is wrapped by the <text> element within the <section> element, and must contain the human readable content to be rendered. The relationship between human readable content and machine readable entries is enabled via a text linking mechanism. See also Human Readability and Rendering CDA Documents and CDA Conformance for principles governing the representation of the narrative block, and conformance requirements on the part of originators when populating the block, and recipients when rendering it.

Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two <observation> CDA entries, and a <substanceAdministration> entry containing a nested <supply> entry, although several other CDA entries are defined.

CDA entries can nest and optionally reference external objects. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the <externalObservation> element). Externally referenced material is not covered by the authentication of the document referencing it.

Example 1 - highlights the elements that might appear in CDA document, it does not include all required elements.

Example X

<ClinicalDocument>
  ... CDA Header ...
  <structuredBody>
    <section>
      <text>...</text>
      <observation>...</observation>
      <substanceAdministration>
        <supply>...</supply>
      </substanceAdministration>
      <observation>
        <externalObservation>...
        </externalObservation>
      </observation>
    </section>
    <section>
        <section>...</section>
    </section>
  </structuredBody>
</ClinicalDocument>

1.2.2 The "A" in "CDA"

The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML Schemas to achieve the goals enumerated above (see Goals and Design Principles). This hierarchy formed an "architecture", hence the "A" in "CDA".

Table X: Evolution of CDA "levels" from CDA, Release One to CDA, Release Two

CDA, Release One	CDA, Release Two
CDA Level One	The unconstrained CDA.
CDA Level Two	The CDA specification with section-level templates applied, with no expectation of entry-level templates being present.
CDA Level Three	The CDA specification with at least one section containing one or more entry-level templates.

While the notion of levels in CDA, Release Two remains constant, the approach to representing the hierarchies has changed. The current specification consists of a single CDA XML Schema, and the architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which serve to constrain the richness and flexibility of CDA.

The RIM's InfrastructureRoot class contains an attribute, templateId, which is available for use in CDA. Where templateId(s) have been asserted within a CDA document instance, the constraints contained within the template are assumed to be imposed. See Section 4 CDA Templating for more details.

There is no requirement that CDA must be constrained, however implementations that use structured data elements to drive automated processes will typically reference templates found in CDA Implementation Guide(s). The use of entry-level templates enables the semantic interoperability of any structured content found in documents exchanged.

There are many kinds of HL7 Templates that might be created. Among them, three are particularly relevant for clinical documents: (1) those that constrain the document content or document-level templates, (2) those that constrain content expected in sections or section-level templates and (3) those that constrain the entries within document sections or entry-level templates. Other kinds of templates can be used, for example to enable consistency in demographic data and the representation of names, addresses and telecom references, or phone numbers.

An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here:

Example X

• CDA Base Standard
  • Progress Note section-level template applied.
    • Progress Note section-level and Vital Signs entry-level template applied.
      • Endocrinology Progress Note section-level and Vital Signs entry-level template applied.
      • Progress Note section-level and ICU Vital Signs entry-level template applied.
  • Cardiology Progress Note section-level template applied
  • Cardiology Progress Note section-level and Cardiac Exam entry-level template applied.
  • Endocrinology Progress Note section-level template applied.
  • Endocrinology Progress Note section-level and Vital Signs entry-level template applied.

1.2.3 Human Readability and Rendering CDA Documents

The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release 2.1, with its blend of narrative and CDA entries, presents challenges to this requirement. Among the requirements affecting the design of CDA Release 2.1 are the following:

• There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
  • Authenticated documents, need to convey with fidelity the clinical content reviewed by the legal and other authenticator(s).
  • Documents which are not authenticated, (e.g. machine generated documents) should convey the clinical content implied by the ClinicalDocument.code and the other header metadata in the document's section.text elements.
• Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools.
• Human readability applies to the authenticated narrative content. There may be additional information conveyed in the entries that is not required for human interpretation, but at no time shall the information provided in the entries conflict with the narrative content.
• When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
• When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.

These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.text field (see Section Narrative Block). The content model of this field is specially hand crafted to meet the above requirements, and corresponds closely to the content model of sections in CDA, Release One. Structured observations can reference narrative content in the Section.text field. Multimedia observations are encoded outside the Section.text field, and the <renderMultiMedia> tag within the Section.text field provides an outgoing pointer that indicates where the referenced multimedia should be rendered.

1.2.4 XML Markup of CDA Documents

XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the CDA Schema and may be subject to additional validation (see CDA Conformance). There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming instances are compatible.

Design Principles of the CDA Schema include:

• General Requirements: The design of the CDA Schema follows the more general requirements for CDA (see Goals and Design Principles).
• CDA Schema and V3 Implementation Technology Specification (ITS) : The CDA Schema will follow the general V3 XML ITS.
• RIM Mapping: The CDA Schema describes the style of XML markup of CDA instances for the purpose of exchange. It cannot be understood outside the context of this defining specification. At the same time, the CDA Schema is useful on its own for implementation purposes even though it is not intended to replicate or take the place of the R-MIM and HD. The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM.
• Document Analysis: The CDA Schema and conformant instances should adhere to the requirements of document analysis in derivation of the content model.

  NOTE: Document analysis is a process that might be thought of as the document equivalent of a use case. Document analysis looks at a single instance or class of documents and analyzes their structure and content, often representing this as a tree structure "elm" notation. Document analysis also looks at the business rules for the lifecycle of that document or document class. Traditionally, document analysis determines the content model and overall structure and style of XML.

  Document analysis is an iterative step in content model derivation -- the "bottom up" approach to complement the "top down" derivation from the RIM. This will ensure that schemas and instances are not only RIM-derived, but represent recognizable artifacts in a simple manner.

• Forward and Backward Compatibility: The CDA Schema should adhere to the requirements for forward and backward compatibility. (See Backwards and Forwards Compatibility)
• Naming: While XML markup, by definition, is for machine processing, it should be optimized for human review, debug, and design. The CDA Schema is not "self-documenting", but meaning should be clear from tag name and documentation (e.g., mapping to RIM). The human-language sense of a tag name should not be counterintuitive.
• Vocabulary: Vocabulary can be enumerated within the CDA Schema or in an external, referenced source. It is preferable to enumerate it when the vocabulary terms are both limited (not too large in number) and stable (not subject to change between ballot cycles). Where vocabulary is either too large or is subject to change, it is preferable to maintain it external to the CDA Schema and incorporate it by reference. In these cases, XML schema validation will not suffice for conformance.

1.2.5 Security, Confidentiality, and Data Integrity

Application systems sending and receiving CDA documents are responsible for meeting all legal requirements for document authentication, confidentiality, and retention. For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.

The CDA does provide confidentiality status information to aid application systems in managing access to sensitive data. Confidentiality status may apply to the entire document or to specified segments of the document.

1.2.6 Relationship of the CDA to HL7 Messaging Standards

A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 message (see CDA Document Exchange in HL7 Messages). Thus, the CDA complements HL7 messaging specifications.

Clinical documents can be revised, and they can be appended to existing documents. CDA does not support an explicit forward pointer from an outdated version to the newer version. Without a process that tracks the chain of custody of clinical documents and all of their copies, there can be no way to guarantee that a clinical document being viewed has not been subsequently revised.

To minimize the risk of viewing superseded information, there is a critical interdependence between clinical documents and document management systems. If CDA documents are viewed outside the context of a document management system, it cannot be known with certainty whether or not the viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual information that ensures accurate viewing of clinical data.

1.3 CDA Conformance

NOTE: See HL7 V3 Refinement and Localization for a complete discussion of V3 conformance.

A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. However a computer cannot validate every aspect of conformance. The focus of this section is to highlight these aspects of CDA that cannot be machine validated - particularly those aspects related to the CDA human readability requirements.

A document originator is an application role that creates a CDA document. CDA documents can be created via transformation from some other format, as a direct output of an authoring application, etc. The document originator often is responsible for communicating with a persistent storage location, often using HL7 V2 MDM or HL7 V3 Medical Records messages. The document originator is responsible for ensuring that generated CDA documents are fully conformant to this specification.

A document recipient is an application role that receives status updates and documents from a document originator or document management system. The document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification.

Because CDA is an exchange standard and may not represent the original form of a document, there are no persistent storage requirements for CDA documents defined in this standard. However, as noted above (see Relationship of the CDA to HL7 Messaging Standards), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see custodian) is the participant charged with maintaining the original document, which may be in some form other than CDA.

1.3.1 Recipient Responsibilities

• Assume default values where they are defined in this specification, and where the instance does not contain a value : Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance. (NOTE: These values have been identified as having Minimum Cardinality = 0 and code binding = "Fixed" or "Closed w/ Default".)
• Parse and interpret the complete CDA header : A recipient of a CDA document must be able to parse and interpret the complete CDA header. Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient. In addition, rendering of the CDA document header can be dependent on local business practice and context of use (e.g. electronic health record, de-identified scenario). However, extreme caution must be exercised if patient-identifying header information (e.g., name, address, data of birth, gender...) from the CDA document are not rendered. Those elements, if different, may indicate a patient mismatch or may indicate data discrepancies that should be analyzed and reconciled. Where a document originator wants to suggest a rendering, they can include one or more XML style sheets with an exchanged CDA document. Use of these style sheets is at the discretion of the recipient.
• Parse and interpret the CDA body sufficiently to be able to render it : A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules:
  • If the CDA Body is non-XML, it will need to be rendered with a software tool that recognizes its particular MIME media type.
  • If the CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section.
  • If the CDA Body is structured, the contents of the Section.text field must rendered per the rules defined in Section Narrative Block.
• A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body. Within a local implementation, trading partners may ascribe additional recipient responsibilities to parse and interpret various entries.
• A recipient of a CDA document is not required to validate a CDA document against referenced templates. Within a local implementation, trading partners may ascribe additional recipient responsibilities for template validation.

1.3.2 Originator Responsibilities

• Properly construct CDA Narrative Blocks : An originator of a CDA document must ensure that the attested portion of the document body is structured such that a recipient, adhering to the recipient responsibilities above, will correctly render the document. This includes:
  • If the CDA Body is structured, the label of a section must be conveyed in the Section.title component. The absence of the Section.title component signifies an unlabeled section.
  • If the CDA Body is structured, the attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced in the narrative must be added as ObservationMedia and/or RegionOfInterest CDA entries.
  • If the CDA Body is structured, the contents of the Section.text field must be created per the rules defined in Section Narrative Block.
• An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within a local implementation, trading partners may ascribe additional originator responsibilities to create various entries.

1.4 CDA Extensibility

NOTE: See XML ITS - Informal Extensions for a complete discussion of V3 XML Extensibility rules.

Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging content for local requirements. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.

Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must not be included within an element of type ED (e.g., <text> within <procedure>) since the contents of an ED datatype within the conformant document may be in a different namespace. Since all conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any extension content into a foreign namespace (any namespace other than the HL7 namespace). Receiving systems must not report an error if such extensions are present.

When these extension mechanisms mark up content of general relevance, HL7 encourages users to get their requirements formalized in a subsequent version of the standard so as to maximize the use of shared semantics.

1.5 Backwards and Forwards Compatibility

NOTE: A detailed list of all changes between CDA, Release 2.0 and CDA, Release 2.1 can be found in the appendix (see Changes from CDA Release 2.0).

CDA Release 2.1 represents a minor dot release enhancement to the CDA Release 2.0 standard. As such, the changes introduced into the CDA R2.1 schema should not generate errors when processing a legacy CDA R2.0 document instance. However, with the inclusion of new RIM attributes and RIM structural vocabulary (Class Codes, Mood Codes and Type Codes) CDA R2.1 will likely require changes to implementation guides previously based on CDA R2.0, when citing CDA R2.1 as their base. The enhancements provided are intended to reduce the usage of previous extensions and improve the semantic modeling capabilities found in CDA.

The following updates have been made to the CDA document model. These include, but are not necessarily limited to:

1. CDA R2.0 errata will be included
2. Extensions previously required and cited by CDA Implementation Guides
3. Attributes omitted from the classes derived from the RIM, where use cases exist for their inclusion
4. Additional values to value sets such as Mood codes, will be considered to ensure consistency with modeling from other committees
5. The inclusion of tables within tables in the narrative block will be considered as a minor presentation markup change.
6. Include current language about bindings if appropriate
7. Additional informative content will be considered for a number of topics:
   1. CDA Implementation Guides and Templating
   2. Vocabulary Binding Syntax in CDA
   3. Exchanging CDA documents

This section describes the types of changes that can be introduced to a new release of CDA and CDA principles of forward and backward compatibility. In general, changes can include the addition of new components; a renaming of components (including XML element and attribute names in the CDA Schema); a deprecation of components defined in a prior release; a change in cardinality of a component (to loosen); or a change in a vocabulary domain of a component {to add or change values, to change between Open (CWE) and Closed (CNE)}. The following set of guiding principles defines how CDA can continue to evolve, while protecting the investment implementers have made through their adoption of earlier releases.

• Documentation : A new release of CDA will enumerate all substantive changes from the previous release.
• Attested content : Attested, human readable content must be completely loss-less across CDA releases. Backwards and forwards compatibility on the attested content will be supported such that it will be possible for an automated transformation script to translate the human readable content in both directions.
• New components : A new release of CDA can introduce new components. To preserve roundtrip translation capability, a translation from the new release to a prior release must represent the new components as extensions (e.g. local markup or local namespace).
• Renaming : A new release of CDA can rename components (including XML element and attribute names). Where this occurs, a mapping table will list all changes. Renaming will adhere to the naming convention articulated above (see XML Markup of CDA Documents).
• Deprecated components : A new release of CDA can deprecate components defined in a prior release. Deprecated components will be removed from the subsequent release of the standard, and therefore their use is not recommended.
• Cardinality : A new release of CDA can change the cardinality of a component. Where an optional component becomes required, a translation between releases requires a dummy value or a null value.
• Changes to vocabulary domain : A new release of CDA can change the vocabulary domain of a component. Where this occurs, a mapping table will list changes.
• Change within Closed (CNE) : Where a value in a Closed (CNE) domain in a prior release is no longer present or has been renamed, a mapping table will indicate what the current value should be.
• Change within Open (CWE) : When a CWE domain is expanded, users should begin using the new codes in addition to any equivalent local codes they may already be using.
• Change from Open (CWE) to Closed (CNE) : To preserve roundtrip translation capability, a translation between releases must represent unrecognized components as extensions (e.g. local markup or local namespace). Ideally these situations will surface during a ballot cycle, allowing the Closed (CNE) domain to be sufficiently inclusive.

These guiding principles have lead to the current approach, defined in this Release 2.1 of the CDA standard. The goal is to ensure that the documents created using Release 2.0 can be processed by implementation adopting CDA R2.1 (with legacy extension references) with no loss of machine processable content or loss of attested, human-readable content.

2 Introduction to CDA Technical Artifacts

A complete understanding of CDA requires an understanding of the normative artifacts used to define the specification. The CDA Hierarchical Description is the definitive source for CDA conformance rules and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description. The CDA Hierarchical Description is derived from the CDA R-MIM, which in turn is derived from the HL7 Reference Information Model (RIM). The HL7 RIM is the definitive source for class and attribute definitions.

The following sections summarize the artifacts used by CDA, and how they can be used by those seeking to implement or understand the CDA specification.

2.1 HL7 Reference Information Model

The definitive description of the HL7 Reference Information Model can be found here.

The HL7 RIM is the definitive reference source for class and attribute definitions. The CDA specification does not exhaustively replicate RIM definitions, but instead refers the reader to the RIM for complete definitions. While CDA may further constrain RIM definitions, at no time will CDA definitions conflict with those in the RIM.

CDA, Release Two is derived from Release-4 of the ANSI Normative RIM I.e. Version 2.35.

Where a reader needs to see the complete definition of a RIM attribute or class, they should refer to the HL7 RIM.

2.2 HL7 V3 Data Types

HL7 defines both an abstract data type specification, which is the definitive reference, and an XML-specific data type representation.

Data types define the structural format of the data carried within a RIM attribute and influence the set of allowable values an attribute may assume. Some data types have very little intrinsic semantic content. However HL7 also defines more extensive data types such as the one for an entity's name. Every attribute in the RIM is associated with one and only one data type.

CDA, Release Two uses the HL7 V3 Data Types, Release One abstract and XML-specific specification.

A reader will often find that the XML-specific description of a data type is sufficient for implementation, but at times will want to refer to the abstract data type specification for a more comprehensive discussion.

2.3 HL7 Vocabulary Domains

Change to: Vocabulary Use in CDA

The definitive description of HL7 V3 Vocabulary Domains can be found here.

Vocabulary domains represent value sets for coded CDA components. These domains can include HL7-defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED. The HL7 Vocabulary chapter is the definitive reference source for the definitions of HL7-defined concepts. In this specification, references to code bindings using "D:concept-domain" indicates that a concept domain has been specified and the documentation defined in the RIM Vocabulary chapter should be referenced for an understanding of the code systems to be used when creating a CDA document.

Value sets referenced in CDA R2.1 can be found here. An alternative to Concept Domain binding, the value set binding allows for a defined set of codes from one or more code systems to be bound to a CDA coded attribute. In this specification references to using "V:value set" indicates that a value set has been specified. Note: A number of value set bindings have been specified using "<= code", where the "<=" binding indicates that the value set is defined as a given code and all of it's descendant (subtype) coded concepts within the specified code system. In Section 5, those bindings include a reference to the value set specification for the reader's convenience..

Lastly, single code bindings can also be found in CDA R2.1 specification. Where a single code binding is being specified, the specification will indicate "= code" syntax. In Section 5, single code bindings are defined as Fixed bindings, as only the code specified can be used in CDA document instances. A number of these code bindings have a minimum cardinality of zero, as indicated by the [0..1] wire cardinality reference. In the cases where the code is fixed and the minimum wire cardinality is zero, instances of CDA conformant documents are not required to include the attribute in a document instance. See 1.3.1 Recipient Responsibilities for more information.

Vocabulary domains have a coding strength that can be "Closed", in which case the only allowable values for the CDA component are those in stated value set; or "Open", in which case values outside the stated value set can be used if necessary. Every vocabulary domain has a unique HL7-assigned identifier, and every concept within a vocabulary domain has a unique code.

Where a coded CDA component is associated with a Closed value set, the allowable values are fixed by the standard, and are enumerated as shown in the following example:

Table X: Value set for relatedDocument.typeCode

v:x_ActRelationshipDocument [2.16.840.1.113883.1.11.11610] (CLOSED)
Code	Display Name		Code	Display Name
APND	is appendage		RPLC	replaces
XFRM]	transformation
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

A number of vocabulary domains and coding systems already in existence (e.g., LOINC, SNOMED) may be used to encode concepts in CDA documents (e.g., Section.code, Observation.code). These domains are referenced as external domains according to HL7 V3 processes. Where a coded CDA component is associated with an Open vocabulary domain, a preferred value set may be specified by the standard (such as for ClinicalDocument.code or for ClinicalDocument.confidentialityCode). Where the standard does not enumerate any values, the implementor is free to choose from any external source, such as LOINC or SNOMED or some other realm-specific vocabulary.

Where a reader needs to see the complete definition of an HL7-defined value, they should refer to the HL7 Vocabulary chapter.

2.4 HL7 CDA R-MIM

The definitive description of the HL7 V3 model refinement process, R-MIM development and interpretation can be found here.

The CDA R-MIM is described below (see CDA R-MIM).

HL7 specifications derived from the HL7 RIM use a process known as "cloning" to refine domain specific models from the base HL7 RIM. When a refined model makes use of a specialization of an HL7 RIM class, the new class in the refined model is known as a clone of the HL7 RIM class. These specializations may further constrain the base class, for example, by specifying more restrictive attribute cardinality or by further constraints on the allowed vocabulary values. Multiple clones of a particular HL7 RIM class may appear in a refined model, each representing a different specialization.

The CDA R-MIM is a graphical representation of the CDA specification. It is presented using diagramming conventions and notations that were developed by HL7 to represent the specific semantic constructs contained in the critical, "back-bone" classes of the RIM. Although it could be represented in UML notation, as the RIM is, the HL7 notation provides more details about the specific constraints and class clones being represented. The HL7 diagramming convention abbreviates some relationship conventions, enabling diagrams to be smaller and more concise and to convey more information visually.

The CDA R-MIM is a graphical aid to understanding the specification. Because the CDA Hierarchical Description, and subsequently the CDA Schema, are derived from the R-MIM, the R-MIM serves as a good basis for describing the standard. The narrative description of the specific clones used by CDA is organized to correspond with the R-MIM.

2.5 HL7 CDA Hierarchical Description

The definitive description of developing and interpreting HL7 Hierarchical Descriptions can be found here.

The CDA HD is described below (see CDA Hierarchical Description).

A Hierarchical Description is a tabular representation of the sequence of elements (i.e., classes, attributes and associations) represented in an R-MIM and that define the structure of the instance without reference to XML or any other implementation technology

The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description. For CDA, Release 2.1, the CDA HD is uniquely identified by the string "POCD_HD000040UV02". As described below (see Clinical Document), this value must be included in a CDA instance to serve as an unambiguous reference to the CDA, Release 2.1 specification.

2.6 HL7 CDA XML Implementation

The CDA Schema is derived through the use of the HL7 XML Implementation Technology Specification (ITS). The definitive description of HL7 XML ITS and the process used to go from Hierarchical Description to Schema can be found here.

The CDA Schema is described below (see CDA XML Implementation).

CDA, Release 2.1 is based on the HL7 V3 XML Implementable Technology Specification for V3 Structures, Release One.

Specific enhancements to the CDA Schema, above and beyond those defined in the HL7 V3 XML ITS, are described below in CDA XML Implementation.

Looking at the CDA R-MIM, a reader familiar with the RIM, the HL7 Development Framework and its rules for XML implementations, can identify the corresponding XML elements and attributes. Due to algorithmic generation of some of the element names, the correspondence may be unclear, and the reader should refer to the HL7 V3 XML ITS for more details.

2.7 Backwards and Forwards Compatibility

NOTE: A detailed list of all changes between CDA, Release 2.0 and CDA, Release 2.1 can be found in the appendix (see Changes from CDA Release 2.0).

CDA Release 2.1 represents a minor dot release enhancement to the CDA Release 2.0 standard. As such, the changes introduced into the CDA R2.1 schema should not generate errors when processing a legacy CDA R2.0 document instance. However, with the inclusion of new RIM attributes and RIM structural vocabulary (Class Codes, Mood Codes and Type Codes) CDA R2.1 will likely require changes to implementation guides previsouly based on CDA R2.0, when citing CDA R2.1 as their base. The enhancements provided are intended to reduce the usage of previous extensions and improve the semantic modeling capabilities found in CDA.

The following updates have been made to the CDA document model, these include, but are not necessary limited to:

1. CDA R2 errata will be included
2. Extensions previously required and cited by CDA Implementation Guides
3. Attributes omitted from the classes derived from the RIM, where use cases exist for their inclusion
4. Additional values to value sets such as Mood codes, will be considered to ensure consistency with modeling from other committees
5. The inclusion of tables within tables in the narrative block will be considered as a minor presentation markup change.
6. Include current language about bindings if appropriate
7. Additional informative content will be considered for a number of topics:
   1. CDA Implementation Guides and Templating
   2. Vocabulary Binding Syntax in CDA
   3. Exchanging CDA documents

This section describes the types of changes that can be introduced to a new release of CDA and CDA principles of forward and backward compatibility. In general, changes can include the addition of new components; a renaming of components (including XML element and attribute names in the CDA Schema); a deprecation of components defined in a prior release; a change in cardinality of a component (to loosen); or a change in a vocabulary domain of a component {to add or change values, to change between Open and Closed binding types}. The following set of guiding principles defines how CDA can continue to evolve, while protecting the investment implementers have made through their adoption of earlier releases.

• Documentation : A new release of CDA will enumerate all substantive changes from the previous release.
• Attested content : Attested, human readable content must be completely loss-less across CDA releases. Backwards and forwards compatibility on the attested content will be supported such that it will be possible for an automated transformation script to translate the human readable content in both directions.
• New components : A new release of CDA can introduce new components. To preserve roundtrip translation capability, a translation from the new release to a prior release must represent the new components as extensions (e.g. local markup or local namespace).
• Renaming : A new release of CDA can rename components (including XML element and attribute names). Where this occurs, a mapping table will list all changes. Renaming will adhere to the naming convention articulated above (see XML Markup of CDA Documents).
• Deprecated components : A new release of CDA can deprecate components defined in a prior release. Deprecated components will be removed from the subsequent release of the standard, and therefore their use is not recommended.
• Cardinality : A new release of CDA can change the cardinality of a component. Where an optional component becomes required (in Release 2.1), a translation from Release 2.0 to Release 2.1 CDA document will require a dummy value or null value.
• Changes to vocabulary domain : A new release of CDA can change the vocabulary domain of a component. Where this occurs, a mapping table will list changes.
• Change within Closed : Where a value in a Closed domain in a prior release is no longer present or has been renamed, a mapping table will indicate what the current value should be.
• Change within Open : When an Open domain is expanded, users should begin using the new codes in addition to any equivalent local codes they may already be using.
• Change from Open to Closed : To preserve roundtrip translation capability, a translation between releases must represent unrecognized components as extensions (e.g. local markup or local namespace). Ideally these situations will surface during a ballot cycle, allowing the Closed domain to be sufficiently inclusive.

These guiding principles have lead to the current approach, defined in this Release 2.1 of the CDA standard. The goal is to ensure that the documents created using Release 2.0 can be processed by implementations adopting CDA R2.1 (with legacy extension references) with no loss of machine processable content or loss of attested, human-readable content.

As a result two versions of the CDA R2.1 schema are planned to be made available by HL7.

1. The first will include only local extensions approved specifically by Structured Documents Work Group (SDWG) for CDA R2.1.
2. The second will additionally include the legacy CDA R2.0 approved extensions, to better support processing of both CDA R2.0 & R2.1 document instances. Note that implementers choosing to process both CDA R2.1 and CDA R2.0 documents using the second scheme will need to manage information appearing in both CDA R2.1 elements and legacy extensions defined for CDA R2.0.

3 CDA Document Exchange in HL7 Messages

NOTE: The exact method by which a CDA instance is packaged and exchanged is outside the scope of this standard. While the MIME packaging method described here is not normative, it does illustrate one mechanism that meets the document exchange requirements described below.

Any CDA exchange strategy must accommodate the following requirements:

• All components of a CDA document that are integral to its state of wholeness (such as attested multimedia) are able to be included in a single exchange package.
• Content needing to be rendered if exchanging across a firewall where the links won't be traversable, must be able to be included in a single exchange package.
• Additional files associated with a CDA document to provide the recipient with the sender's rendering suggestions (such as one or more style sheets) are able to be included in a single exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when creating the exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when extracting the contents of an exchange package.
• There is no need to change any values of attributes of type XML ID when creating the exchange package.
• There are no restrictions on the directory structure used by receivers. Receivers can place the components of the CDA document into directories of their choosing.
• Critical metadata about the CDA instance needed for document management (e.g. document state, document archival status) must be included in the exchange package. (For a complete discussion of clinical document metadata, document management, and HL7 V3 document states and state transitions, refer to the HL7 V3 Medical Records specification).

From the perspective of a V2.x, V3 message and FHIR, a CDA document can be thought of as a multimedia object that can be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED).

The current MIME recommendation is to follow the approach described in the Internet standard RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", which is the approach for the MIME encapsulations of aggregate documents used by ebXML and DICOM.

3.1 Using HL7 V2.x messages

In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field 00573 Observation value), encoded as a V2.x encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED". The value of OBX.3 should be the same as ClinicalDocument.code.

Many fields in the message will overlap in meaning with fields in the CDA document. The following table shows the correspondence between the HL7 V2 MDM message's TXA segment and components of CDA.

Table X: HL7 V2 TXA Segment :: CDA Mapping

TXA Field	CDA Component
TXA-2 Document type	ClinicalDocument.code
TXA-4 Activity date/time	ServiceEvent.effectiveTime
TXA-5 Primary activity provider code/name	ServiceEvent performer
TXA-6 Origination date/time	ClinicalDocument.effectiveTime
TXA-7 Transcription date/time	dataEnterer.time
TXA-9 Originator code/name	author
TXA-11 Transcriptionist code/name	dataEnterer
TXA-12 Unique document number	ClinicalDocument.id
TXA-13 Parent document number	ParentDocument.id
TXA-14 Placer order number	Order.id
TXA-18 Document confidentiality status	ClinicalDocument.confidentialityCode
TXA-22 Authentication person, time stamp	authenticator, legalAuthenticator
TXA-23 Distributed copies	informationRecipient

The following example shows a non-normative, valid use of RFC 2557 in a V2 message. Several other valid representations are possible.

Example X

MSH|...
EVN|...
PID|...
PV1|...
TXA|...
OBX|1|ED|11492-6^History and Physical^LN||
   ^multipart^related^A^
   MIME-Version: 1.0\X13\
   Content-Type: multipart/related; boundary="HL7-CDA-boundary";
   type="text/xml"; start="10.12.45567.43"\X13\
   Content-Transfer-Encoding: BASE64\X13\

   --HL7-CDA-boundary\X13\
   Content-Type: text/xml; charset="US-ASCII"\X13\
   Content-ID: <10.12.45567.43>\X13\

   ... Base 64 of base CDA document, which contains 
      ...
      <observationMedia classCode="OBS" moodCode="EVN">
         <id root="10.23.4567.345"/> 
         <value mediaType="image/jpeg">
            <reference value="left_hand_image.jpeg"/>
         </value>
      </observationMedia>
      ...

   --HL7-CDA-boundary
   Content-ID: <10.23.4567.345>\X13\
   Content-Location: canned_left_hand_image.jpeg\X13\
   Content-Type: image/JPEG\X13\

   ... Base64 image ...

   --HL7-CDA-boundary--

   ...

3.2 Using HL7 V3 Messages

In V3, CDA documents can be exchanged in any message that can exchange documents (such as the HL7 V3 Medical Records messages). The Act.text RIM attribute contains the MIME package, encoded as an encapsulated data type.

As is the case with V2, many fields in the V3 message will overlap in meaning with fields in the CDA document. Since CDA and V3 Medical Records messages derive from a common model, the correspondence is clear, as shown in the following table.

Table X: HL7 V3 Medical Records :: CDA Mapping

HL7 V3 Medical Records Component	CDA Component	Comments
ClinicalDocument	ClinicalDocument	Medical Records includes attributes not present in CDA (text, statusCode, availabilityTime, reasonCode, completioncode, storageCode, copyTime); CDA includes attributes not present in Medical Records (title).
authenticator	authenticator
legalAuthenticator	legalAuthenticator
dataEnterer	dataEnterer
EncounterEvent / encounterPerformer	encompassingEncounter / encounterParticipant; serviceEvent / performer	The Medical Records encounterPerformer is split into two CDA participants.
responsibleParty	responsibleParty
custodian	custodian
participant	participant
informationRecipient	informationRecipient
recordTarget	recordTarget
author	author
subject	subject	The Medical Records subject is a directory of all subjects listed in the document.
relatedDocument / ParentDocument	relatedDocument / parentDocument
documentationOf / Event	documentationOf / serviceEvent
inFulfillmentOf / Order	inFulfillmentOf / order
componentOf / EncounterEvent	componentOf / encompassingEncounter

The following example shows a non-normative, valid use of RFC 2557 in a V3 message. Several other valid representations are possible.

Example X

<someMessage>
  <Act.Code code="11488-4" 
    codeSystem="2.16.840.1.113883.6.1" 
    displayName="Consultation note"/>
  <Act.text type="multipart/related">
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: <10.12.45567.43>

 ... Base 64 of base CDA document, which contains 
  ...
  <observationMedia classCode="OBS" moodcode="EVN">
    <id root="10.23.4567.345"/> 
    <value mediaType="image/jpeg">
      <reference value="left_hand_image.jpeg"/>
    </value>
  </observationMedia>
  ...

--HL7-CDA-boundary
Content-ID: <10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

 ... Base64 image ...

--HL7-CDA-boundary--

      </Act.text>
    </someMessage>

3.3 Using HL7 FHIR Services

In FHIR, CDA documents are to be exchanged using the FHIR DocumentReference resource. A DocumentReference resource is used to describe a document that is made available to a healthcare system. A document is some sequence of bytes that is identifiable, establishes its own context (e.g., what subject, author, etc. can be displayed to the user), and has defined update management. The DocumentReference resource can be used with any document format that has a recognized mime type and that conforms to this definition.

A client can ask a server to generate a document reference from a document. The server reads the existing document and generates a matching DocumentReference resource, or returns one it has previously generated. Servers may be able to return or generate document references for the following types of documents, FHIR Documents, CDA Documents, or Other Documents.

For CDA documents, the uri returned is a reference to a Binary end-point that returns either a CDA document, or some kind of CDA Package that the server knows how to process (e.g., an IHE .zip, Multipart Mime package)

The operation is initiated by a named query, using _query=generate on the /DocumentReference end-point:

 GET [service-url]/DocumentReference/?_query=generate&uri=:url&...

The "uri" parameter is a relative or absolute reference to one of the document types described above. Other parameters may be supplied:

Name	Meaning
persist	Whether to store the document at the document end-point (/Document) or not, once it is generated. Value = true or false (default is for the server to decide).

4 CDA Implementation Guides

The Clinical Document Architecture defines a single logical schema, which may be used to instantiate any clinical document for exchange. CDA can be used, by itself, to create such documents, which then can be shared and read by recipients with no problem. However the true utility of CDA to improve interoperability, is only realized when the base CDA standard is further constrained to define specific types of documents, their expected sections and their associated processable clinical statements.

4.1 Benefits of Constraining CDA

There are a number of benefits derived from constraining CDA documents:

1. Specific types of documents can be defined, instantiated, exchanged and used (E.g. Consult Note, Procedure Note, Continuity of Care Document, ...)
2. Required and optional sections of a clinical document can be identified (E.g. Reason for Visit, Family History, ...)
3. Realm specific constraints and conventions can be identified (E.g. US Realm Header, US Address and Patient Naming, ...)
4. Required and optional entries (machine processable content) can be identified (E.g. Medication Entries, Problem Entries, ...)

In addition to serving as a useful guides for originators of CDA documents, CDA Implementation Guides with their associated templates can:

1. Be used to create new document types, by using reusable sections and clinical statement models from previously defined IGs.
2. Be used to improve consistency across documents, by reusing sections and clinical statement models from previous Implementation Guides.
3. Be used to validate document instance conformance to constraints and best practices (Machine Processable Conformance Testing)
4. Be used by consumers of CDA documents to aid in their processing of complex clinical content, thereby improving semantic interoperability.

The Architecture of CDA is demonstrated in the system of reusable constraint models (templates) which have been created, used and reused in various CDA Implementation Guides. Implementation Guides contain the constraints or expected additional conformance rules to be applied to document instances beyond those already defined within the CDA standard itself. As such, every CDA document expressing conformance to a template is still a CDA document, it simply asserts additional conformance to the constraints defined within a template.

4.2 CDA Implementation Guide Design

A typical CDA Implementation Guide will define the constraints used for one or more types of Clinical Documents. Some implementation Guides are for a single document type, while others are used to define sets of documents that share common features or use cases. Over time, a structure has been established for CDA Implementation Guides.

CDA Implementation Guides generally contain:

1. Introduction
2. Background Information
3. Header Templates
4. Document Templates
5. Section Templates
6. Entry Templates
7. Reusable Templates (Address, Name conventions, etc.)
8. Listing of all Templates
9. Listing of all Value Sets
10. Listing of All Code Systems
11. Appendices

Note that generally each element in the CDA Schema supports a templateId, therefore templates can be defined, as needed, anywhere they are required. An example exception is in the case of the "US Realm Address" template, where the <addr> element does not contain a templateId.

4.3 Templates on CDA

As can be seen, there are many kinds of templates that might be created. Among them, the most common are:

• Header-level templates: These templates constrain fields for parts of the CDA header, like the patient, the author, the service event or variants of participants. They are typically reused in multiple document templates, and enable greater consistency across document types.

• Document-level templates: These templates constrain fields in the CDA header, and define containment relationships to CDA sections. For example, a History and Physical document-level template might require that the patient’s name be present, and that the document contain a Physical Exam section.

• Section-level templates: These templates constrain fields in the CDA section, and define containment relationships to CDA entries. For example, a Physical Exam section-level template might require that the section/code be fixed to a particular LOINC code, and that the section contains a Systolic Blood Pressure observation. As defined by the templates standard containment constraints between a section and its entry are indirect in this standard,meaning that where a section asserts containment of an entry, that entry can either be a direct child or a further descendent of that section.

• Entry-level templates: These templates constrain the CDA clinical statement model in accordance with real-world observations and acts. For example, a Systolic Blood Pressure entry-level template defines how the CDA Observation class is constrained (how to populate observation/code, how to populate observation/value, etc.) to represent the notion of a systolic blood pressure.

• Other templates: Templates that exist to establish a set of constraints that are reused in the CDA document. These other templates are only used within another template, rather than on their own as a complete clinical statement. For example, US Realm Date and Time (DTM.US.FIELDED) includes a set of common constraints for recording time. This template is referenced several times with other templates used in the implementation guide. They reduce the need to repeat constraints in templates that use the common set.

4.3.1 Template Identifiers

Each template specified in a CDA Implementation Guide will have an associated template identifier. Those identifiers can be placed in a CDA instance via the "templateId" to indicate where it wants to assert conformance to a given template version. On the receiving side, the recipient can then not only test the instance for conformance against the CDA Extensible Markup Language (XML) schema, but also test the instance for conformance against asserted templates.

4.3.2 Template Versioning

A new version of an existing implementation guide, typically reuses templates from the previous version. During the ballot phase or update phase, templates carry the designation “Published” to indicate the template is unchanged from the previous version or “Draft” to indicate a new or revised template. Substantial revisions to previously published templates are indicated by the version number (V2, V3, etc.) in all phases: ballot, update, and published guides.

If there are no substantive changes to a template that has been successfully published, the template will carry the same templateId/@root (identifier oid) and templateId/@extension as in the previous implementation guide. (In the case of older templates, where the @extension attribute was not present, developers of new/updated Implementation Guides are encouraged to add an @extension attribute to these templates with an appropriate date.) During a new ballot or update phase, “Published” is appended to the main heading for the template to indicate that the template cannot be commented on in the ballot or update. The “Published” designation is removed in the final publication versions.

A revised version of a previously published template keeps the same templateId/@root as the previous version but is assigned a new templateId/@extension. In the US Realm, The @extension is populated with an common acknowledged creation date for all new and revised templates contained within the associated Implementation Guide. The accepted format is "YYYY-MM-DD". The notation “(Vn)” (V2, V3, etc.) is also added to the template name to assist human recognition of the template's version.

Versions are not necessarily forward or backward compatible. A versioning may be due to substantive changes in the template or because a contained template has changed. The “(Vn)” designation is persistent; it appears with that template when it is used in subsequent guides. During a new ballot or update phase, “Draft” is appended to the main heading for the template to indicate that it may be voted on in the ballot or commented on in the update; the “Draft” designation is removed in the final publication versions.

Structured Documents Working Group collaborated with Templates Working Group to establish template versioning recommendations, recently published in the following specification: HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1. SDWG will leverage that specification to create guidance for template IDs and template versioning for future CDA implementation guides, including future versions of C-CDA, but that work is still in progress. The versioning approach described here is likely to be close to the final guidance, but has not been formally approved by SDWG for all implementation guides at this time.

Each version of a template has a status. For example, a template version can be draft, active, or deprecated, etc. The HL7 Templates DSTU describes the various status states that may apply to a template version over the course of its lifecycle. Each version of a template has an associated status. Thus, one version of a template may be deprecated, while a newer version of that template may be draft or active.

4.3.3 Open and Closed Templates

In open templates, all of the features of the CDA R2.1 base specification are allowed except as constrained by the templates. By contrast, a closed template specifies everything that is allowed and nothing further may be included.

Estimated Date of Delivery (templateId 2.16.840.1.113883.10.20.15.3.1) as defined in C-CDA R2.1 is an example of a closed template. Open templates allow implementers to specify additional content not specifically precluded by a given template's definition. HL7 encourages implementers to bring their use cases forward as candidate requirements to be formalized in a subsequent versions of a template to maximize the use of shared semantics.

4.4 Conformance Statements

Each template defined within a CDA Implementation Guide, will contain one or more conformance statements. The following represents an example of one way conformance constraints could be documented. Each conformance statement will have a conformance identifier, (CONF:####), identify a conformance verb, SHALL, SHOULD, MAY, etc.), identify the element or attribute that is the subject or context of the conformance constraint and define one or more constraint(s) to be imposed on that item. Constraints can specify cardinality, allowed use of nullFlavors, various types of attribute binding, inclusive of single code, value set and concept domain binding for code types and allowed specializations on data type usage. In general constrains can be used to ensure that implementers and receivers of CDA documents can share rich semantically processable information.

4.4.1 Conformance Verbs (Keywords)

The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT represent the set of conformance verbs that can be asserted on conformance statements. They are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.

• SHALL: an absolute requirement
• SHALL NOT: an absolute prohibition against inclusion
• SHOULD/SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
• MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications

The keyword "SHALL" allows the use of nullFlavor unless the requirement is on an attribute or the use of nullFlavor is explicitly precluded. When conformance statements are nested (or have subordinate clauses) the conformance statements are to be read and interpreted in hierarchical order. These hierarchical clauses can be interpreted as "if then, else" clauses. Thus...

a. This structuredBody SHOULD contain zero or one [0..1] component (CONF:1098-29066) such that it

  i. SHALL contain exactly one [1..1] Plan of Treatment Section (V2) 
(identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.10:2014-06-09) (CONF:1098-29067).

...is understood as:

a. It is recommended (SHOULD) that the structureBody contains a component.

  i. If the component exists, then it must contain a Plan of Treatment Section (V2),

  ii. else the component does not exist, and the conformance statement about the Plan of Treatment Section (V2) 
should be skipped.

In the case where the higher level conformance statement is a SHALL, there is no conditional clause. Thus...

b. This structuredBody SHALL contain exactly one [1..1] component (CONF:1098-29086) such that it

  i. SHALL contain exactly one [1..1] Problem Section (entries required) (V2) 
(identifier: urn:hl7ii:2.16.840.1.113883.10.20.22.2.5.1:2014-06-09) (CONF:1098-29087).

...means that the structuredbody is always required to have a Problem Section component.

4.4.2 Cardinality Constraints

The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within a document instance. The cardinality indicators are interpreted with the following format “m…n” where m represents the least and n the most:

• 0..1 zero or one
• 1..1 exactly one
• 1..* at least one
• 0..* zero or more
• 1..n at least one and not more than n

When a constraint has subordinate clauses, the scope of the cardinality of the parent constraint must be clear. In the next figure, the constraint says exactly one, participant is to be present, i.e., no less or more than one. The subordinate constraint specifies some additional characteristics of that participant.

1. SHALL contain exactly one [1..1] participant (CONF:2777).
    a. This participant SHALL contain exactly one [1..1] @typeCode="LOC" 
       (CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:2230).

In the next figure, the constraint says only one participant “like this” is to be present. Other participant elements are not precluded by this constraint.

1. SHALL contain exactly one [1..1] participant (CONF:2777) such that it
   a. SHALL contain exactly one [1..1] @typeCode="LOC" 
      (CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType) (CONF:2230).

4.4.2.1 Optional and Required with Cardinality

The terms optional and required describe the lower bound of cardinality as follows:

Optional means that the number of allowable occurrences of an element may be 0; the cardinality will be expressed as [0..1] or [0..*] or similar. In these cases, the element may not be present in the instance. Conformances formulated with MAY or SHOULD are both considered "optional" conformances.

Required means that the number of allowable occurrences of an element must be at least 1; the cardinality will be expressed as [m..n], where m >=1 and n >=1 (for example, [1..1] or [1..*]). In these cases, the element must be present in the instance. Conformance statements formulated with SHALL are required conformances. If an element is required but it is not known, the @nullFlavor attribute must be used.

4.4.2.2 Conformance using SHALL NOT and Cardinality

It is important to note that the expressions of cardinality in CDA conformance statements when associated with "SHALL NOT contain" will be expressed with a cardinality of [0..0] which represents a restatement of the constraint.

Diagnostic Imaging Report Example:

SHALL NOT contain [0..0] informant (CONF:1198-8410).

As noted in this example, no informant element shall be present in the header.

It is important to note, that not all SHALL NOT conformance statements are about whether an element is disallowed in a given context. Sometimes it is used to indicate other restrictions:

MethodCode SHALL NOT conflict with the method inherent in Observation / code (CONF:1098-8249).

In the following case, a Observation / Method Code used for Procedure Activity must not conflict with the method inherent in the Observation / Code used in the same observation instance.

4.4.3 Data Types

All data types used in a CDA document are defined in the "ITS: XML Data Types, Release 1", with the exception of ClinicalDocument.versionNumber which is modeled after "ITS:XML:Data Types, Release 2.1b", which enables backwards compatability with CDA R2. All attributes of a data type are allowed unless explicitly prohibited by implementation guides.

4.4.4 Vocabulary Binding

The templates in a CDA Implementation Guide can use terms from several code systems. These vocabularies are defined in various supporting specifications and may be maintained by other bodies, as is the case for the LOINC® and SNOMED CT® vocabularies.

4.4.4.1 Code Binding

Example: Single Code Binding

2. SHALL contain exactly one [1..1] code (CONF:15403).
   a) This code SHALL contain exactly one [1..1] @code="11450-4" Problem List (CONF:15408).
   b) This code SHALL contain exactly one [1..1] @codeSystem="2.16.840.1.113883.6.1"
       (CodeSystem: LOINC 2.16.840.1.113883.6.1 STATIC) (CONF: 31141).

The notation conveys the actual code (11450-4), the code’s displayName (Problem List), the OID of the codeSystem from which the code is drawn (2.16.840.1.113883.6.1), and the codeSystemName (LOINC).

HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying data type is “Coded Simple” or “CS”, in which case it is prohibited. The displayName and the codeSystemName are optional, but recommended.

The above example would be properly expressed as follows.

Figure: XML Expression of a Single-Code Binding

or best practice recommendation:

4.4.4.2 Value Set Binding

Value set bindings should adhere to HL7 Vocabulary Working Group best practices, and include both an indication of stability and of coding strength for the binding. Value set bindings can be STATIC, meaning that they bind to a specified version of a value set, or DYNAMIC, meaning that they bind to the most current version of the value set. If a STATIC binding is specified, both the value set definition and the code system versions need to be specified. If a DYNAMIC binding is specified, the value set authority i.e. a URL for a service or page specifying the current values of the set SHALL be included, so implementers can access the current version of the value set. When a vocabulary binding binds to a single code, as previously depicted, the stability of the binding is implicitly STATIC.

 9. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the code SHOULD be selected 
     from ValueSet Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC (CONF:1198-9058).

Figure: XML Expression of a Value-Set Binding

   <value xsi:type="CD"  code="233604007"  codeSystem="2.16.840.1.113883.6.96"  displayName="Pneumonia" />

Note that value set identifiers (e.g., ValueSet Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC) used in the binding definitions of template conformance statements do not appear in the XML instance of a CDA document. The definition of the template must be referenced to determine or validate the vocabulary conformance requirements of the template.

4.4.4.3 Concept Domains

Note: Concept domains are not directly implementable. They declare the conceptual semantic space to be used. Bindings to value sets or single codes must be specified in Implementation Guides to identify codes to be used.

A full discussion of the representation of vocabulary is outside the scope of this document; for more information, see the HL7 V3 Normative Edition 2010 sections on Abstract Data Types and XML Data Types R1.

4.4.5 Readable Conformance

The presentation of the conformance statements within a CDA Implementation Guide has slowly evolved over time. As all conformance requirements are typically captured using one of a number the profiling tools available, two patterns have established themselves within the industry. Tabular and narrative presentation models of representation are both currently in use. The HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 (DSTU) provides an excellent resource for those wanting to know more about templating and the current best practices.

4.5 Machine Processsable Conformance

When a CDA document instance is validated against the CDA R2.1 schema, it has demonstrated conformance to the CDA standard in its usage of XML proper elements and attributes as defined in the schema. There are additional conformance requirements, but in essence the document instance would likely be viewable using any one of a number of CDA stylesheet that are available for viewing CDA documents.

However, when a document instance is created which declares conformance to templates, it does so, by the inclusion of templateId identifiers. Thus, when a CDA document is received it can potentially be validated against the additional conformance claims defined within the identified templates. The ability to express conformance constraints in machine processable formats continues to evolve as more CDA tooling becomes available.

4.5.1 Benefits of Processable Conformance

One of the obvious benefits of having machine processable conformance with CDA documents, is the ability to perform automatic validation of the secondary conformance claims asserted in a given CDA document instance. This ability also enables the exchange of CDA documents which both can be read and processed to extract clinical statements as needed. Without additional conformance claims, and automated testing of those claims, receivers of CDA documents would have significant difficultly attempting to process descrete data.

4.5.2 Machine Processable Strategies

A number of different strategies have been employed in the automated validation of secondary conformance claims found in CDA Implementation Guides. In general, the choice of tool used to create an Implementation Guide will determine the means by which conformance will be validated. The typical strategies are:

1. Schematron - conformance statements are converted into a set of processable X-Path expressions which test conformance in a CDA instance using XSLT processing.
2. Java code - conformance statements are used to generate Java code which is used to read and validate the document instance into an object model.

5 CDA Design

NOTE: The definitive description of HL7 V3 model refinement, R-MIM development and interpretation can be found here.

The CDA R-MIM POCD_RM000040UV02 can be found here: Link to wide graphic (opens in a new window)

A CDA document is comprised of a header and a body. The header identifies and classifies the document; provides information on authentication, the encounter, the patient, and the provider; and sets the context for the document as a whole. The body contains the clinical report, and is conceptually divided up into nested sections, each containing a narrative block to be rendered along with structured entries and external references.

5.1 Clinical Document

The ClinicalDocument class is the entry point into the CDA R-MIM, and corresponds to the <ClinicalDocument> XML element that is the root element of a CDA document instance. This section will outline the CDA Document's physical design, first in the header and then the body.

A CDA document is logically broken up into a CDA Header and a CDA Body. The CDA Header is comprised of ClinicalDocument attributes, participants, and act relationships. The CDA Body is the target of the ClinicalDocument component act relationship.

5.2 Header

The purpose of the CDA header is to enable clinical document exchange across and within institutions; facilitate clinical document management; and facilitate compilation of an individual patient's clinical documents into a lifetime electronic patient record. The CDA header sets the context for the document as a whole and the context for understanding the content contained in the document.

5.2.1 ClinicalDocument

The CDA schema was produced by serialization of the CDA model. The starting point for his serialization was the ClinicalDocument class. The ClinicalDocument is the root element in a CDA document instance.

5.2.1.1 ClinicalDocument Attributes

This section describes attributes defined in the ClinicalDocument class.

The table below identifies the attributes of ClinicalDocument. For each item, the name is provided, along with the data type, wire cardinality*, code bindings, and binding type or strength. The links allow will access to the item's definition, data type definition, and when appropriate, the concept domain or value set used with the item.

Table X: ClinicalDocument Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DOCCLIN	Fixed
moodCode	CS	[0..1]	EVN	Fixed
typeId	II	[1..1]
templateId	II	[0..*]
id	II	[1..1]
code	CE	[1..1]	D:DocumentType	Open
title	ST	[0..1]
effectiveTime	TS	[0..1]
confidentialityCode	SET<CE>	[0..*]	V:x_BasicConfidentialityKind	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed
setId	II	[0..1]
versionNumber	ST	[0..1]
copyTime (Deprecated)	TS	[0..1]

Note*: The wire cardinality represents is the effective cardinality of an element, taking into account 1.3.1 Recipient Responsibilities, relaxation of the requirement to exchange fixed and defaulted values. The logical cardinality expressed in the CDA Hierarchical Description is still present, but assumed by the recipient, not imposed on the wire format of an instance of a CDA document.

ClinicalDocument.classCode

The ClinicalDocument.classCode in the CDA model is fixed to "DOCCLIN". As a result, in the CDA R2.1 Schema, the ClinicalDocument/@classCode has been fixed to "DOCCLIN".

As noted in section 1.3.1 Recipient Responsibilities, fixed and default values asserted in this standard are not required to be present in CDA document instances. However, CDA Implementation Guides can still require them via conformance statements.

Table X: Fixed ClinicalDocument.classCode

Code	Display Name
DOCCLIN	clinical document
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ClinicalDocument.moodCode

The ClinicalDocument.moodCode in the CDA model is fixed to "EVN" or event mood to indicate that this is documentation of a past service. In the CDA R2.1 Schema, the ClinicalDocument/@moodCode has been fixed to "EVN".

Table X: Fixed ClinicalDocument.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

The ClinicalDocument class inherits various attributes from the InfrastructureRoot class of the RIM, including ClinicalDocument.templateId and ClinicalDocument.typeId which are discussed here. All CDA classes inherit from infrastructureRoot, which is discussed in Section (link here).

ClinicalDocument.typeId

ClinicalDocument.typeId is a technology-neutral explicit reference to this CDA, Release Two specification, and must be valued as follows: ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension = "POCD_HD000040UV20" (which is the unique identifier for the CDA, Release Two Hierarchical Description).

ClinicalDocument.templateId

When a templateId is present in a CDA element, it signals the imposition of a set of template-defined constraints for that element. The templateId is one of the infrastructure attributes added to all CDA classes. It has only been displayed for ClinicalDocument, but is present in all CDA classes, where it can be used to identify constraints defined in an external Implementation Guide template. See 4.3.2 Template Versioning.

ClinicalDocument.id

Represents the unique instance identifier of a clinical document.

ClinicalDocument.code

The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note). The value set is drawn from LOINC, and has a CWE coding strength.

Within the LOINC database, beginning with version 2.09, May 2003, document type codes are those that have a value of "DOC" in the Scale component. This subset of LOINC is described in the appendix (see LOINC Document Codes).

ClinicalDocument.title

Represents the title of the document. It's commonly the case that clinical documents do not have a title, and are collectively referred to by the display name of ClinicalDocument.code (e.g. a "consultation" or "progress note"). Where these display names are rendered to the clinician, or where the document has a unique title, the ClinicalDocument.title component should be used. In the example document in the appendix (see Sample Document), the value of ClinicalDocument.title = "Good Health Clinic Consultation Note".

ClinicalDocument.effectiveTime

Signifies the document creation time, when the document first came into being. Where the CDA document is a transform from an original document in some other format, the ClinicalDocument.effectiveTime is the time the original document was created. The time when the transform occurred is not currently represented in CDA.

ClinicalDocument.ConfidentialityCode

Confidentiality is a required contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by a nested value (as further described in CDA Context). A best practice for clinical documents is to assert the highest level of confidentiality present within a document at the header level.

Table X: Value set for ClinicalDocument.confidentialityCode

x_BasicConfidentialityKind [2.16.840.1.113883.1.11.16926] (OPEN)
Code	Display Name		Code	Display Name
N	normal		R	restricted
V	very restricted
Code System: Confidentiality (HL7) Code System OID: 2.16.840.1.113883.5.25

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.

ClinicalDocument.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066 for the Identification of Languages, ed. H. Alvestrand. 1995, which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121". Language is a contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by a nested value (as further described in CDA Context).

ClinicalDocument.setId

Represents an identifier that is common across all document revisions.

ClinicalDocument.versionNumber

A string used to represent the version of the document. For CDA R2.1 we use the ST data type as defined in the HL7 Version 3 Standard: XML Implementation Technology Specification - Wire Format Compatible Release 1 Data Types, Release 1 (XML ITS R2B). We have adopted, for all versionNumber references in CDA R2.1, this data type because it supports an @value attribute, and can support wire format compatibility with the versionNumber in CDA R2.0.

ClinicalDocument.copyTime (Deprecated)

Represents the time a document is released (i.e. copied or sent to a display device) from a document management system that maintains revision control over the document. Once valued, it cannot be changed. The intent is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.

Included for backwards compatibility with CDA, Release One. ClinicalDocument.copyTime has been deprecated because it is not part of the document at the time it is authenticated, but instead represents metadata about the document, applied at some variable time after authentication. Further use is discouraged.

5.2.2 Header Participants

This section describes classes related to the root ClinicalDocument class via a Participation.

5.2.2.1 authenticator

Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it. (See also legalAuthenticator)

A clinical document can have zero to many authenticators. Both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual.

Table X: Authenicator

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	AUTHEN	Fixed
time	TS	[1..1]
signatureCode	CV	[0..1]	S	Fixed
signatureText	ED	[0..1]

authenticator.typeCode

The authenticator.typeCode is fixed to "AUTHEN" to indicate that a participant has attested his participation through a signature.

Table X: Fixed authenticator.typeCode

Code	Display Name
AUTHEN	authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

authenticator.time

Authenticator has a required authenticator.time indicating the time of authentication.

authenticator.signatureCode

Authenicator has a required authenticator.signatureCode, indicating that a signature has been obtained and is on file.

Table X: Fixed authenticator.signatureCode

Code	Display Name
S (Fixed)	signed
Code System: ParticipationSignature (HL7) Code System OID: 2.16.840.1.113883.5.89

Note: CDA Release One represented either an intended ("X") or actual ("S") authenticator. CDA Release 2 and 2.1 only represents an actual authenticator, so usage of "X" and "I" are deprecated.

authenticator.signatureText

A new attribute, SignatureText has been added to authenticator. The signature can be represented either inline or by reference according to the ED data type. Typical cases are:

1. Paper-based signatures: the ED data type may refer to a document or other resource that can be retrieved through an electronic interface to a hardcopy archive.
2. Electronic signature: this attribute can represent virtually any electronic signature scheme.
3. Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.

5.2.2.1.1 AssignedEntity

An authenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class). (See here for a description of "player" and "scoper" role associations.)

Table X: AssignedEntity

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ASSIGNED	Fixed
id	SET<II>	[1..*]
code	CE	[0..1]	D:RoleCode	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

AssignedEntity.classCode

The classCode is fixed to "ASSIGNED", which is used in this context to indicate that a person in the employ of an organization was acting as their agent.

Table X: Fixed AssignedEntity.classCode

Code	Display Name
ASSIGNED	assigned entity
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

AssignedEntity.id

In this context, it is a unique identifier for the person in this Role.

AssignedEntity.code

Identifies the specific kind of Role to which an Role-instance belongs. The AssignedEntity.code is bound to D:RoleCode, which enables any code from the HL7 RoleCode vocabulary.

AssignedEntity.addr

A postal address for the Entity while in the Role.

AssignedEntity.telecom

A telecommunication address for the Entity while in the Role.

5.2.2.1.2 Person

Refer to Person as defined for Author participation.

5.2.2.1.3 Organization

Table X: Organization

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ORG	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
id	SET<II>	[0..*]
name	SET<ON>	[0..1]
telecom	SET<TEL>	[0..*]
addr	SET<AD>	[0..*]
standardIndustryClassCode	CE	[0..1]	D:OrganizationIndustryClass

Organization.classCode With the code fixed to "ORG", it indicates we are referencing an Organization.

Table X: Fixed Organization.classCode

Code	Display Name
ORG	organization
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Organization.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates that the scoping organization referenced, is a specific instance of an organization.

Table X: Fixed Organization.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Organization.id

A unique identifier for the Organization.

Organization.name

A non-unique textual identifier or moniker for the organization.

Organization.telecom

A telecommunication address for the Organization.

Organization.addr

The postal or residential address of an organization.

Organization.standardIndustryClassCode

A code which identifies the industrial category of an organization. In the US Realm, it has been bound to the Code System: North American Industry Classification System [2.16.840.1.113883.6.85] (NAICS). The binding type is Open, so other code system and values sets may be used in the US and other realms. D:OrganizationIndustryClass

5.2.2.1.4 OrganizationPartOf

A scoping organization can be part of a larger organization. Where there is a need to include whole-part relationships, the OrganizationPartOf role can be used. OrganizationPartOf.statusCode indicates the state of the whole-part relationship (e.g. "active", "terminated").

Table X: OrganizationPartOf

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PART	Fixed
id	SET<II>	[1..*]
code	CE	[0..1]	D:RoleCode	Open
statusCode	CS	[0..1]	V:RoleStatus	Closed
effectiveTime	IVL<TS >	[0..1]

OrganizationPartOf.classCode

Table X: Fixed OrganizationPartOf.classCode

Code	Display Name
PART	part
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

OrganizationPartOf.id

A unique identifier for the player organization in this Role.

OrganizationPartOf.code

The specific kind of Role to which an Role-instance belongs.

OrganizationPartOf.statusCode

The state of this Role as defined in the state-transition model.

Table X: Value set for OrganizationPartOf.statusCode

V:RoleStatus [2.16.840.1.113883.5.1068] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		active	active
cancelled	cancelled		pending	pending
suspended	suspended		terminated	terminated
nullified	nullified
Code System: RoleStatus (HL7) Code System OID: 2.16.840.1.113883.5.1068

OrganizationPartOf.effectiveTime

The OrganizationPartOf.effectiveTime is an interval of time specifying the period during which the whole-part relationhship is in effect, if such time limit is applicable and known.

5.2.2.2 author

author

Represents the humans and/or machines that authored the document.

Table X: author

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	AUT	Fixed
functionCode	CE	[0..1]	D:ParticipationFunction	Open
contextControlCode	CS	[0..1]	OP	Fixed
time	TS	[1..1]

author.typeCode

The author.typeCode is fixed to "AUT", used to indicate the party that originates the document and is responsible for the information in the document.

Table X: Fixed author.typeCode

Code	Display Name
AUT	author
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

author.functionCode

The author.functionCode is bound to the concept domain ParticipationFunction, which is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (Open).

In some cases, the role or function of the author is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Medical Student Progress Note". The role of the author can also be recorded in the Author.functionCode or AssignedAuthor.code attribute. If either of these attributes is included, they should be equivalent to or further specialize the role inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Physician Progress Note" and the value of Author.functionCode is "rounding physician"), and shall not conflict with the role inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

author.contextControlCode

The author.contextControlCode is fixed to "OP". It means that the author will replace the set of author participations that have propagated from ancestor Acts, and will itself be the only author to propagate to any child Acts that allow context to be propagated.

Table X: Fixed author.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

author.time

The author.time is used to capture the time this specific author contributed content to the document.

5.2.2.2.1 AssignedAuthor

An author is a person in the role of an assigned author (AssignedAuthor class). The entity playing the role is a person (Person class) or a device (AuthoringDevice class). The entity scoping the role is an organization (Organization class), and is the organization from which the document originates.

Table X: AssignedAuthor

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ASSIGNED	Fixed
id	SET<II>	[1..*]
code	CE	[0..1]	D:RoleCode	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

AssignedAuthor.classCode

The classCode is fixed to "ASSIGNED", which is used in this context to indicate that a person in the employ of an organization was acting as their agent.

Table X: Fixed AssignedAuthor.classCode

Code	Display Name
ASSIGNED	assigned entity
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

AssignedAuthor.id

In this context, it is a unique identifier for the person in this Role.

AssignedAuthor.code

Identifies the specific kind of Role to which an Role-instance belongs. The AssignedEntity.code is bound to D:RoleCode, which enables any code from the HL7 RoleCode vocabulary.

AssignedAuthor.addr

A postal address for the Entity while in the Role.

AssignedAuthor.telecom

A telecommunication address for the Entity while in the Role.

5.2.2.2.2 Person

A human being.

Table X: Person

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PSN	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
name	SET<PN>	[0..*]
desc	ED	[0..1]
birthTime	TS	[0..1]

Person.classCode

With the code fixed to "PSN", it indicates we are referencing a Person.

Table X: Fixed Person.classCode

Code	Display Name
PSN	person
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Person.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates that we are dealing with a specific person.

Table X: Fixed Person.determinerCode

Code	Display Name
INSTANCE (Fixed)	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Person.name

The person's name.

Note: The person name data type "PN" supports current, and historical names using validTime, and the specification of different use codes can indicate legal name, tribal name, stage name and others.

Person.desc

A textual or multimedia depiction of the person.

Person.birthTime

The date and time of a person's birth.

5.2.2.2.3 AuthoringDevice

Table X: AuthoringDevice

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DEV	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
code	CE	[0..1]	D:EntityCode
manufacturerModelName	SC	[0..1]	D:ManufacturerModelName
softwareName	SC	[0..1]	D:SoftwareName

AuthoringDevice.classCode

The AuthoringDevice.classCode is fixed to "DEV" indicating that a device was used to generate content in the document.

Table X: Fixed AuthoringDevice.classCode

Code	Display Name
DEV	role
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

AuthoringDevice.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates we are referencing a specific device.

Table X: Fixed AuthoringDevice.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

AuthoringDevice.code

The AuthoringDevice.code is bound to the EntityCode domain.

AuthoringDevice.manufacturerModelName

Is used to convey a coded name for the device.

AuthoringDevice.softwareName

Is used to convey a coded name for the software used to author content.

5.2.2.2.4 MaintainedEntity (Deprecated)

NOTE: In CDA, Release One, it was possible to specify those individuals responsible for the device. This functionality has been deprecated in CDA, Release Two. The MaintainedEntity class is present for backwards compatibility, and its use is discouraged, except where needed to support the transformation of CDA, Release One documents.

Table X: MaintainedEntity

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	MNT	Fixed
effectiveTime	IVL<TS>	[0..1]

MaintainedEntity.classCode

With the classCode fixed to "MNT", it indicates that AuthoringDevice is maintained by person assuming responsibility for proper operation, quality, and safety.

Table X: Fixed MaintainedEntity.classCode

Code	Display Name
MNT	maintained entity
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

MaintainedEntity.effectiveTime

An interval of time specifying the period during which the Role is in effect.

5.2.2.3 custodian

custodian

Represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian.

The custodian participation satisfies the CDA definition of Stewardship (see What is the CDA). Because CDA is an exchange standard and may not represent the original form of the authenticated document, the custodian represents the steward of the original source document.

Table X: custodian

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	CST	Fixed

custodian.typeCode

The custodian.typeCode is fixed to "CST", which indicates in this instance an organization that is in charge of maintaining this document. Examples: Medical Records Dept in hospital, Health Information Management Dept., etc.

Table X:Fixed custodian.typeCode

Code	Display Name
CST	custodian
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

A custodian is a scoping organization in the role of an assigned custodian (AssignedCustodian class). The steward organization (CustodianOrganization class) is an entity scoping the role of AssignedCustodian, and has a required CustodianOrganization.id.

5.2.2.3.1 AssignedCustodian

Table X: AssignedCustodian

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ASSIGNED	Fixed

AssignedCustodian.classCode

Table X: Fixed AssignedCustodian.classCode

Code	Display Name
ASSIGNED	assigned entity
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

5.2.2.3.2 CustodianOrganization

Table X: CustodianOrganization

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ORG	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
id	SET<II>	[1..*]
name	SET<ON>	[0..1]
telecom	SET<TEL>	[0..*]
addr	SET<AD>	[0..*]

CustodianOrganization.classCode With the code fixed to "ORG", it indicates we are referencing an Organization.

Table X: Fixed CustodianOrganization.classCode

Code	Display Name
ORG	organization
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

CustodianOrganization.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates that the scoping organization referenced, is a specific instance of an organization.

Table X: Fixed CustodianOrganization.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

CustodianOrganization.id

A unique identifier for the Organization.

CustodianOrganization.name

A non-unique textual identifier or moniker for the organization.

CustodianOrganization.telecom

A telecommunication address for the Organization.

CustodianOrganization.addr

The postal or residential address of an organization.

5.2.2.4 dataEnterer (Transcriptionist)

dataEnterer

Represents the participant who has transformed a dictated note into text.

Table X: dataEnterer

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	ENT	Fixed
contextControlCode	CS	[0..1]	OP	Fixed
time	TS	[1..1]

dataEnterer.typeCode

The dataEnterer.typeCode is fixed to "ENT".

Table X: Fixed dataEnterer.typeCode

Code	Display Name
ENT	data entry person
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

dataEnterer.contextControlCode

The dataEnterer.contextControlCode is fixed to "OP".

Table X: Fixed dataEnterer.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

dataEnterer.time

The date and time the data was entered into the originating system.

5.2.2.4.1 AssignedEntity

Refer to AssignedEntity as defined for authenticator participation.

5.2.2.5 encounterParticipant

See EncompassingEncounter for a description of the encounterParticipant participant.

5.2.2.6 informant

informant

An informant (or source of information) is a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma.

Table X: informant

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	INF	Fixed
contextControlCode	CS	[0..1]	OP	Fixed

informant.typeCode The informant.typeCode is fixed to "INF", which indicates the source of reported information (e.g., a next of kin who answers questions about the patient's history).

Table X: Fixed informant.typeCode

Code	Display Name
INF	informant
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

informant.contextControlCode

The informant.contextControlCode is fixed to "OP". It means that the informant will replace the set of informant participations that have propagated from ancestor Acts, and will itself be the only informant to propagate to any child Acts that allow context to be propagated.

Table X: Fixed informant.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

An informant can be a person in one of two roles RelatedEntity or AssignedEntity.

5.2.2.6.1 RelatedEntity

The RelatedEntity role is used to represent an informant without a role.id (e.g. a parent or guy on the street). The informant in this case bears some formal or personal relationship to the patient. The role is unscoped, with the assumption that the patient is always the implied scoper. RelatedEntity.code can be used to specify the nature of the relationship.

Table X: RelatedEntity

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	v:RoleClassMutualRelationship	Closed
code	CE	[0..1]	D:PersonalRelationshipRoleType	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]
effectiveTime	IVL<TS>	[0..1]

RelatedEntity.classCode

Table X: Value set for RelatedEntity.classCode

v:RoleClassMutualRelationship [2.16.840.1.113883.1.11.19316] (CLOSED)
Code	Display Name		Code	Display Name
AFFL	affiliate		AGNT	agent
ASSIGNED	assigned entity		COMPAR	commissioning party
SGNOFF	signing authority or officer		CON	contact
ECON	emergency contact		NOK	next of kin
GUARD	guardian		CIT	citizen
COVPTY	covered party		CLAIM	claimant
NAMED	named insured		DEPEN	dependent
INDIV	individual		SUBSCR	subscriber
PROG	program eligible		CRINV	clinical research investigator
CRSPNSR	clinical research sponsor		EMP	employee
MIL	military person		GUAR	guarantor, GuarantorRole
INVSBJ	Investigation Subject		CASEBJ	Case Subject
RESBJ	research subject		LIC	licensed entity
NOT	notary public		PROV	healthcare provider
PAT	patient		PAYEE	payee
PAYOR	invoice payor		POLHOLD	policy holder
QUAL	qualified entity		SPNSR	coverage sponsor
STD	student		UNDWRT	underwriter
CAREGIVER	caregiver		PRS	personal relationship
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

RelatedEntity.code

The RelatedEntity.code is bound to the PersonalRelationshipRoleType concept domain.

RelatedEntity.addr

The RelatedEntity.addr is used to convey the postal address for the informant.

RelatedEntity.telecom

The RelatedEntity.telecom is used to convey the phone number for the informant.

RelatedEntity.effectiveTime

The RelatedEntity.effectiveTime is used to convey the time period that the role is/was in effect.

5.2.2.6.2 AssignedEntity

The AssignedEntity role is used for an identified informant, and is scoped by an Organization.

Refer to AssignedEntity as defined for authenticator participation.

5.2.2.7 informationRecipient

informationRecipient

Represents a recipient who should receive a copy of the document.

NOTE: The information recipient is an entity to whom a copy of a document is directed, at the time of document authorship. It is not the same as the cumulative set of persons to whom the document has subsequently been disclosed, over the life-time of the patient. Such a disclosure list would not be contained within the document, and it is outside the scope of CDA.

Table X: informationRecipient

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[1..1]	V:x_InformationRecipient	Closed

informationRecipient.typeCode

Two values are available for the informationRecipient.typeCode, the default value is primary information recipient an alternative value is tracker.

Table X: Value set for informationRecipient.typeCode

v:x_InformationRecipient [2.16.840.1.113883.1.11.19366] (CLOSED)
Code	Display Name		Code	Display Name
PRCP (Default)	primary information recipient		TRC	tracker
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

5.2.2.7.1 IntendedRecipient

Identifies the person(s), organization or health chart to receive the document.

Table X: IntendedRecipient

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	V:x_InformationRecipientRole	Closed
id	SET<II>	[1..*]
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

IntendedRecipient.classCode

Where a person is the intended recipient (IntendedRecipient class), the IntendedRecipient.classCode is valued with "ASSIGNED", and the playing entity is a person (Person class), optionally scoped by an organization (Organization class). Where the intended recipient is an organization, the IntendedRecipient.classCode is valued with "ASSIGNED", and the recipient is reflected by the presence of a scoping Organization, without a playing entity. Where a health chart is the intended recipient, the IntendedRecipient.classCode is valued with "HLTHCHRT" (health chart). In this case there is no playing entity, and an optional scoping organization (Organization class).

Table X: Value set for IntendedRecipient.classCode

V:x_InformationRecipientRole [2.16.840.1.113883.1.11.16772] (CLOSED)
Code	Display Name		Code	Display Name
ASSIGNED (Default)	assigned entity		HLTHCHRT	health chart
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

IntendedRecipient.id

Optional identifier of the intended recipient.

IntendedRecipient.addr

Optional postal address of the intended recipient.

IntendedRecipient.telecom

Optional phone number for the intended recipient.

5.2.2.7.2 Person

Refer to Person as defined for Author participation.

5.2.2.7.3 Organization

Refer to organization as defined for authenticator participation.

5.2.2.8 legalAuthenticator

Represents the participant(s) who has legally authenticated the document.

CDA R2.1, now supports [0..*] legal authentications. This enhancement was put into CDA to support the sharing of medical documents needing to take more than one legal authentication signature.

The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a local document is transformed into a CDA document for exchange, authentication occurs on the local document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being either authenticated or legally authenticated).

Both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. A legalAuthenticator has a required legalAuthenticator.time indicating the time of authentication, and a required legalAuthenticator.signatureCode, indicating that a signature has been obtained and is on file.

Table X: legalAuthenticator[0..*]

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	LA	Fixed
contextControlCode	CS	[0..1]	OP	Fixed
time	TS	[1..1]
signatureCode	CV	[0..1]	S	Fixed
signatureText	ED	[0..1]

legalAuthenticator.typeCode

The ClinicalDocument.typeCode is fixed to "LA" to indicate that a participant has legally attested his participation through a signature.

Table X: Fixed legalAuthenticator.typeCode

Code	Display Name
AUTHEN	authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

legalAuthenticator.contextControlCode

The legalAuthenticator.contextControlCode is fixed to "OP". It means that the legalAuthenticator will propagate to any child Acts that allow context to be propagated.

legalAuthenticator.time

legalAuthenticatorhas a required legalAuthenticator.time indicating the time of authentication.

legalAuthenticator.signatureCode

legalAuthenticatorhas a required legalAuthenticator.signatureCode, indicating that a signature has been obtained and is on file.

Table X: Fixed legalAuthenticator.signatureCode

Code	Display Name
S (Fixed)	signed
Code System: ParticipationSignature (HL7) Code System OID: 2.16.840.1.113883.5.89

Note: CDA Release One represented either an intended ("X") or actual ("S") legalAuthenticator. CDA Release 2 and 2.1 only represents an actual legalAuthenticator, so only S / Signed can be indicated for the signatureCode.

legalAuthenticator.signatureText

A new attribute, SignatureText has been added to legalAuthenticator. The signature can be represented either inline or by reference according to the ED data type. Typical cases are:

1. Paper-based signatures: the ED data type may refer to a document or other resource that can be retrieved through an electronic interface to a hardcopy archive.
2. Electronic signature: this attribute can represent virtually any electronic signature scheme.
3. Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.

Table X: Fixed legalAuthenticator.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

A legalAuthenticator is a person in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

5.2.2.8.1 AssignedEntity

Refer to AssignedEntity as defined for authenticator participation.

5.2.2.8.2 Person

Refer to Person as defined for Author participation.

5.2.2.8.3 Organization

Refer to Organization as defined for authenticator participation.

5.2.2.8.4 OrganizationPartOf

Refer to OrganizationPartOf as defined for authenticator participation.

5.2.2.9 participant

participant

Table X: participant

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	ParticipationType	Fixed
functionCode	CE	[0..1]	D:ParticipationFunction	Open
contextControlCode	CS	[0..1]	OP	Fixed
time	TS	[1..1]

participant.typeCode

The participant.typeCode is can be any code defined in the ParticipationType domain. Which can be used to represent other participants not explicitly mentioned by other classes, that were somehow involved in the documented acts.

Table X: Value set for participant.typeCode

v:ParticipationType [2.16.840.1.113883.1.11.10901] (CLOSED)
Code	Display Name		Code	Display Name
ATND	attender		ADM	admitter
CALLBCK	callback contact		CON	consultant
DIS	discharger		ESC	escort
REF	referrer		TRANS	Transcriber
ENT	data entry person		WIT	witness
CST	custodian		DIR	direct target
BBY	baby		DEV	device
NRD	non-reuseable device		RDV	reusable device
EXPAGNT	ExposureAgent		EXPART	ExposureParticipation
EXPTRGT	ExposureTarget		EXSRC	ExposureSource
IND	indirect target		BEN	beneficiary
CAGNT	causative agent		COV	coverage target
GUAR	guarantor party		HLD	holder
DON	donor		RCV	receiver
IRCP	information recipient		NOT	ugent notification contact
PRCP	primary information recipient		REFB	Referred By
REFT	Referred to		TRC	tracker
LOC	location		DST	destination
ELOC	entry location		ORG	origin
RML	remote		VIA	via
RESP	responsible party		VRF	verifier
AUTHEN	authenticator		PART	Participation
Use the following participations, only if the other participations provided in CDA will not work
RCT	record target		AUT	author (originator)
INF	informant		CSM	consumable
PRD	product		SBJ	subject
SPC	specimen		PRF	performer
DIST	distributor		PPRF	primary performer
SPRF	secondary performer		LA	legal authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

participant.functionCode

The participant.functionCode is bound to the concept domain ParticipationFunction, which is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (Open).

participant.contextControlCode

The participant.contextControlCode is fixed to "OP". It means that the participantType code specified in participant.typeCode will replace the set of author participations that have propagated from ancestor Acts, and will itself be the only author to propagate to any child Acts that allow context to be propagated.

Table X: Fixed participant.contextControlCode

Code	Display Name
OP (Fixed)	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

participant.typeCode.time

The participant.typeCode.time is the date and time the specific participation occurred.

5.2.2.9.1 AssociatedEntity

A participant is a person or organization in the role of a participating entity (AssociatedEntity class). The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

Table X: AssociatedEntity

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	V:RoleClassAssociative	Closed
id	SET<II>	[0..*]
code	CE	[0..1]	D:RoleCode	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

AssociatedEntity.classCode

When the participating entity is an organization, this is reflected by the presence of a scoping Organization, without a playing entity. Otherwise, the participating entity is considered a person with or without a scoping Organization.

Table X: Value set for ParticipatingEntity.classCode

V:RoleClassAssociative [2.16.840.1.113883.1.11.19313] (CLOSED)
Code	Display Name		Code	Display Name
ROL (Default)	role		AFFL	affiliate
AGNT	agent		ASSIGNED	assigned entity
COMPAR	commissioning party		SGNOFF	signing authority or officer
CON	contact		ECON	emergency contact
NOK	next of kin		GUARD	guardian
CIT	citizen		COVPTY	covered party
CLAIM	claimant		NAMED	named insured
DEPEN	dependent		INDIV	individual
SUBSCR	subscriber		PROG	program eligible
CRINV	clinical research investigator		CRSPNSR	clinical research sponsor
EMP	employee		MIL	military person
GUAR	guarantor		INVSBJ	Investigation Subject
CASEBJ	Case Subject		RESBJ	research subject
LIC	licensed entity		NOT	notary public
PROV	healthcare provider		PAT	patient
PAYEE	payee		PAYOR	invoice payor
POLHOLD	policy holder		QUAL	qualified entity
SPNSR	underwriter		STD	student
UNDWRT	coverage sponsor		CAREGIVER	caregiver
PRS	personal relationship		ACCESS	access
ADMM	Administerable Material		BIRTHPL	birthplace
DEATHPLC	place of death		DST	distributed material
RET	retailed material		EXPR	exposed entity
HLD	held entity		HLTHCHRT	health chart
IDENT	identified entity		MANU	manufactured product
THER	therapeutic agent		MNT	maintained entity
OWN	owned entity		RGPR	regulated product
SDLOC	service delivery location		DSDLOC	dedicated service delivery location, health care facility
ISDLOC	incidental service delivery location		TERR	territory of authority
USED	used entity		WRTE	warranted product
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

AssociatedEntity.id

An identifier for the associate person (when present) or the organization.

AssociatedEntity.code

An optional role code taken from the RoleCode concept domain. This binding is open so other code systems can be used.

AssociatedEntity.addr

The postal address for the associate person (when present) or the organization.

AssociatedEntity.telecom

The phone number for the associated person (when present) or the organization.

5.2.2.9.2 Person

Refer to Person as defined for Author participation.

5.2.2.9.3 Organization

Refer to Organization as defined for authenticator participation.

5.2.2.10 performer

See ServiceEvent for a description of the performer participant.

5.2.2.11 recordTarget

recordTarget

The recordTarget identifies the specified patient's medical record that the document belongs to.

A clinical document typically has exactly one recordTarget participant. In the uncommon case where a clinical document (such as a group encounter note) is placed into more than one patient chart, more than one recordTarget participant can be stated.

Note: The recordTarget(s) of a document are stated in the header and propagate to nested content, where they cannot be overridden. However, the patient(s) specified by the recordTarget are assumed to be the default subjects of the clinical document. Unlike the recordTarget, which can not be overridden, the patients or subjects propagate to nested components, and can be overridden at the section or entry level. (see See CDA Context).

Table X: recordTarget

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	RCT	Fixed
contextControlCode	CS	[0..1]	OP	Fixed

recordTarget.typeCode

The recordTarget.typeCode is fixed to "RCT" and indicates that this is a record target participation.

Table X: Fixed recordTarget.typeCode

Code	Display Name
RCT	record target
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

recordTarget.contextControlCode

The recordTarget.contextControlCode is fixed to "OP". It means that the recordTarget identified in the header will propagate to any child Acts that allow context to be propagated.

Table X: Fixed recordTarget.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

A recordTarget is represented as a relationship between a person and an organization, where the person is in a patient role (PatientRole class). The entity playing the role is a patient (Patient class). The entity scoping the role is an organization (Organization class). A patient is uniquely identified via the PatientRole.id attribute.

5.2.2.11.1 PatientRole

Table X: PatientRole

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PAT	Fixed
id	SET<II>	[1..*]
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

PatientRole.classCode

The PatientRole.classCode is fixed to "PAT" to indicate a person (Patient) as a recipient of health care services from a healthcare provider.

Table X: Fixed PatientRole.classCode

Code	Display Name
PAT	patient
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

PatientRole.id

A unique identifier for the person in this patient role.

PatientRole.addr

The postal address for the Patient.

PatientRole.telecom

The phone number for the Patient.

5.2.2.11.2 Patient

Table X: Patient

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PSN	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
id (Deprecated)	SET<II>	[0..*]
name	SET<PN>	[0..*]
desc	ED	[0..1]
administrativeGenderCode	CE	[0..1]	D:administrativeGender	Open
birthTime	TS	[0..1]
deceasedInd	BL	[0..1]
deceasedTime	TS	[0..1]
multipleBirthInd	BL	[0..1]
multipleBirthOrderNumber	INT	[0..1]
maritalStatusCode	CE	[0..1]	D:MaritalStatus	Open
religiousAffiliationCode	CE	[0..1]	D:ReligousAffiliation	Open
raceCode	SET<CE>	[0..*]	D:Race	Open
ethnicGroupCode	SET<CE>	[0..*]	D:Ethnicity	Open

Note: Not all Patient elements defined in the RIM have been added to CDA's Patient class. Only those originally defined, or added using extensions within actual implementation guides have been included in CDA R2.1. Implementers are free to use extensions with CDA R2.1 or model missing information using the Observation class within the CDA body.

Patient.classCode

The Patient.classCode is fixed to "PSN", indicating that the entity is a person.

Table X: Fixed Patient.classCode

Code	Display Name
PSN	person
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Patient.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates a specific person is a patient.

Table X: Fixed Patient.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Patient.id (Deprecated)

CDA Release 1.0 allowed for additional person identifiers, corresponding to the Patient.id attribute in CDA Release 2.1. This attribute is included for backwards compatibility and has been deprecated because having two different ways to identify a patient can result in inconsistent usage. Further use of Patient.id is discouraged.

Patient.name

The patient's name.

Note: The person name data type "PN" supports current, and historical names using validTime, and the specification of different use codes can indicate legal name, tribal name, stage name and others.

Patient.desc

A textual or multimedia depiction of the patient.

Patient.administrativeGenderCode

The gender (i.e., the behavioral, cultural, or psychological traits typically associated with one sex) of a living subject as defined for administrative purposes.

Patient.birthTime

The date and time of the patient's birth.

Patient.deceasedInd

An indication that the subject is dead.

Patient.deceasedTime

The date and time that the patient's death occurred.
Note: If the deceasedTime is valued, then the deceasedInd SHALL be set true. If deceasedInd is set true, the deceasedTime should be valued, if known.

Patient.multipleBirthInd

An indication as to whether the patient was part of a multiple birth.

Patient.multipleBirthOrderNumber

The order within a multiple birth in which this patient was born.

Patient.maritalStatusCode

The domestic partnership status of the patient.

Patient.religiousAffiliationCode

The primary religious preference of the patient.

Patient.raceCode

The race of the patient.

Note: More than one race code is now supported in CDA R2.1.

Patient.ethnicGroupCode

The ethnic group of the patient.

Note: More than one ethnic group is now supported in CDA R2.1.

Note: See 2.7 Backwards and Forwards Compatibility, for discussion on sdtc: extensions defined for CDA R2.0 and CDA R2.1.

5.2.2.11.3 Organization

The optional Organization in recordTarget identifies the Patient's healthcare organization. Refer to Organization as defined for authenticator participation for details.

5.2.2.11.4 LanguageCommunication

A patient's language communication skills can be expressed in the associated LanguageCommunication class.

Table X: LanguageCommunication

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
languageCode	CS	[0..1]	D:HumanLanguage	Open
modeCode	CE	[0..1]	D:LanguageAbilityMode	Open
proficiencyLevelCode	CE	[0..1]	D:LanguageAbilityProficiency	Open
preferenceInd	BL	[0..1]

LanguageCommunication.languageCode

A language for which the patient has some level of proficiency for communication.
Note: Providing a language reference with the LanguageCommunication.languageCode is recommended, when using this class.

LanguageCommunication.modeCode

The method of expression of the language, e.g. expressed spoken, expressed written, expressed signed, received spoken, received written, received signed

LanguageCommunication.proficiencyLevelCode

The level of proficiency the patient has in a particular language, e.g. excellent, good, fair, poor

LanguageCommunication.preferenceInd

An indicator specifying whether the language is preferred by the patient for the associated mode.

5.2.2.11.5 Birthplace

A Patient's birthplace is represented as a relationship between a patient and a place. The Birthplace class is played by a place (Place class), and scoped by the patient (Patient class).

Table X: Birthplace

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	BIRTHPL	Fixed

Birthplace.classCode

The Birthplace.classCode it fixed to "BIRTHPL" indicating in this context, that the Place referenced is the birth place of the patient.

Table X: Fixed Birthplace.classCode

Code	Display Name
BIRTHPL	birthplace
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

5.2.2.11.6 Place

Table X: Place

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PLC	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
name	SET<ON>	[0..1]
addr	SET<AD>	[0..*]

Place.classCode

A physical place or site with its containing structure. May be natural or man-made. The geographic position of a place may or may not be constant.

Table X: Fixed Place.classCode

Code	Display Name
PLC	place
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Place.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates a specific place is being identified.

Table X: Fixed Place.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Place.name

The name of place of birth (E.g. Queen Mary)

Place.addr

The postal address for the patient's birthplace.

5.2.2.11.7 Guardian

A patient's guardian is a person or organization in the role of guardian (Guardian class). The entity playing the role of guardian is a person (Person class) or organization (Organization class). The entity scoping the role is the patient (Patient class).

Where a guardian is not explicitly stated, the value should default to local business practice (e.g. the patient makes their own health care decisions unless incapacitated in which case healthcare decisions are made by the patient's spouse).

Table X: Guardian

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	GUARD	Fixed
id	SET<II>	[0..*]
code	CE	[0..1]	D:RoleCode	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

Guardian.classCode

The Guardian.classCode is fixed to "GUARD", indicating that the associated person or institution are legally empowered with responsibility for the care of a ward.

Table X: Fixed Guardian.classCode

Code	Display Name
GUARD	guardian
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

Guardian.code

An optional role code taken from the RoleCode concept domain. This binding is open so other code systems can be used.

Guardian.addr

The guardian's postal address.

Guardian.telecom

The guardian's phone number.

5.2.2.11.8 Person

Refer to Person as defined for Author participation.

5.2.2.11.9 Organization

Refer to organization as defined for authenticator participation.

5.2.2.12 responsibleParty

See EncompassingEncounter for a description of the responsibleParty participant.

5.2.2.13 Participant Scenarios

Several CDA Header participations can be played by the same person. In such cases, the person should be identified as the player for each appropriate participation. For instance, if a person is both the author and the authenticator of a document, the CDA Header should identify that person as both the author participant and the authenticator participant.

On other occasions, CDA Header participants are played by different people. The following table shows a number of scenarios and the values for various participants.

Table X: CDA participation scenarios

1. StaffPhysicianOne sees a patient as a consultant, dictates a note, and later signs it.

Author — StaffPhysicianOne Encounter Participant — StaffPhysicianOne (typeCode="CONS") Legal Authenticator — StaffPhysicianOne

2. StaffPhysicianOne sees a patient and dictates a note. StaffPhysicianTwo later signs the note. *

Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianTwo

3. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianOne. *

Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne

4. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianTwo. *

Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo

5. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, and goes off on vacation. The note is signed by ResidentTwo and by StaffPhysicianOne. *

Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne

6. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, which is later signed by ResidentTwo and StaffPhysicianTwo. *

Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo

7. StaffPhysicianOne receives an abnormal laboratory result, attempts to contact patient but can't, and writes and signs a progress note.

Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianOne

8. ResidentSurgeonOne is operating on a patient with StaffSurgeonOne. StaffSurgeonOne dictates an operative report and later signs it.

Author — StaffSurgeonOne Authenticator — null (need not be included) Legal Authenticator — StaffSurgeonOne Performer — StaffSurgeonOne (typeCode="PPRF") Performer — ResidentSurgeonOne (typeCode="SPRF")

9. In Austria, a PET-CT report, is authored and legally authenticated by a radiologist together with a nuclear medicine specialist. The two specialists are working for different medical institutes. Their work and expertise are equal in importance.

Author — Radiologist Author — Nuclear Medicine Specialist Legal Authenticator — Radiologist Legal Authenticator — Nuclear Medicine Specialist

* Note that the ability of one clinician to co-sign or to sign on behalf of another clinician is subject to regulatory and local practice constraints.

5.2.3 Header Relationships

This section describes classes related to the root ClinicalDocument class via an ActRelationship.

5.2.3.1 ParentDocument

ParentDocument

The ParentDocument represents the source of a document revision, addenda, or transformation.

5.2.3.1.1 relatedDocument

The optional relatedDocument class is used to associate a ClinicalDocument to a ParentDocument.

Table X: relatedDocument Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[1..1]	x_ActRelationshipDocument	Closed
inversionInd	BL	[0..1]

relatedDocument.typeCode

Allowable values for the intervening relatedDocument.typeCode are shown in the following table.

Table X: Value set for relatedDocument.typeCode

v:x_ActRelationshipDocument [2.16.840.1.113883.1.11.11610] (CLOSED)
Code	Display Name		Code	Display Name
APND	is appendage		RPLC	replaces
XFRM	transformation
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

A conformant CDA document can have a single relatedDocument with typeCode "APND"; a single relatedDocument with typeCode "RPLC"; a single relatedDocument with typeCode "XFRM"; a combination of two relatedDocuments with typeCodes "XFRM" and "RPLC"; or a combination of two relatedDocuments with typeCodes "XFRM" and "APND". No other combinations are allowed.

relatedDocument.inversionInd

Technical note: CDA R2.0 design assumes that ClinicalDocument was the source for all typecodes found in relatedDocument, ("APND", "RPLC" and "XFRM"). For "APND" and "RPLC" this is correct, however for "XFRM", the RIM definition indicates that "it is used when the target Act is a transformation of the source Act...". This technically is an error in CDA R2.0's design, which normally should have required the use of inversionInd to establish the ClinicalDocument as the target and the ParentDocument as the source for the "XFRM" relation.

As a result, in CDA R2.1 when "XFRM" is assigned to the relatedDocument.typeCode, the associated inversionInd will be assumed to be fixed to true, but will not be required to be present in the instance document. In all other cases, "APND", "RPLC" the associated inversionInd will not be present and will be assumed to be false. This enables wire format compatibility between CDA R2.0 and CDA R2.1, and ensures proper interpretation of the "XFRM" ActRelationshipType code.

5.2.3.1.2 ParentDocument

The ParentDocument identifies and optionally provides a reference to the original document serving as the source for the current document revision, addendum or transformation.

Table X: ParentDocument Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DOCCLIN	Fixed
moodCode	CS	[0..1]	EVN	Fixed
typeId	II	[1..1]
id	II	[1..*]
code	CE	[1..1]	D:DocumentType	Open
text	ED	[0..1]
setId	II	[0..1]
versionNumber	ST	[0..1]

ParentDocument.classCode

The ParentDocument.classCode is fixed to "DOCCLIN".

Table X: Fixed ParentDocument.classCode

Code	Display Name
DOCCLIN	clinical document
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ParentDocument.moodCode

The ParentDocument.moodCode is fixed to "EVN".

Table X: Fixed ParentDocument.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ParentDocument.id

The ParentDocument.id is a required identifier, which uniquely identifies the parent document.

ParentDocument.code

The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note). The value set is drawn from LOINC, and has a CWE coding strength.

ParentDocument.text

ParentDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the parent document. It is not to be used to embed the related document, and thus ParentDocument.text.BIN is precluded from use.

ParentDocument.setId

Optional setID for the parent document.

ParentDocument.versionNumber

Optional versionNumber of the parent document.

Additional Information on Document Identification, Revisions, and Addenda

A clinical document can be replaced by a new document and/or appended with an addendum.

A replacement document is a new version of the parent document. The parent document is considered superseded, but a system may retain it for historical or auditing purposes. The parent document being replaced is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "RPLC" (for "replaces"). An example is a report found to contain an error that is subsequently replaced by the corrected report.

An addendum is a separate document that references the parent document, and may extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients. The parent report (represented by the ParentDocument class) being appended is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "APND" (for "appends").

Every CDA document must have a unique ClinicalDocument.id, and thus the replacement or addendum documents each have ClinicalDocument.id that is different from that of the parent document.

CDA documents may also contain a ClinicalDocument.setId and a ClinicalDocument.versionNumber, which together support a document identification and versioning scheme used in some document management systems. In this scheme, all documents in a chain of replacements have the same ClinicalDocument.setId and are distinguished by an incrementing ClinicalDocument.versionNumber. The initial version of a document gets, in addition to a new unique value for ClinicalDocument.id, a new value for ClinicalDocument.setId, and has the value of ClinicalDocument.versionNumber set to equal "1". A replacement document gets a new globally unique ClinicalDocument.id value, and uses the same value for ClinicalDocument.setId as the parent report being replaced, and increments the value of ClinicalDocument.versionNumber by 1. (Note that version number must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.)

These relationships are illustrated in the following exhibit "Document Identification, Revisions, and Addenda Scenarios". Typical scenarios are:

• A simple relacement (e.g. ClinicalDocument.id "1.2.345.6789.266" replacing ClinicalDocument.id "1.2.345.6789.123")
• A simple append (e.g. ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123").

More complex scenarios that might be anticipated include:

[1] replacement of an addendum (e.g. ClinicalDocument.id "1.2.345.6789.224" replaces ClinicalDocument.id "1.2.345.6789.456", which itself is an addendum to ClinicalDocument.id "1.2.345.6789.123") - expected behavior would be to render the replacement as the addendum (e.g. render ClinicalDocument.id "1.2.345.6789.224" as the addendum to ClinicalDocument.id "1.2.345.6789.123");

[2] addendum to a replaced document (e.g. ClinicalDocument.id "1.2.345.6789.456" appends ClinicalDocument.id "1.2.345.6789.123", which has been replaced by ClinicalDocument.id "1.2.345.6789.266") - expected behavior would be to render the addendum along with the replacement (e.g. render ClinicalDocument.id "1.2.345.6789.456" as an addendum to ClinicalDocument.id "1.2.345.6789.266").

Document transformations

A CDA document can be a transformation from some other format, meaning that it has undergone a machine translation from some other format (such as DICOM SR). In this case, relatedDocument.typeCode should be set to "XFRM".

A proper transformation must ensure that the human readable clinical content of the report is not impacted. Local business rules determine whether or not a transformed report replaces the source, but typically this would not be the case. If it is, an additional relationship of type "RPLC" is to be used. The "XFRM" relationship can also be used when translating a document in a local format into CDA for the purpose of exchange. In this case, the target of the "XFRM" relationship is the local document identifier.

Link to wide graphic (opens in a new window)

5.2.3.2 ServiceEvent

ServiceEvent

The ServiceEvent is used to represent the main activity being documented. It may used to represent a specific procedure, such as a colonoscopy, an appendectomy, or other clinical activity. When the ClinicalDocument represents a summary of care, the ServiceEvent.code can be set to "PCPR" to indicate the service is care provisioning.

5.2.3.2.1 documentationOf

The optional documentationOf class is used to associate a ClinicalDocument to a ServiceEvent.

Table X: documentationOf Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	DOC	Fixed

documentationOf.typeCode

The documentationOf.typeCode is fixed to "DOC" which indicates that the ClinicalDocument provides documentation is about ServiceEvent.

Table X: Fixed documentationOf.typeCode

Code	Display Name
DOC	documents
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.2.3.2.2 ServiceEvent

In some cases, the ServiceEvent is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "History and Physical Report" and the procedure being documented is a "History and Physical". A ServiceEvent can further specialize the act inherent in the ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Procedure Report" and the procedure was a "colonoscopy". If ServiceEvent is included, it must be equivalent to or further specialize the value inherent in the ClinicalDocument.code, and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

Table X: ServiceEvent Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	V:ActClassRoot	Fixed
moodCode	CS	[0..1]	EVN	Fixed
id	II	[0..*]
code	CD	[0..1]	D:ActCode	Open
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]

ServiceEvent.classCode

The ServiceEvent.classCode identifies the RIM Act class code of the service event instance.

Table X: Value set for ServiceEvent.classCode

V:ActClassRoot [2.16.840.1.113883.1.11.13856] (CLOSED)
Code	Display Name		Code	Display Name
ACT (Default)	act		COMPOSITION	composition, Attestable unit
DOC	document		DOCCLIN	clinical document
CDALVLONE	CDA Level One clinical document		CONTAINER	record container
CATEGORY	category		DOCBODY	document body
CATEGORY	document section, Section		TOPIC	topic
EXTRACT	extract		EHR	electronic health record
FOLDER	folder		GROUPER	grouper
CLUSTER	Cluster		ACCM	accommodation
ACCT	account		ACSN	accession
ADJUD	financial adjudication, financial adjudication results		CACT	control act
ACTN	action		INFO	information
STC	state transition control		CNTRCT	contract
FCNTRCT	financial contract		COV	coverage
CONS	consent		CONTREG	container registration
CTTEVENT	clinical trial timepoint event		DISPACT	disciplinary action
EXPOS	exposure		AEXPOS	acquisition exposure
TEXPOS	transmission exposure		INC	incident
INFRM	inform		INVE	invoice element
LIST	working list		MPROT	monitoring program
OBS	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		PCPR	care provision
ENC	encounter		POLICY	policy
JURISPOL	jurisdictional policy		ORGPOL	organizational policy
SCOPOL	scope of practice policy		STDPOL	standard of practice policy
PROC	procedure		SBEXT	Substance Extraction
SPECCOLLECT	Specimen Collection		SBADM	substance administration
REG	registration		REV	review
SPCTRT	specimen treatment		SPLY	supply
DIET	diet		STORE	storage
SUBST	Substitution		TRFR	transfer
TRNS	transportation		XACT	financial transaction
CNOD (Deprecated)	Condition Node		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ServiceEvent.moodCode

The ServiceEvent.moodCode is fixed to "EVN", which indicates documentation of a past service.

Table X: Fixed ServiceEvent.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ServiceEvent.id

The optional unique identifier for the ServiceEvent.

ServiceEvent.code

The particular kind of service event that the this instance represents within its class code. The ServiceEvent.code is bound to the D:ActCode concept domain.

ServiceEvent.statusCode

The ServiceEvent.statusCode can take on any of the values defined in the D:ActStatus domain.

ServiceEvent.effectiveTime

ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the encounter surrounding the event) took place.

5.2.3.2.3 performer

The performer participant represents clinicians who actually and principally carry out the ServiceEvent.

Table X: performer

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[1..1]	x_ServiceEventPerformer	Closed
functionCode	CE	[0..1]	D:ParticipationFunction	Open
time	TS	[1..1]

performer.typeCode

Allows for the optional identification of performers, primary performers and secondary performers.

Table X: Value set for performer.typeCode

v:x_ServiceEventPerformer [2.16.840.1.113883.1.11.19601] (CLOSED)
Code	Display Name		Code	Display Name
PRF	performer		PPRF	primary performer
SPRF	secondary performer
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

performer.functionCode

Performer.functionCode can be used to specify addition detail about the function of the performer (e.g. scrub nurse, third assistant). The functionCode is bound to the D:ParticipationFunction concept domain.

performer.time

Performer.time can be used to specify the time during which the performer is involved in the activity.

5.2.3.2.4 AssignedEntity

A performer is an entity in the role of assigned entity (AssignedEntity class).

5.2.3.2.5 Person

An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person] class).

5.2.3.2.6 Organization

The entity scoping the role is an organization (Organization class).

5.2.3.3 Order

Order

This class represents those requests that are fulfilled by this document. For instance, a provider orders an X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order identifier is transmitted in the Order class, the performed X-Ray procedure is transmitted in the ServiceEvent class, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".

5.2.3.3.1 inFullfillmentOf

The optional inFullfillmentOf class is used to associate a ClinicalDocument to an Order.

Table X: Fixed InFulfillmentOf.typeCode

Code	Display Name
FLFS	fulfills
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.2.3.3.2 Order

A reference to the fulfilled order.

Table X: Order Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	V:ActClassRoot	Closed
moodCode	CS	[0..1]	RQO	Fixed
id	II	[1..*]
code	CD	[0..1]	D:ActCode	Open
priorityCode	CS	[0..1]	V:ActPriority	Open

Order.classCode

The Order.classCode identifies the RIM Act class code of the order instance.

Table X: Value set for Order.classCode

V:ActClassRoot [2.16.840.1.113883.1.11.13856] (CLOSED)
Code	Display Name		Code	Display Name
ACT (Default)	act		COMPOSITION	composition, Attestable unit
DOC	document		DOCCLIN	clinical document
CDALVLONE	CDA Level One clinical document		CONTAINER	record container
CATEGORY	category		DOCBODY	document body
CATEGORY	document section, Section		TOPIC	topic
EXTRACT	extract		EHR	electronic health record
FOLDER	folder		GROUPER	grouper
CLUSTER	Cluster		ACCM	accommodation
ACCT	account		ACSN	accession
ADJUD	financial adjudication, financial adjudication results		CACT	control act
ACTN	action		INFO	information
STC	state transition control		CNTRCT	contract
FCNTRCT	financial contract		COV	coverage
CONS	consent		CONTREG	container registration
CTTEVENT	clinical trial timepoint event		DISPACT	disciplinary action
EXPOS	exposure		AEXPOS	acquisition exposure
TEXPOS	transmission exposure		INC	incident
INFRM	inform		INVE	invoice element
LIST	working list		MPROT	monitoring program
OBS	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		PCPR	care provision
ENC	encounter		POLICY	policy
JURISPOL	jurisdictional policy		ORGPOL	organizational policy
SCOPOL	scope of practice policy		STDPOL	standard of practice policy
PROC	procedure		SBEXT	Substance Extraction
SPECCOLLECT	Specimen Collection		SBADM	substance administration
REG	registration		REV	review
SPCTRT	specimen treatment		SPLY	supply
DIET	diet		STORE	storage
SUBST	Substitution		TRFR	transfer
TRNS	transportation		XACT	financial transaction
CNOD (Deprecated)	Condition Node		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Order.moodCode

The Order.moodCode is fixed to "RQO", which indicates we are referencing the actual order instance.

Table X: Fixed Order.moodCode

Code	Display Name
RQO	request
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Order.id

The Order.id is a unique identifier for the order that was fulfilled.

Order.code

The particular kind of order that the this instance represents within its class code. The optional Order.code is bound to the D:ActCode concept domain.

Order.priorityCode

The optional Order.priorityCode, identifies the priority requested when the order was placed. It is bound to the D:ActPriority concept domain.

5.2.3.4 Consent

Consent

Provides references to consents on file.

5.2.3.4.1 authorization

The optional authorization class is used to associate a ClinicalDocument to a Consent.

Table X: authorization Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	AUTH	Fixed

authorization.typeCode

Table X: Fixed authorization.typeCode

Code	Display Name
AUTH	authorized by
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.2.3.4.2 Consent

This class references the consents associated with this document.

Table X: Consent Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	CONS	Fixed
moodCode	CS	[0..1]	EVN	Fixed
id	II	[0..*]
code	CD	[0..1]	D:ActCode	Open
statusCode	CS	[1..1]	completed	Fixed

Consent.classCode

The Consent.classCode is fixed to "CONS" to represent a consent. The Consent class represents informed consents and all similar medico-legal transactions between the patient (or his legal guardian) and the provider.

Table X: Fixed Consent.classCode

Code	Display Name
CONS	consent
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Consent.moodCode

The Consent.moodCode is fixed to "EVN" (event) which indicates the consent has already been captured and is assumed to be on file.

Table X:Fixed Consent.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Consent.id

Optional identifier for the consent.

Consent.code

The Consent.code is bound to the D:ActCode concept domain. It is used to optionally identify the type of consent (e.g. a consent to perform the related ServiceEvent, a consent for the information contained in the document to be released to a third party).

Consent.statusCode

Consents referenced in the CDA Header have been finalized (Consent.statusCode must equal "completed") and should be on file.

Table X: Fixed Consent.statusCode

Code	Display Name
completed	completed
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

5.2.3.5 EncompassingEncounter

EncompassingEncounter

This optional class represents the setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred. Documents are not necessarily generated during an encounter, such as when a clinician, in response to an abnormal laboratory result, attempts to contact the patient but can't, and writes a Progress Note: in such a case, the encompassingEncounter could be omitted.

5.2.3.5.1 componentOf

The optional componentOf class is used to associate the ClinicalDocument to an EncompassingEncounter.

Table X: componentOf Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	COMP	Fixed

componentOf.typeCode

The componentOf.typeCode is fixed to "COMP", which indicates that the ClinicalDocument was created within the context of an encounter (encompassingEncounter).

Table X: Fixed componentOf.typeCode

Code	Display Name
COMP	component
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.2.3.5.2 EncompassingEncounter

The EncompassingEncounter represents an interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s).

Table X: EncompassingEncounter Attributes

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	ENC	Fixed
moodCode	CS	[0..1]	EVN	Fixed
id	II	[0..*]
code	CD	[0..1]	V:ActEncounterCode	Open
effectiveTime	IVL<TS>	[0..1]
admissionReferralSourceCode	CE	[0..1]	D:EncounterReferralSourceCode	Open
dischargeDispositionCode	CE	[0..1]	D:EncounterDischargeDisposition	Open

EncompassingEncounter.classCode

The EncompassingEncounter.classCode is fixed to "ENC" to represent a encounter. The encounter class is used to represent an interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient.

Table X: Fixed EncompassingEncounter.classCode

Code	Display Name
ENC	encounter
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

EncompassingEncounter.moodCode

The EncompassingEncounter.moodCode is fixed to "EVN" (event) which indicates that the encounter is on-going or completed.

Table X: Fixed EncompassingEncounter.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

EncompassingEncounter.id

The optional EncompassingEncounter.id can be used to uniquely identify the encounter.

EncompassingEncounter.code

The optional EncompassingEncounter.code is bound to the ActEncounterCode value set.

Table X: Value set for EncompassingEncounter.code

V:ActEncounterCode [2.16.840.1.113883.1.11.13955] (OPEN)
Code	Display Name		Code	Display Name
AMB	ambulatory		EMER	emergency
FLD	field		HH	home health
IMP	inpatient encounter		ACUTE	inpatient acute
NONAC	virtual		SS	short stay
VR	inpatient non-acute
Code System: ActCode (HL7) Code System OID: 2.16.840.1.113883.5.4

EncompassingEncounter.effectiveTime

For Encounters, the effectiveTime is the "administrative" time, i.e., the encounter start and end date as established by business rules. For inpatient encounters, the effectiveTime/low value is the admission date and time and the effectiveTime/high value is the discharge date and time. Note: If the encounter is still active at the time of document creation, the effectiveTime/high element SHALL be omitted to indicate the encounter is on-going. This is preferred over using a nullFlavor.

EncompassingEncounter.admissionReferralSourceCode

The optional EncompassingEncounter.admissionReferralSourceCode can be use to depict the type of place or organization responsible for the patient's care immediately prior to a patient encounter.

EncompassingEncounter.dischargeDispositionCode

The optional EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).

5.2.3.5.3 location

The location participant (location class) relates a healthcare facility (HealthCareFacility class) to the encounter to indicate where the encounter took place.

Table X: location

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[1..1]	LOC	Fixed

location.typeCode

Table X: Fixed participant.typeCode

Code	Display Name
LOC	location
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

5.2.3.5.4 HealthCareFacility

The HealthCareFacility class supports the identification of the service delivery location. The location may be the setting (place) with an optional organizational reference, or a reference to the healthcare organization.

Table X: HealthCareFacility

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	V:RoleClassServiceDeliveryLocation	Closed
id	SET<II>	[0..*]
code	CE	[0..1]	V:ServiceDeliveryLocation	Open

HealthCareFacility.classCode

The HealthCareFacility.classCode is bound to the ServiceDeliveryLocation value set and defaulted to the "SDLOC" to indicate the service delivery location.

Table X: Value set for HealthCareFacility.classCode

v:RoleClassServiceDeliveryLocation [2.16.840.1.113883.1.11.16927] (CLOSED)
Code	Display Name		Code	Display Name
SDLOC (Default)	service delivery location		DSDLOC	dedicated service delivery location, health care facility
ISDLOC	incidental service delivery location
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

HealthCareFacility.id

An optional HealthCareFacility.id can be sent to uniquely identify the health care facility.

HealthCareFacility.code

The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. A value set ServiceDeliveryLocationRoleType is provided for the this field.

Note: In some cases, the setting of the encounter is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Diabetes Clinic Progress Note". The setting of an encounter can also be transmitted in the HealthCareFacility.code attribute. If HealthCareFacility.code is sent, it should be equivalent to or further specialize the value inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Clinic Progress Note" and the value of HealthCareFacility.code is "cardiology clinic"), and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.

5.2.3.5.5 Place

The entity playing the role of HealthCareFacility is a place (Place class).

The setting (place) and physical location are not the same. There is a many-to-many relationship between setting and the physical location where care is delivered. Thus, a particular room can provide the setting for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.

5.2.3.5.6 Organization

The entity scoping the HealthCareFacility role is an organization (Organization class). When the location is an organization, this is indicated by the presence of a scoping Organization, without a playing Place.

5.2.3.5.7 responsibleParty

The responsibleParty participant represents the participant having primary legal responsibility for the encounter. This differs from the legalAuthenticator participant in that the legalAuthenticator may or may not be the responsible party, and is serving a medical records function by signing off on the document, moving it into a completed state.

responsibleParty.typeCode

The responsibleParty.typeCode is fixed to "RESP" to indicate the responsible party i.e. The person or organization that has primary responsibility for the encounter. The responsible party is not necessarily present in an action, but is accountable for the action through the power to delegate, and the duty to review actions with the performing actor after the fact. This responsibility may be ethical, legal, contractual, fiscal, or fiduciary in nature.

Table X: Fixed responsibleParty.typeCode

Code	Display Name
RESP	responsible party
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

A responsibleParty is a person or organization in the role of an assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

When the responsible party is an organization, the value for AssignedEntity.classCode is "ASSIGNED", and the responsible party is reflected by the presence of a scoping Organization, without a playing entity.

5.2.3.5.8 AssignedEntity

A performer is an entity in the role of assigned entity (AssignedEntity class).

5.2.3.5.9 Person

An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a Person class.

5.2.3.5.10 Organization

The entity scoping the role is an organization (Organization class).

5.2.3.5.11 encounterParticipant

The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).

Table X: performer

Attribute Name	Data Type	Wire Cardinality	Code Binding	Binding Type
typeCode	CS	[1..1]	V:x_EncounterParticipant	Closed
time	TS	[0..1]

encounterParticipant.typeCode

The encounterParticipant typeCode is bound to the x_EncounterParticipant value set. It supports for the following participation: admitter, attender, consultant, discharger, and referrer.

Table X: Value set for encounterParticipant.typeCode

V:x_EncounterParticipant [2.16.840.1.113883.1.11.19600] (CLOSED)
Code	Display Name		Code	Display Name
ADM	admitter		ATND	attender
CON	consultant		DIS	discharger
REF
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

encounterParticipant.time

An encounterParticipant is an entity in the role of assigned entity (AssignedEntity class). An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a person (Person class). The entity scoping the role is an organization (Organization class).

5.2.3.5.12 AssignedEntity

A performer is an entity in the role of assigned entity (AssignedEntity class).

5.2.3.5.13 Person

An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a Person class.

5.2.3.5.14 Organization

The entity scoping the role is an organization (Organization class).

5.3 Body

5.3.1 Body Choice

The CDA body choice can be either a document body in a format other than XML, or the CDA structured body. Every CDA document has exactly one body, associated with the ClinicalDocument class through the component relationship.

5.3.1.1 component

The component class relates the ClinicalDocument header to the body choice; NonXMLBody or StructuredBody.

Table X: documentationOf Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	DOC	Fixed
contextConductionInd	BL	[0..1]

component.typeCode

The component.typeCode is fixed to "COMP", which indicates that the body is a component part of the StructuredDocument.

Table X: Fixed component.typeCode

Code	Display Name
COMP	has component
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

component.contextConductionInd

The component.contextConductionInd indicator is fixed to "true". Ancestor elements () which propagate, will conduct through this component class to the associated child element.

5.3.1.2 NonXMLBody

The NonXMLBody class represents a document body that is in some format other than XML. The NonXMLBody can be used to represent scanned document(s) or legacy document(s) needing to be transferred using the CDA standard.

Table X: NonXMLBody Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DOCCLIN	Fixed
moodCode	CS	[0..1]	EVN	Fixed
text	ED	[1..1]
confidentialityCode	SET<CE>	[0..*]	V:x_BasicConfidentialityKind	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed

NonXMLBody.typeCode

The ClinicalDocument.classCode in the CDA model is fixed to "DOCCLIN".

Table X: Fixed NonXMLBody.classCode

Code	Display Name
DOCBODY	document body
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

NonXMLBody.moodCode

The NonXMLBody.moodCode is fixed to "EVN" or event mood to indicate that this is documentation of a past service.

Table X: Fixed NonXMLBody.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

NonXMLBody.text

NonXMLBody.text is used to reference data that is stored externally to the CDA document or to encode the data directly inline. Rendering a referenced non-XML body requires a software tool that recognizes the particular MIME media type for this type of body.

NonXMLBody.confidentialityCode

Confidentiality is a required contextual component of CDA, where the value expressed in the ClinicalDocument can be overridden for the NonXMLBody of the document.

Table X: Value set for NonXMLBody.confidentialityCode

X_BasicConfidentialityKind [2.16.840.1.113883.1.11.16926] (OPEN)
Code	Display Name		Code	Display Name
N	normal		R	restricted
V	very restricted
Code System: Confidentiality (HL7) Code System OID: 2.16.840.1.113883.5.25

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.

NonXMLBody.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066 for the Identification of Languages, ed. H. Alvestrand. 1995, which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121". Language is a contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by the NonXMLBody (as further described in CDA Context).

5.3.1.3 StructuredBody

The StructuredBody class represents a CDA document body that is comprised of one or more document sections.

Table X: StructuredBody Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DOCCLIN	Fixed
moodCode	CS	[0..1]	EVN	Fixed
confidentialityCode	SET<CE>	[0..*]	V:x_BasicConfidentialityKind	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed

StructuredBody.classCode

Table X: Fixed StructuredBody.classCode

Code	Display Name
DOCBODY	document body
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

StructuredBody.moodCode

Table X: Fixed StructuredBody.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

StructuredBody.confidentialityCode

Table X: Value set for StructuredBody.confidentialityCode

X_BasicConfidentialityKind [2.16.840.1.113883.1.11.16926] (OPEN)
Code	Display Name		Code	Display Name
N	normal		R	restricted
V	very restricted
Code System: Confidentiality (HL7) Code System OID: 2.16.840.1.113883.5.25

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.

StructuredBody.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 1995 , which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121".

A value for StructuredBody.languageCode overrides the value propagated from the header. See CDA Context for more details.

5.3.1.3.1 component

A component class is used to relate the body choice (NonXMLBody, StructuredBody) to it's component Section(s). See component for its attributes.

5.3.2 Section Attributes

Section

Document sections can nest, can override context propagated from the header (see CDA Context, and can contain narrative and CDA entries.

Table X: Section Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DOCSECT	Fixed
moodCode	CS	[0..1]	EVN	Fixed
id	II	[0..1]
code	CE	[1..1]	D:DocumentSectionType	Open
title	ST	[0..1]
text	ED.STRUCTURED_TEXT	[0..1]
confidentialityCode	SET<CE>	[0..*]	V:x_BasicConfidentialityKind	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed

NOTE: XML ID Attribute added. For more information, see ID/IDREF discussion in Section Narrative Block.

Section.classCode

The Section.classCode is fixed to "DOCSECT", which represents a context that subdivides the body of a document. Document sections are typically used for human navigation, to give a reader a clue as to the expected content. Document sections are used to organize and provide consistency to the contents of a document body. Document sections can contain document sections and can contain entries.

Table X: Fixed Section.classCode

Code	Display Name
DOCSECT	document section
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Section.moodCode

The Section.moodCode is fixed to "EVN" (event) which indicates the section is about a service that actually happens, may be an ongoing service or a documentation of a past service.

Table X: Fixed Section.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Section.id

The unique instance identifier of a particular document section.

Section.code

The code specifying the particular kind of section (e.g. Chief Complaint, Review of Systems, Assessment). The value set is drawn from LOINC in the US Realm, but has an OPEN binding to enable other coding systems in other realms.

Section.title

Represents the label of a section. If valued, it is to be rendered as part of the narrative content of the clinical document body.

Section.text

Used to store narrative to be rendered. Also referred to as the CDA Narrative Block. See Section Narrative Block for details.

Section.confidentialityCode

A value for Section.confidentialityCode overrides the value propagated from StructuredBody. See CDA Context for more details.

Table X: Value set for Section.confidentialityCode

X_BasicConfidentialityKind [2.16.840.1.113883.1.11.16926] (OPEN)
Code	Display Name		Code	Display Name
N	normal		R	restricted
V	very restricted
Code System: Confidentiality (HL7) Code System OID: 2.16.840.1.113883.5.25

* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.

Section.languageCode

Specifies the human language of character data (whether they be in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 1995 , which obsoletes RFC 1766. The HL7 code system for these values is "2.16.840.1.113883.6.121".

A value for Section.languageCode overrides the value propagated from StructuredBody. See CDA Context for more details.

5.3.3 Section Participants

5.3.3.1 author

The author participant (described above, see author), can be ascribed to a CDA section, where it overrides the value(s) propagated from the CDA header.

5.3.3.2 informant

The informant participant (described above, see informant), can be ascribed to a CDA section where it overrides the value(s) propagated from the CDA header.

5.3.3.3 subject

The subject participant represents the primary target of the entries recorded in the document. Most of the time the subject is the same as the recordTarget (see recordTarget), but need not be, for instance when the subject is a fetus observed in an obstetrical ultrasound.

The subject participant can be ascribed to a CDA section or a CDA entry. It propagates to nested components, unless overridden. The subject of a document is presumed to be the patient.

Table X: informant

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	INF	Fixed
contextControlCode	CS	[0..1]	OP	Fixed
awarenessCode	CE	[0..1]	D:TargetAwareness	Open

subject.typeCode

The subject.typeCode is fixed to "SBJ" to indicate that a participant that is the principle target (subject) of the service acts documented.

Table X: Fixed subject.typeCode

Code	Display Name
SBJ	subject
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

subject.contextControlCode

The subject.contextControlCode is fixed to "OP". Any subject(s) defined for a section will override the the Patient in recordTarget (an implicit subject) and propagate to the sub-sections and entries this section contains.

Table X: Fixed subject.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

5.3.3.3.1 RelatedSubject

A subject is a person playing one of several possible roles (RelatedSubject class).

Table X: RelatedSubject

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	x_DocumentSubject	Closed
code	CE	[0..1]	D:PersonalRelationshipRoleType	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

RelatedSubject.classCode

The RelatedSubject.classCode can take two codes; "PAT" a Role of a LivingSubject (player) as a recipient of health care services from a healthcare provider (scoper) and "PRS" which links two people in a personal relationship. The character of the relationship must be defined by a PersonalRelationshipRoleType code.

Table X: Value set for RelatedSubject.classCode

v:x_DocumentSubject [2.16.840.1.113883.1.11.19368] (CLOSED)
Code	Display Name		Code	Display Name
PAT (Default)	patient		PRS	personal relationship
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

RelatedSubject.code

The RelatedSubject.code is bound to the PersonalRelationshipRoleType concept domain

RelatedSubject.addr

An optional postal address for the subject.

RelatedSubject.telecom

An optional phone number for the subject.

5.3.3.3.2 SubjectPerson

The entity playing in the role RelatedSubject, is a person (SubjectPerson class).

Table X: SubjectPerson

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PSN	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
id	SET<II>	[0..*]
name	SET<PN>	[0..*]
desc	ED	[0..1]
administrativeGenderCode	CE	[0..1]	D:administrativeGender	Open
birthTime	TS	[0..1]
deceasedInd	BL	[0..1]
deceasedTime	TS	[0..1]
multipleBirthInd	BL	[0..1]
multipleBirthOrderNumber	INT	[0..1]
maritalStatusCode	CE	[0..1]	D:MaritalStatus	Open
religiousAffiliationCode	CE	[0..1]	D:ReligousAffiliation	Open
raceCode	SET<CE>	[0..*]	D:Race	Open
ethnicGroupCode	SET<CE>	[0..*]	D:Ethnicity	Open

SubjectPerson.classCode

The SubjectPerson.classCode is fixed to "PSN", indicating that the entity is a person.

Table X: Fixed SubjectPerson.classCode

Code	Display Name
PSN	person
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

SubjectPerson.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates a specific person is a SubjectPerson.

Table X: Fixed SubjectPerson.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

SubjectPerson.id

Optional identifier for the SubjectPerson.

SubjectPerson.name

The subject's name.

Note: The person name data type "PN" supports current, and historical names using validTime, and the specification of different use codes can indicate legal name, tribal name, stage name and others.

SubjectPerson.desc

A textual or multimedia depiction of the subject.

SubjectPerson.administrativeGenderCode

The gender (i.e., the behavioral, cultural, or psychological traits typically associated with one sex) of a living subject as defined for administrative purposes.

SubjectPerson.birthTime

The date and time of the subject's birth.

SubjectPerson.deceasedInd

An indication that the subject is dead.

SubjectPerson.deceasedTime

The date and time that the Subject's death occurred.

SubjectPerson.multipleBirthInd

An indication as to whether the subject was part of a multiple birth.

SubjectPerson.multipleBirthOrderNumber

The order within a multiple birth in which this subject was born.

SubjectPerson.maritalStatusCode

The domestic partnership status of the subject.

SubjectPerson.religiousAffiliationCode

The primary religious preference of the subject.

SubjectPerson.raceCode

The race of the subject.

Note: More than one race code is now supported in CDA R2.1.

SubjectPerson.ethnicGroupCode

The ethnic group of the subject.

Note: More than one ethnic group is now supported in CDA R2.1.

Note: See 2.7 Backwards and Forwards Compatibility, for discussion on sdtc: extensions defined for CDA R2.0 and CDA R2.1.

5.3.4 Section Relationships

5.3.4.1 component

The "component" Act Relationship is used to nest a Section within a Section. Context propagates to nested sections (see CDA Context). Refer to component above for more information.

5.3.4.2 entry

The relationship between a section and its entries is encoded in the intervening "entry" Act Relationship.

The narrative of each Section, together with the multimedia content referenced in the narrative, comprises the complete authenticated content of the Section. This multimedia content consists of ObservationMedia and RegionOfInterest entries referenced by tags in the Section.text. This is the only case where the entries contain authenticated content that must be rendered with the narrative.

NOTE: See Referencing in and out of the narrative block for a discussion of referencing in and out of a section's narrative block.

Table X: entry Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	V:x_ActRelationshipEntry	Fixed
contextConductionInd	BL	[0..1]

entry.typeCode

In terms of the relationship between a section and its entries, CDA defines a default general case, and a more specific case that can be used when applicable.

The entry relationship is defaulted to "COMP" (component), for the general case where the only assertion is that the related entries are contained within the source section and no other semantics are implied. In this case, the narrative is the original authenticated content. The CDA entries are created by various techniques (e.g., natural language processing, a human coder, a structured data entry tool that outputs both entries and a text report). The method of entry creation may be indicated by the entry participants (e.g., by identifying the algorithm or person that generated them). Relationships between various entries (such as two Observations or an Observation and an ObservationMedia) are encoded using the relationship types defined in entryRelationship.

A section may also have no narrative content in the case where the entries represent information that is not part of the clinical content of the document. A report may embed information referencing evidence data, reagents, calibration or other information that may be used for later processing but is not part of the clinical content. Such entries are also linked to the Section with ActRelationships possessing typeCode="COMP".

The entry relationship "DRIV" (is derived from) can be used in the special case where the narrative is fully derived from CDA Entries. When a report consisting entirely of structured entries is transformed into CDA, the encoding application must ensure that the authenticated content (narrative plus multimedia) is a faithful and complete rendering of the clinical content of the structured source data. This ensures that the narrative plus multimedia represents, as in all CDA documents, the complete authenticated content of the Section. In this case, narrative plus multimedia does not contain any clinical content that is not present in the Entries. An example of this case is a DICOM Structured Reporting document of obstetrical measurements made by ultrasound, rendered into a tabular report by a program converting it to CDA narrative block. If the typeCode of the ActRelationship linking these Entries to the Section was "DRIV", it would indicate to a receiving application: 1) the source of the narrative block is the Entries; 2) the contents of the two are equivalent.

The entries sourced from a Section may have a mix of ActRelationship typeCodes. In such a case, the union of the targets with a "DRIV" relationship are those used to generate the narrative block, and are those that, taken in total, are equivalent to the narrative block. Additional entries with "COMP" relationships are contained within the same section, with no implied semantics.

Table X: Value set for entry.typeCode

V:x_ActRelationshipEntry [2.16.840.1.113883.1.11.19446] (CLOSED)
Code	Display Name		Code	Display Name
COMP (Default)	has component		DRIV	is derived from
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

entry.contextConductionInd

The component.contextConductionInd indicator is fixed to "true". Ancestor elements () which propagate, will conduct through this component class to the associated child element.

5.3.5 Section Narrative Block

The Section.text field is used to store narrative to be rendered, as described above in CDA Conformance, and is therefore referred to as the CDA Narrative Block.

The CDA Narrative Block schema can be found here.

The content model of the CDA Narrative Block schema is specially hand crafted to meet the requirements outlined above (see Human Readability and Rendering CDA Documents). The schema is registered as a MIME type (text/x-hl7-text+xml), which is the fixed media type for Section.text. Components of the schema are described in the sections that follow.

5.3.5.1 <content>

The CDA <content> element is used to wrap a string of text so that it can be explicitly referenced, or so that it can suggest rendering characteristics. The <content> element can nest recursively, which enables wrapping a string of plain text down to as small a chunk as desired.

The <content> element contains an optional identifier, that can serve as the target of a reference. All values of attributes of type XML ID must be unique within the document (per the W3C XML specification). The originalText component of a RIM attribute present in any CDA entry can make explicit reference to the identifier, thereby indicating the original text associated with the attribute in the CDA entry.

Note: The <content> element is not the only element which can serve as the target of a reference. All narrative elements (including <text>) contain an ID element which can be referenced by the originalText component in a CDA entry. <content> is simply a tool which can be used to reference only a portion of a longer string contained in another narrative element.

Example X

<section>
   <code code="10153-2" 
    codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Past Medical History</title>
   <text>
    There is a history of <content ID="a1">Asthma</content>
   </text>
   <entry>
      <observation classCode="OBS" moodCode="EVN">
         <code code="195967001" 
          codeSystem="2.16.840.1.113883.6.96" 
          codeSystemName="SNOMED CT" 
          displayName="Asthma">
            <originalText>
               <reference value="#a1"/>
            </originalText>
         </code>
         <statusCode code="completed"/>
      </observation>
   </entry>
</section>

There is no requirement that CDA entries must reference into the CDA Narrative Block. The referencing mechanism can be used where it is important to represent the original text component of a coded CDA entry.

The <content> element contains an optional "revised" attribute that can be valued with "insert" or "delete", which can be used to indicate narrative changes from the last version of a CDA document. The attribute is limited to a single generation, in that it only reflects the changes from the preceding version of a document. If applied, it needs to be used in conjunction with standard CDA revision tracking. Changes to a CDA document that has been released for patient care still require a formal versioning and revision, and the revised document can optionally carry the "revised" attribute to show the delta in the narrative. Receivers are required to interpret the "revised" attribute when rendering by visually distinguishing or suppressing deleted narrative.

5.3.5.2 <linkHtml>

The CDA <linkHtml> is a generic referencing mechanism, similar, but not identical, to the HTML anchor tag. It can be used to reference identifiers that are either internal or external to the document.

Multimedia that is integral to a document, and part of the attestable content of the document requires the use of the ObservationMedia CDA entry, which is referenced by the <renderMultiMedia> element (see <renderMultiMedia>). Multimedia that is simply referenced by the document and not an integral part of the document can use <linkHtml>.

The source of a link uses the linkHtml.href attribute. The target of an internal reference is an identifier of type XML ID, which can exist on other elements in the same or a different narrative block, or XML ID attributes that have been added to the <section>, <ObservationMedia>, or <renderMultiMedia> elements of the CDA Schema. The linkHtml.name attribute is deprecated, because attributes of type XML ID provide an alternative and more consistent target for referencing. Following the conventions of HTML, an internal link is prefaced with the pound sign, as shown in the following example.

Example X

<section ID="SECT001">
   <code code="10164-2" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>History of Present Illness</title>
   <text>Mr. Smith is a 57 year old male presenting with 
    chest pain. He sustained a myocardial infarction 3 years 
    ago, ...
   </text>
</section>

 ...

<section ID="SECT003">
   <code code="10153-2" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Past Medical History</title>
   <text>History of coronary artery disease, as noted
    <linkHtml href="#SECT001">above</linkHtml>.</text>
</section>

CDA links do not convey shareable meaning. Shareable semantics are only achieved by the inclusion of CDA entries and their associated formalized relationships. There is no requirement that a receiver render an internal or external link, or the target of an external link.

5.3.5.3 <sub> and <sup>

The CDA <sub> and <sup> elements are used to indicate subscripts and superscripts, respectively.

Receivers are required to interpret these elements when rendering by visually distinguishing subscripted and superscripted characters.

5.3.5.4 <br>

The CDA <br/> element is used to indicate a hard line break. It differs from the CDA <paragraph> element in that the <br/> element has no content. Receivers are required to interpret this element when rendering so as to represent a line break.

5.3.5.5 <footnote> and <footnoteRef>

The CDA <footnote> element is used to indicate a footnote. The element contains the footnote, inline with the flow of text to which it is applied.

The <footnoteRef> element can reference an existing footnote in the same or different CDA Narrative Block of the same document. It can be used when the same footnote is being used multiple times. The value of the footnoteRef.IDREF must be an footnote.ID value in the same document.

Receivers are required to interpret these elements when rendering by visually distinguishing footnoted text. The exact rendition is at the discretion of the recipient, and might include a mark at the location of the footnote with a hyperlink to the footnoted text, a simple demarcation (such as "This is the text [this is the footnote] that is being footnoted"), etc.

5.3.5.6 <renderMultiMedia>

The CDA <renderMultiMedia> element references external multimedia that is integral to a document, and part of the attestable content of the document, and serves to show where the referenced multimedia is to be rendered.

The <renderMultiMedia> element has an optional <caption>, and contains a required referencedObject attribute (of type XML IDREFS), the values of which must equal the XML ID value(s) of ObservationMedia or RegionOfInterest CDA entries within the same document.

Example X

<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Skin exam</title>
   <text>Erythematous rash, palmar surface, left index 
    finger.<renderMultiMedia referencedObject="MM1"/>
   </text>
   <entry>
      <observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
         <id root="2.16.840.1.113883.19.2.1"/>
         <value xsi:type="ED" mediaType="image/jpeg">
            <reference value="left_hand_image.jpeg"/>
         </value>
      </observationMedia>
   </entry>
</section>

Multimedia that is simply referenced by the document and not an integral part of the document must use <linkHtml>.

The expected behavior is that the referenced multimedia should be rendered or referenced at the point of reference. Where a caption is present, it must also be rendered. <renderMultiMedia> can either reference a single ObservationMedia, or one or more RegionOfInterest. If <renderMultiMedia> references a single ObservationMedia, that ObservationMedia should be rendered or referenced at the point of reference. If <renderMultiMedia> references one or more RegionOfInterest, all RegionOfInterests should be rendered or referenced at the point of reference, atop the multimedia they are regions of. If <renderMultiMedia> references more than one RegionOfInterest, each RegionOfInterest must be a region on the same multimedia.

5.3.5.7 <paragraph>

A CDA <paragraph> is similar to the HTML paragraph, which allows blocks of narrative to be broken up into logically consistent structures. A CDA <paragraph> element contains an optional caption, which if present must come first before any other character data.

5.3.5.8 <list>

A CDA <list> is similar to the HTML list. A CDA <list> has an optional caption, and contains one or more <item> elements. A CDA <item> element contains an optional caption, which if present must come first before any other character data. The required listType attribute specifies whether the <list> is ordered or unordered (with unordered being the default). Unordered lists are typically rendered with bullets, whereas ordered lists are typically rendered with numbers, although this is not a requirement.

5.3.5.9 <table>

The CDA <table> is similar to the HTML table. The table markup is for presentation purposes only and, unlike a database table, does not possess meaningful field names. Remember to access the discrete data conveyed in a CDA document, process the RIM models contained within the <entry> element.

CDA modifies the strict XHTML table model by removing formatting tags and by setting the content model of cells to be similar to the contents of other elements in the CDA Narrative Block. A notable enhancement to the CDA R2.1 standard is the support of the <table> element within <td> & <th> elements. The support of tables within tables was not supported in CDA R2.0, but has been added for those implementation requiring complex table layouts. For definitions of the @align and @valign attributes see the W3C HTML 4.01 Specification section 11.3.2 <http://www.w3.org/TR/html401/struct/tables.html#h-11.3.2>.

The table.border, table.cellspacing, and table.cellpadding attributes are deprecated, because the styleCode attribute (see styleCode attribute) provides a more consistent way for senders to suggest rendering characteristics.

5.3.5.10 <caption>

The CDA <caption> is a label for a paragraph, list, list item, table, or table cell. It can also be used within the <renderMultiMedia> element to indicate a label for referenced ObservationMedia and RegionOfInterest entries. A <caption> contains plain text and may contain links and footnotes.

5.3.5.11 styleCode attribute

The styleCode attribute is used within the CDA Narrative Block to give the instance author the ability to suggest rendering characteristics of the nested character data. Receivers are not required to render documents using the style hints provided and can present stylized text in accordance with their local style conventions.

The value set is drawn from the HL7 styleType vocabulary domain, and has a CWE coding strength.

Table X: Value set for styleCode (CWE)

Code	Definition
Font style (Defines font rendering characteristics.)
Bold	Render with a bold font.
Underline	Render with an underlines font.
Italics	Render italicized.
Emphasis	Render with some type of emphasis.
Table rule style (Defines table cell rendering characteristics.
Lrule	Render cell with left-sided rule.
Rrule	Render cell with right-sided rule.
Toprule	Render cell with rule on top.
Botrule	Render cell with rule on bottom.
Ordered list style (Defines rendering characteristics for ordered lists.)
Arabic	List is ordered using Arabic numerals: 1, 2, 3.
LittleRoman	List is ordered using little Roman numerals: i, ii, iii.
BigRoman	List is ordered using big Roman numerals: I, II, III.
LittleAlpha	List is ordered using little alpha characters: a, b, c.
BigAlpha	List is ordered using big alpha characters: A, B, C.
Unordered list style (Defines rendering characteristics for unordered lists.)
Disc	List bullets are simple solid discs.
Circle	List bullets are hollow discs.
Square	List bullets are solid squares.

Local extensions to the styleType vocabulary domain must follow the following convention: [x][A-Za-z][A-Za-z0-9]* (first character is "x", second character is an upper or lower case A-Z, remaining characters are any combination of upper and lower case letters or numbers).

The styleCode attribute can contain multiple values, separated by white space. Where an element containing a styleCode attribute is nested within another element containing a styleCode attribute, the style effects are additive, as in the following example:

Example X

<section>
   <text><content styleCode="Bold">This is rendered bold, 
    <content styleCode="Italics">this is rendered bold and 
    italicized,</content> this is rendered bold. </content>
    <content styleCode="Bold Italics">This is also rendered 
    bold and italicized.</content>
   </text>
</section>

5.3.5.12 Referencing in and out of the narrative block

NOTE: See entry for a discussion of the relationships between a section and its contained entries.

To summarize the mechanisms for referencing in and out of the CDA Narrative Block:

CDA entries can point in to the <content> element of the CDA Narrative Block (see <content>).

The <linkHtml> element of the CDA Narrative Block can reference targets that are either internal or external to the document (see <linkHtml>).

The <footnoteRef> element of the CDA Narrative Block can reference a <footnote> element in the same or different CDA Narrative Block of the same document (see <footnote> and <footnoteRef>).

The <renderMultiMedia> element of the CDA Narrative Block can point out to CDA ObservationMedia and RegionOfInterest entries of the same document (see <renderMultiMedia>).

5.3.6 Entry Acts

CDA entries represent the structured computer-processable components within a document section. Each section can contain zero to many entries.

Clinical documents contain a wide breadth of content, requiring much of the RIM to enable a full and complete encoding. The current set of CDA entries have been developed in response to identified requirements and scenarios that are in CDA's scope. Rather than creating specific entries for each scenario, similar requirements are merged to create broader entries, which can then be constrained within a particular realm or implementation. This approach is consistent with the approach taken by CEN, DICOM, and OpenEHR.

The model for CDA entries is derived from the shared HL7 Clinical Statement model, which is a collaborative project between several committees striving to provide a consistent representation of clinical observations and acts across various V3 specifications.

5.3.6.1 Act

A derivative of the RIM Act class, to be used when the other classes present in the CDA Clinical Statement choice pattern are not appropriate.

Table X: Act Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	V:x_ActClassDocumentEntryAct	Closed
moodCode	CS	[1..1]	V:x_DocumentActMood	Closed
id	SET <II>	[0..*]
code	CD	[1..1]	D:ActCode	Open
actionNegationInd	BL	[0..1]
negationInd (Deprecated)	BL	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
uncertaintyCode	CE	[0..1]	D:ActUncertainty	Open
reasonCode	SET<CE>	[0..*]	D:ActReason	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed

Act.classCode

The major class of Acts to which an Act-instance belongs.

Table X: Value set for Act.classCode

x_ActClassDocumentEntryAct [2.16.840.1.113883.1.11.19599] (CLOSED)
Code	Display Name		Code	Display Name
ACT	Act		ACCM	accommodation
CONS	consent		CTTEVENT	clinical trial timepoint event
INC	incident		INFRM	inform
PCPR	care provision		REG	registration
SPCTRT	specimen treatment		TRNS	transportation
ACSN	accession		CONTREG	container registration
DISPACT	disciplinary action		EXPOS	exposure
AEXPOS	acquisition exposure		TEXPOS	transmission exposure
LIST	working list		MPROT	monitoring program
REV	review		STORE	storage
TRFR	transfer
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Act.moodCode

The intended use of the Act statement: as a report of fact, a command, a possibility, a goal, etc. Since the mood code is a determining factor for the meaning of an entire Act object, the mood must always be known. This means that whenever an act object is instantiated, the mood attribute SHALL be assigned to a valid code, and the mood assignment SHALL NOT change throughout the lifetime of the act object.

Table X: Value set for Act.moodCode

V:x_DocumentActMood [2.16.840.1.113883.1.11.19458] (CLOSED)
Code	Display Name		Code	Display Name
APT	appointment		ARQ	appointment request
EVN	event		DEF	definition
RQO	request		INT	intent
PRMS	promise		PRP	proposal
RSK	risk
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Act.id

A unique identifier for the Act.

Act.code

The particular kind of Act that the Act-instance represents within its class. Act.code, if used, SHALL be a specialization of the Act.classCode. This attribute defines a specific sub-type of a given Act type (determined by the "classCode" attribute). It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the limited set of Act types defined by "classCode." The Act.code is bound to the ActCode concept domain.

Act.actionNegationInd

The Act.actionNegationInd works as a negative existence quantifier on the actual, intended or described Act event. In Event mood, it indicates the defined act did not occur. In Intent mood, it indicates the defined act is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the Act as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, reasonCode and any of their components.

The remaining properties represent the document characteristics, E.g. Act.id, Act.moodCode, Act.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Act.negationInd

Act.negationInd, is deprecated in RIM 2.35, and CDA R2.1 retains it for backwards compatibility. CDA R2.1 compliant implementation guides should use actionNegationInd moving forward.

Act.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. The Act.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Act.statusCode

The status reflects the state of the activity. The RIM based state machine diagram depicts the allowable state transitions that an Act.StatusCodes can take on.

Table X: Value set for Act.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

Act.effectiveTime

Act.effectiveTime is used to indicate the clinically or operationally relevant time of an act, exclusive of administrative activity.

Act.activityTime

Act.activityTime is a time expression specifying when an act occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the act occurred, is supposed to occur, is scheduled to occur, etc.

Act.availabilityTime

Act.availabilityTime is the point in time at which information about an act instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the act itself.

Act.priorityCode

The urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Act.priorityCode is bound to the ActPriority concept domain.

Act.confidentialityCode

Constraints around appropriate disclosure of information about this Act, regardless of mood. The Act.confidentialityCode is bound to the Confidentiality concept domain.

Act.uncertaintyCode

An indication that the Act statement as a whole, with its subordinate components has been asserted to be uncertain in some way. The use of the uncertaintyCode is appropriate only if the entirety of the Act and its dependent Acts is questioned. The Act.uncertaintyCode is bound to the ActUncertainty concept domain.

Act.reasonCode

The motivation, cause, or rationale of an Act, when such rationale is not reasonably represented as an ActRelationship of type "has reason" linking to another Act. The Act.reasonCode is bound to the ActReason concept domain.

Most reasons for acts can be clearly expressed by linking the new Act to another prior Act record using an ActRelationship of type "has reason." This simply states that the prior Act is a reason for the new Act (see ActRelationship). The prior act can then be a specific existing act or a textual explanation. This works for most cases, and the more specific the reason data is, the more should this reason ActRelationship be used instead of the reasonCode.

The reasonCode remains as a place for common reasons that are not related to a prior Act or any other condition expressed in Acts. Indicators that something was required by law or was on the request of a patient may qualify. However, if that piece of legislation, regulation, or the contract or the patient request can be represented as an Act (and they usually can), such a representation is preferable to the reasonCode.

Act.languageCode

The primary language in which this Act statement is specified, particularly the language of the Act.text. The Act.languageCode is bound to the HumanLanguage concept domain.

5.3.6.2 Encounter

Encounter

A derivative of the RIM PatientEncounter class, used to represent related encounters, such as follow-up visits or referenced past encounters.

NOTE: The EncompassingEncounter class in the CDA Header (see Header Relationships) represents the setting of the clinical encounter during which the documented act occurred. The Encounter class in the CDA Body is used to represent other related encounters.

Table X: Encounter Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	ENC	Fixed
moodCode	CS	[1..1]	V:x_DocumentEncounterMood	Closed
id	SET <II>	[0..*]
code	CD	[0..1]	D:ActCode	Open
actionNegationInd	BL	[0..1]
negationInd (Deprecated)	BL	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
uncertaintyCode	CE	[0..1]	D:ActUncertainty	Open
reasonCode	SET<CE>	[0..*]	D:ActReason	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed
admissionReferralSourceCode	<CE>	[0..1]	D:EncounterReferralSource	Open
lengthOfStayQuantity	<PQ>.TIME	[0..1]
dischargeDispositionCode	<CE>	[0..1]	D:EncounterDischargeDisposition	Open
preAdmitTestInd	BL	[0..1]
specialCourtesiesCode	SET<CE>	[0..*]	D:EncounterSpecialCourtesy	Open
specialArrangementCode	SET<CE>	[0..*]	D:SpecialArrangement	Open

Encounter.classCode

The Encounter.classCode is fixed to "ENC" to represent an encounter. The encounter class is used to represent an interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient.

Table X: Fixed Encounter.classCode

Code	Display Name
ENC (Fixed)	encounter
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Encounter.moodCode

The Encounter.moodCode is bound to the x_DocumentEncounterMood value set. This enables to the modeling of both past, present and planned future encounters.

Table X: Value set for Encounter.moodCode

V:x_DocumentEncounterMood [2.16.840.1.113883.1.11.19459] (CLOSED)
Code	Display Name		Code	Display Name
APT	appointment		ARQ	appointment request
EVN	event		DEF	definition
RQO	request		INT	intent
PRMS	promise		PRP	proposal
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Encounter.id

The optional Encounter.id can be used to uniquely identify the encounter.

Encounter.code

The optional Encounter.code is bound to the ActEncounterCode value set.

Table X: Value set for EncompassingEncounter.code

V:ActEncounterCode [2.16.840.1.113883.1.11.13955] (OPEN)
Code	Display Name		Code	Display Name
AMB	ambulatory		EMER	emergency
FLD	field		HH	home health
IMP	inpatient encounter		ACUTE	inpatient acute
NONAC	virtual		SS	short stay
VR	inpatient non-acute
Code System: ActCode (HL7) Code System OID: 2.16.840.1.113883.5.4

Encounter.actionNegationInd

The Encounter.actionNegationInd works as a negative existence quantifier on the actual, intended or described Encounter event. In Event mood, it indicates the defined encounter did not occur. In Intent mood, it indicates the defined encounter is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the Encounter as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, reasonCode, admissionReferralSourceCode, lengthOfStayQuantity, dischargeDispositionCode, preAdmitTestInd, specialCourtesiesCode, specialArrangementCode and any of their components.

The remaining properties represent the document characteristics, E.g. Encounter.id, Encounter.moodCode, Encounter.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative encounter. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Encounter.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Encounter. The Encounter.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Encounter.statusCode

The status reflects the state of the Encounter. The RIM based state machine diagram depicts the allowable state transitions that an Encounter.statusCode can take on.

Encounter.effectiveTime

For Encounters, the effectiveTime is the "administrative" time, i.e., the encounter start and end date as established by business rules. For inpatient encounters, the effectiveTime/low value is the admission date and time and the effectiveTime/high value is the discharge date and time. Note: If the encounter is still active at the time of document creation, the effectiveTime/high element can be omitted to indicate the encounter is on-going.

Encounter.activityTime

Encounter.activityTime is a time expression specifying when an Encounter occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the Encounter occurred, is supposed to occur, is scheduled to occur, etc.

Encounter.availabilityTime

Encounter.availabilityTime is the point in time at which information about an Encounter instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the Encounter itself.

Encounter.priorityCode

The urgency under which the Encounter happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Encounter.priorityCode is bound to the ActPriority concept domain.

Encounter.confidentialityCode

Constraints around appropriate disclosure of information about this Encounter, regardless of mood. The Encounter.confidentialityCode is bound to the Confidentiality concept domain.

Encounter.reasonCode

The motivation, cause, or rationale of an Encounter, when such rationale is not reasonably represented as an ActRelationship of type "has reason" linking to another Act. The Encounter.reasonCode is bound to the ActReason concept domain.

Encounter.languageCode

The primary language in which this Encounter statement is specified, particularly the language of the Encounter.text. The Encounter.languageCode is bound to the HumanLanguage concept domain.

Encounter.admissionReferralSourceCode

The optional EncompassingEncounter.admissionReferralSourceCode can be use to depict the type of place or organization responsible for the patient's care immediately prior to a patient encounter.

Encounter.lengthOfStayQuantity

The total quantity of time when the subject is expected to be or was resident at a facility as part of an encounter. Note, the actual days quantity cannot be simply calculated from the admission and discharge dates because of possible leaves of absence.

Encounter.dischargeDispositionCode

The optional EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).

Encounter.preAdmitTestInd

An indication that pre-admission tests are required for this patient encounter.

Encounter.specialCourtesiesCode

Extraordinary considerations or services provided within the context of the Patient Encounter. Examples include: Professional courtesy, VIP courtesies, no courtesies

Encounter.specialArrangementCode

Extraordinary provisions required in the context of the patient encounter. For encounters in intention moods, this information can be used to identify special arrangements that will need to be made for the incoming patient.

5.3.6.3 Observation

Observation

A derivative of the Observation(§ RIM 2.35) class, it is intended to result in new information about a subject. The main difference between Observations and other Acts is that Observations have a value attribute. The code attribute of Observation and the value attribute of Observation must be considered in combination to determine the semantics of the observation.

Table X: Observation Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	<= OBS" is V:ActClassObservation	Closed
moodCode	CS	[1..1]	V:x_ActMoodDocumentObservation	Closed
id	SET <II>	[0..*]
code	CD	[1..1]	D:ObservationType	Open
actionNegationInd	BL	[0..1]
negationInd (Deprecated)	BL	[0..1]
derivationExpr	ST	[0..1]
title	ED	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
repeatNumber	IVL<INT>	[0..1]
uncertaintyCode	CE	[0..1]	D:ActUncertainty	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed
isCriterionInd	BL	[0..1]
value	SET<ANY>	[0..*]	D:ObservationValue	Open
valueNegationInd	BL	[0..1]
interpretationCode	SET<CE>	[0..*]	D:ObservationInterpretation	Open
methodCode	SET<CE>	[0..*]	D:ObservationMethod	Open
targetSiteCode	SET<CD>	[0..*]	D:ActSite	Open

Observation.classCode

The defines a specific sub-type of a given Observation type.

Table X: Value set for Observation.classCode

V:ActClassObservation [2.16.840.1.113883.1.11.11529] (CLOSED)
Code	Display Name		Code	Display Name
OBS	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
CNOD (Deprecated)	Condition Node
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Observation.moodCode

The intended use of the Observation statement: as a report of fact, a command, a possibility, a goal, etc. Since the mood code is a determining factor for the meaning of an entire Observation object, the mood must always be known. This means that whenever an Observation is instantiated, the mood attribute SHALL be assigned to a valid code, and the mood assignment SHALL NOT change throughout the lifetime of the Observation.

Table X: Value set for Observation.moodCode

V:x_ActMoodDocumentObservation [2.16.840.1.113883.1.11.19644] (CLOSED)
Code	Display Name		Code	Display Name
APT	appointment		ARQ	appointment request
EVN	event		DEF	definition
GOL	goal		INT	intent
PRMS	promise		PRP	proposal
RSK	risk		RQO	request
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Observation.id

A unique identifier for the Observation.

Observation.code

The particular kind of Observation that the Observation-instance represents within its class. Observation.code, if used, SHALL be a specialization of the Observation.classCode. This attribute defines a specific sub-type of a given Observation type (determined by the "classCode" attribute). The Observation.code is bound to the ActCode concept domain.

Observation.actionNegationInd

The Observation.actionNegationInd works as a negative existence quantifier on the actual, intended or described observation event. In Event mood, it indicates the defined observation did not occur. In Intent mood, it indicates the defined observation is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the Observation as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, derivationExpr, repeatNumber, isCriterionInd, value, valueNegationInd, interpretationCode, methodCode, targetSiteCode, and any of their components.

The remaining properties represent the document characteristics, E.g. Observatoin.id, Observation.moodCode, Observation.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Observation.negationInd

Observation.negationInd, is deprecated in RIM 2.35, and CDA R2.1 retains it for backwards compatibility. It was deprecated as the type of negation required knowledge of template documentation to determine the actual type of negation I.e. value or action negation. CDA R2.1 compliant implementation guides should use actionNegationInd or valueNegationInd moving forward.

Observation.derivationExpr

A character string containing a formal language expression that specifies how the Observation's attributes are, should be, or have been derived from input parameters associated with derivation relationships. Derived observations can be defined through association with other observations using ActRelationships of type "derivation." For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with a Hemoglobin (HGB) observation and a Red Blood cell Count (RBC) observation: the derivation expression value encodes the formula: MCH = HGB / RBC.

Observation.title

A word or phrase by which a specific Observation may be known among people. This is not a formal identifier but rather a human-recognizable common name. However it is similar to the id attribute in that it refers to a specific Observation rather than a 'kind' of Observation. (For definition mood, the title refers to that specific definition, rather than to a broad category that might be conveyed with Observation.code.)

Observation.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Observation. The Observation.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Observation.statusCode

The status reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing (e.g., "new," "complete," "cancelled"), not the status of what is being observed (e.g., disease status, "Active" allergy to penicillin). To convey the status of the subject being observed, consider coordinating it into the code or value attribute of the Observation or using a related Observation. The RIM based state machine diagram depicts the allowable state transitions that an Observation.StatusCode can take on.

Table X: Value set for Observation.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

Observation.effectiveTime

Observation.effectiveTime is used to indicate the clinically or operationally relevant time of an observation, exclusive of administrative activity. For example, in a Blood Gas Analysis (BGA), a result might not be available for several minutes after the specimen was taken. The effectiveTime is the time the specimen was taken, the availabilityTime would be the time the result was available for review. For clinical Observations, the effectiveTime represents the time at which the observation holds (is effective) for the patient. In V2 the effectiveTime was known as the biologically relevant time.

Observation.activityTime

Observation.activityTime is a time expression specifying when an Observation occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the observation occurred, is supposed to occur, is scheduled to occur, etc. When an observation of a prior symptom is made, the activityTime describes the time the observation is made, as opposed to effectiveTime which is the time the symptom is reported to have occurred. Thus the activityTime may be entirely different from the effectiveTime for the same observation instance.

Observation.availabilityTime

Observation.availabilityTime is the point in time at which information about an observation instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the Observation itself. For CDA documents, the availabilityTime reported for its contents, would represent the time the observation first became available to a source system generating the CDA document.

Observation.priorityCode

The urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Act.priorityCode is bound to the ActPriority concept domain.

Observation.confidentialityCode

Constraints around appropriate disclosure of information about this Observation, regardless of mood. The Observation.confidentialityCode is bound to the Confidentiality concept domain.

Observation.repeatNumber

An interval of integer numbers stating the minimal and maximal number of repetitions of the Observation.

Observation.uncertaintyCode

An indication that the Observation statement as a whole, with its subordinate components has been asserted to be uncertain in some way. The use of the uncertaintyCode is appropriate only if the entirety of the Observation and its dependent Acts is questioned. The Observation.uncertaintyCode is bound to the ActUncertainty concept domain. Note: Implementation Guides will need to provide explicit guidance on the proper evaluation and interpretation, as well as provide a default value assignment.

Observation.languageCode

The primary language in which this Observation statement is specified, particularly the language of the Observation.text. The Observation.languageCode is bound to the HumanLanguage concept domain.

Observation.isCriterionInd

Is defaulted to false, when set to true it indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

Observation.value

The result of the observation action. Extensive usage notes are available in the RIM, reference Value UsageNotes

Observation.valueNegationInd

Observation.valueNegationInd, indicates that when the observation event occurred, the finding communicated by the value attribute was NOT found. So, when we want to indicate the patient does not have asthma, we can negate a finding of asthma, using this indicator. Note: The RIM indicates that this attribute should only be used when the terminology used for Observation.value is not itself capable of expressing negated findings. (E.g. ICD9). Implementation experience may override the RIM definition and it's important to review template definitions and Value Set content and binding for consistent negation implementation. Existing CDA R2.0 implementations use negationInd in many C-CDA templates.

Observation.interpretationCode

A qualitative interpretation of the observation. These interpretation codes are sometimes called "abnormal flags," however, the judgment of normalcy is just one of the interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy," and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions are never considered "normal."

Observation.methodCode

The means or technique used to ascertain the observation. In all observations the method is already partially specified by the Observation.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY still be used to identify this method more clearly in addition to what is implied from the Observation.code. However, an information consumer system or process SHOULD NOT depend on this methodCode information for method detail that is implied by the Observation.code.

Observation.targetSiteCode

The anatomical site or system that is the focus of the observation. Most observation target sites are implied by the observation definition and Observation.code, or Observation.value. For example, "heart murmur" always has the heart as target. This attribute is used only when the observation target site needs to be refined, to distinguish right from left, etc. If the subject of the Observation is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the Observation focuses. For example, if the subject is a lake, the site could be inflow and outflow, etc. If the subject is a lymphatic node, "hilus," "periphery," or other node sites would be valid target sites.

The following is an example of how an author can record a patient that has no known allergies. It uses the new valueNegationInd with an "Allergy to substance" code in the value element.

Example X

<section>
    <templateId .../>
    <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
    <title>ALLERGIES AND ADVERSE REACTIONS</title>
    <text>No Known Allergies</text>
    <entry typeCode="DRIV">
        <!-- Allergy Concern Act -->
        <act classCode="ACT" moodCode="EVN">
            <templateId ... />
            <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/>
            <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>
            <statusCode code="active"/>
            <effectiveTime>
                <low value="20100103"/>
            </effectiveTime>
            <author> ... </author>
            <entryRelationship typeCode="SUBJ">
                <!-- No Known Allergies -->
                <!-- The <valueNegationInd value="true" /> negates the observation/value -->
                <observation classCode="OBS" moodCode="EVN">
                    <!-- allergy - intolerance observation template -->
                    <templateId ... />
                    <templateId ... />
                    <id ... />
                    <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
                    <statusCode code="completed"/>
                    <effectiveTime>
                        <low nullFlavor="NA"/>
                    </effectiveTime>
                    <value xsi:type="CD" code="419199007"
                        displayName="Allergy to substance (disorder)"
                        codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
                    <valueNegationInd value="true"/>
                    <author> ... </author>
                    <participant typeCode="CSM">
                        <participantRole classCode="MANU">
                            <playingEntity classCode="MMAT">
                                <code nullFlavor="NA"/>
                            </playingEntity>
                        </participantRole>
                    </participant>
                </observation>
            </entryRelationship>
        </act>
    </entry>
</section>
 

5.3.6.3.1 Reference Range

An Observation can have zero to many referenceRange relationships, which relate an Observation to the ObservationRange class.

referenceRange.typeCode

The referenceRange.typeCode has been fixed to "REFV", which indicates an association to a reference range.

Table X: Fixed referenceRange.typeCode

Code	Display Name
REFV	has reference values
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.3.6.3.2 ObservationRange

ObservationRange or reference ranges are essentially descriptors of a class of result values assumed to be "normal", "abnormal", or "critical." Those can vary by sex, age, or any other criterion.

Table X: ObservationRange Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	<= OBS is V:ActClassObservation	Closed w/ Default
moodCode	CS	[0..1]	ENV.CRT	Fixed
code	CD	[1..1]	D:ActCode	Open
text	ED	[0..1]
isCriterionInd	BL	[0..1]
value	SET<ANY>	[0..*]	D:ObservationValue	Open
valueNegationInd	BL	[0..1]
interpretationCode	SET<CE>	[0..*]	D:ObservationInterpretation	Open

ObservationRange.classCode

Table X: Value set for ObservationRange.classCode

V:ActClassObservation [2.16.840.1.113883.1.11.11529] (CLOSED)
Code	Display Name		Code	Display Name
OBS (Default)	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
CNOD (Deprecated)	Condition Node
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ObservationRange.moodCode

The ObservationRange.moodCode is fixed to the "EVN.CRT" (event criterion). The "EVN.CRT" is a criterion or condition over service events that must apply for an associated service to be considered.

Table X: Fixed ObservationRange.moodCode

Code	Display Name
EVN.CRT	event criterion
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ObservationRange.code

The particular kind of Observation that the ObservationRange-instance represents within its class. ObservationRange.code, if used, SHALL be a specialization of the ObservationRange.classCode. This attribute defines a specific sub-type of a given Observation type (determined by the "classCode" attribute). The ObservationRange.code is bound to the ActCode concept domain.

ObservationRange.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the ObservationRange. The ObservationRange.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

ObservationRange.isCriterionInd

Is set to true to indicate that the data conveyed by the ObservationRange, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

ObservationRange.value

The result of the ObservationRange action. Extensive usage notes are available in the RIM, reference Value UsageNotes

ObservationRange.valueNegationInd

ObservationRange.valueNegationInd, indicates that when the ObservationRange event occurred, the finding communicated by the value attribute was NOT found. Note: This attribute should only be used when the terminology used for ObservationRange.value is not itself capable of expressing negated findings. (E.g. ICD9).

ObservationRange.interprerationCode

A qualitative interpretation of the ObservationRange. These interpretation codes are sometimes called "abnormal flags," however, the judgment of normalcy is just one of the interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy," and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions are never considered "normal."

5.3.6.4 ObservationMedia

Observation Media

A derivative of the RIM Observation class that represents multimedia that is logically part of the current document. This class is only for multimedia that is logically part of the attested content of the document. Rendering a referenced ObservationMedia requires a software tool that recognizes the particular MIME media type. The distinction between ObservationMedia and ExternalObservation is that ObservationMedia entries are part of the attested content of the document whereas ExternalObservations are not. For instance, when a clinician draws a picture as part of a progress note, that picture is represented as a CDA ObservationMedia. If that clinician is also describing a finding seen on a chest-x-ray, the referenced chest-x-ray is represented as a CDA ExternalObservation.

Table X: ObservationMedia Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	<= OBS is V:ActClassObservation	Closed
moodCode	CS	[1..1]	EVN	Fixed
id	SET <II>	[0..*]
languageCode	CS	[0..1]	D:HumanLanguage	Closed
value	ED	[1..1]

NOTE: XML ID Attribute added

An XML attribute "ID" of type XML ID, is added to ObservationMedia within the CDA Schema. This attribute serves as the target of a <renderMultiMedia> reference (see <renderMultiMedia>). All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).

ObservationMedia.classCode

The ObservationMedia.classCode is defaulted to "OBS" for Observation, but can be set to any sub-type of Observation that may more accurately characterize the multi-media referenced via the ObservationMedia class.

Table X: Value set for ObservationMedia.classCode

V:ActClassObservation [2.16.840.1.113883.1.11.11529] (CLOSED)
Code	Display Name		Code	Display Name
OBS (Default)	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
CNOD (Deprecated)	Condition Node
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ObservationMedia.moodCode

The ObservationMedia.moodCode is fixed to "EVN" or event mood to indicate that this is ObservationMedia is from a past service.

Table X: Fixed ObservationMedia.moodCode

Code	Display Name
EVN	event (occurrence)
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ObservationMedia.id

An optional identifier for the ObservationMedia instance.

ObservationMedia.languageCode

Specifies the human language of character data (whether they be in contents or attribute values).

ObservationMedia.value

The ObservationMedia.value is set to the xsi:type="ED" which enables the referencing of the multi-media object. Review the ED data type for more information about linking to files.

5.3.6.5 Organizer

Organizer

A derivative of the RIM Act class, which can be used to create arbitrary groupings of other CDA entries that share a common context. An Organizer can contain other Organizers and/or other CDA entries, by traversing the component relationship. An Organizer can refer to external acts by traversing the reference relationship. An Organizer cannot be the source of an entryRelationship relationship.

NOTE: CDA entries such as Observation can also contain other CDA entries by traversing the entryRelationship class. There is no requirement that the Organizer entry be used in order to group CDA entries.

Table X: Organizer Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	V:x_ActClassDocumentEntryOrganizer	Closed
moodCode	CS	[1..1]	EVN	Fixed
id	SET <II>	[0..*]
code	CD	[0..1]	D:ActCode	Open
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open

Organizer.classCode

The Organizer.classCode can take on one of two values, BATTERY or CLUSTER.

1. CLUSTER is an ACT that organizes a set of component acts into a semantic grouping that have a shared subject. The subject may be either a subject participation (SBJ), subject act relationship (SUBJ), or child participation/act relationship types.
2. The BATTERY is an observation that is composed of a set of observations. These observations typically have a logical or practical grouping for generally accepted clinical or functional purposes, such as observations that are run together because of automation. A battery can define required and optional component observations and, in some cases, will define complex rules that determine whether or not a particular observation is made. BATTERY is a constraint on the Observation class in that it is understood to always be composed of component observations.

Table X: Value set for Organizer.classCode

V:x_ActClassDocumentEntryOrganizer [2.16.840.1.113883.1.11.19598] (CLOSED)
Code	Display Name		Code	Display Name
BATTERY	battery		CLUSTER	Cluster
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Organizer.moodCode

The Organizer.moodCode is fixed to the "EVN" or event mood to indicate that the Organizer has been created with the contents specified.

Table X: Fixed Organizer.moodCode

Code	Display Name
EVN	event (occurrence)
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Organizer.id

An optional identifier for the Organizer instance.

Organizer.code

The particular kind of Organizer that the Organizer-instance represents within its class. Organizer.code, if used, SHALL be a specialization of the Organizer.classCode. This attribute defines a specific sub-type of a given Organizer type (BATTERY or CLUSTER). The Organizer.code is bound to the ActCode concept domain.

Organizer.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Organizer. The Organizer.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Organizer.statusCode

The status reflects the state of the activity. The RIM based state machine diagram depicts the allowable state transitions that an Organizer.StatusCode can take on.

Table X: Value set for Organizer.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

Organizer.effectiveTime

The optional Organizer.effectiveTime is used to indicate the clinically or operationally relevant time of an Organizer's component items, exclusive of administrative activity. For example, in a Blood Gas Analysis (BGA), a result might not be available for several minutes after the specimen was taken. The effectiveTime is the time the specimen was taken, the availabilityTime would be the time the result was available for review.

Organizer.activityTime

The optional Organizer.activityTime is a time expression specifying when the activityTime of the Organizer's component items occurred, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the component Acts occurred, is supposed to occur, is scheduled to occur, etc.

Organizer.availabilityTime

The optional Observation.availabilityTime is the point in time at which information about the component Acts regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the Organizer's component activities themselves.

Organizer.priorityCode

The optional priorityCode identifies the urgency under which the component Act's happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Organizer.priorityCode is bound to the ActPriority concept domain.

Organizer.confidentialityCode

The optional confidentialityCode identifies any constraints around appropriate disclosure of information about this Organizer and it's component Acts, regardless of mood. The Organizer.confidentialityCode is bound to the Confidentiality concept domain.

5.3.6.6 Procedure

Procedure

A derivative of the RIM Procedure class, is represents an act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject.

Table X: Procedure Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	<= PROC is V:ActClassProcedure	Closed
moodCode	CS	[1..1]	V:x_DocumentProcedureMood	Closed
id	SET <II>	[0..*]
code	CD	[0..1]	D:ActProcedureCode	Open
actonNegationInd	BL	[0..1]
negationInd (Deprecated)	BL	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	IVL<TS>	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
uncertaintyCode	CE	[0..1]	D:ActUncertainty	Open
languageCode	CS	[0..1]	D:HumanLanguage	Closed
isCriterionInd	BL	[0..1]
methodCode	CE	[0..*]	D:ProcedureMethod	Open
approachSiteCode	CE	[0..*]	D:ActSite	Open
targetSiteCode	CE	[0..*]	D:ActSite	Open

Procedure.classCode

The defines a specific sub-type of a given Procedure type. The Procedure.classCode is bound to the V:ActClassProcedure value set.

Table X: Value set for Procedure.classCode

V:ActClassProcedure [2.16.840.1.113883.1.11.19665] (CLOSED)
Code	Display Name		Code	Display Name
PROC (Default)	procedure		SBEXT	Substance Extraction
SPECCOLLECT	Specimen Collection
Note: Although SBADM is technically allowed, is best used with the SubstanceAdministration Entry Class
SBADM	substance administration
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Procedure.moodCode

The intended use of the Procedure statement: as a procedure report, a command, a possibility, a goal, etc. Since the mood code is a determining factor for the meaning of an entire Procedure object, the mood must always be known. This means that whenever an Procedure is instantiated, the mood attribute SHALL be assigned to a valid code, and the mood assignment SHALL NOT change throughout the lifetime of the Procedure.

Table X: Value set for Procedure.moodCode

V:x_DocumentProcedureMood [2.16.840.1.113883.1.11.19460] (CLOSED)
Code	Display Name		Code	Display Name
APT	appointment		ARQ	appointment request
EVN	event		DEF	definition
RQO	request		INT	intent
PRMS	promise		PRP	proposal
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Procedure.id

A unique identifier for the Procedure.

Procedure.code

The particular kind of Procedure that the Procedure-instance represents within its class. Procedure.code, if used, SHALL be a specialization of the Procedure.classCode. This attribute defines a specific sub-type of a given Procedure type (determined by the "classCode" attribute). The Procedure.code is bound to the ActProcedureCode concept domain.

Procedure.actionNegationInd

The Procedure.actionNegationInd works as a negative existence quantifier on the actual, intended or described Procedure event. In Event mood, it indicates the defined procedure did not occur. In Intent mood, it indicates the defined procedure is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the Act as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, isCriterionInd, methodCode, approachSiteCode, targetSiteCode and any of their components.

The remaining properties represent the document characteristics, E.g. Procedure.id, Procedure.moodCode, Procedure.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Procedure.negationInd

Procedure.negationInd, is deprecated in RIM 2.35, and CDA R2.1 retains it for backwards compatibility. CDA R2.1 compliant implementation guides should use actionNegationInd moving forward.

Procedure.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Procedure. The Procedure.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Procedure.statusCode

The status reflects the state of the activity. The RIM based state machine diagram depicts the allowable state transitions that an Procedure.statusCode can take on.

Table X: Value set for Procedure.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

Procedure.effectiveTime

Procedure.effectiveTime is used to indicate the clinically or operationally relevant time of a procedure, exclusive of administrative activity. For a surgical procedure (operation), the effectiveTime is the time relevant for the patient, i.e., between incision and last suture. For transportation acts, the effective time is the time the transported payload is en route.

Procedure.activityTime

Procedure.activityTime is a time expression specifying when a procedure occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the procedure occurred, is supposed to occur, is scheduled to occur, etc. For Procedures the activityTime can provide a needed administrative function by providing a more inclusive time to be anticipated in scheduling.

Procedure.availabilityTime

Procedure.availabilityTime is the point in time at which information about a procedure instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the procedure itself.

Procedure.priorityCode

The urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Procedure.priorityCode is bound to the ActPriority concept domain.

Procedure.confidentialityCode

Constraints around appropriate disclosure of information about this Procedure, regardless of mood. The Procedure.confidentialityCode is bound to the Confidentiality concept domain.

Procedure.uncertaintyCode

An indication that the Procedure statement as a whole, with its subordinate components has been asserted to be uncertain in some way. The use of the uncertaintyCode is appropriate only if the entirety of the Procedure and its dependent Acts is questioned. The Procedure.uncertaintyCode is bound to the ActUncertainty concept domain.

Procedure.languageCode

The primary language in which this Procedure statement is specified, particularly the language of the Procedure.text. The Procedure.languageCode is bound to the HumanLanguage concept domain.

Procedure.isCriterionInd

Is defaulted to false, when set to true it indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

Procedure.methodCode

The means or technique used to ascertain the observation. In some procedures the method is already partially specified by the Procedure.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY still be used to identify this method more clearly in addition to what is implied from the Procedure.code. However, an information consumer system or process SHOULD NOT depend on this methodCode information for method detail that is implied by the Procedure.code.

Procedure.approachSiteCode

The anatomical site or system through which the procedure reaches its target.

Procedure.targetSiteCode

The anatomical site or system that is the focus of the procedure. Most procedure target sites are implied by the procedure definition and Procedure.code, or Procedure.value. If the subject of the procedure is something other than a human patient or animal, the attribute is used analogously to specify a structural landmark of the thing where the Procedure occurred.

5.3.6.7 RegionOfInterest

Region of Interest

A derivative of the RIM Observation class that represents a region of interest on an image, using an overlay shape. RegionOfInterest is used to make reference to specific regions in images, e.g., to specify the site of a physical finding by "circling" a region in a schematic picture of a human body. The relationship between a RegionOfInterest and its referenced ObservationMedia or ExternalObservation is specified by traversing the entryRelationship or reference class, respectively, where typeCode equals "SUBJ". A RegionOfInterest must reference exactly one ObservationMedia or one ExternalObservation. If the RegionOfInterest is the target of a <renderMultimedia> reference, then it shall only reference an ObservationMedia and not an ExternalObservation.

Table X: RegionOfInterest Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	ROIOVL	Fixed
moodCode	CS	[1..1]	EVN	Fixed
id	SET <II>	[0..*]
code	CE	[0..1]	V:ROIOverlayShape	Closed
value	LIST<INT>	[1..*]

NOTE: XML ID Attribute added

An XML attribute "ID" of type XML ID, is added to RegionOfInterest within the CDA Schema. This attribute serves as the target of a <renderMultiMedia> reference (see <renderMultiMedia>). All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).

RegionOfInterest.classCode

The RegionOfInterest.classCode is fixed to "ROIOVL" which is a Region of Interest (ROI) specified for an image using an overlay shape. Typically used to make reference to specific regions in images, e.g., to specify the location of a radiologic finding in an image or to specify the site of a physical finding by "circling" a region in a schematic picture of a human body. The units of the coordinate values are in pixels. The origin is in the upper left hand corner, with positive X values going to the right and positive Y values going down. The relationship between a ROI and its referenced Act is specified through an ActRelationship of type "subject" (SUBJ), which must always be present.

Table X: Fixed RegionOfInterest.classCode

Code	Display Name
ROIOVL	overlay ROI
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

RegionOfInterest.moodCode

The RegionOfInterest.moodCode is fixed to "EVN" or event mood to indicate that this is region of interest, was created.

Table X: Fixed RegionOfInterest.moodCode

Code	Display Name
EVN (Fixed)	event (occurrence)
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

RegionOfInterest.id

The optional RegionOfInterest.id allows for the unique identification of the region of interest.

RegionOfInterest.code

There are 4 types of regions that can be created, they are determined by the RegionOfInterest.code which can take on 1 of the following codes: circle, ellipse, point and polyline.

Table X: Value set for RegionOfInterest.code

V:ROIOverlayShape [2.16.840.1.113883.1.11.16117] (CLOSED)
Code	Display Name		Code	Display Name
CIRCLE	circle		ELLIPSE	ellipse
POINT	point		POLY	polyline
Code System: ActCode (HL7) Code System OID: 2.16.840.1.113883.5.4

RegionOfInterest.value

The RegionOfInterest.value units are pixels, expressed as a list of integers. The origin is in the upper left hand corner, with positive X values going to the right and positive Y values going down.

EXAMPLE

The following example illustrates one sample use of RegionOfInterest. In this case, the clinician has identified a rash upon physical examination of the skin, and indicates this by creating a region of interest atop a hand image taken from an image library. The narrative block references the RegionOfInterest via the <renderMultiMedia> tag, and the referenced RegionOfInterest references the hand image.

Example X

<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Skin Exam</title>
   <text>Erythematous rash, palmar surface, left index 
    finger.<renderMultiMedia referencedObject="MM2"/>
   </text>
   <entry>
      <observation classCode="OBS" moodCode="EVN">
         <code code="271807003" 
          codeSystem="2.16.840.1.113883.6.96" 
          codeSystemName="SNOMED CT" 
          displayName="Rash"/>
         <statusCode code="completed"/>
         <targetSiteCode code="48856004" 
          codeSystem="2.16.840.1.113883.6.96" 
          codeSystemName="SNOMED CT" 
          displayName="Skin of palmer surface of index finger">
            <qualifier>
               <name code="78615007" 
                codeSystem="2.16.840.1.113883.6.96" 
                displayName="with laterality"/>
               <value code="7771000" 
                codeSystem="2.16.840.1.113883.6.96" 
                displayName="left"/>
            </qualifier>
         </targetSiteCode>
         <entryRelationship typeCode="SPRT">
            <regionOfInterest classCode="ROIOVL" moodCode="EVN" ID="MM2">
               <id root="2.16.840.1.113883.19.3.1"/>
               <code code="ELLIPSE"/>
               <value value="3"/>
               <value value="1"/>
               <value value="3"/>
               <value value="7"/>
               <value value="2"/>
               <value value="4"/>
               <value value="4"/>
               <value value="4"/>
               <entryRelationship typeCode="SUBJ">
                  <observationMedia classCode="OBS" moodCode="EVN">
                     <id root="2.16.840.1.113883.19.2.1"/>
                     <value mediaType="image/jpeg">
                        <reference value="lefthand.jpeg"/>
                     </value>
                  </observationMedia>
               </entryRelationship>
            </regionOfInterest>
         </entryRelationship>
      </observation>
   </entry>
</section>

5.3.6.8 SubstanceAdministration

Substance Administration

A derivative of the RIM SubstanceAdministration class, used for representing medication-related events such as medication history or planned medication administration orders.

Table X: SubstanceAdministration Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	SBADM	Fixed
moodCode	CS	[1..1]	V:x_DocumentSubstanceMood	Closed
id	SET <II>	[0..*]
code	CD	[0..1]	D:ActSubstanceAdministrationCode	Open
actonNegationInd	BL	[0..1]
negationInd (Deprecated)	BL	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	GTS	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..1]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
repeatNumber	IVL<INT>	[0..1]
languageCode	CS	[0..1]	D:HumanLanguage	Closed
isCriterionInd	BL	[0..1]
routeCode	CE	[0..1]	D:RouteOfAdministration	Open
approachSiteCode	SET<CD>	[0..*]	D:ActSite	Open
doseQuantity	IVL<PQ>	[0..*]
rateQuantity	IVL<PQ>	[0..*]
doseCheckQuantity	SET<RTO<PQ,PQ.TIME>>	[0..*]
maxDoseQuantity	SET<RTO<PQ,PQ.TIME>>	[0..*]
administrationUnitCode	CE	[0..1]	D:AdministrableDrugForm	Open

SubstanceAdministration.classCode

The SubstanceAdministration.classCode is fixed to "SBADM" which indicates an act of introducing or otherwise applying a substance to the subject.

Table X: Fixed SubstanceAdministration.classCode

Code	Display Name
SBADM	substance administration
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

SubstanceAdministration.moodCode

SubstanceAdministration.moodCode has been bound to the x_DocumentSubstanceMood value set.

Table X: Fixed SubstanceAdministration.moodCode

V:x_DocumentSubstanceMood [2.16.840.1.113883.1.11.19461] (CLOSED)
Code	Display Name		Code	Display Name
EVN	event		DEF	definition
RQO	request		INT	intent
PRMS	promise		PRP	proposal
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

SubstanceAdministration.id

The optional SubstanceAdministration.id can be used to uniquely identify the substance administration.

SubstanceAdministration.code

The SubstanceAdministration.code has been bound to the ActSubstanceAdministrationCode concept domain.

SubstanceAdministration.actionNegationInd

The SubstanceAdministration.actionNegationInd works as a negative existence quantifier on the actual, intended or described substance administration event. In Event mood, it indicates the defined substance administration did not occur. In Intent mood, it indicates the defined substance administration is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the SubstanceAdministration as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, repeatNumber, isCriterionInd, routeCode, approachSiteCode, doseQuantity, rateQuantity, maxDoseQuantity, administrationUnitCode and any of their components.

The remaining properties represent the document characteristics, E.g. SubstanceAdministration.id, SubstanceAdministration.moodCode, SubstanceAdministration.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

SubstanceAdministration.negationInd

SubstanceAdministration.negationInd, is deprecated in RIM 2.35, and CDA R2.1 retains it for backwards compatibility. CDA R2.1 compliant implementation guides should use actionNegationInd moving forward.

SubstanceAdministration.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the SubstanceAdministration. The SubstanceAdministration.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

SubstanceAdministration.statusCode

The status reflects the state of the activity. The RIM based state machine diagram depicts the allowable state transitions that an SubstanceAdministration.StatusCode can take on.

Table X: Value set for SubstanceAdministration.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

SubstanceAdministration.effectiveTime

SubstanceAdministration.effectiveTime is the clinically relevant time of an substance administration act, exclusive of administrative activity. It is used to indicate the time over which the substance is to be administered, including the frequency of administration (e.g., TID for 10 days). SubstanceAdministration.effectiveTime is used to describe the timing of administration. It is modeled using the GTS data type to accommodate various dosing scenarios, as illustrated in the following example.

SubstanceAdministration.activityTime

SubstanceAdministration.activityTime is a time expression specifying when the substance administration activity occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. The substance administration activityTime can provide a needed administrative function, by providing a more inclusive time to be anticipated in scheduling.

SubstanceAdministration.availabilityTime

SubstanceAdministration.availabilityTime is the point in time at which information about a substance administration instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the substance administration itself.

SubstanceAdministration.priorityCode

The urgency under which the SubstanceAdministration happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The SubstanceAdministration.priorityCode is bound to the ActPriority concept domain.

SubstanceAdministration.confidentialityCode

Constraints around appropriate disclosure of information about this SubstanceAdministration, regardless of mood. The SubstanceAdministration.confidentialityCode is bound to the Confidentiality concept domain.

SubstanceAdministration.repeatNumber

An interval of integer numbers stating the minimal and maximal number of repetitions of the SubstanceAdministration.

SubstanceAdministration.languageCode

The primary language in which this SubstanceAdministrationstatement is specified, particularly the language of the SubstanceAdministration.text. The SubstanceAdministration.languageCode is bound to the HumanLanguage concept domain.

SubstanceAdministration.isCriterionInd

Is defaulted to false, when set to true it indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

SubstanceAdministration.routeCode

The physiological path or route for introducing the therapeutic material into or onto the subject. Route, site of administration (administrationSiteCode), method of administration (methodCode) and the device used in administration are closely related. All four (if present) must be closely coordinated and in agreement. In some cases, the coding system used to specify one may pre-coordinate one or more of the others.

SubstanceAdministration.approachSiteCode

The anatomical site or system through which the procedure reaches its target.

SubstanceAdministration.doseQuantity

SubstanceAdministration.doseQuantity indicates how much medication is given per dose.

SubstanceAdministration.rateQuantity

SubstanceAdministration.rateQuantity can be used to indicate the rate at which the dose is to be administered (e.g., the flow rate for intravenous infusions).

SubstanceAdministration.doseCheckQuantity

The ratio of a quantity to be consumed over the period of time during which it expected to be consumed.

SubstanceAdministration.maxDoseQuantity

SubstanceAdministration.maxDoseQuantity is used to capture the maximum dose of the medication that can be given over a stated time interval (e.g., maximum daily dose of morphine, maximum lifetime dose of doxorubicin).

SubstanceAdministration.administrationUnitCode

A unit for the administered substance.

1. This attribute SHOULD be used if and only if the material specified as the player of the Role attaching to the consumable participation is not in itself the finished dose form to be administered but a larger whole, pack, etc.
2. If the material so specified is the proper administered dose form, such as a tablet, capsule, etc. then this attribute SHOULD be valued NULL (not applicable).
3. If the material so specified is an amorphous substance (liquid, gas, powder, etc.) to be measured as a volume, mass, etc., then this attribute SHOULD remain NULL (not applicable).
4. If the material so specified is a container, and the content is to be measured as a volume, mass, etc., then this attribute SHOULD be specified as "measured portion".

Example X

<section>
   <text>Take captopril 25mg PO every 12 hours, starting on 
    Jan 01, 2002, ending on Feb 01, 2002.
   </text>
   <entry>
      <substanceAdministration classCode="SBADM" moodCode="RQO">
         <effectiveTime xsi:type="IVL_TS">
            <low value="20020101"/>
            <high value="20020201"/>
         </effectiveTime>
         <effectiveTime xsi:type="PIVL_TS" operator="A">
            <period value="12" unit="h"/>
         </effectiveTime>
         <routeCode code="PO" 
          codeSystem="2.16.840.1.113883.5.112" 
          codeSystemName="RouteOfAdministration"/>
         <doseQuantity value="1"/>
         <consumable>
            <manufacturedProduct>
               <manufacturedLabeledDrug>
                  <code code="318821008" 
                   codeSystem="2.16.840.1.113883.6.96" 
                   codeSystemName="SNOMED CT" 
                   displayName="Captopril 25mg tablet"/>
               </manufacturedLabeledDrug>
            </manufacturedProduct>
         </consumable>
      </substanceAdministration>
   </entry>
</section>

5.3.6.8.1 consumable

The capture of medication-related information also involves the interrelationship of SubstanceAdministration with several other classes.

Table X: consumable

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	CSM	consumable
contextControlCode	CS	[0..1]	OP	Fixed

consumable.typeCode

The consumable.typeCode is fixed to "CSM" to represent a consumable participation.

Table X: Fixed consumable.typeCode

Code	Display Name
CSM	consumable
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

consumable.contextControlCode

The consumable.contextControlCode is fixed to "OP". It means that the consumable identified will replace the set of consumables that have propagated from ancestor Acts, and will itself be the only consumable to propagate to any child Acts that allow context to be propagated.

5.3.6.8.2 ManufacturedProduct

The consumable participation is used to bring in the LabeledDrug or Material entity that describes the administered substance via the ManufacturedProduct role class.

ManufacturedProduct.classCode

The ManufacturedProduct.typeCode is fixed to "MANU" to represent the role of manufactured. The playing role is what was manufactured and the scoping role identifies the manufacturer.

Table X: Fixed ManufacturedProduct.classCode

Code	Display Name
MANU	manufactured
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

ManufacturedProduct.id

An optional unique identifier assigned by the manufacturer.

5.3.6.8.3 LabeledDrug

The LabeledDrug class, which is an Entity class playing the Role of Manufactured Product, identifies the drug that is consumed in the substance administration. The medication is identified by means of the LabeledDrug.code or the LabeledDrug.name.

LabeledDrug.classCode

The LabeledDrug.classCode is fixed to "MMAT" which indicates the substance administered was manufactured.

Table X: Fixed LabeledDrug.classCode

Code	Display Name
MMAT	A manufactured material.
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

LabeledDrug.determinerCode

The determinerCode is fixed to "KIND", which indicates that the LabeledDrug referenced, represents a kind or class of Labeled drug.

Table X: Fixed LabeledDrug.determinerCode

Code	Display Name
KIND	described
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

LabeledDrug.code

The LabeledDrug.code is bound to the DrugEntity concept domain, which identifies a substance whose therapeutic effect is produced by chemical action within the body.

LabeledDrug.name'

An optional non-unique textual identifier or moniker for the LabeledDrug.

5.3.6.8.4 Material

The Material entity can be used to identify non-drug administered substances such as vaccines and blood products and drugs.

Material.classCode

The Material.classCode is fixed to "MMAT" which indicates the material administered was manufactured.

Table X: Fixed Material.classCode

Code	Display Name
MMAT	A manufactured material.
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Material.determinerCode

The determinerCode is fixed to "KIND", which indicates that the Material referenced, represents a kind or class of Material.

Table X: Fixed Material.determinerCode

Code	Display Name
KIND	described
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Material.code

The Material.code is bound to the MaterialEntityClassType concept domain, which identifies types of materials.

Material.name

An optional non-unique textual identifier or moniker for the Material.

Material.desc

A textual or multimedia depiction of the Material.

Material.formCode

The physical state and nature of the material.

Material.lotNumberText

An identifier for a particular batch of manufactured material.

5.3.6.9 Supply

Supply

The Supply class represents dispensing, whereas the SubstanceAdministration class represents administration. Prescriptions are complex activities that involve both an administration request to the patient (e.g. take digoxin 0.125mg by mouth once per day) and a supply request to the pharmacy (e.g. dispense 30 tablets, with 5 refills). This should be represented in CDA by a SubstanceAdministration entry that has a component Supply entry. The nested Supply entry can have Supply.independentInd set to "false" to signal that the Supply cannot stand alone, without it's containing SubstanceAdministration. The following example illustrates a prescription representation in CDA.

Table X: Supply Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	SPLY	Fixed
moodCode	CS	[1..1]	V:x_DocumentSubstanceMood	Closed
id	SET <II>	[0..*]
code	CD	[0..1]	D:ActSupplyType	Open
actonNegationInd	BL	[0..1]
text	ED	[0..1]
statusCode	CS	[0..1]	V:ActStatus	Closed
effectiveTime	GTS	[0..1]
activityTime	GTS	[0..1]
availabilityTime	TS	[0..1]
priorityCode	CE	[0..*]	D:ActPriority	Open
confidentialityCode	SET<CE>	[0..*]	D:Confidentiality	Open
repeatNumber	IVL<INT>	[0..1]
independentInd	BL	[0..1]
languageCode	CS	[0..1]	D:HumanLanguage	Closed
isCriterionInd	BL	[0..1]
quantity	PQ	[0..1]
expectedUseTime	IVL<TS>	[0..1]

Supply.classCode

The Supply.classCode is fixed to "SPLY" which is used to represent a Supply. Supply orders and deliveries are simple Acts that focus on the delivered product. The product is associated with the Supply Act via Participation.typeCode="product". With general Supply Acts, the precise identification of the Material (manufacturer, serial numbers, etc.) is important. Most of the detailed information about the Supply should be represented using the Material class.

Table X: Fixed Supply.classCode

Code	Display Name
SPLY	supply
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Supply.moodCode

The Supply.moodCode is bound to the x_ClinicalStatementSubstanceMood value set.

Table X: Value set for Supply.moodCode

V:x_ClinicalStatementSubstanceMood [2.16.840.1.113883.1.11.19645] (CLOSED)
Code	Display Name		Code	Display Name
EVN	event		DEF	definition
RQO	request		INT	intent
PRMS	promise		PRP	proposal
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Supply.id

The optional Supply.id is used to uniquely identify the supply activity.

Supply.code

The optional Supply.code is bound to the ActSupplyType concept domain, which is used to further define the type of supply for order or distribution. Examples:

• central supply
• materials management
• nurse station supply

Supply.actionNegationInd

The Supply.actionNegationInd works as a negative existence quantifier on the actual, intended or described Supply event. In Event mood, it indicates the defined supply act did not occur. In Intent mood, it indicates the defined supply act is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd negates the Supply act as described by the descriptive properties which are: classCode, code, statusCode, effectiveTime, activityTime, priorityCode, repeatNumber, independentInd, isCriterionInd, quantity, expectedUseTime and any of their components.

The remaining properties represent the document characteristics, E.g. Supply.id, Supply.moodCode, Supply.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Supply.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Supply activity.

Supply.statusCode

The status reflects the state of the activity. The RIM based state machine diagram depicts the allowable state transitions that an Supply.StatusCodes can take on.

Table X: Value set for Supply.statusCode

V:ActStatus [2.16.840.1.113883.1.11.15933] (CLOSED)
Code	Display Name		Code	Display Name
normal	normal		aborted	aborted
active	active		cancelled	cancelled
completed	completed		held	held
new	new		suspended	suspended
nullified	nullified		obsolete	obsolete
Code System: ActStatus (HL7) Code System OID: 2.16.840.1.113883.5.14

Supply.effectiveTime

Supply.effectiveTime is used to indicate the clinically or operationally relevant time of a supply, exclusive of administrative activity.

Supply.activityTime

Supply.activityTime is a time expression specifying when a supply occurs, inclusive of administrative time E.g. times of component actions, such as preparation and clean-up. Depending on the mood code used, it represents the time the Supply activity occurred, is supposed to occur, is scheduled to occur, etc.

Supply.availabilityTime

Supply.availabilityTime is the point in time at which information about an Supply instance (regardless of mood) first became available to a system. The availabilityTime is metadata describing the recording of, not the Supply itself.

Supply.priorityCode

The urgency under which the Supply activity happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. The Supply.priorityCode is bound to the ActPriority concept domain.

Supply.confidentialityCode

Constraints around appropriate disclosure of information about this Supply activity, regardless of mood. The Supply.confidentialityCode is bound to the Confidentiality concept domain.

Supply.repeatNumber

An interval of integer numbers stating the minimal and maximal number of repetitions of the Supply activity.

Supply.independentInd

An indicator specifying whether the Act can be manipulated independently of other Acts or only through a super-ordinate composite Act that has this Act as a component. By default the independentInd should be true. An Act definition is sometimes marked with independentInd=false if the business rules would not allow this act to be ordered without ordering the containing act group.

Supply.languageCode

The primary language in which this Supply statement is specified, particularly the language of the Supply.text. The Supply.languageCode is bound to the HumanLanguage concept domain.

Supply.isCriterionInd

Is defaulted to false, when set to true it indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

Supply.quantity

The optional Supply.quantity is used to represent the amount of material that was or is to be supplied.

Supply.expectedUseTime

Th optional Supply.expectedUseTime is used to identify the period time over which the supplied product is expected to be used.

5.3.6.9.1 Product

The dispensed product is associated with the Supply act via a product participant, which connects to the same ManufacturedProduct role used for SubstanceAdministration.

Product.typeCode

The Product.typeCode is fixed to "PRD" which represents a product participation.

Table X: Fixed product.typeCode

Code	Display Name
PRD	product
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

5.3.6.9.2 ManufacturedProduct

See ManufacturedProduct above.

Example X

<section>
   <text>Digoxin 0.125mg, 1 PO qDay, #30, 5 refills.</text>
   <entry>
      <substanceAdministration classCode="SBADM" moodCode="RQO">
         <effectiveTime xsi:type="PIVL_TS">
            <period value="24" unit="h"/>
         </effectiveTime>
         <routeCode code="PO" 
          codeSystem="2.16.840.1.113883.5.112" 
          codeSystemName="RouteOfAdministration"/>
         <doseQuantity value="1"/>
         <consumable>
            <manufacturedProduct>
               <manufacturedLabeledDrug>
                  <code code="317896006" 
                   codeSystem="2.16.840.1.113883.6.96" 
                   codeSystemName="SNOMED CT" 
                   displayName="Digoxin 125micrograms tablet"/>
               </manufacturedLabeledDrug>
            </manufacturedProduct>
         </consumable>
         <entryRelationship typeCode="COMP">
            <supply classCode="SPLY" moodCode="RQO">
               <repeatNumber>
                  <low value="0"/>
                  <high value="5"/>
               </repeatNumber>
               <independentInd value="false"/>
               <quantity value="30"/>
            </supply>
         </entryRelationship>
      </substanceAdministration>
   </entry>
</section>

5.3.7 Entry Participants

CDA structures and entries can have various participants, some of which are also defined in the CDA header. As described in the discussion of CDA context (see CDA Context), participants propagated from the header can be overridden within the body.

Entry Participants

5.3.7.1 author

The author participant (described above, see author), can be ascribed to a CDA section where it overrides the value(s) propagated from the CDA header, or can be ascribed to a CDA entry, where it overrides the value(s) propagated from a CDA section and propagates to nested entries.

5.3.7.2 consumable

The consumable participant is described above (see Entry Acts).

5.3.7.3 informant

The informant participant (described above, see informant), can be ascribed to a CDA section where it overrides the value(s) propagated from the CDA header, or can be ascribed to a CDA entry, where it overrides the value(s) propagated from a CDA section and propagates to nested entries.

5.3.7.4 participant

Participant

Can be used to represent any other participant that cannot be represented with one of the more specific participants. The participant can be ascribed to a CDA entry, and propagates to nested CDA entries, unless overridden.

Table X: informant

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	INF	Fixed
functionCode	CE	[0..1]	D:ParticipationFunction	Open
contextControlCode	CS	[0..1]	OP	Fixed
time	IVL<TS>	[0..1]
awarenessCode	CE	[0..1]	D:TargetAwareness	Open

participant.typeCode

The participant.typeCode is bound to the v:ParticipationType value set. This enables a wide range of participation types to be selected. Note: Where an existing participation exists, it should be used in preference to the generic participation, failure to do so, will result in needlessly additional complexity for implementations.

Table X: Value set for participant.typeCode

v:ParticipationType [2.16.840.1.113883.1.11.10901] (CLOSED)
Code	Display Name		Code	Display Name
PART	Participation		ADM	admitter
ATND	attender		ADM	admitter
CALLBCK	callback contact		CON	consultant
DIS	discharger		ESC	escort
REF	referrer		TRANS	Transcriber
ENT	data entry person		WIT	witness
CST	custodian		DIR	direct target
BBY	baby		DEV	device
NRD	non-reuseable device		RDV	reusable device
EXPAGNT	ExposureAgent		EXPART	ExposureParticipation
EXPTRGT	ExposureTarget		EXSRC	ExposureSource
IND	indirect target		BEN	beneficiary
CAGNT	causative agent		COV	coverage target
GUAR	guarantor party		HLD	holder
DON	donor		RCV	receiver
IRCP	information recipient		NOT	ugent notification contact
PRCP	primary information recipient		REFB	Referred By
REFT	Referred to		TRC	tracker
LOC	location		DST	destination
ELOC	entry location		ORG	origin
RML	remote		VIA	via
RESP	responsible party		VRF	verifier
AUTHEN	authenticator
Use the following participations, only if the other participations provided in CDA will not work
RCT	record target		AUT	author (originator)
INF	informant		CSM	consumable
PRD	product		SBJ	subject
SPC	specimen		PRF	performer
DIST	distributor		PPRF	primary performer
SPRF	secondary performer		LA	legal authenticator
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

participant.functionCode

The participant.functionCode is bound to the concept domain ParticipationFunction, which is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (Open).

participant.contextControlCode

The participant.contextControlCode is fixed to "OP". Any participant(s) defined in a clinical entry, will override the participants with the same typeCode propagating from ancestor elements, in the header, body or sections.

Table X: Fixed participant.contextControlCode

Code	Display Name
OP	overriding, propagating
Code System: ContextControl (HL7) Code System OID: 2.16.840.1.113883.5.1057

participant.time

The time during which the participant is involved in the act through this Participation.

participant.awarenessCode

The extent to which the Entity playing the participating Role is aware of the associated Act. For diagnostic observations, the patient, family member or other participant may not be aware of the patient's terminal illness. Because this attribute typically indicates that awareness is in question, it normally describes a target Participation (e.g., that of a patient). If the awareness, denial, unconsciousness, etc. is the subject of medical considerations (e.g., part of the problem list), explicit observations should be employed: this simple attribute in the Participation cannot represent information sufficient to support medical decision-making.

5.3.7.4.1 ParticipantRole

A participant is an entity playing one of several possible roles (ParticipantRole class). The entity playing the role is a device (Device class) or other entity (PlayingEntity class).

Table X: ParticipantRole

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[1..1]	V:RoleClassRoot	Fixed
id	SET<II>	[0..*]
code	CE	[0..1]	D:RoleCode	Open
addr	SET<AD>	[0..*]
telecom	SET<TEL>	[0..*]

ParticipantRole.classCode

The ParticipantRole.classCode can be any role defined in the V:RoleClassRoot value set, not already provided for the Clinical Statement choice pattern.

Table X: Value set for ParticipantRole.classCode

V:RoleClassRoot [2.16.840.1.113883.1.11.13940] (CLOSED)
Code	Display Name		Code	Display Name
ROL (Default)	role		AFFL	affiliate
AGNT	agent		ASSIGNED	assigned entity
COMPAR	commissioning party		SGNOFF	signing authority or officer
CON	contact		ECON	emergency contact
NOK	next of kin		GUARD	guardian
CIT	citizen		COVPTY	covered party
CLAIM	claimant		NAMED	named insured
DEPEN	dependent		INDIV	individual
SUBSCR	subscriber		PROG	program eligible
CRINV	clinical research investigator		CRSPNSR	clinical research sponsor
EMP	employee		MIL	military person
GUAR	guarantor		INVSBJ	Investigation Subject
CASEBJ	Case Subject		RESBJ	research subject
LIC	licensed entity		NOT	notary public
PROV	healthcare provider		PAT	patient
PAYEE	payee		PAYOR	invoice payor
POLHOLD	policy holder		QUAL	qualified entity
SPNSR	underwriter		STD	student
UNDWRT	coverage sponsor		CAREGIVER	caregiver
PRS	personal relationship		ACCESS	access
ADMM	Administerable Material		BIRTHPL	birthplace
DEATHPLC	place of death		DST	distributed material
RET	retailed material		EXPR	exposed entity
HLD	held entity		HLTHCHRT	health chart
IDENT	identified entity		MANU	manufactured product
THER	therapeutic agent		MNT	maintained entity
OWN	owned entity		RGPR	regulated product
SDLOC	service delivery location		DSDLOC	dedicated service delivery location, health care facility
ISDLOC	incidental service delivery location		TERR	territory of authority
USED	used entity		WRTE	warranted product
EQUIV	equivalent entity		SAME	same
SUBY	subsumed by		GEN	has generalization
GRIC	has generic		INST	instance
SUBS	subsumer		CONT	content
EXPAGTCAR	exposure agent carrier		EXPVECTOR	exposure vector
FOMITE	fomite		INGR	ingredient
ACTI	active ingredient		ACTIB	active ingredient - basis of strength
ACTIM	active ingredient - moiety is basis of strength		ACTIR	active ingredient - reference substance is basis of strength
ADTV	additive		BASE	base
IACT	inactive ingredient		COLR	color additive, color
FLVR	flavor additive, flavor		PRSV	preservative
STBL	stabilizer		LOCE	located entity
STOR	stored entity		MBR	member
PART	part		ACTM	active moiety
SPEC	specimen		ALQT	aliquot
ISLT	isolate
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

ParticipantRole.id

The optional participantRole.id is a unique identifier for the player Entity in this Role.

ParticipantRole.code

The optional ParticipantRole.code is bound the the EntityCode concept domain.

ParticipantRole.addr

The optional ParticipantRole.addr is the postal address for the Entity while in the Role.

ParticipantRole.telecom

The optional ParticipantRole.telecom is the telecommunication address (phone number) for the Entity while in the Role.

5.3.7.4.2 Device

Scoping the ParticipantRole is an entity (Entity class).

Table X: Device

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DEV	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
code	CE	[0..1]	D:EntityCode
manufacturerModelName	SC	[0..1]	D:ManufacturerModelName
softwareName	SC	[0..1]	D:SoftwareName

Device.classCode

The Device.classCode is defaulted to "DEV", but can take on any value defined in the EntityClassDevice value set.

Table X: Value set for Device.classCode

V:EntityClassDevice [2.16.840.1.113883.1.11.11623] (CLOSED)
Code	Display Name		Code	Display Name
DEV (Default)	role		CER	certificate representation
MODDV	imaging modality, ImagingModalityEntity
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Device.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates we are referencing a specific device.

Table X: Fixed Device.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Device.code

The optional Device.code is bound to the EntityCode domain.

Device.manufacturerModelName

The optional Device.manufacturerModelName is used to convey a coded name for the device.

Device.softwareName

The optional Device.softwareName is used to convey a coded name for the software used to author content.

5.3.7.4.3 PlayingEntity

Table X: PlayingEntity

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	DEV	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
code	CE	[0..1]	D:EntityCode
quantity	SET<PQ>	[0..*]
name	SET<PN>	[0..*]
desc	ED	[0..1]

Note: Support for more than one quantity element in PlayingEntity has been deprecated in CDA R2.1. The CDA R2.1 schema will continue to support multiple quantities for backwards compatibility with CDA R2, but implementers of new templates and document instances are encouraged to support only [0..1] instances.

PlayingEntity.classCode

The PlayingEntity.classCode is bound to the V:EntityClassRoot value set.

Table X: Value set for PlayingEntity.classCode

V:EntityClassRoot [2.16.840.1.113883.1.11.13922] (CLOSED)
Code	Display Name		Code	Display Name
ENT (Default)	entity		HCE	health chart entity
LIV	living subject		NLIV	non-person living subject
ANM	animal		MIC	microorganism
PLNT	plant		PSN	person
MAT	material		CHEM	chemical substance
FOOD	food		MMAT	manufactured material
CONT	container		HOLD	holder
DEV	device		CER	certificate representation
MODDV	imaging modality, ImagingModalityEntity		ORG	organization
PUB	public institution		STATE	state
NAT	Nation		PLC	place
CITY	city or town		COUNTRY	country
COUNTY	county or parish		PROVINCE	state or province
RGRP	group
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

PlayingEntity.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates we are referencing a specific entity.

Table X: Fixed PlayingEntity.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

PlayingEntity.code

The optional PlayingEntity.code is bound to the EntityCode domain. For each Entity, the value for this attribute is drawn from one of several coding systems as suggested by the Entity.classCode, such as living subject (animal and plant taxonomies), chemical substance (e.g., IUPAC code), organization (e.g., CMS provider number), etc. It is possible that Entity.code may be so fine grained that it represents a single instance. An example is the CDC vaccine manufacturer code, modeled as a concept vocabulary, when in fact each concept refers to a single instance. The boundary cases distinguishing codes and identifiers are controversial: this specification allows a certain amount of flexibility.

PlayingEntity.quantity

The optional PlayingEntity.quantity defines the a physical quantity specifying the amount of the physical thing represented by the Entity object, either as a count of the members of a group, or as some other physical quantity. In order to explicitly identify a group of like entities, a static model design should constrain the PQ data type of this attribute to INT, thus providing a count of the entities in the group.

Note: Support for more than one quantity element in PlayingEntity has been deprecated in CDA R2.1. The CDA R2.1 schema will continue to support multiple quantities for backwards compatibility with CDA R2, but implementers of new templates and document instances are encouraged to support only [0..1] instances.

PlayingEntity.name

Most entities have a commonly used name that can be used to differentiate them from other Entities, but that does not provide a necessarily unique identifier.

PlayingEntity.desc

A textual or multimedia depiction of the Entity.

5.3.7.4.4 Entity

A physical thing, group of physical things or an organization capable of participating in Acts while in a role.

Table X: Entity

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	[http://cda/infrastructure/vocabulary/EntityClass.htm#ENT ENT	Fixed
determinerCode	CS	[0..1]	INSTANCE	Fixed
id	SET<II>	[0..*]
code	CE	[0..1]	D:EntityCode
desc	ED	[0..1]

Entity.classCode

The Entity.classCode is bound to the V:EntityClassRoot value set.

Table X: Value set for Entity.classCode

V:EntityClassRoot [2.16.840.1.113883.1.11.13922] (CLOSED)
Code	Display Name		Code	Display Name
ENT (Default)	entity		HCE	health chart entity
LIV	living subject		NLIV	non-person living subject
ANM	animal		MIC	microorganism
PLNT	plant		PSN	person
MAT	material		CHEM	chemical substance
FOOD	food		MMAT	manufactured material
CONT	container		HOLD	holder
DEV	device		CER	certificate representation
MODDV	imaging modality, ImagingModalityEntity		ORG	organization
PUB	public institution		STATE	state
NAT	Nation		PLC	place
CITY	city or town		COUNTRY	country
COUNTY	county or parish		PROVINCE	state or province
RGRP	group
Code System: EntityClass (HL7) Code System OID: 2.16.840.1.113883.5.41

Entity.determinerCode

The determinerCode is fixed to "INSTANCE", which indicates we are referencing a specific entity.

Table X: Fixed Entity.determinerCode

Code	Display Name
INSTANCE	specific
Code System: EntityDeterminer (HL7) Code System OID: 2.16.840.1.113883.5.30

Entity.id

The optional Entity.id is used to uniquely identify the Entity.

Entity.code

The optional Entity.code is bound to the EntityCode domain.

Entity.desc

The optional Entity.desc is a textual or multimedia depiction of the Entity.

5.3.7.5 performer

Performer

The performer is a person who carries out or will carry out a particular act. The performer need not be the principal responsible participant, e.g. a surgery resident operating under supervision of attending surgeon is a performer.

Table X: performer

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	PRF	Fixed
functionCode	CE	[0..1]	D:ParticipationFunction	Open
time	IVL<TS>	[0..1]
modeCode	CE	[0..1]	D:ParticipationMode	Fixed

performer.typeCode

The performer.typeCode is fixed to "PRF" which indicates a person, or organization that actually and principally carries out the action. Need not be the principal responsible actor.

Table X: Fixed performer.typeCode

Code	Display Name
PRF	performer
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

performer.functionCode

The performer.functionCode is bound to the concept domain ParticipationFunction, which is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (Open).

performer.time

An optional interval of time which indicating the performer's participation in the associated Act.

performer.modeCode

The modality by which the Entity playing the Role is participating in the Act.

5.3.7.5.1 AssignedEntity

A performer is an entity in the role of assigned entity (AssignedEntity class).

5.3.7.5.2 Person

An assigned entity is a person assigned to the role by the scoping organization. The entity playing the role is a Person class.

5.3.7.5.3 Organization

The entity scoping the role is an organization (Organization class).

5.3.7.6 product

The product participant is described above (see Entry Acts).

5.3.7.7 specimen

Specimen

A specimen is a part of some entity, typically the subject, that is the target of focused laboratory, radiology or other observations. In many clinical observations, such as physical examination of a patient, the patient is the subject of the observation, and there is no specimen. The specimen participant is only used when observations are made against some substance or object that is taken or derived from the subject.

Table X: informant

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	SPC	Fixed

specimen.typeCode

The specimen.typeCode is fixed to "SPC" to indicate the subject of non-clinical (e.g. laboratory) observation services is a specimen.

Table X: Fixed specimen.typeCode

Code	Display Name
SPC	specimen
Code System: ParticipationType (HL7) Code System OID: 2.16.840.1.113883.5.90

5.3.7.7.1 SpecimenRole

A role played by a material entity that is a specimen for an act.

Table X: AssignedAuthor

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	SPEC	Fixed
id	SET<II>	[0..*]

SpecimenRole.classCode

The SpecimenRole.classCode is fixed to "SPEC".

Table X: Fixed SpecimenRole.classCode

Code	Display Name
SPEC	specimen
Code System: RoleClass (HL7) Code System OID: 2.16.840.1.113883.5.110

SpecimenRole.id

An optional SpecimenRole.id can be used to uniquely identify the specimen.

5.3.7.7.2 PlayingEntity

A specimen is an PlayingEntity in the role of SpecimenRole (PlayingEntity class).

5.3.7.8 subject

The subject participant (described above, see subject), can be ascribed to a CDA section, or it can be ascribed to a CDA entry, where it overrides the value(s) propagated from a CDA section and propagates to nested entries.

5.3.8 Entry Relationships

5.3.8.1 component

The component relationship has a source of Organizer (see Organizer, and a target that is another CDA entry, and is used to create groupings of CDA entries within an Organizer.

Table X: documentationOf Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	COMP	Fixed
contextConductionInd	BL	[0..1]
sequenceNumber	INT	[0..1]
seperatableInd	BL	[0..1]

component.typeCode

The component.typeCode is fixed to "COMP", which indicates that the associated Clinical Statement choice is a component part of the Organizer.

Table X: Fixed component.typeCode

Code	Display Name
COMP (FIXED)	has component
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

component.contextConductionInd

The component.contextConductionInd indicator is fixed to "true". Ancestor elements () which propagate, will conduct through this component class to the associated child element.

component.sequenceNumber

The optional component.sequenceNumber is an integer specifying the relative sequential ordering of this relationship among other like-types relationships having the same source Act.

component.seperatableInd

The optional component.seperatableInd is an indication that the source Act is intended to be interpreted independently of the target Act. The default value is true.

5.3.8.2 precondition

The precondition class, derived from the ActRelationship class, is used along with the Criterion class to express a condition that must hold true before some over activity occurs.

Table X: precondition Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	PRCN	Fixed

precondition.typeCode

The precondition.typeCode is fixed to PRCN which indicates a requirement to be true before a service is performed. The target can be any service in criterion mood. For multiple pre-conditions a conjunction attribute (AND, OR, XOR) is applicable.

Table X: Fixed precondition.typeCode

Code	Display Name
PRCN	has pre-condition
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

5.3.8.2.1 Criterion

Criterion class is used to express a condition that must hold true before some over activity occurs.

Table X: Criterion Attributes

RIM Attribute(s)	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	<= OBS is V:ActClassObservation	Closed w/ Default
moodCode	CS	[0..1]	ENV.CRT	Fixed
code	CD	[1..1]	D:ActCode	Open
actonNegationInd	BL	[0..1]
text	ED	[0..1]
isCriterionInd	BL	[0..1]
value	SET<ANY>	[0..*]	D:ObservationValue	Open
valueNegationInd	BL	[0..1]
interpretationCode	SET<CE>	[0..*]	D:ObservationInterpretation	Open

Criterion.classCode

The Criterion.classCode is defaulted to "OBS" which represents an observation, but can take only any value defined in the ActClassObservation value set.

Table X: Value set for Criterion.classCode

V:ActClassObservation [2.16.840.1.113883.1.11.11529] (CLOSED)
Code	Display Name		Code	Display Name
OBS (Default)	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
CNOD (Deprecated)	Condition Node
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

Criterion.moodCode

The Criterion.moodCode is fixed to "EVN.CRT" which indicates a criterion or condition over service events that must apply for an associated service to be considered.

Table X: Fixed Criterion.moodCode

Code	Display Name
EVN.CRT	event criterion
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

Criterion.code

The particular kind of Criterion that the Criterion-instance represents. Criterion.code, if used, SHALL be a specialization of the Criterion.classCode. This attribute defines a specific sub-type of a given Criterion type. It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the Criterion. The Criterion.code is bound to the ActCode concept domain.

Criterion.actionNegationInd

The Criterion.actionNegationInd indicates that the condition is based on the non-occurrence of the event.

The actionNegationInd negates the Criterion as described by the descriptive properties which are: classCode, code, isCriterionInd, value, valueNegationInd, interpretationCode and any of their components.

The remaining properties represent the document characteristics, E.g. Criterion.moodCode, Criterion.text are not negated. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

Criterion.text

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Criterion. The Criterion.text attribute can reference the associated narrative content in the section using the XML ID attribute added to the Narrative Text elements.

Criterion.isCriterionInd

Is defaulted to false, when set to true it indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

Criterion.value

The result of the observation action. Extensive usage notes are available in the RIM, reference Value UsageNotes

Criterion.valueNegationInd

Criterion.valueNegationInd, indicates that the Criterion, as defined in in this Criterion class is NOT true. Note: This attribute should only be used when the terminology used for Criterion.value is not itself capable of expressing negated findings. (E.g. ICD9).

Criterion.interpretationCode

A qualitative interpretation of the Criterion. These interpretation codes are sometimes called "abnormal flags," however, the judgment of normalcy is just one of the interpretations, and is often not relevant. For example, the susceptibility interpretations are not about "normalcy," and for any observation of a pathologic condition, it does not make sense to state the normalcy, since pathologic conditions are never considered "normal."

5.3.8.3 referenceRange

The referenceRange relationship (described above, see Observation), has a source of Observation, and a target of ObservationRange.

5.3.8.4 entryRelationship

Entry Relationship

CDA has identified and modeled various link and reference scenarios. These scenarios enable CDA entries to be semantically linked to entries that exist within the same document (by traversing the entryRelationship class) or to objects external to it (by traversing the reference class).

Table X: entryRelationship Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	V:ActRelationshipType	Closed
inversionInd	BL	[0..1]
contextConductionInd	BL	[0..1]
sequenceNumber	INT	[0..1]
negationInd	BL	[0..1]
seperatableInd	BL	[0..1]

In CDA R2.0, the following entryRelationships scenarios were provided as informative content:

Table X: Examples of typical entryRelationships

ActRelationship Type	Reasonable Source and Target entries	Comments
CAUS (is etiology for)	(Act | Observation | Procedure | SubstanceAdministration) CAUS (Observation)	Used to show that the source caused the target observation (for instance, source "diabetes mellitus" is the cause of target "kidney disease").
COMP (has component)	(Act | Observation | Procedure | SubstanceAdministration | Supply) COMP (Act | Observation | Procedure | SubstanceAdministration | Suppply)	Used to show that the target is a component of the source (for instance "hemoglobin measurement" is a component of a "complete blood count").
GEVL (evaluates (goal))	(Observation) GEVL (Observation)	Used to link an observation (intent or actual) to a goal to indicate that the observation evaluates the goal (for instance, a source observation of "walking distance" evaluates a target goal of "adequate walking distance").
MFST (is manifestation of)	(Observation) MFST (Observation)	Used to say that the source is a manifestation of the target (for instance, source "hives" is a manifestation of target "penicillin allergy").
REFR (refers to)	(Act | Observation | Procedure | SubstanceAdministration | Supply) REFR (Act | Observation | ObservationMedia | Procedure | RegionOfInterest | SubstanceAdministration | Supply)	Used to show a general relationship between the source and the target, when the more specific semantics of the relationship isn't known.
RSON (has reason)	(Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply) RSON (Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply)	Used to show the reason or rational for a service (for instance source "treadmill test" has reason "chest pain").
SAS (starts after start)	(Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply) SAS (Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply)	The source Act starts after the start of the target Act (for instance source "diaphoresis" starts after the start of target "chest pain").
SPRT (has support)	(Observation) SPRT (Observation | ObservationMedia | RegionOfInterest)	Used to show that the target provides supporting evidence for the source (for instance source "possible lung tumor" has support target "mass seen on chest-x-ray").
SUBJ (has subject)	(Observation | RegionOfInterest) SUBJ (Observation | ObservationMedia)	Used to relate a source region of interest to a target image, or to relate an observation to its subject observation (for instance, source "moderate severity" has subject target "chest pain").

NOTE: The preceding table provides examples of reasonable relationships between CDA entries, but does not represent a conformance constraint.

The ActRelationshipType "has subject" is similar to the ParticipationType "subject". Entries that primarily operate on physical subjects use the Participation, whereas entries that primarily operate on other entries use the ActRelationship.

XCRPT (is excerpt of) (Act | Observation) XCRPT (Act | Observation | Procedure | SubstanceAdministration | Supply) Used to show that the source is excerpted from the target (for instance source "hemoglobin value of 12" is an excerpt of target "complete blood count").

The distinction between an excerpt and an informant participant can be blurry — such as in the case of recording a patient's medication history where the clinician may obtain the information from an informant or may excerpt the information from another computer system. An informant (or source of information) is a person who provides relevant information. An informant class is in the header, and can be overridden in the body. An excerpt is a sub portion of some other act.

entryRelationship.typeCode

In CDA R2.1 any entry (excluding Organizer), may be related to another entry, using the entryRelationship class. In the entryRelationship class, the typeCode attribute is used to define the semantic relationship that exists between the source or parent entry and the destination or child entry. The value set binding on typeCode was been significantly enhanced in CDA R2.1, and now any code present in the HL7 entryRelationship code system (RIM 2.35) may be used.

Table X: Value set for entryRelationship.typeCode

V:ActRelationshipType [2.16.840.1.113883.1.11.10317] (CLOSED)
Code	Display Name		Code	Display Name
CIND	has contra-indication		PRCN	has pre-condition
RSON	has reason		BLOCK	Blocks
CURE	curative indication		CURE.ADJ	adjunct curative indication
DIAG	diagnosis		MITGT	mitigates
RCVY	Recovery		MTGT.ADJ	adjunct mitigation
SYMP	symptomatic relief		TRIG	has trigger
COMP	has component		ARR	arrival
CTRLV	has control variable		DEP	departure
OUTC	has outcome		OBJC	has continuing objective
OBJF	has final objective		GOAL	has goal
RISK	has risk		PERT	has pertinent information
SAE	starts after end of		SAS	starts after start of
CHRG	has charge		COST	has cost
CREDIT	has credit		DEBIT	has debit
AUTH	authorized by		CAUS	is etiology for
COVBY	covered by		DRIV	is derived from
ELNK	episodeLink		EVID	provides evidence for
EXACBY	exacerbated by		EXPL	has explanation
ITEMSLOC	items located		LIMIT	limited by
MFST	is manifestation of		NAME	assigns name
PREV	has previous instance		REFR	refers to
REFV	has reference values		RELVBY	relieved by
SPRT	has support		SPRTBND	has bounded support
SUBJ	has subject		SUMM	summarized by
SEQL	is sequel		APND	is appendage
COMPLY	Update		DOC	documents
FLFS	fulfills		OCCR	occurrence
OREF	references order		SCH	schedules request
GEN	has generalization		GEVL	evaluates (goal)
INST	instantiates (master)		MOD	modifies
MTCH	matches (trigger)		OPTN	has option
RCHAL	re-challenge		REV	reverses
RPLC	replaces		SUCC	succeeds
UPDT	updates (condition)		XCRPT	Excerpts
VRXCRPT	Excerpt verbatim		XFRM	transformation
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

Note: Implementation Guide ("IG") authors will need to exercise caution and ensure they fully understand the semantics of the relationship defined by the term they have selected. In addition, IG authors will need to understand the impact of both inversionInd and negationInd flags, as these attributes can materially impact those semantics when machine processing.

entryRelationship.inversionInd

The entryRelationship.inversionInd can be set to "true" to indicate that the relationship should be interpreted as if the roles of the source and target entries were reversed. As in the example provided in CDA R2.0, "treadmill test" RSON (has reason) "chest pain". Inverted, this would have "chest pain" as the source and "treadmill test" as the target: "chest pain" RSON (inverted) "treadmill test". Inversion can be useful when the current context is describing the target of an act relationship that needs to be related back to the source.

The entryRelationship.negationInd can be set to "true" to indicate that the meaning of the link is negated. Examples where this might be useful:

• If the relationship without negation specifies that Act A has Act B as a component, then the negation indicator specifies that Act A does not have Act B as a component.
• If B is a reason for A, then negation means that B is not a reason for A.
• If B is a pre-condition for A, then negation means that B is not a precondition for A.

entryRelationship.contextConductionInd

The entryRelationship.contextConductionInd differs from the otherwise common use of this attribute (see CDA Context) in that in all other cases where this attribute is used, the value is fixed at "true", whereas here the value is defaulted to "true", and can be changed to "false" when referencing an entry in the same document. Setting the context conduction to false when referencing an entry in the same document keeps clear the fact that the referenced object retains its original context.

entryRelationship.sequenceNumber

An integer specifying the relative sequential ordering of this relationship among other like-types relationships having the same source Act.

entryRelationship.negationInd

An indicator that asserts that the meaning of the link is negated.

entryRelationship.seperatableInd

An indication that the source Act is intended to be interpreted independently of the target Act. The value is defaulted to true.

5.3.8.5 reference

External

CDA entries can reference external objects such as external images and prior reports. These external objects are not part of the authenticated document content. They contain sufficient attributes to enable an explicit reference rather than duplicating the entire referenced object. The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block.

Each object allows for an identifier and a code, and contains the RIM Act.text attribute, which can be used to store the URL and MIME type of the object. External objects always have a fixed moodCode of "EVN".

Table X: reference Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
typeCode	CS	[0..1]	V:ActRelationshipExternalReference	Fixed
seperatableInd	BL	[0..1]

reference.typeCode

A description of allowable reference.typeCode values are shown in the following table.

Table X: Value set for reference.typeCode

V:ActRelationshipType [2.16.840.1.113883.1.11.10317] (CLOSED)
Code	Display Name		Code	Display Name
ELNK	episodeLink		REFR	refers to
SPRT	has support		RPLC	replaces
XCRPT	Excerpts
Code System: ActRelationshipType (HL7) Code System OID: 2.16.840.1.113883.5.1002

reference.seperatableInd

The reference class contains the attribute reference.seperatableInd, which indicates whether or not the source is intended to be interpreted independently of the target. The indicator cannot prevent an individual or application from separating the source and target, but indicates the author's desire and willingness to attest to the content of the source if separated from the target. Typically, where seperatableInd is "false", the exchanged package should include the target of the reference so that the recipient can render it.

As in the table above (CDA entryRelationship Types), the following table is a guideline for reasonable relationships between CDA entries and external objects, and is not a conformance constraint.

Table X: EXAMPLE entryRelationship Types

ActRelationship Type	Reasonable Source and Target classes	Comments
ELNK (episode link)	(Observation) ELNK (ExternalObservation)	Used to show that the source and the target are part of the same episode (for instance, a diagnosis of "pneumonia" can be linked to an external problem list entry of "pneumonia" to show that the current diagnosis is part of the ongoing episode of pneumonia).
REFR (refers to)	(Act | Observation | Procedure | SubstanceAdministration | Supply) REFR (ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure)	Used to show a general relationship between the source and the target, when the more specific semantics of the relationship isn't known.
RPLC (replace)	(Act | Encounter | Observation | ObservationMedia | Organizer | Procedure | SubstanceAdministration | Supply) RPLC (ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure)	Used to indicate that the source entry is a replacement for the target external act.
SPRT (has support)	(Observation) SPRT (ExternalDocument | ExternalObservation)	Used to show that the target provides supporting evidence for the source.
SUBJ (has subject)	(Observation | RegionOfInterest) SUBJ (ExternalObservation)	Used to relate a source region of interest to a target image, or to relate an observation to its subject observation.
XCRPT (is excerpt of)	(Act | Observation) XCRPT (ExternalAct | ExternalDocument | ExternalObservation | ExternalProcedure)	Used to show that the source is excerpted from the target (for instance "the hemoglobin is 10.7" is an excerpt of an externally referenced "complete blood count").

Target classes of the reference relationship include ExternalAct, ExternalDocument, ExternalObservation, and External Procedure.

5.3.8.5.1 ExternalAct

The ExternalAct is a derivative of the RIM Act class, to be used when the other more specific classes are not appropriate.

Table X: ExternalAct Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	<= ACT is V:ActClassRoot	Closed w/ Default
moodCode	CS	[0..1]	EVN	Fixed
id	II	[1..*]
code	CD	[0..1]	D:ActCode	Open
text	ED	[0..1]

ExternalAct.classCode

The ExternalAct.classCode is bound to the ActClassRoot value set.

Table X: Value set for ExternalAct.classCode

V:ActClassRoot [2.16.840.1.113883.1.11.13856] (CLOSED)
Code	Display Name		Code	Display Name
ACT (Default)	act		COMPOSITION	composition, Attestable unit
DOC	document		DOCCLIN	clinical document
CDALVLONE	CDA Level One clinical document		CONTAINER	record container
CATEGORY	category		DOCBODY	document body
CATEGORY	document section, Section		TOPIC	topic
EXTRACT	extract		EHR	electronic health record
FOLDER	folder		GROUPER	grouper
CLUSTER	Cluster		ACCM	accommodation
ACCT	account		ACSN	accession
ADJUD	financial adjudication, financial adjudication results		CACT	control act
ACTN	action		INFO	information
STC	state transition control		CNTRCT	contract
FCNTRCT	financial contract		COV	coverage
CONS	consent		CONTREG	container registration
CTTEVENT	clinical trial timepoint event		DISPACT	disciplinary action
EXPOS	exposure		AEXPOS	acquisition exposure
TEXPOS	transmission exposure		INC	incident
INFRM	inform		INVE	invoice element
LIST	working list		MPROT	monitoring program
OBS	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		PCPR	care provision
ENC	encounter		POLICY	policy
JURISPOL	jurisdictional policy		ORGPOL	organizational policy
SCOPOL	scope of practice policy		STDPOL	standard of practice policy
PROC	procedure		SBEXT	Substance Extraction
SPECCOLLECT	Specimen Collection		SBADM	substance administration
REG	registration		REV	review
SPCTRT	specimen treatment		SPLY	supply
DIET	diet		STORE	storage
SUBST	Substitution		TRFR	transfer
TRNS	transportation		XACT	financial transaction
CNOD (Deprecated)	Condition Node		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ExternalAct.moodCode

The ExternalAct.moodCode is fixed to "EVN" which represents the event mood. Indicating that the act has taken place and this is information about that act.

Table X: Fixed ExternalAct.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ExternalAct.id

The unique instance identifier for the ExternalAct.

ExternalAct.code

The particular kind of Act that the Act-instance represents within its class. ExternalAct.code, if used, SHALL be a specialization of the ExternalAct.classCode. This attribute defines a specific sub-type of a given Act type (determined by the "classCode" attribute). It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the limited set of Act types defined by "classCode." The ExternalAct.code is bound to the ActCode concept domain.

ExternalAct.text

A reference to a renderable textual or multimedia description of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the ExternalAct.

5.3.8.5.2 ExternalDocument

The ExternalDocument is a derivative of the RIM Document class, used for representing external documents. ExternalDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the external document.

Table X: ExternalDocument Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	<=DOC is V:ActClassDocument	Closed w/ Default
moodCode	CS	[0..1]	EVN	Fixed
typeId	II	[1..1]
id	II	[1..*]
code	CE	[1..1]	D:DocumentType	Open
text	ED	[0..1]
setId	II	[0..1]
versionNumber	ST	[0..1]

ExternalDocument.classCode

The ExternalDocument.classCode is fixed to "DOCCLIN"

Table X: Fixed ExternalDocument.classCode

V:ActClassDocument [2.16.840.1.113883.1.11.18938] (CLOSED)
Code	Display Name		Code	Display Name
DOC(Default)	document		DOCCLIN||clinical document
CDALVLONE	CDA Level One clinical document
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ExternalDocument..moodCode

The ExternalDocument.moodCode is fixed to "EVN" which represents the event mood. Indicating that the document has been created and is available.

Table X: Fixed ExternalDocument.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ExternalDocument.id

The unique instance identifier for the ExternalDocument.

ExternalDocument.code

The ExternalDocument.code is bound to the DocumentType concept domain.

ExternalDocument.text

A reference to the external document.

ExternalDocument.setId

The ExternalDocument.setId is an optional identifier that does not change with revisions to a document.

ExternalDocument.versionNumber

A string used to represent the version of the document. For CDA R2.1 we use the ST data type as defined in the r2b datatypes. We have adopted, for all versionNumber references in CDA R2.1, this data type because it supports an @value attribute, and can support wire format compatibility with the versionNumber in CDA R2.0.

5.3.8.5.3 ExternalObservation

The ExternalObservation is a derivative of the RIM Observation class, used for representing external coded and other observations.

Table X: ExternalObservation Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	<= OBS is V:ActClassObservation	Closed w/ Default
moodCode	CS	[0..1]	EVN	Fixed
id	II	[1..*]
code	CD	[0..1]	D:ActCode	Open
text	ED	[0..1]

ExternalObservation.classCode

The ExternalObservation.classCode is defaulted to "OBS" in indicate an observation, but be be set to any code in the ActCode concept domain.

Table X: Value set for ExternalObservation.classCode

V:ActClassObservation [2.16.840.1.113883.1.11.11529] (CLOSED)
Code	Display Name		Code	Display Name
OBS (Default)	Observation		ALRT	detected issue
BATTERY	battery		CLNTRL	clinical trial
CONC	concern		COND	Condition
CASE	public health case		OUTB	outbreak
DGIMG	diagnostic image		GEN	genomic observation
DETPOL	determinant peptide		EXP	expression level
LOC	locus		PHN	phenotype
POL	polypeptide		SEQ	bio sequence
SEQVAR	bio sequence variation		INVSTG	investigation
OBSSER	observation series		OBSCOR	correlated observation sequences
POS	position		POSACC	position accuracy
POSCOORD	position coordinate		SPCOBS	specimen observation
VERIF	Verification		ROIBND	bounded ROI
ROIOVL	overlay ROI		LLD (Deprecated)	left lateral decubitus
PRN (Deprecated)	prone		RLD (Deprecated)	right lateral decubitus
SFWL (Deprecated)	Semi-Fowler's		SIT (Deprecated)	sitting
STN (Deprecated)	standing		SUP (Deprecated)	supine
RTRD (Deprecated)	reverse trendelenburg		TRD (Deprecated)	trendelenburg
CNOD (Deprecated)	Condition Node
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ExternalObservation.moodCode

The ExternalObservation.moodCode is fixed to "EVN" which represents the event mood. Indicating that the observation has taken place and this is information about that observation.

Table X: Fixed ExternalObservation.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ExternalObservation.id

The unique instance identifier for the ExternalObservation.

ExternalObservation.code

The particular kind of observation that the observation-instance represents within its class. ExternalObservation.code, if used, SHALL be a specialization of the ExternalObservation.classCode. This attribute defines a specific sub-type of a given Observation type (determined by the "classCode" attribute). It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the limited set of observation types defined by "classCode." The ExternalObservation.code is bound to the ActCode concept domain.

ExternalObservation.text

A reference to a renderable textual or multimedia description of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the ExternalObservation.

5.3.8.5.4 ExternalProcedure

The ExternalProcedure is a derivative of the RIM Procedure class, used for representing external procedures.

Table X: ExternalProcedure Attributes

Attribute Name	Data Type	Cardinality	Code Binding	Binding Type
classCode	CS	[0..1]	PROC	Fixed
moodCode	CS	[0..1]	EVN	Fixed
id	II	[1..*]
code	CD	[0..1]	D:ActCode	Open
text	ED	[0..1]

ExternalProcedure.classCode

The ExternalProcedure.classCode is fixed to "PROC".

Table X: Fixed ExternalProcedure.classCode

Code	Display Name
PROC	procedure
Code System: ActClass (HL7) Code System OID: 2.16.840.1.113883.5.6

ExternalProcedure.moodCode

The ExternalProcedure.moodCode is fixed to "EVN" which represents the event mood. Indicating that the procedure has taken place and this is information about that procedure.

Table X: Fixed ExternalProcedure.moodCode

Code	Display Name
EVN	event
Code System: ActMood (HL7) Code System OID: 2.16.840.1.113883.5.1001

ExternalProcedure.id

The unique instance identifier for the ExternalProcedure.

ExternalProcedure.code

The particular kind of procedure that the procedure-instance represents within its class. ExternalProcedure.code, if used, SHALL be a specialization of the ExternalProcedure.classCode. This attribute defines a specific sub-type of a given Procedure type (determined by the "classCode" attribute). It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the limited set of Procedure types defined by "classCode." The ExternalProcedure.code is bound to the ActCode concept domain.

ExternalProcedure.text

A reference to a renderable textual or multimedia description of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the ExternalProcedure.

5.4 CDA Context

CDA context is set in the CDA header and applies to the entire document. Context can be overridden at the level of the body, section, and/or CDA entry.

5.4.1 Overview of CDA Context

A document, in a sense, is a contextual wrapper for its contents. Assertions in the document header are typically applicable to statements made in the body of the document, unless overridden. For instance, the patient identified in the header is assumed to be the subject of observations described in the body of the document, unless a different subject is explicitly stated, or the author identified in the header is assumed to be the author of the entire document, unless a different author is explicitly identified on a section. The objective of the CDA context rules are to make these practices explicit with relationship to the RIM, such that a computer will understand the context of a portion of a document the same way that a human interprets it.

At the same time, there is no guarantee that machine processing will identify a mistaken application of contextual rules. If a physician records an "outside diagnosis" in narrative but does not nullify the "informant" context, machine processing will not identify the switch in attribution. This is a special case illustrating the limits of automated validation of electronic records and would apply regardless of the context inheritance mechanism. In other words, from some errors of encoding, there is no recovery other than human review.

CDA's approach to context, and the propagation of that context to nested document components, follows these design principles:

• CDA uses the RIM context mechanism (contextControlCode for Participations; contextConductionInd for ActRelationships), and assigns fixed values to these attributes to accomplish the design objectives below, thus constraining the RIM context model. CDA extends the context propagation property to designated attributes of the CDA Header, which also propagate through any ActRelationship for which contextConductionInd="true".
• The CDA Header sets context for the entire document. A propagating value specified in the document header holds true throughout the document, unless explicitly overridden. This principal applies to both Participations and to designated attributes of the CDA Header. Contextual header components (i.e., those that have propagating values) include:
  • Author
  • Confidentiality
  • Data enterer
  • Human language
  • Informant
  • Legal authenticator
  • Participant
  • Record target
• Context components that can be overridden at the level of the document body include:
  • Confidentiality
  • Human language
• Context components that can be overridden at the level of a document section include:
  • Author
  • Confidentiality
  • Human language
  • Informant
  • Subject
• Context components that can be overridden at the level of a CDA entry include:
  • Author
  • Human language
  • Informant
  • Participant
  • Subject
• Context propagates from outer tags to nested tags. Context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides context propagated from an outer tag. For instance, the specification of authorship at a document section level overrides all authorship propagated from outer tags.
• Context is sometimes known precisely, and is sometimes unknown, such as in the case where a document is comprised of a large unparsed narrative block that potentially includes statements that contradict outer context. Because CDA context always propagates unless overridden, the representation of unknown context is achieved by overriding with a null value.

5.4.2 Technical Aspects of CDA Context

The RIM defines the "context" of an act as those participants of the act that can be propagated to nested acts. In the RIM, whether or not contextual participants do propagate to nested acts depends on whether or not the intervening act relationship between parent and child act allows for conduction of context. The explicit representation of context, and whether or not the context on an act can propagate to nested acts, is expressed via the RIM attributes Participation.contextControlCode and ActRelationship.contextConductionInd. CDA constrains the general RIM context mechanism such that context always overrides and propagates, as shown in the following table.

Table X: CDA constraints on RIM context attributes

RIM attribute	Cardinality	Conformance	Fixed Value
Participation.contextControlCode	1..1	Mandatory (NULL values not permitted)	"OP" (overriding, propagating)
ActRelationship.contextConductionInd	1..1	Mandatory (NULL values not permitted)	"true"*

*The one exception to this is entryRelationship.contextConductionInd, which is defaulted to "true", but can be changed to "false". See entryRelationship for details.

Where the context of a nested component is unknown, the propagated context must be overridden with a null-valued component, as shown in the following table.

Table X: Blocking context propagation with null values

Context	Null value representation
Author	AssignedAuthor.id = NULL; No playing entity; No scoping entity.
Confidentiality	confidentialityCode = NULL.
Human language	languageCode = NULL.
Informant	AssignedEntity.id = NULL; No playing entity; No scoping entity.
Participant	ParticipantRole.id = NULL; No playing entity; No scoping entity.

The following exhibit illustrates the CDA context model. ClinicalDocument has an author participant, a confidentialityCode, and a languageCode, all of which will propagate to nested acts. The component act relationship going from ClinicalDocument to bodyChoice has contextConductionInd fixed as "true", thus allowing for the propagation of context. The bodyChoice classes, NonXMLBody and StructuredBody, contain a confidentialityCode and languageCode which can be used to override the value specified in the header. The component act relationship going from StructuredBody to Section has contextConductionInd fixed at "true", thus the context on StructuredBody will propagate through to Section. Section can override confidentialityCode, languageCode, and author. A null value for the Section's author participant indicates that the author for that particular section is unknown.

Link to wide graphic (opens in a new window)

Because context is always overriding and propagating, one can compute the context of a given node by looking for the most proximate assertion. The following example is a sample XPath expression that can be used to identify the <author> context of a section or entry:

Example X

(ancestor-or-self::*/author)[position()=last()]

5.4.3 InfrastructureRoot & CDA Classes

All of CDA classes inherits 1 attribute and 3 element from InfrastructureRoot. Infrastructure Root provides a set of infrastructure attributes that may be used in instances of HL7-specified, RIM-based classes. When valued in an instance, these attributes indicate whether the information structure is being constrained by specifically defined templates, realms or common element types.

• An optional nullFlavor attribute has been added to each CDA class. When the class is null, this code can be used to indicate the flavor of null that is intended.

The following 3 optional elements have been added at the beginning of each CDA class:

• realmCode, is vocabulary domain qualifier that allows the vocabulary domain of coded attributes to be specialized according to the geographical, organizational, or political environment where the HL7 standard is being used. It is defined as a SET<CS>data type.
• typeId, is a unique identifier for an HL7 static structure that imposes constraints on an artifact. In CDA it must be defined at the root element, to indicate a CDA R2.1 document,with ClinicalDocument.typeId.root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models); ClinicalDocument.typeId.extension = "POCD_HD000040UV02" (which is the unique identifier for the CDA, Release Two Hierarchical Description). As CMETs are not used in CDA, this element will not be used in other classes. It is defined as a II data type.
• templateId, is an optional unique identifier, which indicates to a receiver that a set of constraints have been defined for a given class and it's attributes. See section 4 on templates in CDA.

6 CDA Hierarchical Description

NOTE: The definitive description of HL7 Hierarchical Description development and interpretation can be found here.

The CDA Hierarchical Description POCD_HD000040UV02 as an Excel View can be found here.

The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description, and to the rules expressed in the narrative of this specification.

HL7 enables conformance specification at the level of each RIM attribute. RIM attributes can be defined as "Required", in which case the originator must populate the attribute where a value is known even if the cardinality is optional, and "Mandatory", in which case the originator must populate the attribute with a non-NULL value in all cases.

In CDA R2.1, Release 2.35, the "Required" and "Mandatory" conformance indicators are applied as follows:

• Required attributes:
  • Section.text
  • All attributes where lower cardinality is greater than 0.
• Mandatory attributes:
  • ClinicalDocument.typeId
  • RIM Structural Attributes
    • ClassCode
    • MoodCode
    • TypeCode
    • DeterminerCode
  • Context attributes
    • contextControlCode
    • ContextConductionInd

Note: Note that where Mandatory attributes have a default or fixed value supplied in the CDA HD, the instance need not contain a value. In such cases, the receiver must assume the default value.

7 CDA XML Implementation

Note: The definitive description of HL7 XML Implementation Technology Specification and the process used to go from Hierarchical Description to Schema can be found here.

The CDA Schema can be found here

The Datatypes.xsd file can be found here

Datatypes-base.xsd file can be found here

POCD_MT000040UV02.xsd file can be found here

CDA Narrative Block schema can be found here.

voc.xsd file can be found here.

The CDA Schema is not itself a normative artifact. Rather, checking an instance against the CDA Schema is a surrogate for validating conformance against the normative XML ITS. An instance which validates against the CDA Schema might still not be a conformant CDA according to this Standard.

The CDA Narrative Block, which is the XML content model of section.text, is manually crafted, as described above (see Section Narrative Block). Note that while the CDA Schema is not a normative artifact, the CDA Narrative Block schema is.

8 Appendix A. Samples

8.1 Sample Document

This file is not included in the wiki form of the CDA standard.

8.2 Sample CDA Instance

This is a valid and conformant CDA instance based on the sample document above.

NOTE: Readers should be aware of the evolving "Using SNOMED CT in HL7 Version 3" implementation guide, currently in a draft state. The guide, co-developed by HL7 and the College of American Pathologists, will be balloted by HL7 as an Informative Document. Recommendations in the final published guide should usurp patterns of SNOMED CT usage found in this sample instance

Open the Sample File

8.3 Sample CDA Style Sheet

This is a sample CDA XSLT style sheet that can be used to transform a CDA instance into HTML. It is provided as a convenient starting point for local style sheet development, and has several known limitations, including:

• Local implementations may have different requirements for rendering the CDA header.
• Does not support RegionOfInterest rendering.
• Does not support rendering of inline multimedia (e.g. multimedia that is Base 64 encoded within the CDA document).
• Does not support rendering of deleted text within the CDA Narrative Block.

Open the Sample Style Sheet

9 Appendix B. Implementation Notes

9.1 Creating CDA Documents

Introduction

There are an ever-increasing variety of tools and techniques for creating CDA documents:

1. Transcription: most clinical documents are created through a voice interface. CDA is available as an output from transcription vendors large and small today. Some are integrating natural language processing to provide coded structures within dictated CDAs.
2. EMR/EHR: many electronic medical record vendors have CDA output capability, although they provide it on-demand, not as a standard feature. For EMRs, CDA is relatively simple type of report.
3. XML forms: a new generation of XML tools for forms generation can create CDA on output.
4. Knowledge base: at least one major US provider has built a CDA editor on top of a knowledge base for guided, structured entry.
5. Dynamic query: dynamic assembly of CDA documents is used in some distributed applications to prepopulate documents from existing data stores, such as laboratory result databases. This method can be used in conjunction with any of the others.

This appendix considers not the specific tools and technologies, but is intended as a general guide to use of CDA in document creation.

Before you start: RIM compliance

• structures, vocabulary, datatypes

Creating a CDA-compliant instance, by definition, means that the information contained within is defined by the HL7 RIM. Regardless of your starting point or method of document generation, when you are done, the computable semantics of the document will derive their meaning from the relationship between RIM classes, controlled vocabulary and the V3 RIM datatypes. Any CDA-generation implementation must start with an examination of how document requirements relate to the RIM, the datatypes and vocabulary.

The RIM, however, is a highly abstract model and recognizes many extensive vocabulary domains. While RIM-mapping is a necessary condition for CDA generation, it is not sufficient to determine the method of generation or to drive a user interface for document creation.

An exchange specification, not an authoring specification

• CDA is not deterministic for document creation

CDA is a specification for the exchange form of a clinical document. A CDA schema can validate many of the conformance requirements, but will be too general for most authoring applications. In general, standards for interoperability and broadbased exchange will not directly drive an authoring GUI. Given the extent of the CDA domain – clinical care – the requirements for generalized exchange overlap with, but don’t match, the requirements for driving an authoring interface.

For example, the CDA requirement for human readability demands that a single stylesheet render the authenticated clinical content of any CDA document. If CDA elements were defined in the generic schema that corresponds to the sections of a document, <historyOfPresentIllness> or <Subjective>, for example, a stylesheet would need to recognize each of these tags as section-level tags and render them accordingly. The CDA approach, defining <section> and asserting the type of section through coded vocabulary means that not only is the CDA extensible through the externally-maintained vocabulary domains, but that document designers have the flexibility to create hierarchies of sections and to name and tag them according to local requirements, while maintaining compatibility for the exchange context. Thus, while specific tagging that makes it easier to drive a GUI is fine locally, where practice can be more tightly constrained, CDA needs to take a more general approach.

Both sets of requirements, for authoring and for exchange, should be recognized. Within a defined community of interest, such as a single business enterprise, a professional society or in some cases, local and regional health authorities, there can be tight agreement on the form of a document so that the authoring definitions and the exchange definitions coincide. Unless and until there is universal agreement, there can be no universal exchange unless the diversity of local requirements is acknowledged. This is a long-winded way of saying that CDA will remain a general exchange standard, and other approaches must be available to define data entry and document creation validation requirements.

General approaches: constrain or transform

• constrain: emit valid CDA directly from the authoring system using a schema that isn’t CDA
• transform: example - emit local XML, map to CDA

Given that CDA is not an authoring schema, there are two logical alternatives to creating valid CDA instances.

The first is to add constraints to the CDA schema so that the resulting specification defines a particular document type (see the following exhibit "Creating a CDA through a local schema"). There are several technologies available for adding constraints. One approach is to modify the CDA schema itself to a local variant (local.cda.xsd below). Modifications could include limiting the levels of nesting; constraining vocabulary and sequence, for example requiring that a section with a LOINC code for "Subjective" initiate the document body and be followed by a section coded "Objective". These modifications could be expressed in W3C Schema or as Xpath statements within the local schema. Instances that validate against this constrained, local version of CDA are, by definition, also valid CDA instances.

Link to wide graphic (opens in a new window)

Templates are one type of constraint. HL7 is in the process of defining a formal template mechanism (see The "A" in "CDA").

The second approach is to create a local schema and then transform the local XML instance to CDA

Link to wide graphic (opens in a new window)

9.2 LOINC Document Codes

The number of active document codes available from LOINC, version 2.61, June 23, 2017 for CDA R2.1, equal 8,532. They equals the subset of LOINC codes, whose scale = "DOC" (and whose status <> "DEL"). Refer to Chapter 6 LOINC Document Ontology in the LOINC Users' Guide for more details on document ontology created to support document coding in CDA.

9.3 CDA and Semantic Interoperability

A long term objective of CDA and other specifications in the V3 family is to achieve increasingly greater and greater "semantic interoperability", which might be defined as the ability of two applications to share data, with no prior negotiations, such that decision support within each application continues to function reliably when processed against the received data.

CDA seeks to achieve the highest level of constraint that can exist in an international standard. Where international consensus is lacking, and where uses cases in different realms currently preclude consensus, CDA will need to be necessarily inclusive. In such areas, ongoing harmonization and consensus building will further enable semantic interopability, which will be reflected in future iterations of CDA.

While the framework provided by the RIM and by CDA and by the shared HL7 Clinical Statement Model are a critical component of semantic interoperability, they are not currently sufficient, particularly given the lack of global terminology solution, and the fact that each terminology overlaps with the RIM in different ways. Such terminology solutions are outside the scope of CDA, and will need to be addressed in various national and international forums.

9.4 Changes from CDA Release 1

CDA, Release One became an ANSI-approved HL7 Standard in November, 2000, representing the first specification derived from the HL7 Reference Information Model (RIM). Since then, the RIM has matured, as has the methodology used to derive RIM-based specifications. In addition, early adopters are posing new use cases for incorporation.

The basic model of CDA, Release Two is essentially unchanged. A CDA document has a header and a body. The body contains nested sections. These sections can be coded using standard vocabularies, and can contain "entries". CDA, Release One entries included such things as character data, hyperlinks, and multimedia.

The main evolutionary steps in CDA, Release Two are that both header and body are fully RIM-derived, and there is a much richer assortment of entries to use within CDA sections. CDA, Release Two enables clinical content to be formally expressed to the extent that is it modeled in the RIM.

CDA, Release Two takes advantage of HL7’s growing expertise in creating model-based XML standards. Given the evolution of the RIM and the HL7 development methodology since November 2000, there are a number of changes between the new and the old CDA.

9.4.1 Deprecated Components

The following components are retained for backwards compatibility with CDA, Release One, and have been deprecated:

• ClinicalDocument/copyTime.
• ClinicalDocument/assignedAuthor/assignedAuthoringDevice/MaintainedEntity.
• ClinicalDocument/recordTarget/patientRole/patient/id.
• linkHtml.name.
• table.border, table.cellspacing, table.cellpadding.

Further use of these components is discouraged.

9.4.2 CDA R2.0 to CDA R2.1 Correspondence

A number of new attributes have been added to classes in CDA R2.1. The CDA_Changes.xlsx file identifies those and a number of other changes that have been made to the CDA R2.1 standard.