1.0 Introduction

1.1 Overview

The Manage Consent Directives Transaction Package describes the messages needed to capture, manage, and communicate rights granted or withheld by a consumer to one or more identified entities in a defined role to access, collect, use, or disclose Individually Identifiable Health Information (IIHI), and also supports the delegation of the patients right to consent. The transactions described in this construct are intended to be carried out by:

HITSP/TP13 Manage Sharing of Documents: The registry that manages the consents may or may not be differentfrom the registry whichmanages the clinical documents;therefore the consents may not always be managed in the same place as the clinical documents

HITSP/T31 Document Reliable Interchange: For point to point exchange, a structured or unstructured consent directive may be sent alone or along with any documents and messages. The consent directive indicates the document or message content to which it applies.

HITSP/T33 Transfer of Documents on Media: For portable media exchange, a structured or unstructured consent directive may be sent alone or along with any documents and messages. The consent directive indicates the document or message content to which it applies.

A consumer of healthcare services is the individual establishing his/her personal consent directives and is hereby referred to throughout this document as the Consenter. The Consenter could be the individual consumer/patient, or a consumer/patient representative.

A consent directive is a record of a healthcare consumers privacy policy, which is in accordance with governing jurisdictional and organization privacy policies that grant or withhold consent:

To one or more identified entities in a defined role

To perform one or more operations (e.g., collect, access, use, disclose, amend, or delete)

On an instance or type of IIHI

For a purpose such as treatment, payment, operations, research, public health, quality measures, health status evaluation by third parties, or marketing

Under certain conditions, e.g., when unconscious

For specified time period, e.g., effective and expiration dates

In certain context, e.g., in an emergency

A consent directive is an instance of governing jurisdictional and organization privacy policies, which may or may not be backed up by a signed document (paper or electronic).

1.2 Copyright Permissions

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 Consent related vocabulary including Confidentiality Codes 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) International. Copies of this standard may be retrieved from the IHE Web Site at www.ihe.net .

1.3 Reference Documents

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

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 that provides the overall context for use of the HITSP Security and Privacy 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.

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