Documents

The HITSP Portal contains data for health interoperability specifications and related constructs, such as C32, C80, C83, and C154.
These specifications have been registered and structured to support research, analysis and comparison.

Artifacts

Resources

The APCD portal offers a convenient set of tools for users to compare and download All-Payer Claims reporting specifications from single
state and multiple states, as well as the APCD council core specification.

Topic Area Views

User Tools

The Children's EHR Format (the Format) is a set of child-specific requirements (and other requirements of special importance for children) that an EHR should meet to perform optimally for the particular health care needs of children. The Format is provided by the Agency for Healthcare Research and Quality (AHRQ) and the Centers for Medicare & Medicaid Services (CMS).

1. Introduction

1.1 Overview

The purpose of the Health Information Technology Standards Panel (HITSP) Clinical Document and Message Terminology Component is to define the vocabulary for either document-based or message-based HITSP constructs such as Clinical Document Architecture (CDA) documents, HL7 V2 messages, etc. For more in-depth information about how this Component relates to other HITSP constructs, see HITSP/TN901 Clinical Documents.

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.

2.1.1 Value Set Metadata

The Value Sets in this document are defined in a table as shown below.

Element

Description

Identifier

This is the unique identifier of the value set

Name

This is the name of the Value Set

Source

This is the source of the Value Set, identifying the originator or publisher of the information

URL

A URL referencing the Value Set members or its definition at the time of publication

Purpose

Brief description about the general purpose of Value Set

Definition

A text definition formally describing how concepts in the Value Set are (intensional) or were (extensional) selected

Version

This row contains a string identifying, where necessary, the specific version of the Value Set

Type

Extensional (Enumerated) or Intensional (Criteria-based)

Binding

Static or Dynamic

Status

Active (Current) or Inactive (Retired)

Effective Date

The date when the Value Set is expected to be effective

Expiration Date

The date when the Value Set is no longer expected to be used

Creation Date

The date of creation of the Value Set

Revision Date

The date of revision of the Value Set

Code System Source

This row identifies the source for the code system

Code System Name

This row provides the name of the code system associated with the Value Set

2.2 Rules for Implementing Value Sets

The use of this construct is defined by the Component, Transaction, Transaction Package, Capability or Interoperability Specification that may refer to it

2.2.1 General Information Value Sets

See Value Sets: State, Postal Code, and Country Value Sets for details

2.2.3.10 Advance Directives

2.2.3.11 Genetic Testing

The following sections describe the value sets selected for reporting the results of genetic tests. See Value Sets: Genetic Test Result Identifier, Genetic Test Result for details

2.2.3.12 Genetic Disease

This identifies genetic diseases. See Value Set 2.2.3.1.1 Problems for details

2.2.3.13 Medication Assessed in Genetic Test

This identifies the medication assessed for the genetic test. See Value Set 2.2.3.3.8 Medication Clinical Drug Name for details

2.2.3.15 Document Metadata

The following sections describe the value sets selected for recording document metadata in transactions used to register and exchange clinical documents. Descriptions of the value sets in this section are drawn from the IHE IT Infrastructure Technical Framework, Volume II, Release 4.0. Only those metadata elements that require coded values are listed in this section; other fields should be provided as described in the relevant base standard. See Value Sets: Document Class, Document Type, Healthcare Facility Type, Clinical Specialty, Format Code, Author Role for details