1.0 Introduction

As an introduction to the Healthcare Information Technology Standards Panel (HITSP) Patient-Provider Secure Messaging Interoperability Specification, this section provides a high level overview of the information sharing scenario enabled by following this specification, provides a document map of the construct relationships for the Interoperability Specification, acknowledges the copyright protections that pertain, and provides a list of key reference documents and background material.

1.1 Interoperability Specification Overview

This section provides a high level definition of this Interoperability Specification and background information about the underlying Use Case that it is based upon.

This HITSP Patient-Provider Secure Messaging Interoperability Specification describes the information flows, issues, and system capabilities that are required for patients to interact with their healthcare clinicians remotely using common computer technologies readily available in homes and other settings.

1.2 Interoperability Specification Document Map

Each HITSPInteroperability Specification (IS)is comprised of a suite of constructs that, taken as a whole, define how to integrate and constrain existing standards and specifications to satisfy the requirementsimposed by a given Use Case. TheIS groups specific actions and actors to describe the relevant context(s) for the use ofHITSP constructs that further identify and constrain standards where necessary. In addition to ISs, there are three other types of HITSP constructs called Transaction Packages (TP), Transactions (T), andComponents (C). The document map in Figure 1.2-1depicts how this IS integrates and constrains HITSP constructs to support the information exchange, within the defined context of the Use Case. Implementers should read the documents that describe the constructs depicted in the diagram for their details and specific uses. Note that the baseline Security and Privacy constructs are not shown in the diagram, however, they are described in Table 1-1 List of Constructs.

Figure 1-1 Interoperability Specification Document Map

1.2.1 List of Constructs

The following table lists and describes the HITSP constructs that are used by the Interoperability Specification. All references to HITSP specifications are to the current, and Panel approved Released for Implementation versions of the specifications retrieved from www.hitsp.org.

Where HITSP has adopted HL7 V3.0 CDA/CCD for conveying information between Electronic Health Record (EHR) and Personal Health Record (PHR) applications and in other healthcare scenarios, it has consolidated common constraints applied against the Content Modules in HITSP/C83CDA Content Modules.Likewise,HITSP/C80 Clinical Document and Message Terminology maintains commonly applied terminology constraints. Readers should refer to HITSP/TN901 Technical Note for Clinical Documents to better understand how HITSP/C83 and HITSP/C80 are used by other constructs that are based upon HL7 V3.0 CDA/CCD (e.g., HITSP/C32Summary Documents Using HL7 Continuity of Care Document (CCD), HITSP/C48Encounter Document Using IHE Medical Summary (XDS-MS) and HITSP/C84 Consult and History & Physical Note).

Table 1-1 List of Constructs

Construct

Description

HITSP/C19 - Entity Identity Assertion

The Entity Identity Assertion Component provides the mechanisms to ensure that an entity is the person or application that claims the identity provided. An example of this Component is the validation and assertion of a consumer logging on to a Personal Health Record (PHR) system

HITSP/C62 - Unstructured Document

The Unstructured Document Component is provided for the capture and storage of patient identifiable, unstructured document content, such as text, PDF, and images rendered in PDF. It is based on the Cross-Enterprise Sharing of Scanned Documents (XDS-SD) profile from the Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF)

HITSP/T15 - Collect and Communicate Security Audit Trail

The Collect and Communicate Security Audit Trail Transaction is a means to provide assurance that security policies are being followed or enforced and that risks are being mitigated. This document describes the mechanisms to define and identify security relevant events and the data to be collected and communicated as determined by policy, regulation or risk analysis. It also provides the mechanism to determine the record format to support analytical reports that are needed

HITSP/T16 - Consistent Time

The Consistent Time Transaction provides a mechanism to ensure that all of the entities that are communicating within the network have synchronized system clocks

HITSP/T17 - Secured Communication Channel

The Secured Communication Channel Transaction provides the mechanisms to ensure the authenticity, integrity, and confidentiality of transmissions, and the mutual trust between communicating parties. Its objectives include providing: mutual node authentication to assure each node of the others identity; transmission integrity to guard against improper information modification or destruction while in transit; and transmission confidentiality to ensure that information in transit is not disclosed to unauthorized individuals, entities, or processes

HITSP/T23 - Patient Demographics Query

The Patient Demographics Query Transaction is intended to provide a list patients and their demographics query/patient(s) and their demographics identified response message pair (QBP^Q22, RSP^K22) for use wherever such needs exist. This Transaction document extracts the Health Level Seven (HL7) version 2.5 Query and Response data mapping. The underlying basis for this extraction can be found in the Integrating the Healthcare Enterprise IT Infrastructure Technical Framework, Patient Demographics Query integration profile

HITSP/T31 - Document Reliable Interchange

The Document Reliable Interchange Transaction provides a standards-based mechanism for conveying a set of medical documents in a point-to-point network-based communication. This Transaction uses the IHE Cross-Enterprise Document Reliable Interchange (XDR) Integration Profile, a companion to the IHE Cross-Enterprise Document Sharing (XDS) Integration Profile. Cross-Enterprise Document Reliable Interchange (XDR) uses the XDS defined metadata formats in a simpler environment in which the communicating parties have agreed to a point-to-point interchange rather than communicating via document sharing

HITSP/TP20 - Access Control

The Access Control Transaction Package provides the mechanism for security authorizations which control the enforcement of security policies including: role-based access control; entity based access control; context based access control; and the execution of consent directives. An example of this is a functional role that has the permission to perform an act (e.g., consumer updating a Personal Health Record (PHR). In an emergency, this construct must support the capability to alter access privileges to the appropriate level (failsafe/emergency access), which may include override of non-emergency consents

HITSP/TP22 - Patient ID Cross-Referencing

The Patient ID Cross-Referencing Transaction Package is used for identifying and cross-referencing different attributes for the same patient. It contains a query for cross-reference and patient identity feed transactions. These transactions are used to identify patients from a list of potentials, and/or to communicate patient demographic data

HITSP/TP30 - Manage Consent Directives

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

1.3 Copyright Permissions

COPYRIGHT NOTICE

2008 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.

1.4 Reference Documents

This section provides a list of key reference documents and background material. If you are already familiar with this information, proceed to Section 2.

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-2 Reference Documents

Reference Document

Document Description

HITSP Acronyms List

Lists and defines the acronyms used in this document

HITSP Conventions List

Describes the conventions that are used to convey the full descriptions and usage of standards in the HITSP specifications

HITSP Glossary

Provides definitions for relevant terms used by HITSP documents

HITSP Harmonization Framework

Describes the current framework within which the Interoperability Specifications are built

HITSP Interoperability Specification Overview

Provides background information about the HITSP and its role in the overall U.S. efforts to realize large scale interoperability of health information. The document also provides a description of the HITSP process for healthcare standards harmonization and explains how to use the Interoperability Specifications and other related documents to inform your health IT system development or refinement

Patient-Provider Secure Messaging Use Case: March 21, 2008

AHIC Use Case that is the basis of this HITSP Interoperability Specification

TN900 - Security and Privacy Technical Note

Developed as a reference document to provide the overall context for use of the HITSP Security and Privacy constructs. It includes the following:

The scope, reference policy background, and Security and Privacy principles used in the development of the constructs

A detailed description and schematics of the conceptual relationship between the Security and Privacy constructs

A mapping of existing standards and constructs to be used in meeting the stated requirements of the AHIC Use Cases

A list of identified gaps and the recommended approaches to resolving those gaps

A roadmap for how the Security and Privacy constructs will evolve and eventually align with other HITSP Interoperability Specifications

A conceptual framework for Security and Privacy management, including reference information on privacy policies, risk assessment, and risk management

A description of the application of the Security and Privacy constructs to the HITSP Interoperability Specifications for the three initial AHIC Use Cases Biosurveillance, Electronic Health Records - Laboratory Results Reporting, and Consumer Empowerment

HITSP will periodically update this Technical Note as required by the introduction of new contexts for use.

TN901 - Technical Note for Clinical Documents

Developed as a reference document to provide the overall context for use of the HITSP Care Management and Health Records constructs. It includes the following:

The scope, background, and principles for use in the development of the CMHR constructs

A detailed description and schematics of the relationship between CMHR constructs

A conceptual framework for the construction of clinical documents

An overview of Clinical Document concepts

An overview of Vocabulary concepts

1.4.1 Glossary Term Clarifications

The following table lists HITSP Glossary Terms used by this Interoperability Specification where the meaning or intent of the term differs between the glossary and common practice. The intent of this section is not to re-define the HITSP Glossary Terms, but to point out subtle or significant differences between HITSP terms and those terms in general use within the industry segment described by this Interoperability Specification. Public comment is requested on these terms and definitions.

Table 1-3 Glossary Term Clarifications

Term

HITSP Glossary Definition and Clarification

Clinician

HITSP Glossary V1.2 does not include the term "clinician." A proposed definition is: "Refers to a person licensed, certified, or otherwise authorized or permitted by law to administer healthcare in the ordinary course of business or practice of a profession. This includes primary care physicians, other physicians, nurse-practitioners, physician assistants, etc. The definition of a clinician is not limited by the working environment: the clinician does not have to work within a hospital or other traditional healthcare organization or facility, a clinician may provide healthcare services within any business environment and still be considered a clinician. NOTE: HL7 uses "practitioner". The term "clinician does not include non-person entities such as healthcare facilities, clinics, hospitals, etc."

In common use, "clinician" is often used interchangeably with "provider" or "healthcare provider." However, the HITSP use of "healthcare provider" includes non-person entities. The use of "clinician" in this Interoperability Specification is purposeful to refer to people and to exclude non-person entities.

Clinician Support Staff

HITSP Glossary V1.2 does not include the term "Clinician Support Staff." A proposed definition is: "Refers to a person or group of people that assist Clinicians with business and clinical workflow who are not themselves permitted to administer healthcare."

Healthcare Provider

HITSP Glossary V1.2: "Refers to a person authorized or permitted by law to administer healthcare. The term "provider may also refer to healthcare facilities, clinics, hospitals, etc."

In common use, "healthcare provider" is often used interchangeably with "clinician." However, the HITSP use of "healthcare provider" is inclusive of individuals, facilities and organizations. The use of "healthcare provider" in this Interoperability Specification is purposeful to include these non-person entities.

Provider

HITSP Glossary V1.2 does not include the term "provider" but does define "healthcare provider."

This Interoperability Specification uses the terms "provider" and "healthcare provider" interchangeably. The preferred term is "healthcare provider."