ANSI/HL7 CDA, R2-2005 HL7 Clinical Document Architecture, Release 2 4/21/2005 |
| Chair/Editor | Robert H. Dolin, MD<EMAIL_ADDRESS>Kaiser Permanente |
| Chair/Editor | Liora Alschuler<EMAIL_ADDRESS>alschuler.spinosa |
| Chair/Editor | Sandy Boyer, BSP<EMAIL_ADDRESS>Consultant |
| Chair/Editor | Calvin Beebe<EMAIL_ADDRESS>Mayo Clinic |
| Editor | Fred M. Behlen, PhD<EMAIL_ADDRESS>American College of Radiology |
| Editor | Paul V. Biron<EMAIL_ADDRESS>Kaiser Permanente |
| Editor | Amnon Shabo (Shvo), PhD<EMAIL_ADDRESS>IBM Research Lab in Haifa |
Last Published: 06/18/2008 11:47 AM
HL7® Version 3 Standard, © 2008 Health Level Seven®, Inc. All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off
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 a documentation of clinical observations and services, with the following characteristics:
A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.
Key aspects of the CDA include:
The scope of the CDA is the standardization of clinical documents for exchange.
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 in HL7 messages designed to transfer clinical documents. While the detailed specification for such messages is outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in HL7 messages (see CDA Document Exchange in HL7 Messages (§ 3 )).
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 Schema 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 (§ 1.2.6 )).
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.
The goals of the CDA are:
A number of design principles follow from consideration of the above goals:
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 (§ A ) for a detailed conformant example).
A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see Header (§ 4.2 )) and a body (see Body (§ 4.3 )). 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.
The body contains the clinical report, and can be either an unstructured blob, 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 document sections.
A CDA document section is wrapped by the <section> element. Each section can contain a single narrative block (see Section Narrative Block (§ 4.3.5 )), and any number of CDA entries (see Entry Acts (§ 4.3.6 )) 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. See also Human Readability and Rendering CDA Documents (§ 1.2.3 ) and CDA Conformance (§ 1.3 ) 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 they can reference external objects. CDA external references always occur within the context of a CDA entry. 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.
<ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument> |
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 (§ 1.1.3 )). This hierarchy formed an "architecture", hence the "A" in "CDA".
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.
NOTE: The CDA can be constrained by mechanisms defined in HL7 V3 Refinement and Localization. HL7 technical formalisms (e.g. HL7 Template specifications, HL7 Model Interchange Format) to constrain CDA are still in development at the time of writing this standard.
The RIM's InfrastructureRoot class contains an attribute, templateId, which is available for use in CDA. Thus, while HL7 Templates are in flux at this time, CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. Until there is a formal HL7 Template specification, there is no standardized process to test conformance against referenced templates.
There is no requirement that CDA must be constrained. Implementations that use structured data elements to drive automated processes will typically require that they be either: (1) constrained by an appropriately refined model or other HL7 approved constraint language; or (2) comply with a detailed implementation guide that details the manner in which structured elements are to be represented and their intended interpretation to a level sufficient to ensure a degree of clinical safety that is appropriate to the use case that it is designed to address.
There are many kinds of HL7 Templates that might be created. Among them, two are particularly relevant for clinical documents: (1) those that constrain the document sections based on the type of document (section-level templates); (2) those that constrain the entries within document sections (entry-level templates). In fact, a comparison can be made between the prior notion of CDA levels and the current notion of CDA with these two kinds of HL7 Templates:
An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here:
|
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 Two, with its blend of narrative and CDA entries, presents new challenges to this requirement.
Among the requirements affecting the design of CDA Release 2 are the following:
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 (§ 4.3.5 )). 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.
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 (§ 1.3 )). 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:
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.
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.
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 (§ 3 )). Thus, the CDA complements HL7 messaging specifications.
Clinical documents can be revised, and they can be appended to existing documents. Ideally, an updated document would declare itself as obsolete, and would contain an explicit pointer to a more recent version. This would lessen the chances of a healthcare provider basing treatment decisions on erroneous or incomplete data.
In practice, however, it is impossible to guarantee 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.
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 (§ 1.2.6 )), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see custodian (§ <IP_ADDRESS> )) is the participant charged with maintaining the original document, which may be in some form other than CDA.
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 meaning that is not shared. 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.
NOTE: A detailed list of all changes between CDA, Release One and CDA, Release Two can be found in the appendix (see Changes from CDA Release 1 (§ B.4 )).
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 CDA entries. 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 it is modeled in the RIM.
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 (either to tighten or to loosen); or a change in a vocabulary domain of a component (to add or change values, to change between CWE and 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.
These guiding principles have lead to the current approach, defined in this Release Two of the CDA standard. The goal is to ensure that the documents created using Release One can be transformed into minimally compliant Release Two instances and that Release Two documents received can be down-translated to Release One instances using automated means (transformations) with no loss of attested, human-readable content and known limitation on loss of universal processing semantics.
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.
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 HL7 RIM, Version 2.07.
Where a reader needs to see the complete definition of a RIM attribute or class, they should refer to the HL7 RIM.
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.
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. While CDA may further constrain these definitions, at no time will CDA definitions conflict with those in the Vocabulary chapter.
Vocabulary domains have a coding strength that can be "Coded, No Extensions" (CNE), in which case the only allowable values for the CDA component are those in stated value set; or "Coded, With Extensions" (CWE), 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 CNE value set, the allowable values are fixed by the standard, and are enumerated as shown in the following example:
| Code | Definition |
|---|---|
|
APND (append) |
The current document is an addendum to the ParentDocument. |
|
RPLC (replace) |
The current document is a replacement of the ParentDocument. |
|
XFRM (transform) |
The current document is a transformation of the ParentDocument. |
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 a CWE 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.
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 (§ 4 )).
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.
The definitive description of developing and interpreting HL7 Hierarchical Descriptions can be found here.
The CDA HD is described below (see CDA Hierarchical Description (§ 5 )).
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 Two, the CDA HD is uniquely identified by the string "POCD_HD000040". As described below (see Clinical Document (§ 4.1 )), this value must be included in a CDA instance to serve as an unambiguous reference to the CDA, Release Two specification.
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 (§ 6 )).
CDA, Release Two 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 (§ 6 ).
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.
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:
From the perspective of a V2.x or V3 message, 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.
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.
| 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.
MSH|... EVN|... PID|... PV1|... TXA|... OBX|1|ED|11492-6^History and Physical^LN|| ^multipart^related^A^ 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-- ... |
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.
| 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.
<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> |
NOTE: The definitive description of HL7 V3 model refinement, R-MIM development and interpretation can be found here.
The CDA R-MIM POCD_RM000040 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.
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.
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.
The ClinicalDocument class inherits various attributes from the InfrastructureRoot class of the RIM, including ClinicalDocument.templateId and ClinicalDocument.typeId. When ClinicalDocument.templateId is valued in an instance, it signals the imposition of a set of template-defined constraints. In addition, the templateId attribute is available in all other CDA classes, thus enabling the imposition of a set of template-defined constraints at any level of granularity. The value of this attribute provides a unique identifier for the template(s) in question.
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_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).
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.
This section describes attributes of the root ClinicalDocument class.
| Code | Definition |
|---|---|
|
DOCCLIN [default] |
A clinical document is a documentation of clinical observations and services, as defined above. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event (i.e., the documentation act already happened and is not just a request, intent, plan or promise to document). |
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 included in the appendix (see LOINC Document Codes (§ B.2 )).
NOTE: The hierarchical relationship among LOINC document codes is in evolution. Per the LOINC version 2.14 (December 2004) manual: As soon as possible, the component terms used in the creation of the names of document type codes will be mapped to either the UMLS Metathesaurus or SNOMED CT. This mapping will help to establish the meaning of the terms and will allow aggregation and classification of document type codes based on definitions, computable relationships, and subsumption hierarchies that exist in the reference terminology.
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 (§ A.1 )), the value of ClinicalDocument.title = "Good Health Clinic Consultation Note".
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 is created. The time when the transform occurred is not currently represented in CDA.
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 (§ 4.4 )).
| Code * | Definition |
|---|---|
|
N (normal) (codeSystem 2.16.840.1.113883.5.25) |
Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or business need may access this item. |
|
R (restricted) (codeSystem 2.16.840.1.113883.5.25) |
Restricted access, e.g. only to providers having a current care relationship to the patient. |
|
V (very restricted) (codeSystem 2.16.840.1.113883.5.25) |
Very restricted access as declared by the Privacy Officer of the record holder. |
* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.
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 (§ 4.4 )).
Represents an identifier that is common across all document revisions.
An integer value used to version successive replacement documents.
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.
This section describes classes related to the root ClinicalDocument class via a Participation.
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 (§ <IP_ADDRESS> ))
A clinical document can have zero to many authenticators. While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. An authenticator has a required authenticator.time indicating the time of authentication, and a required authenticator.signatureCode, indicating that a signature has been obtained and is on file.
| Code | Definition |
|---|---|
|
AUTHEN (authenticator) [default] |
A verifier who attests to the accuracy of an act, but who does not have privileges to legally authenticate the act. |
| Code | Definition |
|---|---|
|
S (signed) |
Signature has been affixed and is on file. |
|
X (required) (Deprecated) |
CDA Release One represented either an intended ("X") or actual ("S") authenticator. CDA Release Two only represents an actual authenticator, so has deprecated the value of "X". |
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.)
| Code | Definition |
|---|---|
|
ASSIGNED (Assigned) [default] |
An agent role in which the agent is an entity acting in the employ of an organization. The focus is on the functional role on behalf of the organization. |
| Code | Definition |
|---|---|
| PSN (person) [default] | A living subject of the species homo sapiens. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
| Code | Definition |
|---|---|
|
ORG (organization) [default] |
A social or legal structure formed by human beings. |
| Code | Definition |
|---|---|
|
INSTANCE (Assigned) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
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"). 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.
| Code | Definition |
|---|---|
|
PART (part) [default] |
An association between two Entities where the playing Entity is part of the scoping entity. |
| Code | Definition |
|---|---|
|
normal (normal) |
The 'typical' state. Excludes "nullified" which represents the termination state of a Role instance that was created in error. |
|
active (active) |
The state representing the fact that the Entity is currently active in the Role. |
|
cancelled (cancelled) |
The terminal state resulting from cancellation of the role prior to activation. |
|
pending (pending) |
The state representing that fact that the role has not yet become active. |
|
suspended (suspended) |
The state that represents a suspension of the Entity playing the Role. This state is arrived at from the "active" state. |
|
terminated (terminated) |
The state representing the successful termination of the Role. |
|
nullified (nullified) |
The state representing the termination of a Role instance that was created in error. |
Represents the humans and/or machines that authored the document.
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.
| Code | Definition |
|---|---|
|
AUT (author) [default] |
A party that originates the Act and therefore has responsibility for the information given in the Act. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
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.
| Code | Definition |
|---|---|
|
ASSIGNED (assigned entity) [default] |
A role in which the playing entity is acting in the employ of or on behalf of a scoping organization. |
| Code | Definition |
|---|---|
|
DEV (device) [default] |
An entity used in an activity, without being substantially changed through that activity. |
| Code | Definition |
|---|---|
|
INSTANCE (Assigned) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
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.
| Code | Definition |
|---|---|
|
MNT (maintained entity) [default] |
An entity that is maintained by another entity. This is typically a role held by durable equipment. The scoper assumes responsibility for proper operation, quality, and safety. |
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 (§ 1.1 )). 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.
| Code | Definition |
|---|---|
|
CST (custodian) [default] |
An organization that is in charge of maintaining this document. |
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.
| Code | Definition |
|---|---|
|
ASSIGNED (assigned entity) [default] |
A role in which the playing entity is acting in the employ of or on behalf of a scoping organization. |
| Code | Definition |
|---|---|
|
ORG (organization) [default] |
A social or legal structure formed by human beings. |
| Code | Definition |
|---|---|
|
INSTANCE (Assigned) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
Represents the participant who has transformed a dictated note into text.
| Code | Definition |
|---|---|
|
ENT (transcriptionist) [default] |
A person entering the data into the originating system. The data entry person is collected optionally for internal quality control purposes. This includes the transcriptionist for dictated text. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
See EncompassingEncounter (§ <IP_ADDRESS> ) for a description of the encounterParticipant participant.
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.
| Code | Definition |
|---|---|
|
INF (informant) [default] |
A source of reported information (e.g., a next of kin who answers questions about the patient's history). For history questions, unless otherwise stated, the patient is implicitly the informant. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
An informant can be a person in one of two roles. 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. The AssignedEntity role is used for an identified informant, and is scoped by an Organization.
| Code | Definition |
|---|---|
|
Any subtype of RoleClassMutualRelationship |
A role of an entity that has some mutual relationship with the patient. The basis of such relationship may be agreements (e.g., spouses, contract parties) or they may be de facto behavior (e.g. friends) or may be an incidental involvement with each other (e.g. parties over a dispute, siblings, children). See vocabulary domain "RoleClassMutualRelationship" for allowable values. |
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 outside the scope of CDA.
| Code | Definition |
|---|---|
|
PRCP (primary recipient) [default] |
Recipient to whom the document is primarily directed. |
|
TRC (secondary recipient) |
A secondary recipient to whom the document is directed. |
Where a person is the intended recipient (IntendedRecipient class), 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).
| Code | Definition |
|---|---|
|
ASSIGNED (assigned entity) [default] |
A role in which the playing entity is acting in the employ of or on behalf of a scoping organization. |
|
HLTHCHRT (health chart) |
A role in which the playing entity is a physical health chart belonging to the scoping organization. |
Represents a participant who has legally authenticated the document.
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).
While electronic signatures are not captured in a CDA document, 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.
| Code | Definition |
|---|---|
|
LA (legal authenticator) [default] |
A verifier who legally authenticates the accuracy of an act. An example would be a staff physician who sees a patient and dictates a note, then later signs it. Their signature constitutes a legal authentication. |
| Code | Definition |
|---|---|
|
S (signed) |
Signature has been affixed and is on file. |
|
X (required) (Deprecated) |
CDA Release One represented either an intended ("X") or actual ("S") legal authenticator. CDA Release Two only represents an actual legal authenticator, so has deprecated the value of "X". |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
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).
Used to represent other participants not explicitly mentioned by other classes, that were somehow involved in the documented acts.
| Code | Definition |
|---|---|
|
Any ParticipationType subtype |
See vocabulary domain "ParticipationType" for allowable values. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
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).
| Code | Definition |
|---|---|
|
Any RoleClassAssociative subtype |
See vocabulary domain "RoleClassAssociative" for allowable values. |
When the participating entity is an organization, this is reflected by the presence of a scoping Organization, without a playing entity.
See ServiceEvent (§ <IP_ADDRESS> ) for a description of the performer participant.
The recordTarget represents the medical record that this 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 participants can be stated.
The recordTarget(s) of a document are stated in the header and propagate to nested content, where they cannot be overridden (see See CDA Context (§ 4.4 )).
| Code | Definition |
|---|---|
|
RCT (record target) [default] |
The record target indicates whose medical record holds the documentation of this act. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
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.
CDA Release One allowed for additional person identifiers, corresponding to the Patient.id attribute in CDA Release Two. 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.
| Code | Definition |
|---|---|
|
PAT (patient) [default] |
A person that receives health care services from a provider. |
| Code | Definition |
|---|---|
|
PSN (person) [default] |
A living subject of the species homo sapiens. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
A patient's language communication skills can be expressed in the associated LanguageCommunication class. 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).
| Code | Definition |
|---|---|
|
BIRTHPL (birthplace) [default] |
Relates a place as the location where a living subject was born. |
| Code | Definition |
|---|---|
|
PLC (place) [default] |
A physicial place or site with its containing structure. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
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).
| Code | Definition |
|---|---|
|
GUARD (guardian) [default] |
An entity (player) that acts or is authorized to act as the guardian of the patient. |
See EncompassingEncounter (§ <IP_ADDRESS> ) for a description of the responsibleParty participant.
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.
| 1. StaffPhysicianOne sees a patient as a consultant, dictates a note, and later signs it. |
|
| 2. StaffPhysicianOne sees a patient and dictates a note. StaffPhysicianTwo later signs the note. * |
|
| 3. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianOne. * |
|
|
4. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by 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. * |
|
|
6. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, which is later signed by ResidentTwo and StaffPhysicianTwo. * |
|
| 7. StaffPhysicianOne receives an abnormal lab result, attempts to contact patient but can't, and writes and signs a progress note. |
|
| 8. ResidentSurgeonOne is operating on a patient with StaffSurgeonOne. StaffSurgeonOne dictates an operative report and later signs it. |
|
* 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.
This section describes classes related to the root ClinicalDocument class via an ActRelationship.
The ParentDocument represents the source of a document revision, addenda, or transformation. 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.
Allowable values for the intervening relatedDocument.typeCode are shown in the following table.
| Code | Definition |
|---|---|
|
APND (append) |
The current document is an addendum to the ParentDocument. |
|
RPLC (replace) |
The current document is a replacement of the ParentDocument. |
|
XFRM (transform) |
The current document is a transformation of the ParentDocument. |
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.
| Code | Definition |
|---|---|
|
DOCCLIN (clinical document) [default] |
A clinical document. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
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".  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) |
This class represents the main Act, such as a colonoscopy or an appendectomy, being documented.
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" act. 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.
ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the encounter surrounding the event) took place.
| Code | Definition |
|---|---|
|
DOC (documents) [default] |
The current document is a documentation of the related ServiceEvent. |
| Code | Definition |
|---|---|
|
ACT (act) [default] |
A healthcare service. |
|
Any ACT subtype |
See vocabulary domain "ActClassRoot" for allowable values. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
The performer participant represents clinicians who actually and principally carry out the ServiceEvent. Performer.time can be used to specify the time during which the performer is involved in the activity. Performer.functionCode can be used to specify addition detail about the function of the performer (e.g. scrub nurse, third assistant). Its value set is drawn from the ParticipationFunction vocabulary domain, and has a CWE coding strength.
| Code | Definition |
|---|---|
|
PRF (performer) |
A person who actually and principally carries out an action. |
|
PPRF (primary performer) |
The principal performer of the ServiceEvent. |
|
SPRF (secondary performer) |
A person assisting in the ServiceEvent through their substantial presence and involvement. This may include assistants, technicians, associates, or other performers. |
A performer 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).
This class represents those orders 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".
| Code | Definition |
|---|---|
|
FLFS (fulfills) [default] |
The current document fulfills the order stated in ActOrder. |
| Code | Definition |
|---|---|
|
ACT (act) [default] |
A healthcare service. |
|
Any ACT subtype |
See vocabulary domain "ActClassRoot" for allowable values. |
| Code | Definition |
|---|---|
|
RQO (request) [default] |
A request or order to perform the stated act. |
This class references the consents associated with this document. 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) is conveyed in Consent.code. Consents referenced in the CDA Header have been finalized (Consent.statusCode must equal "completed") and should be on file.
| Code | Definition |
|---|---|
|
AUTH (authorized by) [default] |
The consent authorizes or certifies acts specified in the current document. |
| Code | Definition |
|---|---|
|
CONS (consent) [default] |
The Consent class represents informed consents and medico-legal transactions. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
| Code | Definition |
|---|---|
|
completed |
The consent being referenced by the CDA document has been finalized and is on file. |
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 lab result, attempts to contact the patient but can't, and writes a Progress 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.
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.).
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The current document is a documentation of events that occurred during the EncompassingEncounter. |
| Code | Definition |
|---|---|
|
ENC (encounter) [default] |
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. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
The location participant (location class) relates a healthcare facility (HealthCareFacility class) to the encounter to indicate where the encounter took place. The entity playing the role of HealthCareFacility is a place (Place class). The entity scoping the HealthCareFacility role is an organization (Organization class).
The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. Note that setting 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 location 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.
When the location is an organization, this is indicated by the presence of a scoping Organization, without a playing Place.
| Code | Definition |
|---|---|
|
LOC (location) [default] |
The location where the service is done. May be a static building (or room therein) or a moving location (e.g., ambulance, helicopter, aircraft, train, truck, ship, etc.) |
| Code | Definition |
|---|---|
|
SDLOC (service delivery location) [default] |
A role played by a place at which services may be provided. |
|
Any SDLOC (RoleClassServiceDeliveryLocation) subtype |
See vocabulary domain "RollClassServiceDeliveryLocation" for allowable values. |
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.
| Code | Definition |
|---|---|
|
RESP (responsible party) [default] |
The provider (person or organization) who has primary responsibility for the encounter. The responsible provider is not necessarily present in an encounter, but is accountable for the action through the power to delegate, and the duty to review actions with the performing participant. |
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.
The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).
| Code | Definition |
|---|---|
|
ADM (admitter) |
The practitioner who admits a patient to a hospital stay. |
|
ATND (attender) |
The primary practitioner that oversees a patient's care during an encounter. |
|
CONS (consultant) |
An advising practioner participating in the encounter by performing evaluations and making recommendations. |
|
DIS (discharger) |
The practitioner who discharges a patient from a hospital stay. |
|
REF (referrer) |
A person having referred the patient for services resulting in the encounter. |
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).
The CDA body can be either an unstructured blob, or can be comprised of structured markup. Every CDA document has exactly one body, associated with the ClinicalDocument class through the component relationship.
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The associated document body is a component of the document. |
The NonXMLBody class represents a document body that is in some format other than XML. 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 of the blob.
| Code | Definition |
|---|---|
|
DOCBODY (document body) [default] |
A context that distinguishes the body of a document from the document header. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of the event. |
| Code * | Definition |
|---|---|
|
N (normal) (codeSystem 2.16.840.1.113883.5.25) |
Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or business need may access this item. |
|
R (restricted) (codeSystem 2.16.840.1.113883.5.25) |
Restricted access, e.g. only to providers having a current care relationship to the patient. |
|
V (very restricted) (codeSystem 2.16.840.1.113883.5.25) |
Very restricted access as declared by the Privacy Officer of the record holder. |
* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.
The StructuredBody class represents a CDA document body that is comprised of one or more document sections.
| Code | Definition |
|---|---|
|
DOCBODY (document body) [default] |
A context that distinguishes the body of a document from the document header. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
| Code * | Definition |
|---|---|
|
N (normal) (codeSystem 2.16.840.1.113883.5.25) |
Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or business need may access this item. |
|
R (restricted) (codeSystem 2.16.840.1.113883.5.25) |
Restricted access, e.g. only to providers having a current care relationship to the patient. |
|
V (very restricted) (codeSystem 2.16.840.1.113883.5.25) |
Very restricted access as declared by the Privacy Officer of the record holder. |
* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.
The StructuredBody class is associated with one or more Section classes through a component relationship.
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The associated section is a component of the document body. |
Document sections can nest, can override context propagated from the header (see CDA Context (§ 4.4 ), and can contain narrative and CDA entries.
An XML attribute "ID" of type XML ID, is added to Section within the CDA Schema. This attribute serves as the target of a <linkHtml> reference (see <linkHtml> (§ <IP_ADDRESS> )). All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).
| Code | Definition |
|---|---|
|
DOCSECT (document section) [default] |
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. |
| Code | Definition |
|---|---|
|
EVN (event) [default] |
An actual occurrence of an event. |
The code specifying the particular kind of section (e.g. Chief Complaint, Review of Systems, Assessment). The value set is drawn from LOINC, and has a CWE coding strength.
Represents the label of a section. If valued, it is to be rendered as part of the narrative content of the clinical document body.
Used to store narrative to be rendered. Also referred to as the CDA Narrative Block. See Section Narrative Block (§ 4.3.5 ) for details.
A value for Section.confidentialityCode overrides the value propagated from StructuredBody. See CDA Context (§ 4.4 ) for more details.
| Code* | Definition |
|---|---|
|
N (normal) (codeSystem 2.16.840.1.113883.5.25) |
Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or business need may access this item. |
|
R (restricted) (codeSystem 2.16.840.1.113883.5.25) |
Restricted access, e.g. only to providers having a current care relationship to the patient. |
|
V (very restricted) (codeSystem 2.16.840.1.113883.5.25) |
Very restricted access as declared by the Privacy Officer of the record holder. |
* The codeSystem value is included here because confidentialityCode is of type CE, and therefore must carry both a code and a codeSystem.
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 (§ 4.4 ) for more details.
The author participant (described above, see author (§ <IP_ADDRESS> )), can be ascribed to a CDA section, where it overrides the value(s) propagated from the CDA header.
The informant participant (described above, see informant (§ <IP_ADDRESS> )), can be ascribed to a CDA section where it overrides the value(s) propagated from the CDA header.
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 (§ <IP_ADDRESS> )), 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.
A subject is a person playing one of several possible roles (RelatedSubject class). The entity playing the role is a person (SubjectPerson class).
| Code | Definition |
|---|---|
|
SBJ (subject) [default] |
The principle target that the service acts on. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
| Code | Definition |
|---|---|
|
PRS (personal relationship) [default] |
The subject has a personal relationship to the patient. The type of personal relationship is stated in SubjectRole.code, with a value drawn from the extensible (CWE) PersonalRelationshipRoleType vocabulary domain. The scoper is always the patient, and is implied. |
|
PAT (patient) |
The subject of an entry is the patient, who is identified in the recordTarget participant in the CDA header. |
| Code | Definition |
|---|---|
|
PSN (person) [default] |
A living subject of the species homo sapiens. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
The "component" Act Relationship is used to nest a Section within a Section. Context propagates to nested sections (see CDA Context (§ 4.4 )).
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The nested section is a component of the outer section. |
The relationship between a section and its entries is encoded in the intervening "entry" Act Relationship.
NOTE: See Referencing in and out of the narrative block (§ <IP_ADDRESS> ) for a discussion of referencing in and out of a section's narrative block.
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 <renderMultimedia> tags in the Section.text. This is the only case where the entries contain authenticated content that must be rendered with the narrative.
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 (§ <IP_ADDRESS> ).
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.
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The associated entry is a component of the section. No semantic relationship is implied. |
|
DRIV (is derived from) |
The narrative was rendered from the CDA Entries, and contains no clinical content not derived from the entries. |
The Section.text field is used to store narrative to be rendered, as described above in CDA Conformance (§ 1.3 ), 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 (§ 1.2.3 )). 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.
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.
<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.
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> (§ <IP_ADDRESS> )). 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.
<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.
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.
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.
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.
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.
<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.1138<IP_ADDRESS>"/> <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.
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.
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.
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.
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.
The table.border, table.cellspacing, and table.cellpadding attributes are deprecated, because the styleCode attribute (see styleCode attribute (§ <IP_ADDRESS> ) provides a more consistent way for senders to suggest rendering characteristics.
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.
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.
| 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:
<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> |
NOTE: See entry (§ <IP_ADDRESS> ) 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 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.
A derivative of the RIM Act class, to be used when the other more specific classes aren't appropriate.
Act.negationInd, when set to "true", is a positive assertion that the Act as a whole is negated. Some properties such as Act.id, Act.moodCode, and the participations are not affected. These properties always have the same meaning: i.e., the author remains the author of the negative Act. An act statement with negationInd is still a statement about the specific fact described by the Act. For instance, a negated "finding of wheezing on July 1" means that the author positively denies that there was wheezing on July 1, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.
| Code | Definition |
|---|---|
|
ACT (act) |
A healthcare service. |
|
ACCM (accommodation) |
An accommodation is a service provided for a Person or other LivingSubject in which a place is provided for the subject to reside for a period of time. |
|
CONS (consent) |
Represents informed consents and other medico-legal transactions between the patient (or legal guardian) and the provider. |
|
CTTEVENT (clinical trial timepoint event) |
An identified point during a clinical trial at which one or more actions are scheduled to be performed (definition mood), or are actually performed (event mood). |
|
INC (incident) |
An event that occurred outside of the control of one or more of the parties involved. Includes the concept of an accident. |
|
INFRM (inform) |
The act of transmitting information and understanding about a topic (or requesting that such information be transmitted) to a subject. |
|
PCPR (care provision) |
A patient care provision is the taking on of the responsibility by a performer for the health care of a patient or group of patients. |
|
REG (registration) |
Represents the act of maintaining information about an entity or role in a registry. |
|
SPCTRT (specimen treatment) |
A procedure or treatment performed on a specimen to prepare it for analysis |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
INT (intent) |
The entry is intended or planned. |
|
APT (appointment) |
The entry is planned for a specific time and place. |
|
ARQ (appointment request) |
The entry is a request for the booking of an appointment. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
|
DEF (definition) |
The entry defines a service (master). |
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 (§ 4.2.3 )) 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.
| Code | Definition |
|---|---|
|
ENC (encounter) |
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. |
| Code | Definition |
|---|---|
|
INT (intent) |
The entry is intended or planned. |
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
APT (appointment) |
The entry is planned for a specific time and place. |
|
ARQ (appointment request) |
The entry is a request for the booking of an appointment. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
A derivative of the RIM Observation class, used for representing coded and other observations.
Observation.negationInd, when set to "true", is a positive assertion that the Observation as a whole is negated. Some properties such as Observation.id, Observation.moodCode, and the participations are not negated. These properties always have the same meaning: i.e., the author remains the author of the negative Observation. An observation statement with negationInd is still a statement about the specific fact described by the Observation. For instance, a negated "finding of wheezing on July 1" means that the author positively denies that there was wheezing on July 1, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.
| Code | Definition |
|---|---|
|
OBS (observation) |
Observations are actions performed in order to determine an answer or result value. |
|
Any OBS subtype |
See vocabulary domain "ActClassObservation" for allowable values. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
DEF (definition) |
The entry serves to define an observation. |
|
GOL (goal) |
The entry represents a goal or objective. |
|
INT (intent) |
The entry is intended or planned. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
An Observation can have zero to many referenceRange relationships, which relate an Observation to the ObservationRange class, where the expected range of values for a particular observation can be specified.
| Code | Definition |
|---|---|
|
REFV (has reference values) [default] |
Reference ranges are essentially descriptors of a class of result values assumed to be "normal", "abnormal", or "critical". This link type can act as a trigger in case of alarms being triggered by critical results. |
| Code | Definition |
|---|---|
|
OBS (observation) [default] |
Observations are actions performed in order to determine an answer or result value. |
|
Any OBS subtype |
See vocabulary domain "ActClassObservation" for allowable values. |
| Code | Definition |
|---|---|
|
EVN.CRT (event criterion) [default] |
A criterion or condition over observations that must apply for an associated service to be considered. |
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.
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> (§ <IP_ADDRESS> )). All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).
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.
| Code | Definition |
|---|---|
|
OBS (observation) |
A multimedia observation. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
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.
| Code | Definition |
|---|---|
|
BATTERY (battery) |
A battery specifies 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 grouped together because of automation. |
|
CLUSTER (cluster) |
A group of entries that have a logical association with one another. The Cluster class permits aggregation into a compound statement. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event |
A derivative of the RIM Procedure class, used for representing procedures.
Procedure.negationInd, when set to "true", is a positive assertion that the Procedure as a whole is negated. Some properties such as Procedure.id, Procedure.moodCode, and the participations are not affected. These properties always have the same meaning: i.e., the author remains the author of the negative Procedure. A procedure statement with negationInd is still a statement about the specific fact described by the Procedure. For instance, a negated "appendectomy performed" means that the author positively denies that there was ever an appendectomy performed, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.
| Code | Definition |
|---|---|
|
PROC (procedure) |
An act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
INT (intent) |
The entry is intended or planned. |
|
APT (appointment) |
The entry is planned for a specific time and place. |
|
ARQ (appointment request) |
The entry is a request for the booking of an appointment. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
|
DEF (definition) |
The entry defines a service (master). |
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 units of the coordinate values in RegionOfInterest.value are in 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. 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.
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> (§ <IP_ADDRESS> )). All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).
| Code | Definition |
|---|---|
|
ROIOVL (overlay region of interest) |
A Region of Interest specified for an image using an overlay shape. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
| Code | Definition |
|---|---|
|
CIRCLE (circle) |
A circle defined by two (column,row) pairs. The first point is the center of the circle and the second point is a point on the perimeter of the circle. |
|
ELLIPSE (ellipse) |
An ellipse defined by four (column,row) pairs, the first two points specifying the endpoints of the major axis and the second two points specifying the endpoints of the minor axis. |
|
POINT (point) |
A single point denoted by a single (column,row) pair, or multiple points each denoted by a (column,row) pair. |
|
POLY (polyline) |
A series of connected line segments with ordered vertices denoted by (column,row) pairs; if the first and last vertices are the same, it is a closed polygon. |
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.
<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.1138<IP_ADDRESS>"/> <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.1138<IP_ADDRESS>"/> <value mediaType="image/jpeg"> <reference value="lefthand.jpeg"/> </value> </observationMedia> </entryRelationship> </regionOfInterest> </entryRelationship> </observation> </entry> </section> |
A derivative of the RIM SubstanceAdministration class, used for representing medication-related events such as medication history or planned medication administration orders.
SubstanceAdministration.negationInd, when set to "true", is a positive assertion that the SubstanceAdministration as a whole is negated. Some properties such as SubstanceAdministration.id, SubstanceAdministration.moodCode, and the participations are not affected. These properties always have the same meaning: i.e., the author remains the author of the negative SubstanceAdministration. A substance administration statement with negationInd is still a statement about the specific fact described by the SubstanceAdministration. For instance, a negated "aspirin administration" means that the author positively denies that aspirin is being administered, and that he takes the same responsibility for such statement and the same requirement to have evidence for such statement than if he had not used negation.
| Code | Definition |
|---|---|
|
SBADM (substance administration) |
The act of introducing or otherwise applying a substance to the subject. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
INT (intent) |
The entry is intended or planned. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
SubstanceAdministration.priorityCode categorizes the priority of a substance administration. SubstanceAdministration.doseQuantity indicates how much medication is given per dose. 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.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.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.
<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> |
The capture of medication-related information also involves the interrelationship of SubstanceAdministration with several other classes. The consumable participation is used to bring in the LabeledDrug or Material entity that describes the administered substance. 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. The Material entity is used to identify non-drug administered substances such as vaccines and blood products.
| Code | Definition |
|---|---|
|
CSM (consumable) [default] |
A substance that is taken up or consumed as part of the substance administration. |
| Code | Definition |
|---|---|
|
MANU (manufactured) [default] |
A manufactured product |
| Code | Definition |
|---|---|
|
MMAT (manufactured) [default] |
A manufactured material. |
| Code | Definition |
|---|---|
|
KIND (kind) [default] |
The described determiner is used to indicate that the given Entity is taken as a general description of a kind of thing that can be taken in whole, in part, or in multiples. |
| Code | Definition |
|---|---|
|
MMAT (manufactured) [default] |
A manufactured material. |
| Code | Definition |
|---|---|
|
KIND (kind) [default] |
The described determiner is used to indicate that the given Entity is taken as a general description of a kind of thing that can be taken in whole, in part, or in multiples. |
A derivative of the RIM Supply class, used for representing the provision of a material by one entity to another.
| Code | Definition |
|---|---|
|
SPLY (supply) |
The act of dispensing or delivering a product. |
| Code | Definition |
|---|---|
|
EVN (event) |
The entry defines an actual occurrence of an event. |
|
INT (intent) |
The entry is intended or planned. |
|
PRMS (promise) |
A commitment to perform the stated entry. |
|
PRP (proposal) |
A proposal that the stated entry be performed. |
|
RQO (request) |
A request or order to perform the stated entry. |
The dispensed product is associated with the Supply act via a product participant, which connects to the same ManufacturedProduct role used for SubstanceAdministration.
| Code | Definition |
|---|---|
|
PRD (product) [default] |
A material target that is brought forth (e.g. dispensed) in the service. |
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.
<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> |
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 (§ 4.4 )), participants propagated from the header can be overridden within the body.
The author participant (described above, see author (§ <IP_ADDRESS> )), 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.
The consumable participant is described above (see Entry Acts (§ 4.3.6 )).
The informant participant (described above, see informant (§ <IP_ADDRESS> )), 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.
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.
| Code | Definition |
|---|---|
|
Any ParticipationType subtype |
See vocabulary domain "ParticipationType" for allowable values. |
| Code | Definition |
|---|---|
|
OP (overriding propagating) [default] |
The participant overrides associations with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships. (See section "CDA Context" below.) |
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). The scoper is any entity (Entity class).
| Code | Definition |
|---|---|
|
Any ROL (RoleClassRoot) subtype |
See vocabulary domain "RoleClassRoot" for allowable values. |
| Code | Definition |
|---|---|
|
DEV (device) [default] |
An entity used in an activity, without being substantially changed through that activity. |
|
Any DEV subtype |
See vocabulary domain "EntityClassDevice" for allowable values. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
| Code | Definition |
|---|---|
|
ENT (entity) [default] |
A physical thing, group of physical things or an organization capable of participating in Acts, while in a role. |
|
Any ENT subtype |
See vocabulary domain "EntityClassRoot" for allowable values. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
| Code | Definition |
|---|---|
|
ENT (entity) [default] |
A physical thing, group of physical things or an organization capable of participating in Acts, while in a role. |
|
Any ENT subtype |
See vocabulary domain "EntityClassRoot" for allowable values. |
| Code | Definition |
|---|---|
|
INSTANCE (instance) [default] |
The INSTANCE determiner indicates an actual occurrence of an entity, as opposed to the KIND determiner, which refers to the general description of a kind of entity. For example, one can refer to a specific car (a car instance), or one can refer to cars in general (a car kind). |
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.
| Code | Definition |
|---|---|
|
PRF (performer) [default] |
A person who actually and principally carries out or will carry out the action. The traditional order filler is a performer. |
The product participant is described above (see Entry Acts (§ 4.3.6 )).
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.
| Code | Definition |
|---|---|
|
SPC (specimen) [default] |
The subject of non-clinical (e.g. laboratory) observation services. |
| Code | Definition |
|---|---|
|
SPEC (specimen) [default] |
A role played by a material entity that is a specimen for an act. |
The subject participant (described above, see subject (§ <IP_ADDRESS> )), 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.
The component relationship has a source of Organizer (see Organizer (§ <IP_ADDRESS> ), and a target that is another CDA entry, and is used to create groupings of CDA entries within an Organizer.
| Code | Definition |
|---|---|
|
COMP (component) [default] |
The associated CDA entry is a component of the organizer. |
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.
| Code | Definition |
|---|---|
|
PRCN (precondition) [default] |
A requirement to be true before a service is performed. |
| Code | Definition |
|---|---|
|
OBS (observation) [default] |
Observations are actions performed in order to determine an answer or result value. |
|
Any OBS subtype |
See vocabulary domain "ActClassObservation" for allowable values. |
| Code | Definition |
|---|---|
|
EVN.CRT (event criterion) [default] |
A criterion or condition that must apply for an associated service to be considered. |
The referenceRange relationship (described above, see Observation (§ <IP_ADDRESS> )), has a source of Observation, and a target of ObservationRange.
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).
NOTE: The CDA specification permits any CDA entry to relate to any CDA entry using any of the following relationship types. In many cases, this would result in nonsensical relationships. The following table is a guideline for reasonable relationships between CDA entries, and is not a conformance constraint.
| ActRelationship Type | Reasonable Source and Target entries | Comments |
|---|---|---|
|
CAUS (is etiology for) |
[Act | Observation | Procedure | SubstanceAdministration] |
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] |
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] |