Sun B2B Suite HIPAA OTD Library User's Guide

Chapter 1 Overview of the HIPAA OTD Library

This chapter provides an overview of the HIPAA OTD Library as well as its support for validation.

This chapter contains the following topics:

About the HIPAA OTD Library

HIPAA is an acronym for the Health Insurance Portability and Accountability Act of 1996. This Act is designed to protect patients. Among other things, it makes specifications affecting standards of treatment and privacy rights. These specifications provide a number of standardized transactions that can be used for such things as a healthcare eligibility inquiry or a healthcare claim.

For more information on HIPAA, visit the following Web sites:

For more information on NCPDP, visit the official NCPDP web site at this address:

The HIPAA Object Type Definition (OTD) Library provides OTDs for the 2000 Standard and 2000 Addenda HIPAA messages.

HIPAA messages have a message structure, which indicates how data elements are organized and related to each other for a particular EDI transaction. In Java CAPS, message structures are defined as OTDs. Each OTD consists of the following:

The HIPAA OTD Library provides HIPAA OTDs that you can use to build Java CAPS Projects for interfacing with HIPAA systems. You can use the OTDs with eGate Integrator or in combination with eXchange Integrator and eGate Integrator.

HIPAA Validation Support

Within each HIPAA OTD are Java methods and Java bean nodes for handling validation as described in performValidation. No pre-built translations are supplied with the OTD libraries. These translations can be built in the Java Collaboration Editor.

HIPAA OTDs have validations and translations, but a validation does not generate an acknowledgment transaction. Instead, the validation generates a string.

The output string of the validation (seecheck and checkAll) is in XML format conforming to the X12OTDErrors.xsd file. Refer to Contents of the X12OTDErrors.xsd File for more information. For a sample of the validation output XML, refer to Sample of Validation Output XML.

On Demand Parsing

For performance enhancement reasons, the unmarshal()method does not unmarshal the entire message to the leaf element and subelement level. Instead, this method does the following:

This behavior is also referred to as “parse on demand,” meaning that elements within a segment or composite are not unmarshaled until an element in that segment or composite is accessed by a getxxx() method invoked in a Collaboration or during marshaling. The OTD may assign unmarshaled segments and composites to a pool that is ready to be freed from memory by the Java Virtual Machine software. Once these segments or composites are freed from memory, they become unparsed. If the element within the segment or composite is accessed again, the OTD reparses the segment or composite.

By default, HIPAA OTDs set no limit of parsed segments or composites held in memory. You can specify a limit for parsed and freed segments or composites by using the following methods at the OTD root levels:

You can use these methods to set and control the runtime memory use of the unmarshaling process.

Sample of ANSI Output

This section shows an excerpt of the XML X12 4010 850 in ANSI format:


ISA*00* *00* *01*9012345720000 *01*9088877320000 *011001*1718*U*
00200*000000001*0*T*:~GS*PO*901234572000*908887732000*20011001*1615*1*T*004010~ST*
850*0001~BEG*01*BK*99AKDF9DAL393*39483920193843*20011001*AN3920943*AC*IBM*02*AE*02*
BA~CUR*AC*USA*.2939*SE*USA*IMF*002*20011001*0718*021*20011001*1952*038*20011001*161
5*002*20011001*0718*021*20011001*1952~REF*AB*3920394930203*GENERAL PURPOSE*BT:123456
78900987654321768958473:CM:500:AB:3920394930203~PER*AC*ARTHUR JONES*TE*(614)555
-1212*TE*(614)555-1212*TE*(614)555-1212*ADDL CONTACT

Note –

The HIPAA OTDs accept standard ANSI X12 format . You do not need to change the existing Business Processes or Collaborations to specify the input format. The standard data is ANSI X12. By default, the OTD output is ANSI. To change the output to XML (reserved for future use), use the setXmlOutput (boolean) method. For information, refer to setXmlOutput. To verify whether the output is XML (reserved for future use), use the getXmlOutput() method. For information, refer to getXmlOutput.


Errors and Exceptions

For all HIPAA OTDs, including the envelope OTDs, when the incoming message cannot be parsed, for example, if the OTD cannot find the ISA segment, then the unmarshal() method generates a com.stc.otd.runtime.UnmarshalException.

The cause of the UnmarshalException depends on which envelope threw the exception:

You can also use the isUnmarshalComplete() method on an OTD to verify whether the unmarshal() method completed successfully. Successful completion does not guarantee that the OTD instance is free of data errors within segments and composites because elements are not unmarshaled until the first invocation of the leaf element getElementXxxx() method of a segment or composite. For more information, refer to On Demand Parsing.

Encountering this exception triggers an automatic background unmarshal of the entire segment. Note that the value returned by the isUnmarshalComplete() method is not influenced by the outcome of the automatic background unmarshal, instead, its value reflects what was set by the explicit invocation of the unmarshal() method.

ISA Segment Parsing

The ISA segment in a HIPAA message is of fixed length, and has sixteen fixed-length data fields. The fixed-length property of the ISA segment enables you to define the fixed positions for delimiters, such as segment terminator and element separator, that are critical for parsing the HIPAA message. Logic has been built into the fully-enveloped OTDs, including the HIPAA Interchange Envelope OTD to retrieve the delimiters at certain fixed positions and use these delimiters to unmarshal the message.

However, if any of the sixteen data fields is longer or shorter than defined in the specification, the positions of delimiters are nonstandard. This error will result in parsing difficulties and probable runtime failure. In some cases, data that is specified incorrectly in this way can cause conflicting delimiter values, such as element separator defined the same as segment terminator, rendering the whole message unparsable.

Steps Taken to Check for ISA Segment Errors

Assuming valid data, the logic for checking ISA segment errors is as follows:

  1. Check whether the character at index=3 is a valid element separator. If not, an UnmarshalException is thrown, and the unmarshaling process is terminated.

  2. Check whether the characters at index=6,17,20,31,34,50,53,69,76,81,83,89,99,101,103 is same as that at index=3. If not, an UnmarshalException is thrown with an error message that begins "ISA Segment Error", and processing continues with variable length parsing.

  3. Check whether the character at index=104 is a valid subelement separator. If not, an UnmarshalException is thrown with an error message that begins "ISA Segment Error", and processing continues with variable-length parsing.

  4. Check whether the character at index=105 is a valid segment terminator, and also verify that this character is different from the element separator and subelement separator. If not, an UnmarshalException is thrown with an error message that begins "ISA Segment Error", and processing continues with variable-length parsing.

  5. If the version of X12 is version 4020 or later, check whether the character at index=82 is a valid repetition separator and different from the element separator, subelement separator, and segment terminator. If not, an UnmarshalException is thrown with an error message that begins "ISA Segment Error", and processing continues with variable-length parsing.

  6. If variable-length parsing becomes necessary, the ISA segment is parsed using the element separator to retrieve the next sixteeen data elements. After this ISA parsing, an UnmarshalException is thrown with an error message that begins "ISA Segment Error", and the OTD with ISA segment parsed may be examined later to retrieve the parsed ISA segment.

If the message does not have a terminator for its last segment , the ISA segment is also parsed before an UnmarshalException is thrown. You can catch this UnmarshalException and examine the parsed ISA segment in the OTD, for example, to generate negative TA1 acknowledgment.