Help
Login
Busy
Search
Continuity of Care Document (CCD) - Project Information

 
Warning
Select building block repository
Select user
Select user
Version: Edit
Add/change logo
Remove File
Compare: Releases


Edit
Edit
Edit
Previous release
 
Name
Continuity of Care Document (CCD)
Description
A CDA implementation of ASTM E2369-05
Standard Specification for Continuity of Care Record© (CCR)
which may be used in lieu of ASTM ADJE2369
[ed: original standard may be found here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6]


April 01, 2007

E2369-05 Standard Specification for Continuity of Care Record is copyright 2006 ASTM International. All rights reserved. Used by permission for the purpose of composing this document. Anyone seeking to implement E2369-05 must have acquired rights from ASTM International and must adhere to the tenets of their license agreement.


1  Introduction

1.1  Scope

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.

1.2  How to read this document

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:

  • Introduction – provides an overview and scope of the CCD specification.
  • CCR Header Representation – defines constraints on CDA R2 corresponding to CCR Header components.
  • CCR Body Representation – defines constraints on CDA R2 corresponding to CCR Body components.
  • CCR Footer Representation – defines constraints on CDA R2 corresponding to CCR Footer components.
  • General Constraints – provides more detailed mappings and CDA R2 constraints for global CCR components, such as data types and identifiers.
  • Appendix – provides detailed and conformant sample CCR and CCD instances.

Each major section or subsection of the document is organized to provide:

  • A narrative overview – provides an overview and scope for the subsection.
  • CDA R2 constraints – ASTM CCR requirements are expressed as constraints on the CDA R2 specification, making this document a “conformance profile”, as described in the Refinement and Localization (http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm) section of the HL7 Version 3 standards. As defined in that document, this guide is both an annotation profile and a localization profile. The base standard for this guide is the HL7 Clinical Document Architecture, Release 2.0.

    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 key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY" , and "NEED NOT" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm).
  • Cardinality constraints are stated from the perspective of the containing element. For instance, assume that SectionOne is optional, that if SectionOne is present then ObservationOne is required and one or more ObservationTwo’s are optional, and that if ObservationTwo is present then ObservationTwo / effectiveTime is required. Corresponding constraints:
    CONF-ex1:CCD MAY contain exactly one SectionOne.
    CONF-ex2:SectionOne SHALL contain exactly one ObservationOne.
    CONF-ex3:SectionOne MAY contain one or more ObservationTwo.
    CONF-ex4:ObservationTwo SHALL contain exactly one ObservationTwo / effectiveTime.
  • Formalisms for value set constraints are based on the latest recommendations from the HL7 Vocabulary Committee. Value set constraints can be “STATIC”, meaning that they are bound to a specified version of a value set, or “DYNAMIC”, meaning that they are bound to the most current version of the value set. A simplified constraint is used when binding is to a single code.
  • Syntax for vocabulary binding to DYNAMIC or STATIC value sets: The value for (“pathName of coded element”) (SHALL | SHOULD | MAY) be selected from ValueSet valueSetOID localValueSetName (DYNAMIC | STATIC (valueSetEffectiveDate)).
    CONF-ex5:The value for “ClinicalDocument / codeSHALL be selected from ValueSet 2.16.840.1.113883.19.3 LoincDocumentTypeCode DYNAMIC.
    CONF-ex6:The value for “ClinicalDocument / codeSHALL be selected from ValueSet 2.16.840.1.113883.19.3 LoincDocumentTypeCode STATIC 20061017.
  • Syntax for vocabulary binding to a single code: The value for (“pathname of coded element”) (SHALL | SHOULD | MAY) be (“code” [“displayName”] codeSystemOID [codeSystemName] STATIC.
    CONF-ex7:The value for “ClinicalDocument / codeSHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.
  • Constraints assume context propagation. For example, if a CDA entry requires an author participant, and authorship is defined at the section level and propagates to the entry, then the constraint is satisfied.
  • Constraints are expressed in a technology-neutral formalism. Section 7.1.4 Sample CCD Validating Style Sheet provides a non-normative example of how one might implement the normative conformance statements, by expressing them as assertions within a Schematron schema.
  • CDA R2 model subset – provides a graphical representation of those portions of the CDA R2 object model being constrained by conformance statements. Those parts of the CDA R2 object model not illustrated and not constrained are to be used in accordance with the base CDA R2 specification.
  • CDA R2 extensions – where applicable, describes extensions to the CDA R2 specification.
  • ASTM CCR mapping – provides a mapping from the CCR attributes and data objects defined in ASTM CCR Table A1.1 “CCR Data Fields Spreadsheet” to corresponding CDA R2 elements.
  • Additional examples – Conformant CCR and CCD instances are provided in the appendix. Where applicable, additional examples may be provided.

1.3  Approach

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:

  • Review a section of CCR, focusing on identifying the data requirements. For instance, review the CCR section describing the representation of lab results.
  • Review overlapping HL7 domain models to see how similar data requirements have been represented. For instance, review the domain model from the Lab committee to see how it accommodates lab results.
  • Review additional relevant references and standards for further cross-validation of requirements.
  • Represent the CCR data requirements as a set of constraints against the HL7 Clinical Statement model, in a way that is isomorphic to existing HL7 domain models. This constrained Clinical Statement model can then be used by any HL7 committee wanting to implement similar requirements in their own specifications.
  • Reflect the Clinical Statement constraints as constraints against CDA R2, making minor adjustments as necessary to accommodate the differences between the models.

1.4  Asserting conformance to this Implementation Guide

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.

Figure 1 Use of the templateId element to assert use of this guide
<ClinicalDocument xmlns='urn:hl7-org:v3'>
  <typeId extension='POCD_HD000040' root='2.16.840.1.113883.1.3'/>
  <templateId root='2.16.840.1.113883.10.20.1'/>
  <-- ... -->
</ClinicalDocument>

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.

Figure 2 Use of the templateId element to assert use of a pattern
<section>
  <templateId root='2.16.840.1.113883.10.20.1.14'/>
  <-- ... -->
  <observation classCode='OBS' moodCode='EVN'>
    <templateId root='2.16.840.1.113883.10.20.1.32'/>
    <-- ... -->
  </observation>
  <-- ... -->
</section>

...

5.4 Data Types

Various CCR data types can be directly mapped onto HL7 RIM classes or data types. These mappings are described in the sections below.

5.4.1 Dates and Times

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

CCR data elementCDA R2 correspondenceComments
ccr:DateTime

effectiveTime

time

birthTime

HL7: Any element using GTS or derived data type (e.g. effectiveTime)
ccr:Type Not Explicitly Modeled

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

entryRelationship/observation/

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

 

ccr:ExactDateTime

@value

 

ccr:Age

 

HL7: See notes on age above.

ccr:ApproximateDateTime

 

HL7: See notes on appriximate times above.

ccr:EndRange

high

 

ccr:ExactDateTime

@value

 

ccr:Age

 

HL7: See notes on age above.

ccr:ApproximateDateTime

 

HL7: See notes on appriximate times above.

 

Table 7. CCR <DateTime> correspondence to CDA mapping – Examples

CCR Data RepresentationCDA R2 Data Representation

<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>

 

<DateTime>

<DateTimeRange>

<EndRange>

<ExactDateTime>
2004-09-01
</ExactDateTime >
</EndRange>

</DateTimeRange>

</DateTime>

 

<time>

<high value="20040901"/>

</time>

<DateTime>

<DateTimeRange>

<BeginRange>
<ExactDateTime>
1965-09-01
</ExactDateTime >
</BeginRange>

<EndRange>

<ExactDateTime>
2004-09-01
</ExactDateTime >
</EndRange>

</DateTimeRange>

</DateTime>

<time>

<low value="19650901"/>

<high value="20040901"/>

</time>

 

5.4.2 Names

Table 8. CCR <CurrentName> correspondence to CDA

CCR data elementCDA R2 correspondenceComments

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

CCR encodedCDA R2 encodedComments

<Name>

 

 

<CurrentName>

<Given></Given>

<Middle></Middle>

<Family></Family>

<Suffix></Suffix>

<Title></Title>

 

 

<NickName></NickName>

</CurrentName>

<name use="L">

<given></given>

<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>

<Given></Given>

<Middle></Middle>

<Family></Family>

<Suffix></Suffix>

<Title></Title>

 

 

<NickName></NickName>

</AdditionalName>

<name>

<given></given>

<given></given>

<family></family>

<suffix></suffix>
<suffix

qualifier="TITLE">

</suffix>

</name>
<name>

<given

qualifier="CM">

</given>

</name>

 

 

<CurrentName>

<Given></Given>

<Middle></Middle>

<Family></Family>

<Suffix></Suffix>

<Title></Title>

 

 

<NickName></NickName>

</CurrentName>

<name use="L">

<given></given>

<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.

<BirthName>

<Given></Given>

<Middle></Middle>

<Family></Family>

<Suffix></Suffix>

<BirthName>

<name>

<given

qualifier="BR">

</given>

<given

qualifier="BR">

</given>

<family

qualifier="BR">

</family>
<suffix></suffix>

</name>

Dont use Title or NickName with BirthName

<DisplayName></DisplayName>

<name></name>

Record the display name without delimiters.

</Name>

 

 

5.4.3 Addresses

Table 10. CCR <Address> correspondence to CDA

CCR data elementCDA R2 correspondenceComments

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

@use

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

CCR encodedCDA R2 encodedComments

<Address>

<addr

 

<Type>Home</Type>

use="HP">

 

<Line1>Address 1</Line1>

<streetAddressLine>
Address 1

</streetAddressLine>

 

<Line2>Address 2</Line2>

<streetAddressLine>

Address 2

</streetAddressLine>

 

<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.

 

5.4.4 Telephone Numbers, E-Mail Addresses, and URLs

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 data elementCDA R2 correspondenceComments

ccr:Telephone/

telecom/

HL7: The CDA uses URLs to represent all telecommunications. The value is represented as a tel: URL.

ccr:Value

@value

ASTM: The value is an unrestricted string.

HL7: The value is a telephone URL conforming to RFC-2806.

ccr:Type

@use

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.

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

@use

ASTM: The ASTM recommended value set includes Active and Temporary (but does not directly included Inactive).

HL7: Set addr.use="TMP" to indicate a temporary address.

Not Mappped

@useablePeriod

 

 

Table 13. CCR <Telephone> correspondence to CDA – Examples

CCR encodedCDA R2 encodedComments

<Telephone>

< telecom

 

<Value>phone number</Value>

value="tel:"phone number

 

<Type>Home</Type>

use="HP">

 

<Status>Temporary</Status>

use="HP" TMP>

Add TMP to the use attribute.

</Telephone>

 

 

<Email>

<telecom

 

<Value>email address</Value>

value="mailto:email

address

 

<Type>Home</Type

use="HP">

 

<Status>Temporary</Status>

use="HP" TMP>

Add TMP to the use attribute.

</Email>

 

 

<URL>

<telecom

 

<Value>URL</Value>

value="http:URL

 

<Type>Home</Type

use="HP">

 

<Status>Temporary</Status>

use="HP" TMP>

Add TMP to the use attribute.

</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.

 

5.4.5 Identifiers

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

IssuerOID Root

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 data elementCDA R2 correspondenceComments

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.

ccr:Type

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.

 

5.5 Terminology conformance

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.

 

5.5.1 Coded Information

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 data elementCDA R2 correspondenceComments

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:Value

@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

value

 

ccr:Value


originalText/reference

 

ccr:Code

code

 

ccr:Value


@code

 

ccr:CodingSystem


@codeSystemName

 

ccr:Version


@codeSystemVersion

And so on

 

Table 17. CCR <Description> correspondence to CDA – Examples

CCR-encodedCDA-encoded

<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>

 

<Description>

<Text>

Acute Anteroseptal Myocardial Infarction

</Text>

<Code>

<Value>410.1</Value>

<CodingSystem>ICD-9 CM</CodingSystem>

<Version>2004</Version>

</Code>

<Code>

<Value>62295002</Value>

<CodingSystem>SNOMED CT</CodingSystem>

</Code>

</Description>

<code
code="410.1"
codeSystemName="ICD9CM"
codeSystem="2.16.840.1.113883.6.2"
codeSystemVersion="2004">
<originalText>

Acute Anteroseptal Myocardial Infarction
</originalText>

<translation
code="62295002"
codeSystemName="SNOMED-CT"
codeSystem="2.16.840.1.113883.6.96">
<translation>

</code>

<Description>

<Text>

Acute Anteroseptal Myocardial Infarction

</Text>

<Code>

<Value>410.1</Value>

<CodingSystem>ICD-9 CM</CodingSystem>

<Version>2004</Version>

</Code>

<Code>

<CodingSystem>SNOMED CT</CodingSystem>

<Value>62695002</Value>

</Code>

<ObjectAttribute>

<Attribute>Diagnosis</Attribute>

<AttributeValue>

<Value>Myocardial Infarction</Value>

<Code>

<Value>22298006</Value>

<CodingSystem>
SNOMED CT

</CodingSystem>

</Code>

</AttributeValue>

</ObjectAttribute>

<ObjectAttribute>

<Attribute>Acuity</Attribute>

<AttributeValue>

<Value>Acute</Value>

<Code>

<Value>53737009</Value>

<CodingSystem>
SNOMED CT

</CodingSystem>

</Code>

</AttributeValue>

</ObjectAttribute>

<ObjectAttribute>

<Attribute>Site</Attribute>

<AttributeValue>

<Value>Anteroseptal</Value>

<Code>

<Value>20706007</Value>

<CodingSystem>
SNOMED CT

</CodingSystem>

</Code>

</AttributeValue>

</ObjectAttribute>

</Description>

<code
code="410.1"
codeSystemName="ICD9CM"
codeSystem="2.16.840.1.113883.6.2"
codeSystemVersion="2004">
<originalText>

Acute Anteroseptal Myocardial Infarction
</originalText>

<translation
code="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>

<qualifier>

<name code="363698007"
displayName="Finding" Site/>

<value code="20706007"
displayName="Anteroseptal"/>

</qualifier>

</translation>

</translation>

</code>

 

 

5.5.2 Coding System Usage

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.

 

Table 18. CCR <CodingSystem> values and corresponding CDA CD.codeSystem values

CCR <CodingSystem>CD.codeSystemCD.codeSystemName

CPT-4

2.16.840.1.113883.6.12

CPT-4

ICD-9 CM

2.16.840.1.113883.6.1

ICD-9 CM

LOINC

2.16.840.1.113883.6.1

LOINC

NDC

2.16.840.1.113883.6.69

NDC

RxNorm

2.16.840.1.113883.6.88

RxNorm

SNOMED CT

2.16.840.1.113883.6.96

SNOMED CT

 

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.

...

6 Acknowledgements

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.

-
Properties Prefix: ccd1- Default language: English (en-US) Contains reusable content?The contents of this 'project' are considered suitable for re-use by other projects when this setting is active. Is private?The project is not listed in the menus and ignored in searches when this setting is active. This useful for projects in incubation fase. You may still work in the project based on direct URLs Experimental/Test?Project is experimental or meant to test things rather than aimed at production use Notifier: Determines the project global issue notifier setting (on/off - default is 'on'). Note: changes to this setting are immediately saved.
Publication location
http://ccd1.art-decor.org/
Project overview Project Index
Project Id 2.16.840.1.113883.3.1937.777.4
Project Last modified 2023-10-24 08:11:21
Repository reference
Prefix URL Format
ad2bbr- http://art-decor.org/decor/services/ DECOR
RESTful Service
Contributors/Copyright
Contributor Type Logo Copyright years
ASTM
Author 2007
HL7
Health Level Seven International
3300 Washtenaw Avenue
Suite 227
Ann Arbor, MI 48104- 4261
USA
T +1 734 677 7777
F +1 734 677 6622
E info@hl7.org
Author 2007
The ART-DECOR expert group
The ART-DECOR expert group
E info@art-decor.org
E contact@art-decor.org
Author 2013 2014
Authors
Name Email Subscribe to all issuesEvery author is notified by default for events on issues where he is the author or from the moment he is assigned to an issue. If you would like to keep track of all issue updates, set this to 'on'
Co-Chair, Editor-in-Chief: Robert H. Dolin, MD Kaiser Permanente Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Co-Chair: Liora Alschuler Alschuler Associates Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Co-Chair: Calvin Beebe Mayo Clinic Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Co-Chair: Fred M. Behlen, PhD American College of Radiology Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Co-Chair: Keith W. Boone GE Healthcare Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Davera Gabriel, RN University of California Davis Health System Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor:Rick Geimer Alschuler Associates Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor:Gay Giannone, MSN, RN Siemens Medical Solutions Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: V. "Juggy" Jagannathan, PhD MedQuist Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Lawrence McKnight, MD Siemens Medical Solutions Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Patrick Mitchell-Jones Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Rick Peters, MD Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Dan Russler, MD Oracle Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Amnon Shabo (Shvo), PhD IBM Research Lab in Haifa Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Steven E. Waldren, MD, MS Center for Health Information Technology, AAFP Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Patricia A. Van Dyke The ODS Companies Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Bob Yencha Alschuler Associates Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Editor: Alan Zuckerman, MD Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
ART-DECOR Expert Group: Alexander Henket Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
ART-DECOR Expert Group: dr Kai Heitmann Not visibleThis info is only visible to this author and any decor-admin author Not visibleThis info is only visible to this author and any decor-admin author
Versions / Releases
Date By Description Status Publication
2019-09-19 Alexander Henket
Fixed Value Set AlertTypeCode id="2.16.840.1.113883.1.11.20.4" / effectiveDate="2006-10-17T00:00:00". This value set had incorrect contents, listing three status codes and missing 281647001 Adverse Reaction
2015-08-27 00:42:00 Alexander Henket
Scripted update of references by name (element/@contains, include/@ref, vocabulary/@valueSet) to references by id. References by name are strongly discouraged as they get ambiguous quickly.
Scripted updated to add template element and attribute ids
Manual update to fix references to CCDplayingDevice and CCDplayingEntity by adding the wrapping element. Synced the template CCDexternalDocument, CCDexternalObservation, CCDexternalProcedure, CCDexternalAct with ad1bbr repository as they were updated there. This fixed the missing wrapping element.
2013-01-10 ART-DECOR expert group
Initial version
MyCommunity
Display Name Name Description
Busy Retrieving…
Governance Groups
Busy Retrieving…
ART-DECOR Applications (ADA)
Application