1.0 Introduction

1.1 Overview

The HITSP Case Report Pre-Populate Component supports the Data Mapping needed for Public Health Case Reports including:

Drug Safety

Device Safety

Drug Administration Management

Vaccine Adverse Event Report

Food Safety

Reportable Disease Reports

Healthcare Associated Infection

Other Healthcare safety reports other than Infection (e.g. falls) (including sentinel events; all never-events, anything that may become a never-event; AHRQ)

This Component addresses pre-populating a form supported by HITSP/TP50 Retrieve Form for Data Capture. It supports only those data attributes that are universal or that pertain to drug safety reporting. For those attributes that are available in a CDA document this Component may be used in support of pre-populating the report. For those attributes that are universal for case reporting but not available in a CDA document refer to the Interoperability Specification for any further information or specific constraints. Other public health specific attributes will be addressed in subsequent releases.

1.2 Copyright Permissions

COPYRIGHT NOTICE

2009 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 ANSIs copyright is clearly noted.

Certain materials contained in this Interoperability Specification are reproduced from HL7 Version 2.5.1 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.

IHE materials used in this document have been extracted from relevant copyrighted materials with permission of Integrating the Healthcare Enterprise (IHE). Copies of this standard may be retrieved from the IHE Website at www.ihe.net.

1.3 Reference Documents

This section provides a list of key reference documents and background material.

A list of key reference documents and background material is provided in the table below. These documents can be retrieved from www.hitsp.org.

Table 1-1 Reference Documents

Reference Document

Document Description

HITSP Acronyms List

Lists and defines the acronyms used in this document

HITSP Glossary

Provides definitions for relevant terms used by HITSP documents

TN900 - Security and Privacy

TN900 is a reference document to provide the overall context for use of the HITSP Security and Privacy constructs

TN901 - Clinical Documents

TN901 is a reference document to provide the overall context for use of the HITSP Care Management and Health Records 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, 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 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 to claim conformance.