Quick Start Guide for Care Record Summary Documents Using CDA Release 2.0

Rendering Considerations

The CDA itself guarantees that legally required, human-readable content can be rendered with a single style sheet. The same applies to CRS, which is a constraint on CDA.

CRS, CCD and the SDTC Roadmap

Starting in December, 2005, the HL7 Structured Documents Technical Committee, in conjunction with ASTM E31.28, launched a project to create a "Continuity of Care Document" or CCD. The CCD will reiterate the clinical content of the ASTM Continuity of Care Record (CCR) as a CDA application. The outcome will be an implementation guide, similar to the one for CRS. Simultaneously, CRS is entering its third ballot cycle for Level 1 and Level 2 summary documents.

The outcome of this activity will be a merged set of implementation specifications covering "continuity of care" such that implementers can work off of a single set of requirements and can implement to the highest level of which they are capable. To achieve this, CRS may be modified to accommodate the CCD and the CCD may be influenced by the design of CRS. This reconciliation must be addressed before the spring ballot cycle in HL7, approximately April 1, 2006.

Document Notational Conventions

Narrative text will appear as Times Roman, plain face text in Word, and plain face in HTML versions.

element is bold when an XML element is discussed in narrative text

attribute is bold-italic when an XML attribute is discussed in narrative text

Coding examples will appear as monospaced font (typically Courier or Courier New) with color to identify optional and fixed content for clarity where applicable.

References are made throughout this document to the CRS Implementation Guide and to the normative HL7 Clinical Document Architecture (CDA), Release 2.0 documentaton set. To improve readability, all references to these documents will appear at the end of each topic as:

Additional references to other HL7 specifications will include the title of the document in addtion to the section number and title, i.e.:

NOTE: Some references are active links if you have installed a local copy of the web version of the HL7 Clinical Document Architecture (CDA), Release 2.0 specification. For proper functioning of the links, place this document in the root directory of the specification created when unzipping the specification. By default it will be ..\CDA_R2_NormativeWebEdition.

If you do not have a local copy, then please navigate to www.hl7.org/memonly/downloads to obtain a copy. Please note that you must have HL7 member log-in privileges to access and download the specification.

CRS IG - Key Words

The CRS implementation guide places constraints on the generality of CDA, therefore that document makes use of key phrases to indicate such constraints.

The key words "shall", "shall not", "should", "should not", "may", and "neednot" in this document are to be interpreted as described the HL7 Version 3 Publishing Facilitator's Guide.

Essentially, "shall" means that the item, subject or article is an absolute requirement, whereas "shall not" indicates an absolute prohibition against inclusion.

"Should" means that valid reasons may exist in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed by the author.

Conversely, "should not" means that valid reasons may exist in particular circumstances when the particular behavior is acceptable or useful, but the full implications should be understood and carefully weighed before implementing any behavior described with this label.

"May" and "neednot" mean that the item is truly optional and can be included or omitted as the author decides with no implications. Note that this can potentially be overridden by local business practices or other external requirements; local implementations should verify whether or not something is truly optional in local practice.

When CRS Constrains CDA

Authoritative Sources

Note:Portions of this document are abstracted from the normative edition of the HL7 Clinical Document Architecture (CDA), Release 2.0 specification and the Care Record Summary (CRS) Implementation Guide (US Realm), Third Informative Ballot, November 17, 2005. This Guide is not a complete reference to the CDA schemas and should be used in conjunction with the full normative specification for implementation and development. Please refer to the normative edition for a complete description of the CDA and its usage. Any deviation between this Guide and the specification is an error in the Guide and the specification should be followed in all cases.

This Quick Start Guide is based on the HL7 Care Record Summary Implementation Guide. It describes how to implement a basic CDA that will facilitate the collection of patient information as a series of CDA documents or in a mixed archive with other types of standards-based persistent objects. The resulting CDA instance will be comprised of an XML-encoded header, and a body which is either non-XML or the simple XML of the CDA Narrative block.

If, through an error, this guide deviates in any way from the CDA Release 2.0 specification or the CRS Implementation Guide (US Realm), those specifications should be followed. Note that in all cases the CDA Release 2.0 Specification is to be considered the authoritative specification.

This Guide covers all required elements of the CRS header and body and gives guidance on some optional elements. The list of CRS-required header elements is greater than the list of required header elements presented in the CDA Quick Start Guide because the CRS tightens some aspects of the CDA.

Assumptions

This document assumes that the reader has a thorough understanding of XML, the W3C Recommendation, as an XML applications developer. The reader should be familiar with W3C schemas, XML validation (parsing) and methods of constructing and de-constructing XML files.

Knowledge of the relevant HL7 standards and approaches are helpful. Additional information to further the readers understanding can be found in the Reference Information section of the guide.

Reference Information

Use of IDs and Codes

While CDA allows more than one type of unique identifier scheme, but most implementations will use ISO object identifiers (OIDs) to uniquely specify the domain of a coded data value or an identifier for a person, organization, or other entity.

The identifier consists of two parts:

root - a globally unique identifier composed of an OID or UUID whose root is assigned by an ISO assigning authority or obtained from HL7.

extension - The value of this attribute is the responsibility of the organization, system and/or application where the document is created and stored.

In typeID the root and extension are fixed, but in most cases the root and extension are supplied by the application using internal OIDs or OIDs for an external organization such as HL7 or LOINC, or a third party that played some role in the event that is being documented, such as a lab, hospital, physicians office or other care setting.

Together the root and extension, when concatenated, result in a universally unique string for identification of the document, person, or organization.

Note: Throughout this document you will see references to the root "2.16.840.1.113883.19.xx". This OID belongs to HL7 (root OID = 2.16.840.1.113883) and is specifically identified for use in example documents and has no other valid use.

To implement CRS, the identifiers you must be prepared to supply:

• document ID: unique identifier for each CDA instance
• patient (record target)
• provider organization associated with the patient
• author and author's organization
• document custodian
• other participants such as providers performing a role in the encounter

The CDA also makes extensive use of code sets for document types, document sections, clinical procedures and clinical findings. Any code set used in the RIM, including internal RIM vocabularies and codes such as CPT, ICD, MEDCIN or SNOMED® can be used.

These vocabularies, or subsets thereof, are made available in the voc.xml file for use by Schematron for CRS rule validation. This file can be extended for local use, please refer to the CRS IG, Appendix A - Validation.

In this guide, we discuss use of Logical Observation Identifier Names and Codes (LOINC®) which is recommended for classification of document types (i.e., Discharge Summary, Transfer Note, History & Physical, etc.). LOINC codes are available for commercial use without charge, subject to the terms of a license that assures the integrity and ownership of the codes. Some commonly-used codes for CDA can be found throughout the specifications in the referenced section for each element described below.

For further information about LOINC and to obtain the latest release of the code database, please visit the LOINC site on the Web. The most current contact information can also be found there.

Internet connection required for the following links:

Vocabularies

A number of controlled vocabularies are referenced in this document. These controlled vocabularies are defined in various supporting specifications, and may be maintained by other bodies, as is the case for the LOINC and SNOMED CT. The Schematron schema makes use of a supporting file (voc.xml) that contains these vocabularies or applicable subsets as of the release of the CRS specification. See Appendix A of the CRS IG for information on how to extend the voc.xml file for local requirements.

Null Flavor

CDA makes use of defined types of null values to indicate what way and why content may be missing from a document. The following table represents the list of defined values and their definitions.

Document Types

There are three primary types of CRS documents:

• Summarization of Episode Note - LOINC: 34133-9
• Discharge Summarization Note - LOINC: 18842-5
• Transfer Summarization Note - LOINC: 18761-7

Implementers may wish to refine the classification of the document by supplying data on training/professional level of the participants in the documentationOf element. This is accomplished by use of a code element on the assignedEntity within a participant in the encompassingEncounter element (see componentOf).

ClinicalDocument

All documents begin with the root element ClinicalDocument which contains one or more attributes for namespace declarations.

Note: HL7 specifications discourage the use of the xsi:schemaLocation attribute in exchanged documents.

Example:

typeID

The typeID is a technology-neutral explicit reference to the CDA, Release Two specification. The element has two attributes that must be valued as follows:

root = "2.16.840.1.113883.1.3" (which is the OID for HL7 Registered models);

extension = "POCD_HD000040" (which is the unique identifier for the CDA, Release Two Hierarchical Description).

Example:

This element must appear with these exact values to be a CDA-conforming instance.

id

The id represents the unique instance identifier (UID) of a clinical document. The id element uniquely and universally distinguishes a document from all other documents. This allows documents to move among systems without ID collision within those systems.

As above, the id element contains a root and extension attribute

Examples:

In this first example, the value of root is an example code defined by HL7. In practice this should be the creating organization's OID that has been assigned by an ISO assigning authority such as HL7. The extension will hold the universally unique value assigned to the document.

code

The code element at the root level of the document (i.e. a direct child of ClinicalDocument) specifies the particular kind of document that is being created, such as a History and Physical, Discharge Summary, or Progress Note. This is typically called a "document type code". The value set is drawn from LOINC, and has a "Coding, With Extensions" (CWE) coding strength. CWE means that implementers should use the supplied code set, in this case from LOINC, but if none of the supplied set applies, a substitute code can be used.

The required attributes are code and codeSystem, where code contains the string indicating the type of document, and the codeSystem is the OID of the organization that defined the string. For human-readability, the optional elements are codeSystemName and displayName. Note that the LOINC display name need not match the title of the document. The LOINC name might be "Summarization of Episode Note" and the actual title might be "Outpatient Episode Note". In the examples below, the code values are LOINC values, and codeSystem contains the OID for LOINC.

Examples:

When the document is a summarization of episode note:

When the document is a discharge summarization note:

When the document is a transfer summarization note:

Note: While LOINC is used to indicate the kind of CRS document, it is NOT an indicator that an instance is explicitly a CRS document. The value of the templateId is the appropriate element whose value declares an instance as one that could be expected to be CRS-compliant, or declares it as another kind of CDA instance.

effectiveTime

As a direct child of ClinicalDocument, 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 effectiveTime is the time the original document is created. Date and times are coded per HL7 adoption of ISO8601.

Examples:

Known to year/month/day/hour/min/sec declared with specific offset from zero meridian

Known to year/month/day/hour/min declared with specific offset from zero meridian

confidentialityCode

Confidentiality is a required contextual component of CDA, where the value expressed in the header holds true for the entire document, unless overridden by a nested value. The coding strength for this element is Coded With Extensions (CWE).

Examples:

Normal Confidentiality per HL7 vocabulary

Restricted Confidentiality per HL7 vocabulary

Very Restricted Confidentiality per HL7 vocabulary

recordTarget

The recordTarget represents the person whose chart this document belongs to. Typically this is the patient who is also the subject of the report, although the subject can be a tissue sample, fetus, etc.

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.

Example:

author

The author is a particpant in a CRS document and represents the humans and/or machines that created the document content. A document may have multiple contributors in which case each must be identified in the document. Note that in some cases the author and dataEnterer may be the same person.

The assignedPerson element contains a name, which in turn has child elements prefix, given, family and suffix.

Additional issues need to be considered when the author of the Care Record Summary is the patient, guardian, relation or other care-giver for the patient. Please refer to the CRS IG, Appendix D - Documents Created by Non-Practitioners of the CRS IG which discusses these issues as they are beyond the scope of this guide.

Example:

In this example, the author is a physician using a software application to create the document

custodian

The custodian element is required 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.

Note that custodian, by inclusion, contains required child element assignedCustodian.

assignedCustodian requires a representedCustodianOrganization, which requires an id and may have an optional name element. Custodian organizations are encouraged to obtain and register their OID with HL7 to facilitate exchange of instances.

Note that systems that allow patients to create Care Record Summaries for their own use must maintain a true and accurate copy of the document, see the CRS IG, Appendix D - Documents Created by Non-Practioners for more details on this requirement.

Example:

documentationOf and serviceEvent

These elements describe the encounter during which the subject was seen and may include a code to describe the encounter as well as identifying the provider, location, time. It indicates the episode of care that the provider further describes in the content of the Care Record Summary

Example:

realmCode

This element identifies the realm to which this document applies.

Example:

templateId

A template ID is used to identify that a pre-determined template has been used as the basis for the creation of the document.

If additional templates are applied, additional elements may be present.

Examples:

When the document is a Level 1 document

When the document is a Level 2 document

languageCode

The languageCode element indicates which human language the document is authored in.

The format is a lowercase 2-alpha character string for the language with optionally an uppercase 2-alpha character string indicating the country.

Examples:

To specify English without indication of location of usage (dialect)

To specify English as used in the United States

To specify English as used in the United Kingdom

title

This element is optional and represents the local title for the document. Where these display names are rendered to the clinician, or where the document has a local title, the title element should be used.

Example:

setId and versionNumber

As with the id element, these two elements are related to document management. They are used together to indicate that the document is a member of a set where all the members of the set are multiple revisions of the same document. The setId is a unique string that is common across all the members of the set (the revisions), where the versionNumber is an integer value indicating the specific revision.  

Examples:

copyTime

dataEnterer

The dataEnterer is an optional element and identifies a participant in a CRS document. A dataEnterer is defined as a person or system that transfers information from one form or another (e.g. from paper to an electronic system) without creating new information though application of their knowledge or skills. A dataEnterer is usually but not always a transcriptionist or clerk copying information from a form into a document without interpretation or extrapolation from the source. In some cases the author and dataEnterer may be the same person.

Example:

informant

The informant is an optional element and identifies a participant in a CRS document who is a source of the information in the CRS. The code element of the assignedEntity or relatedEntity, if present, describes the relationship between the informant and the patient.

Examples:

To represent a healthcare provider with a specific assigned healthcare role where the role can be identified by the author and authoring system.

To represent personal relation that provides information about a patient.

To represent a witness to a significant health event.

To represent a healthcare provider in a healthcare role without an assigned role known or representable to the author. The example below represents a physician who was the patient's primary care provider.

Note: the RoleCode and RoleClass vocabularies contain mnemonics for a large number of relationships. Some common ones are:

MTH - mother

FTH - father

SON - natural son

SONADOPT - adopted son

DAU - natural daughter

DAUADOPT - adopted daughter

CON - contact

PROV - health care provider

informationRecipient

The informationRecipient is a participant in a CRS document in the context of a referral or request for consultation. This element is optional and is used to record the intended recipient of the document at the time the document is created. The intended recipient may be the health chart of the patient, in which case the receivedOrganization shall be the scoping organization of that chart.

Example:

legalAuthenticator

The legalAuthenticator is an optional element and identifies a participant in a CRS document who is the legal authenticator of the document. The act of legal authentication requires privileges be granted to the authenticator depending on local policy. In the case of a patient or other non-practitioner authored document, this privilege may not be available to the author. CRS documents should have the potential to be legally authenticated by an assigned person or entity with the proper credentials. When present, the legalAuthenticator must refer to a person who is accepting responsibility for the document.

Example:

authenticator

The authenticator is an optional element and identifies a participant in a CRS document that has verified the accuracy of the information in the document, but who does not have privileges to legally authenticate the document. A document may have 0 to many authenticators.

Example:

participant

The participant is an optional element and identifies other supporting participants in a CRS document including: parents, relatives, care givers, insurance policy holders, guarantors and others related in some way to the patient. See the entry for documentationOf for information about healthcare providers who are involved in patient care during the episode being summarized.

Example:

When the participant is the guarantor

inFulfillmentOf

This element is optional and describes the prior orders that are fulfilled in whole or part by events described in the CRS. It is anticipated that CRS documents will rarely be created in response to an order, which is the type of information inFulfillmentOf is intended to convey.

authorization

This element is optional and represents the consents associated with this document, e.g. the consent to perform the service related in the serviceEvent, consent to release the information in the document to a third party, etc. CDA states "Consents referenced in the CDA Header have been finalized (Consent.statusCode must equal "completed") and should be on file." The OID indicates this value is from the HL7 ActStatus vocabulary.

Example:

componentOf

This is an optional element that identifies the encounter to which this document pertains.

Example:

In the case where the document is coded as a Discharge Summarization

structuredBody

CDA with a structured (XML) body stipulates the use of the structuredBody element

These sections must be identified by the use of a LOINC value. CRS describes the appropriate contents, but imposes no further requirements on markup beyond those for any CDA. Note that some values in the examples begin with the letter X, these are values that are not currently found in LOINC but are to be submitted for inclusion in the LOINC database at the close of the CRS ballot.

The CRS body defines a number of optional sections as well: Reason for Visit/Chief Complaint, Reason for Referral, Advance Directives, History of Present Illness, Functional Status, Family History, Social History, Immunizations, Past Surgical History, Prior Encounters, Review of Systems, Physical Examinations, Vital Signs, Studies and Reports, Fetal Vital Signs, and Plan of Care. These sections should be identified by the use of a LOINC value.

Section codes have been coordinated with other domains, such as Claims Attachments, for content reuse in a response to a query.

Sections may appear in any order, and may be nested as appropriate, e.g. vital signs may be nested within a physical examination section.

Example:

The examples given are for the three required sections, please refer to the populated example file for other sections. Note the section codes are showing as variable but in this context it is variable between the two possible codes for each section as listed above.

If the document is a Discharge Summary, the following section will be present:

nonXMLBody

A nonXMLBody contains a text element, which has an optional mediaType attribute which identifies the encoding of the encapsulated data and identifies a method to interpret or render the data. Preferred mediaType values include "image/gif", "image/tiff", "text/rtf", "application/pdf", "image/g3fax", "text/html", "image/jpeg", "image/png", and "text/plain".

A text element may contain a reference or thumbnail element. The reference has a required attribute of value, which contains a URL pointing to the external object. It should contain an optional useablePeriod that can declare the length of time the object will be available.

Examples:

A non-XML body with text content

A non-XML body with a reference to a URL with a usable period: