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:
The dictionaries from the Ebix are used to transform the structure of a document per HIPAA regulation.
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.
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.