Components of the iWay Integration Solution for HIPAA


iWay business components used in the construction of a message flow for HIPAA transactions include:


iWay Software provides various e-Business Information Exchange (Ebix) files used in conjunction with the iWay integration solutions. In iWay Service Manager, the iWay Integration Solution for HIPAA contains an Ebix file for the supported HIPAA version.

An Ebix file for HIPAA is named HIPAA_Version.ebx, where Version is the HIPAA version number. For example, the Ebix file for HIPAA version 4010A1 is named HIPAA_4010A1.ebx.

For details on the supported HIPAA transaction sets, see Ebix-Supported Transaction Sets.

An Ebix is a collection of metadata that defines the structure of data. The Ebix supplied with the iWay Integration Solution for HIPAA defines the structure of supported HIPAA messages.

Each Ebix includes:

  • Pre-built data dictionaries. The structure of each HIPAA document is described by two data dictionaries:
    • Header dictionary, which describes the enveloping structure of the document.
    • Document dictionary, which describes the segments and elements that compose each document.

    The dictionaries from the Ebix are used to transform the structure of a document per HIPAA regulation.

  • XML schemas that define the structure and content of the HIPAA messages in iWay XML format.
  • HIPAA to XML transformation templates, and XML to HIPAA templates, for the supported HIPAA transaction sets.
  • Rule files for each message. The iWay Integration Solution for HIPAA uses these rule files to validate inbound and outbound documents.



A preparser is an iWay business component that converts a non-XML document into XML format. The preparser for the iWay Integration Solution for HIPAA converts an incoming HIPAA formatted document to iWay XML format.

The HipaaSplitterPreParser is provided by iWay Software for the iWay Integration Solution for HIPAA.


The HipaaSplitterPreParser (com.ibi.preparsers.HIPAASplitPP) parses a HIPAA input file that contains one or more interchanges (ISA) and multiple documents, and creates multiple XML output files. One XML output file is produced for each document.

For example, if the HIPAA input file contains three documents within one ISA, the HipaaSplitterPreParser creates three XML output files, one per document.

Use the HipaaSplitterPreParser for large files with multiple documents within one ISA; if there is a specific business requirement to create separate XML output files; or if you receive multiple documents within one ISA and want to separate each document for further business processing. You can also use the HipaaSplitterPreParser if there is only one document within the ISA.


The HIPAABatchSplitter (com.ibi.preparsers.XDHIPAABatchSplitter) parses a HIPAA input file that contains one or more interchanges (ISA) and multiple documents. You must use this preparser with the HIPAAPreParser (com.ibi.preparsers.XDHIPAApreParser). The HIPAABatchSplitter should not be used as a standalone preparser. To successfully transform an inbound HIPAA file using this preparser, you must also include the HIPAAPreParser in your channel inlet.

One XML output file is produced for each document that is processed through this inlet definition. For example, if your HIPAA input contains three documents within an ISA, the HIPAABatchSplitter / HIPAAPreparser will create three XML output files, one for each document.

Acknowledgement Service

An acknowledgement service is an iWay business component used in inbound processing to create a functional acknowledgement (997 or 999) for inbound messages.

An acknowledgement indicates that an inbound document was received and validated for structure against the appropriate standard. An acknowledgement does not indicate that a document was processed.

An acknowledgement is typically routed back to the originator of the inbound document or to the next step in the integration process. It is a best business practice to send an acknowledgement to the originator of the inbound document.

The acknowledgement service for the iWay Integration Solution for HIPAA is called HipaaAckAgent (com.ibi.agents.XDHipaaAckAgent).

Deidentification Service

The Deidentification service (com.ibi.agents.XDDeidentifyAgent) provides algorithms that can be used to implement the deidentification of protected health information in accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. Multiple algorithms can be configured since a combination of algorithms will be needed to deidentify the data correctly.

The Deidentification service takes an XML document as input. The first configured algorithm takes this document as input and modifies it in place. The result is fed into the next configured algorithm and so on. The result of the last configured algorithm is the XML document returned by the service.

For more information on configuring and using the Deidentification service, see the iWay Service Manager Component Reference Guide.


A preemitter is a logical process that handles a document immediately before transmission.

Typically a preemitter is used to convert an XML document to non-XML format. The iWay Integration Solution for HIPAA uses a preemitter in outbound processing to convert the XML-formatted HIPAA document to a HIPAA formatted document.

The XML structure must be compliant with the schema supplied in the Ebix.

The preemitter for the iWay Integration Solution for HIPAA is called XDHIPAAPreEmitter (com.ibi.preemit.XDHIPAAPreEmitter).

Data Segments and Data Elements

The following example provides a sample 835 Health Care Claim/Payment Advice document. Each line is called a Data Segment and begins with the Segment Name. For example, 'N1' represents the payer name and identification while 'CLP' represents the claim payment information.

ISA*00*          *00*          *ZZ*SUBMITTER ID   *ZZ*RECEIVER
ID    *020423*1453*U*00401*000000905*1*T*:
GS*HP*SENDER CODE*RECEIVER CODE*20020423*1455*1*X*004010X091A1

Following the Segment Name are a number of Data Elements. In the N1 segment, the code 'PR' stands for payer name and address. Data elements are separated by a single character, usually an asterisk (*). A segment ends with a single character-- in this example a tilde (~).

Other HIPAA documents such as an 820 Payment Order/Remittance Advice document will have their own sets of data segments and data elements. Segments such as the N1 overlap many transaction sets, but an 820 or 835 will have its own segments and elements that are unique to healthcare.

Any number of data segments come together to form a transaction set. In this example, there are 19, as shown in the control counter stored in the very last segment (SE).

Please note that the layout of an 835 Health Care Claim/Payment Advice document that is sent from insurance company #1 to a healthcare provider #2 will be different from the one that is sent by insurance company #3. As a result, healthcare providers must be able to process different 835 document layouts.

iWay Software