Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
The purpose of this document is to describe constraints on the HL7 Clinical Document Architecture, Release 2 (CDA) specification in accordance with requirements set forward in ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR).
The CCR is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. The primary use case for the CCR is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient.
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. From its inception, CDA has supported the ability to represent professional society recommendations, national clinical practice guidelines, and standardized data sets. From the perspective of CDA, the CCR is a standardized data set that can be used to constrain CDA specifically for summary documents.
The resulting specification, known as the Continuity of Care Document (CCD), is developed as a collaborative effort between ASTM and HL7. It is intended as an alternate implementation to the one specified in ASTM ADJE2369 for those institutions or organizations committed to implementation of the HL7 Clinical Document Architecture.
NOTE: The HL7 Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm) (CRS) will be superseded by this CCD implementation guide where the scopes overlap.
This document is arranged analogously to the ASTM CCR specification. More specifically, the organization of this document follows the organization of ASTM CCR Table A1.1 “CCR Data Fields Spreadsheet”. It should be noted however that there are minor discrepancies between elements defined in the CCR Header/Body/Footer and the corresponding elements defined in the CDA Header/Body, such that, for instance, an element defined in the CCR Footer may map to an element defined in the CDA Header. As a result, constraints on, for example, the CDA Header, may be found in various sections of this document.
The document is organized into the following major sections:
Each major section or subsection of the document is organized to provide:
Where no constraints are stated in this guide, CCD instances are subject to and are to be created in accordance with the base CDA R2 specification. Where, for instance, the CDA R2 specification declares an attribute to be optional and the CCD specification contains no additional constraints, that attribute remains optional for use in a CCD instance.
In the absence of an HL7-defined and fully parsable grammar for constraints, certain conventions are followed in this guide so as to minimize ambiguity.
The approach taken in the development of this specification is intended to reflect the ASTM CCR requirements in an HL7 CDA R2 framework, and to do so in such a way that CDA is constrained in accordance with models being developed by other HL7 committees.
The general steps taken include:
This specification defines constraints on CDA Header and Body elements used in a Continuity of Care Document.
CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to constraints specified in this implementation guide.
In addition to assigning a template identifier to the overall implementation guide, this document assigns template identifiers to other patterns, such as document sections and specific clinical statements within document sections. Using the templateId to reference one of these patterns indicates that the CDA instance conforms to the constraints specified in that pattern.
...
Various CCR data types can be directly mapped onto HL7 RIM classes or data types. These mappings are described in the sections below.
CCR <DateTime> elements are typically represented in CDA using the HL7 TS, IVL_TS or PPD_TS data types. Some elements may be represented as PQ or IVL_PQ (e.g., age is one such measurement). Values which give just a narrative or text representation will also need to be stored using PQ.
Table 6. CCR <DateTime> correspondence to CDA
effectiveTime
time
birthTime
ASTM: The list of values for <DateTime><Type> includes numerous values, but has not been formally constrained by the standard.
HL7: The type of the date time is implicity determined its location within the XML structure.
ccr:ExactDateTime
@value
HL7: HL7 time stamps are recorded using ISO 8601 without any delimiters (hyphens, colons, the letter T between date and time).
ASTM: ASTM time stamps are recored using ISO 8601 with delimiters (hyphens, colons, and the letter T between date and time).
ccr:Age
entryRelationship/observation/
value[xsi:type='PQ']
ASTM: Age less than 2 weeks is expressed in days, less than 2 months in weeks, and less than 2 years in months. All others expressed in years.
HL7: Age is expressed as a physical quantity in a subordinate observation.
ccr:ApproximateDateTime
value
ASTM: There is no specified mechanism or vocabulary to express a numerically approximated date time. These are represented in CCR using the Coded Description Type.
HL7: Approximate date times may only be recorded in a CDA when they can be recorded in a related observation whose subject is the primary act. The code of this act should describe the purpose of the date time, and the value of this act should use an appropriate data type, so that it can fully represent the Coded Descrition Type allowed by a CCR.
ccr:DateTimeRange
time[@xsi:type='IVL_TS']
ccr:BeginRange
low
HL7: See notes on age above.
HL7: See notes on appriximate times above.
ccr:EndRange
high
Table 7. CCR <DateTime> correspondence to CDA mapping – Examples
<DateTime><ExactDateTime>2004</ExactDateTime> </DateTime>
<time value="2004"/>
<DateTime><ExactDateTime>2004-09</ExactDateTime> </DateTime>
<time value="200409">
<DateTime><ExactDateTime>2004-09-01</ExactDateTime> </DateTime>
<time value="20040901"/>
<DateTime><ExactDateTime>
2004-09-01T13-0500</ExactDateTime> </DateTime>
<time value="2004090113-0500"/>
<DateTime><ExactDateTime>2004-09-01T13:25-0500</ExactDateTime> </DateTime>
<time value="200409011325-0500"/>
<DateTime><ExactDateTime>2004-09-01T13:25:34-0500</ExactDateTime> </DateTime>
<time value="20040901132534-0500"/>
<DateTime>
<DateTimeRange>
<BeginRange><ExactDateTime>1965-09-01</ExactDateTime ></BeginRange>
</DateTimeRange>
</DateTime>
<time>
<low value="19650901"/>
</time>
<EndRange>
<ExactDateTime>2004-09-01</ExactDateTime ></EndRange>
<high value="20040901"/>
Table 8. CCR <CurrentName> correspondence to CDA
ccr:CurrentName
name[use="L]
ASTM: The CCR current name is the current legal name.
ccr:Given
given[1]
ccr:Middle
given[2]
HL7: HL7 Version 3 does not distinguish between First and Middle given names except by position.
ccr:Family
family
ccr:Suffix
suffix
ASTM: The suffix is for parts of the name, such as Jr., Sr., III, et cetera.
HL7: A suffix appears after a name component.
Jr., Sr., III, et cetera, would be suffixes in an HL7 name, but so would Ph.D. or M.D. (but see below for Title).
ccr:Title
suffix[@qualifier="TITLE]
- or -
prefix[@qualifier="TITLE]
ASTM: Examples of titles in the CCR implementation guide show Ph.D., MD, which would be suffixes.
It is not clear how Dr., Mr., Miss, Ms. Or Mrs. Would be handled in a CCR.
HL7: The TITLE qualifier indicates that the prefix or suffix applies to the whole name, rather than just the preceeding or following component.
ccr:NickName
given[@qualifier="CM]
HL7: The use of the Call Me coded value in qualifier indicates that this is what the person would like to be called.
Table 9. CCR <Name> correspondence to CDA – Examples
<Name>
<CurrentName>
<Given></Given>
<Middle></Middle>
<Family></Family>
<Suffix></Suffix>
<Title></Title>
<NickName></NickName>
</CurrentName>
<name use="L">
<given></given>
<family></family>
<suffix></suffix><suffix
qualifier="TITLE">
</suffix> </name>
<name>
<given
qualifier="CM">
</given>
</name>
Separate the nickname from the legal name in a separate <name> element.
<AdditionalName>
</AdditionalName>
</suffix>
</name> <name>
<BirthName>
qualifier="BR">
<family
</family><suffix></suffix>
Dont use Title or NickName with BirthName
<DisplayName></DisplayName>
<name></name>
Record the display name without delimiters.
</Name>
Table 10. CCR <Address> correspondence to CDA
ccr:Address
addr
ccr:Type
@use
ASTM: The ASTM recommended value set includes Home and Office.
HL7: The use attribute indicates the type of address. Set addr.use="H" or addr.use="HP" for Home, addr.use="WP" for Office.
ccr:Line1
streetAddressLine[1]
HL7: Use one streetAddressLine for each line.
ccr:Line2
streetAddressLine[2]
ccr:City
city
ccr:County
.county
ccr:State
state
ccr:Country
country
ccr:PostalCode
postalCode
ccr:Priority
ASTM: The ASTM recommended value set includes Primary – Preferred and Secondary.HL7: There is no real way to distinguish between Primary and Secondary.
ccr:Status
ASTM: The ASTM recommended value set includes Active and Temporary.
HL7: Set addr.use="TMP" to indicate a temporary address.
Table 11. CCR <Address> correspondence to CDA – Examples
<Address>
<addr
<Type>Home</Type>
use="HP">
<Line1>Address 1</Line1>
<streetAddressLine>Address 1
</streetAddressLine>
<Line2>Address 2</Line2>
<streetAddressLine>
Address 2
<City>City</City>
<city>City</city>
<County>County</County>
<county>County</county>
<State>State</State>
<state>State</state>
<Country>Country</Country>
<country></country>
<PostalCode>code</PostalCode>
<postalCode>code</postalCode>
<Priority></Priority>
<Status>Temporary</Status>
use="TMP
Add TMP to the use attribute.
</Address>
NOTE: For addresses, ASTM defines elements for <Type>, <Priority> and <Status>, whereas HL7 only supplies a single attribute to indicate the type of use. All addresses can be assumed to be active unless otherwise specified. Addresses that are known to be inactive shall include the value BAD in the use attribute to indicate that this address is no longer functioning. A temporary address shall include the value TMP in the use attribute to indicate that this address is only temporary.
ASTM and HL7 Version 3 specifications have similar structures for telephone numbers, e-mail addresses, and web page addresses.
Table 12. CCR <Telephone> correspondence to CDA
ccr:Telephone/
telecom/
HL7: The CDA uses URLs to represent all telecommunications. The value is represented as a tel: URL.
ccr:Value
ASTM: The value is an unrestricted string.
HL7: The value is a telephone URL conforming to RFC-2806.
ASTM:The ASTM recommended value set includes Home and Office, and also provides an example that uses Mobile.
HL7: The use attribute indicates the type of address. Set telecom.use="H" or telecom.use="HP" for Home, telecom.use="WP" for Office, and telecom.use="MC" for Mobile.
ASTM: The ASTM recommended value set includes Primary - Preferred and Secondary.
HL7: There is no real way to distinguish between Primary and Secondary.
ASTM: The ASTM recommended value set includes Active and Temporary (but does not directly included Inactive).
Not Mappped
@useablePeriod
Table 13. CCR <Telephone> correspondence to CDA – Examples
<Telephone>
< telecom
<Value>phone number</Value>
value="tel:"phone number
use="HP" TMP>
</Telephone>
<Email>
<telecom
<Value>email address</Value>
value="mailto:email
address
<Type>Home</Type
</Email>
<URL>
<Value>URL</Value>
value="http:URL
</URL>
NOTE: For e-mail, telephone, and web page addresses, ASTM defines elements for <Type>, <Priority> and <Status>, whereas HL7 only supplies a single attribute to indicate the type of use of these addresses. All addresses should be assumed to be active unless otherwise specified. Addresses that are known to be inactive shall include the value BAD in the use attribute to indicate that this address is no longer functioning. A temporary address shall include the value TMP in the use attribute to indicate that this address is only temporary.
The CCR supports recording identifiers for Payers, Authorizations, Advance Directives, Problems, Social History, Family History, Alerts, Products, Results, Tests, Procedures, Encounters, Interventions, and Actors.Each identifier has a value, and may have a type, date time, and issuer. It may also include a Source, Link, Reference or Comment.
The purpose of the <DateTime> element in the identifier is unspecified, but is presumed to mean the effective time of the identifier.CDA does not support recording the effective times of identifiers.
Examples of <Type> given for <IDNumber>[13] in the CCR Implementation Guide (see Payor) include Subscriber Number, Member Number (if patient is not subscriber), Plan Number, Group Number and Plan Code.
Some common identifier issuers have already been assigned a root by HL7, as follows:
Table 14. Common OIDs assigned by HL7
United States Social Security Number (SSN).
2.16.840.1.113883.4.1
United States Driver License Number (root).See FIPS Pub 5-2 for individual numeric values underneath this root for each State. Note that leading 0 digits are not used in OIDs.
2.16.840.1.113883.4.3
U.S. IRS Assigned Employer Identification Number EIN.
2.16.840.1.113883.4.4
National Provider Identifier
2.16.840.1.113883.4.6
Unique Physician Identification Number (UPIN)
2.16.840.1.113883.4.8
Table 15. CCR <IDs> correspondence to CDA
ccr:IDs/
id
ASTM: Although named <IDs>, this element represents a single identifier.
HL7: All identifiers are represented in the II datatype, and typically appear in an element named id.
ccr:DateTime
Not Mapped
ASTM: No guidance given.
Role, Entity or Act identifier, e.g,
participant/id
assignedPerson/id
act/id
ASTM: Identifers can be stored for Actors, procedures, products, fulfillments, payers, advanced directives, problems, alerts, medications, immunizations, family history, social history, equipment, result, encounter and plan.
HL7: The type of an identifier is determined from its context.
ccr:ID
@extension
ccr:IssuedBy
@assigningAuthority
@root
HL7: The root uid will need to be mapped based on the assigning authority.
This information might be assigned using information in the IssuedBy/ActorRole element of the CCR.
Users of CCD may have additional terminology constraints they wish to implement – such as those imposed by Consolidated Health Informatics (CHI, http://www.hhs.gov/healthit/chiinitiative.html) or Healthcare Information Technology Standards Panel (HITSP, http://www.ansi.org/standards_activities/standards_boards_panels/hisb/hitsp.aspx?menuid=3). Careful attention has been given to avoid introducing constraints in CCD that would impede ones ability to layer on these additional vocabulary constraints. CHI- and HITSP-endorsed vocabularies may be used in CCD where applicable.
The CCR <CodedDescriptionType> is represented using the HL7 CD data type, or any of its restrictions, depending upon usage. The table below shows the correspondence between CCR schema elements and CDA Release 2.0 schema elements.
Table 16. CCR <CodedDescriptionType> correspondence to CDA
ccr:CodedDescriptionType
Any element using the CD or derived data type for example:
code
ccr:Text
originalText/reference
The original text should appear in the body of the section, and should be incorporated by reference, not by value (eliminating duplicated information).
ccr:Code
@code
ccr:CodingSystem
@codeSystemName
@codeSystem
The OID appearing in code.codeSystem shall be appropriately mapped from the ASTM <CodingSystem> value. See section 5.5.2 Coding System Usage for more details.
ccr:Version
@codeSystemVersion
ccr:ObjectAttribute
qualifier
ccr:Attribute
name
ccr:AttributeValue
And so on
Table 17. CCR <Description> correspondence to CDA – Examples
<Description>
<Text>
Acute Anteroseptal Myocardial Infarction
</Text>
<Code>
<Value>410.1</Value>
<CodingSystem>ICD-9 CM</CodingSystem>
<Version>2004</Version>
</Code>
</Description>
<code code="410.1" codeSystemName="ICD9CM" codeSystem="2.16.840.1.113883.6.2" codeSystemVersion="2004"><originalText>
Acute Anteroseptal Myocardial Infarction</originalText>
</code>
<Value>62295002</Value>
<CodingSystem>SNOMED CT</CodingSystem>
<translationcode="62295002" codeSystemName="SNOMED-CT" codeSystem="2.16.840.1.113883.6.96"><translation>
<Value>62695002</Value>
<ObjectAttribute>
<Attribute>Diagnosis</Attribute>
<AttributeValue>
<Value>Myocardial Infarction</Value>
<Value>22298006</Value>
<CodingSystem>SNOMED CT
</CodingSystem>
</AttributeValue>
</ObjectAttribute>
<Attribute>Acuity</Attribute>
<Value>Acute</Value>
<Value>53737009</Value>
<Attribute>Site</Attribute>
<Value>Anteroseptal</Value>
<Value>20706007</Value>
<translationcode="62695002" codeSystemName="SNOMED-CT" codeSystem="2.16.840.1.113883.6.96" <translation code="22298006"codeSystemName="SNOMED-CT" codeSystem="2.16.840.1.113883.6.96"
displayName="Myocardial" Infarction>
<qualifier>
<name code="260908002"displayName="Course"/>
<value code="22298006"displayName="Acute"/></qualifier>
<name code="363698007"displayName="Finding" Site/>
<value code="20706007"displayName="Anteroseptal"/>
</qualifier>
</translation>
The CCR states that Problems should be coded using SNOMED CT, and ICD-9 CM codes, Procedures using SNOMED CT, LOINC and CPT codes, Products and Agents using RxNorm, and Results using CPT and LOINC. In order to utilize these coding systems, an agreement must be reached upon how to represent these systems within a CCR. The table below shows how to map <CodingSystem> values from a CCR into the codeSystem attribute of an HL7 Version 3 CD data type.
<CodingSystem>
codeSystem
Table 18. CCR <CodingSystem> values and corresponding CDA CD.codeSystem values
CPT-4
2.16.840.1.113883.6.12
ICD-9 CM
2.16.840.1.113883.6.1
LOINC
NDC
2.16.840.1.113883.6.69
RxNorm
2.16.840.1.113883.6.88
SNOMED CT
2.16.840.1.113883.6.96
CONF-534: When representing the any of the coding systems listed above, the codeSystem attribute SHALL be present using the values listed in that table.CONF-535: When the codeSystemName attribute is present, it SHALL be valued with the appropriate values from Table 18 above.CONF-536: Where SNOMED CT is used, it SHALL be used per the “Using SNOMED CT in HL7 Version 3” Implementation Guide.
The CCD specification could never have been written without a close working relationship between HL7 and ASTM. CCD reflects an overlap of two complementary specifications (CCR, CDA) derived by different standards organizations, and shows what can be achieved when patient care is the driving priority. Special thanks to Rick Peters, Steven Waldren, and Alan Zuckerman for their active involvement in the creation of CCD.