Components of the iWay Integration Solution for HIPAA

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.

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

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

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
ST*835*998877
BPR*C*750*C*ACH*CTX*01*998877661*DA*338899*1872994342*885666666*01*11223
445*DA*143453454444*20020422
TRN*1*99887766554433*1872994342
REF*EV*R94395
DTM*405*20020423
N1*PR*BCBS MO
N3*123 MAIN STREET
N4*KANSAS CITY*MO*64108
N1*PE*GENERAL HOSPITAL*FI*871234599
N3*123 GENERAL ST
N4*DALLAS*TX*75043
LX*1
CLP*111222333*1*800*750*0*12*987654321
CAS*CO*A2*50
NM1*QC*1*DOE*JOHN*W***34*446928421
SVC*HC:99211*800*800
DTM*150*20020422
DTM*151*20020422
SE*19*998877
GE*1*1
IEA*1*000000905

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.