Return to detail page at www.hitsp.org	HITSP/C32
	Prev  TOC  Next

---

2.0 Component Definition

2.1 Context Overview

This Component describes the document content that summarizes a consumer's medical status for the purpose of health information exchange. While an EHR or PHR system can contain much more information, this Component only deals with the summary information to be exchanged between such systems as established as requirements described in AHIC Use Cases.

HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component is essentially a subset of the data in an EHR or PHR system that has been developed for interoperability purposes for specific business Use Cases. This subset contains the minimum critical or pertinent medical information of sections and data elements used in those business cases. The information in the subset of data to be exchanged and the EHR or PHR system must be consistent. Furthermore there should be no data elsewhere in the EHR or PHR system that would contradict the meaning of any data in the summary. The expectation is that consuming systems will be able to use the information received as appropriate information to input and/or update information in their instantiation of the healthcare record. This specification does not define the policies applicable to the import of this information.

2.1.1 Component Constraints

An Interoperability Specification (IS) may constrain this Component to satisfy the requirements of an information exchange scenario. An Interoperability Specification describes the specific context of exchange and may declare additional constraints, e.g., by requiring the presence of information modules that are otherwise described in this Component as optional. Thus, to satisfy the Use Case of a consumer updating their registration information and medication history, the IS may impose requirements on the exchange to always contain the Person Information and Medications modules.

This Component should not be used outside the context of an Interoperability Specification as this may result in loss of interoperability.

However, the modules defined in this Component are intended for use and reuse whenever summary information such as a consumer's patient registration, medical history, immunizations, or other information modules defined in this Component are needed. Individual modules defined in this specification may be reused in other defined document types, such as operative notes, to convey similar information in other Use Cases. HITSP has assigned template identifiers to the reusable information modules to facilitate this reuse and provide a method for implementers to declare conformance to the templates within this Component.

Specific constraints related to each of the modules are defined in HITSP/C83 CDA Content Modules. Vocabulary constraints on Content Modules data are specified in HITSP/C80 Clinical Document and Message Terminology.

Table 2-1 Component Constraints

2.1.2 Component Dependencies

Although no component dependencies exist, it is important to note the following dependencies that are specific to HITSP constructs:

Table 2-2 Component Dependencies

2.2 Rules for Implementing

2.2.1 Data Mapping

This section describes the specific Content Modules used by this Component. Implementers will need to refer to HITSP/C83 CDA Content Modules, to see the fields that HITSP is constraining differently from the standard.

Table 2-3 defines the Content Modules used by the HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component.

NOTE: Content Modules in this document map to the CCD Entry elements. The CCD sections themselves are not repeatable.

Table 2-3 Content Modules

2.2.1.1 Conformance Statements, Templates, and Identifiers

Conformance statements are used to provide explicit guidance, or rules, on the structure or content of a CDA document. These are identified as numbered statements, the format for the identifier is [docId]-[###] where docId is the mnemonic of the defining document, and the number is any numbering scheme. Note that conformance statement identifiers may not be stable over time; references in validation error reports or other specifications should also cite the specific version and date of publication of the Component where the conformance statement is located.

2.2.1.2 CDA Document

At the clinical document level, template identifiers are employed to assert which template(s) the document conforms to. A document may assert conformance to more than one template. Template identifiers for context specific documents are declared in the Interoperability Specifications where the context is defined.

C32-[CT1-19] A CDA Document SHALL declare conformance to this specification by including a <templateID> element with the root attribute set to the value 2.16.840.1.113883.3.88.11.32.1.

Asserting conformance to this specification via the inclusion of the Summary Document templateID indicates that additional constraints from this specification are followed when applicable.

Required modules from this specification shall be present and follow the associated constraints

Modules that have been explicitly prohibited shall not be included

Optional modules, when present, will follow the associated constraints if that module also asserts conformance to this document, i.e., includes the associated templates

Additional CCD entry elements (the equivalent to modules in this specification) may be present. The consumer of the document may choose to accept or exclude the additional content, but shall not reject the document solely based upon the presence of the additional content

2.2.2 Additional Guidelines and Examples

2.3 Standards

2.3.1 Regulatory Guidance

Table 2-4 Regulatory Guidance

2.3.2 Selected Standards

Table 2-5 Selected Standards

2.3.3 Informative Reference Standards

Table 2-6 Informative Reference Standards

---

	Return to detail page at www.hitsp.org	HITSP/C32
	Prev  TOC  Next