1.0 Introduction

1.1 Overview

This HITSP Patient Health Plan Authorization Request and Response Transaction is intended to provide a mechanism for a healthcare provider (other than a retail pharmacy) to request approval from a health plan to authorize certain healthcare services, when required by the patients health plan contract. The health plan responds to the healthcare provider(s) authorization request for approval of service(s). The information exchanged includes, but is not limited to, approval status for coverage, allowed service provider(s), and certification dates for services that are included in the patients health plan benefits. The response from the health plan indicates that the health plan has determined that the particular service(s) will or will not be covered, and what is the level of coverage if that information is available from the health plan.

The term Health Plan as used in this document encompasses a review entity, utilization management organization, payer, third party administrator, processor, health plan, or any entity performing the authorization approval process on behalf of the health plan. While each of these entities may perform other functions in the healthcare arena, the function is grouped together in this guide, under one term Health Plan.

To support Patient Health Plan Authorization Request and Response Transaction, the HITSP Administrative and Financial Domain Technical Committee (DTC) is using the Accredited Standards Committee (ASC) X12 Insurance Subcommittee X12N Implementation Guide Version 004010X94 plus Addenda 004010X94A1. This X12N Implementation Guide is also being constrained by the HITSP Technical Committee to facilitate the exchange of the HIPAA adopted X12N 278 Health Care Service Review Information Transactions between a healthcare provider (Information Requester) and a utilization management organization (Information Source). The X12N 278 Health Care Service Review Information Transactions is a bi-directional transaction set consisting of two transactions; the first transaction is used to request a healthcare service review and the second transaction is the associated response to that request.

This Transaction may not define all functions, constructs and standards necessary to implement a conforming system in a real world environment. In particular, an implementer must provide the technical infrastructure and security framework necessary to support operations in accordance with law, regulation, best practices and business agreements.

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.

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