Sun B2B Suite HIPAA Protocol Manager User's Guide

About the HIPAA Protocol

The acronym HIPAA stands for the Health Insurance Portability and Accountability Act (of 1996). This law is designed to protect health care patients and ensure the fast, easy exchange of patient-related data. Among other things, the act makes specifications affecting standards of treatment and privacy rights.

The act provides a number of standardized transactions that can be used for such things as a health-care eligibility inquiry or a health care claim. The HIPAA protocol realizes these legal mandates in the form of a standardized, universal data-messaging format and structure.

HIPAA Message Structure

HIPAA messages have a message structure that indicates how data elements are organized and related to each other for a particular electronic data interchange (EDI) transaction.

Java CAPS Object Type Definitions

In the Java CAPS, message structures are defined as Object Type Definitions (OTDs).

Each OTD consists of the following elements:

Physical Hierarchy – The predefined way in which envelopes, segments, and data elements are organized to describe a particular HIPAA EDI transaction.
Delimiters – The specific predefined characters used to mark the beginning and end of envelopes, segments, and data elements.
Properties – The characteristics of a data element, such as the length of each element, default values, and indicators that specify attributes of a data part, for example, whether it is required, optional, or repeating.

Note –
Included with the HIPAA PM product is the HIPAA OTD Library. See the HIPAA OTD Library User’s Guide for details.

HIPAA OTD Usage

The Transaction Set structure of an invoice sent from one trading partner (TP) to another defines the header, trailer, segments, and data elements required by invoice transactions. The HIPAA OTD for a specific version includes Transaction Set structures for each of the transactions available in that version.

You can use these structures as provided, or customize them to suit your business needs. There is an OTD message structure for each HIPAA transaction.

Structure of HIPAA Envelopes

The rules for HIPAA envelope structure ensure the integrity of the data and the efficiency of the information exchange. The actual HIPAA message structure has primary levels that are hierarchical.

From highest to the lowest, they are:

Interchange envelope
Functional Group
Transaction Set

A schematic structure of HIPAA envelopes is shown in Figure 2–1. Each of these levels is explained in more detail in the remainder of this section.

Figure 2–1 HIPAA Envelope Schematic Diagram

Figure 2–2 HIPAA 997 (Functional Acknowledgment) Segment Table

Figure 2–2 shows the standard segment table for an HIPAA 997 (Functional Acknowledgment) as it appears in the HIPAA standard and in most industry-specific implementation guides.

Functional Groups (GS/GE)

Functional Groups, often referred to as the “inner envelope,” are made up of one or more Transaction Sets, all of the same type, which can be batched together into one transmission. The Functional Group is defined by the header and trailer segments.

The Functional Group Header (GS) segment appears at the beginning (the Functional Group Trailer, designated GE, segment appears at the end). Many Transaction Sets can be included in the Functional Group, but all transactions must be of the same type.

Within the Functional Group, each Transaction Set is assigned a functional identifier code, which is the first data element of the header segment. The Transaction Sets that constitute a specific Functional Group are identified by this functional ID code.

The GS segment contains:

Functional ID code (the two-letter transaction code; for example, PO for an 850 Purchase Order, HS for a 270 Eligibility, Coverage, or Benefit Inquiry) to indicate the type of transaction in the Functional Group
Identification of sender and receiver
Control information (the Functional Group control numbers in the header and trailer segments must be identical)
Date and time

The GE segment contains:

Number of Transaction Sets included
Group control number (originated and maintained by the sender)

See Figure 2–3 and Figure 2–4.

Figure 2–3 Example of a Functional Group Header (GS)

Figure 2–4 Example of a Functional Group Trailer (GE)

Interchange Envelopes (ISA/IEA)

The Interchange Envelope, often referred to as the “outer envelope,” is the wrapper for all the data to be sent in one transmission. It can contain multiple Functional Groups. This characteristic means that transactions of different types can be included in the interchange envelope, with each type of transaction stored in a separate Functional Group.

The Interchange Envelope is defined by the header and trailer. The Interchange Control Header (ISA) appears at the beginning (the Interchange Control Trailer, designated IEA appears at the end).

As well as enveloping one or more Functional Groups, the ISA (and IEA) segments include:

Data element separators and data segment terminator
Identification of sender and receiver
Control information (used to verify message was correctly received)
Authorization and security information, if applicable

The sequence of information transmitted is:

ISA
Optional interchange-related control segments
Actual message information, grouped by transaction type into Functional Groups
IEA

See Figure 2–5 and Figure 2–6.

Figure 2–5 Example of an Interchange Header (ISA)

The following list describes the ISA segments shown in Figure 2–5:

Authorization Information Qualifier
Security Information Qualifier
Interchange ID Qualifier
Interchange Sender ID
Interchange ID Qualifier
Interchange Receiver ID
Date
Time
Repetition Separator
Interchange Control Version Number
Interchange Control Number
Acknowledgment Requested
Usage Indicator

Figure 2–6 Example of an Interchange Trailer (IEA)

Transaction Sets (ST/SE)

Each Transaction Set also known as a transaction) contains:

Transaction Set header (designated ST)
Transaction Set trailer (designated SE)
Single message, enveloped within the header and footer

A Transaction Set has a three-digit code, a text title, and a two-letter code, for example, 997, Functional Acknowledgment (FA).

The Transaction Set is composed of logically related pieces of information grouped into units called segments. For example, one segment used in the Transaction Set might convey the address: city, state, postal code, and other geographical information. A Transaction Set may contain multiple segments. For example, the address segment might be used repeatedly to convey multiple sets of address information.

The HIPAA standard defines the sequence of segments in the Transaction Set and also the sequence of elements within each segment. The relationship between segments and elements can be compared to the relationship between records and fields in a database environment. See Figure 2–7 and Figure 2–8.

Figure 2–7 Example of a Transaction Set Header (ST)

Figure 2–8 Example of a Transaction Set Trailer (SE)

Elements of HIPAA Envelopes

HIPAA messages are all in ASCII text, with the single exception that the BIN segment is binary.

Each HIPAA message is made up of a combination of the following elements:

Data
Segments
Loops

Elements are separated by delimiters. The remainder of this section explains these elements.

Data Elements

The data element is the smallest named unit of information in the HIPAA standard. Data elements can be broken down into types. The distinction between the types is strictly a matter of how they are used.

The types are:

Simple: If a data element occurs in a segment outside the defined boundaries of a composite data structure, it is called a simple data element.
Composite: If a data element occurs as an ordinally positioned member of a composite data structure, it is called a composite data element. A telephone number is a simple example of a composite. It has a three-digit area code, which must precede the three-digit central office code, which must precede the final four digits.

Each data element has a unique reference number, and it also has a name, description, data type, and minimum and maximum length.

Segments

A segment is a logical grouping of data elements. In HIPAA, the same segment can be used for different purposes.

This means that a field’s meaning can change based on the segment, for example:

The NM1 segment is for any name (patient, provider, organization, doctor)
The DTP segment is for any date (date of birth, discharge date, coverage period)

For more information on the HIPAA enveloping segments, refer to the Web sites provided under Additional HIPAA References.

Loops

Loops are sets of repeating ordered segments.

In HIPAA you can locate elements by specifying:

Transaction Set ,for example, 270 or 271
Loop, for example, “info. receiver loop”
Occurrence of the loop
Segment, for example, BGN
Field number, for example, 01
Occurrence of the segment if it is a repeating segment

Delimiters

In an HIPAA message, the various delimiters are part of the syntax, dividing up the different elements of a message. The delimiters used in a message are defined in the interchange control header, the outermost layer enveloping the message.

For this reason, there is flexibility in the delimiters that are used. No suggested delimiters are recommended as part of the HIPAA standards, but the industry-specific implementation guides do have recommended delimiters.

The default delimiters used by the HIPAA OTD Library are the same as those recommended by the industry-specific implementation guides. These delimiters are shown in Table 2–1.

Table 2–1 Default Delimiters in the HIPAA OTD Library


Type of Delimiter	Default Value
Segment terminator	~ (tilde)
Data element separator	* (asterisk)
Subelement (component) separator	: (colon)

Within eXchange, delimiters are specified at the enveloping level. The delimiters defined for an envelope apply to all transactions in the same business service (a predefined dialog between the two parties).

If you do not specify delimiters and do not override them in the payload transactions fed into FROMINTERNAL, eXchange expects the default delimiters shown in Table 2–1.

Note –

It is important to note that errors could result if the transmitted data includes any of the characters that have been defined as delimiters. Specifically, the existence of asterisks within transmitted third-party validation data is a known issue in HIPAA and can cause problems with translation.

See Element Separator for information on the ePM delimiter parameter.

Acknowledgment Types

The HIPAA protocol includes the following types of acknowledgments:

TA1 Interchange Acknowledgment
997 Functional Acknowledgment

Note –
See Sample Scenario Business Description.

TA1, Interchange Acknowledgment

The TA1 Interchange Acknowledgment verifies the interchange envelopes only. The TA1 is a single segment and is unique in the sense that this single segment is transmitted without the GS/GE envelope structures. A TA1 acknowledgment can be included in an interchange with other Functional Groups and transactions.

997, Functional Acknowledgment

The Transaction Set 997 Functional Acknowledgment includes much more information than the TA1. This Transaction Set was designed to allow TPs to establish a comprehensive control function as part of the business exchange process.

There is a one-to-one correspondence between Transaction Set 997 and a Functional Group. Segments within this Transaction Set identify whether the Functional Group was accepted or rejected. Data elements that are incorrect can also be identified.

Many EDI implementations have incorporated the acknowledgment process into all of their electronic communications. Typically, Transaction Set 997 is used as a functional acknowledgment to a Functional Group that was transmitted previously.

Note –

Transaction Set 997 is the acknowledgment transaction recommended by HIPAA.

The acknowledgment of the receipt of a payment order is an important issue. Most corporate originators want to receive at least a Functional Acknowledgment (Transaction Set 997) from the beneficiary of the payment. Transaction Set 997 is created using the data about the identity and address of the originator found in the ISA and/or GS segments.

Formats: ANSI ASC X12 and XML

The HIPAA messages accept either the standard ANSI ASC X12 or XML formats as input, by default. You do not need to change the existing Business Protocols (BPs) or eGate Java Collaboration Definitions (JCDs) to specify the input format (standard data is ANSI X12 or XML).

For more information about HIPAA, see the Web sites listed under Additional HIPAA References.

For more information on the ASC X12 protocol, see the following Web site: http://www.x12.org/

For more information on the XML messaging, see the following Web site: http://www.xml.com/