Chapter 2 Overview of HIPAA PM

This chapter provides a general overview of HIPAA data structuring, as well as HIPAA PM and its place in Java CAPS, including system descriptions, general operations, and basic features.

This chapter contains the following topics:

• About the HIPAA Protocol

• HIPAA PM Overview

• About eXchange Integrator

• B2B Suite, eXchange, and Java CAPS

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:

1. Authorization Information Qualifier

2. Security Information Qualifier

3. Interchange ID Qualifier

4. Interchange Sender ID

5. Interchange ID Qualifier

6. Interchange Receiver ID

7. Date

8. Time

9. Repetition Separator

10. Interchange Control Version Number

11. Interchange Control Number

12. Acknowledgment Requested

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

HIPAA PM Overview

Because HIPAA PM integrates with eGate, eInsight, eXchange, and the HIPAA OTD Library, the product enables you to design Java CAPS Projects that process HIPAA messages. Message validation is handled through a third-party service.

For more information about eGate, eXchange, and the HIPAA OTD Library, see the corresponding user’s guides.

---

Note –

As you use this document, refer to the eXchange Integrator User’s Guide for information relating directly to eXchange operation.

---

Basic Operation

HIPAA PM allows you to test and validate your HIPAA transactions by performing calls to a third-party validation service. The HIPAA PM’s validation features allow you to do this operation. HIPAA PM validation supports HIPAA validation, which may consist of any certified HIPAA validation solution.

HIPAA PM and eXchange

eGate and eXchange enable you to build Java CAPS Projects that process standard B2B business protocols and enveloping protocols, such as HIPAA.

HIPAA PM works with eXchange to provide the following features during message processing:

• Message transport

• Message tracking

• Error handling

HIPAA PM and the HIPAA OTD Library

HIPAA messages within eGate are called HIPAA OTDs. The Java CAPS provides packaged HIPAA OTDs for eGate as part of the HIPAA OTD Library.

---

Note –

For more information on these OTDs, see the HIPAA OTD Library User’s Guide.

---

You can also build your own OTDs using the SEF OTD wizard supplied with Java CAPS. HIPAA PM provides packaged BP rules to handle HIPAA OTDs.

Third-party Validation

HIPAA PM allows your system to validate data using third-party services such as EDIFECS and Foresight.

When you import the xengine.jar and xe_extensions.jar files (see Initializing and Running Enterprise Designer) into your Logical Host directories, you enable validation through the EDIFECS XEngine.

For complete instructions on how to set up EDIFECS to validate HIPAA data, as well as how to use the EDIFECS XEngine, see the following Web site:

http://www.edifecs.com

From this Web site, search under EDIFECS XEngine for information on how to enable and use this feature to validate HIPAA data.

You need to create an environment variable XEROOTthat will contain the installation path of the EDIFECS XEngine.

---

Note –

HIPAA PM allows you to set outbound messages to be sent without Business Message Syntax validation, to speed up message processing. However, inbound message validation is always required.

---

To Set Up Foresight to Validate HIPAA Data

For complete instructions on how to set up Foresight to validate HIPAA data, see the following Web site:

http://www.foresightcorp.com

After you have installed the Foresight engine, do the following:

1. Create a new file,TI.csv using the SamplePartnerAutomation.csv file.

   For more information about the SamplePartnerAutomation.csv file, refer to the Foresight documentation.

2. Copy the TI.csv file to the HIPAAValidatorInstream/Bin directory.

3. Open the fsdir.ini file in an editor and modify the parameter PARTNERAUTOMATION.

   1. Remove the colon that is present before the parameter PARTNERAUTOMATION.

   2. Replace the SamplePartnerAutomation.csv file with the TI.csv file.

      PARTNERAUTOMATION="C:\ProgramFiles\HIPAA Validator Instream\Bin\TI.csv"

4. To start the application server on UNIX, you need to set the following Environment variables:

   1. Add the following path to the environment variable FSINSTREAMINI.

      ...ForesightInstallDir/Bin

   2. The LIBPATH(AIX), LD_LIBRARY_PATH(Sun OS), or SHLIB_PATH(HP-UX) needs to contain the value of the FSINSTREAMINI variable.

How HIPAA PM Messaging Works

HIPAA PM operates using the following basic functional layers:

• View: eInsight provides the ability to create and view the structure of HIPAA eXchange Projects, and the eXchange Message Tracking feature allows the searching and viewing of sent and received HIPAA messages. HIPAA PM Message Tracking includes interleaved error reports to allow pinpoint tracking of system messaging errors.

• Services Orchestration: You use the eXchange Partner Manager (ePM) to design HIPAA Transaction Sets; then the appropriate HIPAA Projects prepare and return the interchange and functional acknowledgments (TA1 and 997) to the TP. HIPAA Projects also perform message correlation to associate business responses to the related requests. A HIPAA B2B Host Project manages and coordinates the HIPAA messaging operations.

• Integration Services: The HIPAA Project handles Interchange Envelope (ISA) and Functional Group (GS) enveloping from incoming messages, prepares these envelopes for outgoing messages, batches together documents to be delivered as a single transaction (ISA), and records the activity in Message Tracking. You may configure these enveloping parameters using ePM.

Key Parts of EDI Processing Logic

The key parts of EDI processing logic are listed in Table 2–2.

Table 2–2 Key Parts of EDI Processing

Term	Description	Language Analogy	Java CAPS Component
Structures	Format, segments, loops	Syntax rules	OTD elements and fields
Validations	Data contents “edit” rules	Semantic rules	Not supported by HIPAA PM; handled by a third-party service
Translations (also called mappings)	Reformatting or conversion	Translation	Collaborations, Java Collaboration Definitions (JCDs)
Enveloping	Header and trailer segments	Envelope for a written letter	Special “envelope” OTDs: FunctionalGroupEnv and InterchangeEnv
Acks	Acknowledgments	Return receipt	Specific acknowledgment elements in the OTD

Java CAPS uses structures, translations, enveloping, and acknowledgments, as listed in Table 2–2 to support the HIPAA standard. The remainder of this section explains these terms in greater detail.

OTD Message Structures

The HIPAA OTD Library includes pre-built OTDs for messaging in all supported HIPAA versions. These OTDs can be viewed in the eGate OTD Editor but cannot be modified.

To customize an OTD structure , for example, in order to add a segment or loop , you must first create a .sef file (generally using a third-party application). You then use the SEF OTD wizard to generate the appropriate OTD from a given .sef file.

Translations, Enveloping, and Acknowledgments

Within each HIPAA OTD are Java methods and Java bean nodes for handling translations, enveloping, and acknowledgments. The marshal and unmarshal methods of the two envelope OTDs handle enveloping and de-enveloping.

No prebuilt translations are supplied with the HIPAA OTD Library. You build data translations with an eGate Enterprise Designer user interface called the Java Collaboration Editor (JCE).

---

Note –

In eGate, HIPAA translations are called Java Collaboration Definitions (JCDs).

---

You may also construct eGate XSLT Collaborations and/or eInsight BPs to perform translations.

Message Information Levels

The levels of information that guide the final format of a specific transaction are:

• HIPAA Protocol : The HIPAA Act mandates a standard structure for each HIPAA TP transaction. Specifically, since HIPAA regulations are law, it is important to follow the guidelines for these transactions as strictly as possible.

• TP Agreements : It is normal for TPs to have individual agreements that supplement the standard guidelines. The specific processing of the transactions in each TP’s individual system can vary from one site to another. As a result, additional documentation providing information about the differences is helpful to the site’s TPs and simplifies implementation. For example, although a certain code might be valid in an implementation guide, a specific TP might not use that code in transactions. In such a case, it is important to include that information in the TP agreement.

Using the SEF Wizard

You can use this product with custom SEF OTDs built with the SEF OTD wizard. The wizard supports the most current SEF versions.

The SEF OTD wizard does not handle the following information and sections:

• In the .SEMREFS section, semantic rules with its type of the “exit routine” are ignored as per SEF specification. An exit routine specifies an external routine (such as a COM-enabled server program supporting OLE automation) to run for translators or EDI data analyzers.

• The .TEXT sections (including subsections such as .TEXT,SETS, .TEXT,SEGS, .TEXT,COMS, and .TEXT,ELMS) are ignored, because these sections store information about changes in a standard’s text, such as notes, comments, names, purposes, descriptions, titles, semantic notes, explanations, and definitions.

About eXchange Integrator

eXchange Integrator provides an open Business Protocol framework to support standard EDI and B2B protocols, as well as packaging protocols. The eXchange product supports existing standard protocols, using an extensive set of prebuilt eInsight Business Processes (BPs). It also provides the tools and framework to create and adopt new protocols and to build custom BPs.

B2B modeling semantics are exposed so that eInsight Business Rules can be added and tailored to address the particular needs of providing eBusiness solutions. The tight integration with the rest of Java CAPS provides validation, logging, and reporting capabilities. Because each logical step within any Business Rule is accessible anywhere along the entire eInsight BP, the design tools provide complete end-to-end visibility.

---

Note –

For a complete explanation of eXchange and eInsight, as well as their operation, see the eXchange Integrator User’s Guide and eInsight Business Process Manager User’s Guide.

---

Understanding BPs

An eInsight BP is a collection of actions or operations that take place in your company, revolving around a specific business practice. These processes can involve a variety of participants and may include internal and external computer systems or employees.

In eXchange, you create a graphical representation of a business process called a BP model. When you are using the sample for a PM’s implementation scenario, the system uses the BPs necessary for scenario’s operation. The BPs specific to the sample scenario provided with the product have already been created for this scenario.

Trading Partner Overview

The architecture of eXchange centers around the concept of sending and receiving messages relative to one or more TPs. Each TP that you import or create and then configure corresponds to one of your business trading partners.

These TPs contain configurable transaction profiles for each individual TP relationship. You can configure TPs with Transaction Profiles and Schedules, within ePM, for use by run-time components.

Each Transaction Profile specifies which one or more BPs to use for the current transaction, where and how to receive inbound messages, how to configure and secure messages in their channels, and how and where to deliver outbound messages.

Process Overview

Using eXchange to create a business solution consists of the following phases:

• Design phase within Enterprise Designer

• Configuration/design phase within ePM

• Run-time phase

eXchange Partner Manager

ePM is a feature of eXchange you can use as a tool that allows you to configure eXchange for use with any of your PMs. You must set specific parameter values within ePM to ensure the correct operation of your Projects, for each protocol. This guide explains how to use and configure ePM, to set parameters relevant to this guide’s PM.

For more information on how to use ePM, see the eXchange Integrator User’s Guide.

B2B Suite, eXchange, and Java CAPS

eXchange is one of the products that make up the B2B Suite within Java CAPS. The B2B Suite products, including eXchange, provide a Web-based TP configuration and management solution for automating and securely managing business partner relationships. The products also facilitate real-time interaction between the enterprise and its TPs, suppliers, and customers.

As a part of Java CAPS, the B2B Suite provides the following benefits and features:

• B2B services using eXchange

• Protocol managing, specifically by the PMs

• Protocol formats contained in the OTD Libraries

• Trading partner management facility, that is, the ePM interface

• Archiving tool, the Message Tracking feature

The B2B Suite is tightly integrated with Java CAPS and runs as a group of components within Java CAPS environment. Figure 2–9 illustrates how the B2B Suite, eXchange, and other Java CAPS components work together, including eInsight.

Figure 2–9 Architecture of Java CAPS product stack