1.1 Overview

The purpose of the Healthcare Information Technology Standards Panel (HITSP) CDA Content Modules Component is to define the library of Components that may be used by CDA-based constructs developed by HITSP and others in standards based exchanges. The Components are organized into modules to simplify navigation. These modules are organized along the same principals as the HL7 Continuity of Care Document.

The data elements found in these modules are based on HL7 CDA Implementation Guides and the IHE PCC Technical Framework Volume II, Release 5 and its related supplements. These guides contain specifications for document sections that are consistent with all clinical documents currently selected for HITSP constructs.

1.2 Copyright Permissions

COPYRIGHT NOTICE
© 2010 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSI's copyright is clearly noted.
Certain materials contained in this Interoperability Specification are reproduced from HL7 Version 3 Standard: Core Principals with permission of Health Level Seven, Inc. No part of the material may be copied or reproduced in any form outside of the Interoperability Specification documents, including an electronic retrieval system, or made available on the Internet without the prior written permission of Health Level Seven, Inc. Copies of standards included in this Interoperability Specification may be purchased from the Health Level Seven, Inc. Material drawn from these standards is credited where used.

1.3 Reference Documents

A list of key reference documents and background material is provided in the table below. HITSP-maintained reference documents can be retrieved from the HITSP Web Site.

Reference Document	Document Description
HITSP Acronyms List [publicaa.ansi.org]	Lists and defines the acronyms used in this document
HITSP Glossary [publicaa.ansi.org]	Provides definitions for relevant terms used by HITSP documents
TN901 - Clinical Documents	TN901 is a reference document that provides the overall context for use of the HITSP Care Management and Health Records constructs
TN903 - Data Architecture	TN903 is a reference document that provides the overall context for use of the HITSP Data Architecture constructs

1.4 Conformance

This section describes the conformance criteria, which are objective statements of requirements that can be used to determine if a specific behavior, function, interface, or code set has been implemented correctly.

1.4.1 Conformance Criteria

In order to claim conformance to this construct specification, an implementation must satisfy all the requirements and mandatory statements listed in this specification, the associated HITSP Interoperability Specification or Capability, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must also implement all of the required interfaces within the scope, subset or implementation option that is selected from the associated Interoperability Specification.Claims of conformance may only be made for the overall HITSP Interoperability Specification or Capability with which this construct is associated.

1.4.2 Conformance Scoping, Subsetting and Options

A HITSP Interoperability Specification or Capability must be implemented in its entirety for an implementation to claim conformance to the specification. HITSP may define the permissibility for interface scoping, subsetting or implementation options by which the specification may be implemented in a limited manner. Such scoping, subsetting and options may extend to associated constructs, such as this construct. This construct must implement all requirements within the selected scope, subset or options as defined in the associated Interoperability Specification or Capability to claim conformance.

1.4.3 Use of Vocabulary Recommended to Support ARRA HITECH

This HITSP Component has been modified to support vocabularies allowed for meaningful use and other American Recovery and Reinvestment ACT (ARRA) HITECH requirements for all Components that rely upon it.

In almost all cases, coded values in the HITSP/C83 specifications are either optional (O) or required if known (R2) instead of required (R). In these cases, it is permissible to include a <code> element1 using a nullFlavor of UNK indicating that the information is unknown, and include <translation> The following example shows a case where the elements which indicate codes from other code systems

The following example shows a case where the <value> element in a condition entry includes the optional coded value for the Problem Code data element.

                                            <!-- These examples assume the default namespace is 'urn:hl7-org:v3' -->
                                            <observation classCode='OBS' moodCode='EVN'>
                                                <templateId root='2.16.840.1.113883.10.20.1.28'/> 
                                                    ...
                                                <value xsi:type='CD' code='37796009' displayName='Migraine'
                                                    codeSystem='2.16.840.1.113883.96' codeSystemName='SNOMED CT'/>
                                            </observation>
                                        

Because Problem Code is optional, the following is also a legal rendition for the <value> element. The value element is present; it just does not include the optional coded concept.

                                            <!-- These examples assume the default namespace is 'urn:hl7-org:v3' -->
                                            <observation classCode='OBS' moodCode='EVN'>
                                                <templateId root='2.16.840.1.113883.10.20.1.28'/>
                                                    ...
                                                <value xsi:type='CD' nullFlavor='UNK'>
                                                <translation code='346.9' displayName='Migraine'
                                                    codeSystem='2.16.840.1.113883.6.103'
                                                    codeSystemName='ICD-9-CM'/>
                                                </value>
                                            <observation>
                                        

To clarify this, we have changed the mapping for coded information in this specification to be more precise. Where these mappings formerly identified the XML element where the coded information is to be obtained (typically cda:code or cda:value elements), they now identify the specific attribute where the coded information is expected to be present. The effect on the mapping tables is that what was formerly:

CDA Data Location	HITSP Data Element Identifier and Name	O/R	Additional Specification
cda:code	7.02 - Problem Type	R2/N	2.2.2.7.3
cda:value	7.04 - Problem Code	O/N	2.2.2.7.5

Optionality Legend: "R" for Required, "R2" for Required if known, "O" for Optional and Repeat = "Y" for Yes or "N" for No

Now appears as:

CDA Data Location	HITSP Data Element Identifier and Name	O/R	Additional Specification
cda:code/@code	7.02 - Problem Type	R2/N	2.2.2.7.3
cda:value/@code	7.04 - Problem Code	O/N	2.2.2.7.5

Optionality Legend: "R" for Required, "R2" for Required if known, "O" for Optional and Repeat = "Y" for Yes or "N" for No

These changes are technical and reflect the original intent of the Care Management and Health Records Domain Technical Committee in the construction of the HITSP/C83 specification. Therefore no template identifiers have been changed where these changes have been made.

In only two cases does this specification require absolute adherence to a specific vocabulary.

CDA Data Location	HITSP Data Element Identifier and Name	O/R	Additional Specification
cda:administrativeGenderCode/@code	1.06 - Gender	R2/N	2.2.2.1.4
cda:code/@code	6.02 - Adverse Event Type	O/N	2.2.2.6.2

Optionality Legend: "R" for Required, "R2" for Required if known, "O" for Optional and Repeat = "Y" for Yes or "N" for No

• 1.06 Gender, it was felt that adherence to a vocabulary containing only 3 elements for a commonly understood construct could be met by all producers using the HITSP supplied vocabulary
• 6.02 Adverse Event Type, producers who are unable to classify allergies according to the HITSP vocabulary SHALL use the code 420134006 Propensity to adverse reactions as the code instead of using nullFlavor='UNK' value. In the context of adverse reactions, this code indicates the presence of an adverse reaction of an unknown type to an unknown substance and is preferable to (and equivalent in meaning to) the use of nullFlavor='UNK'

Vocabulary constraints were relaxed from Required (R) to Required if Known (R2) for the following two data elements and the template identifier was updated to reflect this change:

• 5.09 - Patient Relationship to Subscriber
• 5.14 - Financial Responsibility Party Type

Finally, while the requirements for codes on (laboratory) results have not been relaxed, the underlying vocabulary requirements on the result type data element recommend, rather than require specific vocabulary.

1.5 Document Conventions

1.5.1 Key Words

The key words SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119 and will appear when used in that fashion in this TYPEFACE.

The key words REQUIRED and OPTIONAL are also to be interpreted as described in RFC 2119 when they are used to indicate the optionality of components used in an exchange.

1.5.2 Constraints

Constraints in this document will appear as shown below.

C83-[DE-7.04-1]

The problem type SHALL be coded as specified in HITSP/C80 section 2.2.1.1.4.1.2 Problem Type. The first portion identifies the type of artifact being constrained. The second portion is the identifier for that artifact, and the final portion is the sequence number of the constraint on that artifact within this document. Constraints specific to CDA usage will contain the string CDA before the final number

2.2.1 CDA Sections

Two types of content components are specified in this section, they are:

• CDA Entries - a collection of Data Elements pertaining to a single instance of the specified concept. For example, the Allergy/Drug Sensitivity Entry Module describes all the Data Elements for one allergy
• CDA Sections - a collection of Entries pertaining to a single specified concept. For example, the Allergies and Other Adverse Reactions Section can contain a list of allergies (multiple Entry Content Modules)

CDA Sections are typically selected from specifications created by SDOs, such as the HL7 Implementation Guides and IHE Integration Profiles. Definitions for the document sections below are adapted from the IHE Patient Care Coordination Technical Framework, Volume II, Release 5.0, HL7 Implementation Guides for CDA Release 2.0: Consult Note, History and Physical (H&P) Notes, or Operative Note and are used with permission.

Please note that we have added template identifiers to each of the sections that follow. These template identifiers are recommended to be used in exchanges, but are not required due to restrictions on major change. It is possible that these identifiers could be required in future editions of this specification.

CDA Sections	CDA Entries
2.2.1.1 Payers Section	2.2.2.1 Personal Information
2.2.1.2 Allergies and Other Adverse Reactions Section	2.2.2.2 Language Spoken
2.2.1.3 Problem List Section	2.2.2.3 Support
2.2.1.4 History of Past Illness Section	2.2.2.4 Healthcare Provider
2.2.1.5 Chief Complaint Section	2.2.2.5 Insurance Provider
2.2.1.6 Reason for Referral Section	2.2.2.6 Allergy/Drug Sensitivity
2.2.1.7 History of Present Illness Section	2.2.2.7 Condition
2.2.1.8 List of Surgeries Section	2.2.2.8 Medication
2.2.1.9 Functional Status Section	2.2.2.9 Pregnancy
2.2.1.10 Hospital Admission Diagnosis Section	2.2.2.10 Information Source
2.2.1.11 Discharge Diagnosis Section	2.2.2.11 Comment
2.2.1.12 Medications Section	2.2.2.12 Advance Directive
2.2.1.13 Admission Medications History Section	2.2.2.13 Immunization
2.2.1.14 Hospital Discharge Medications Section	2.2.2.14 Vital Sign
2.2.1.15 Medications Administered Section	2.2.2.15 Result
2.2.1.16 Advance Directives Section	2.2.2.16 Encounter
2.2.1.17 Immunizations Section	2.2.2.17 Procedure
2.2.1.18 Physical Examination Section	2.2.2.18 Family History
2.2.1.19 Vital Signs Section	2.2.2.19 Social History
2.2.1.20 Review of Systems Section	2.2.2.20 Medical Equipment
2.2.1.21 Hospital Course Section	2.2.2.21 Functional Status
2.2.1.22 Diagnostic Results Section	2.2.2.22 Plan Of Care
2.2.1.23 Assessment and Plan Section
2.2.1.24 Plan of Care Section
2.2.1.25 Family History Section
2.2.1.26 Social History Section
2.2.1.27 Encounters Section
2.2.1.28 Medical Equipment Section
2.2.1.29 Preoperative Diagnosis Section
2.2.1.30 Postoperative Diagnosis Section
2.2.1.31 Surgery Description Section
2.2.1.32 Surgical Operation Note Findings Section
2.2.1.33 Anesthesia Section
2.2.1.34 Estimated Blood Loss Section
2.2.1.35 Specimens Section
2.2.1.36 Complications Section
2.2.1.37 Planned Procedure Section
2.2.1.38 Indications Section
2.2.1.39 Disposition Section
2.2.1.40 Operative Note Fluids Section
2.2.1.41 Operative Note Surgical Procedure Section
2.2.1.42 Surgical Drains Section
2.2.1.43 Implants Section
2.2.1.44 Assessments Section
2.2.1.45 Procedures and Interventions Section
2.2.1.46 Provider Orders Section
2.2.1.47 Questionnaire Assessment Section