HIPAA Transaction Manager User's Guide
|Chapter 2: Running HIPAA Transaction Manager|
|How HIPAA Transaction Manager works|
Figure 2-1 illustrates how you can use HIPAA Transaction Manager's splitting and merging functionality within a customized workflow. Your actual implementation of HIPAA Transaction Manager may be more or less complex.
A detailed description of the workflow follows the diagram and introduces HIPAA Transaction Manager's split and merge concepts. See "Primary flow" and "Recovery flow".Figure 2-1: Using HIPAA Transaction Manager
In the Primary Flow (activity above the dotted line), the following processes occur:
An X12 data file is received, where it runs through HIPAA Implementation Guide compliance maps. See "Recovery flow" for data that fails HIPAA compliance.
The 997 Functional Acknowledgement and optional TA1 segments are generated so the originator of the data can receive a status on how the X12 data processed through the HIPAA compliance maps.
Transactions that pass HIPAA compliance run through translation maps and then pass to the claims adjudication process.
In the Recovery Flow (activity below the dotted line), the following process applies to data that fails the initial HIPAA compliance validation tests:
Data that fails HIPAA compliance testing is reprocessed through less stringent compliance maps that assure structural compliance with HIPAA transactions. Non-structurally compliant data is rejected as before, at the transaction level, while structurally compliant data is then processed further to recover compliant claims that were rejected because they were bundled into the same transaction with one or more noncompliant claims.
The HIPAA Implementation Guide and HIPAA Structural Compliance Maps both produce accepted and rejected transactions. How you process those transactions internally and, optionally, to your trading partner, is a business workflow decision.
All X12 transactions that pass Step 1are split into individual transactions containing one and only one claim each.
The split transactions process through HIPAA compliance maps again.
Noncompliant (bad) transactions are rejected to an output folder.
Compliant (good) claims that pass HIPAA validation can be passed directly to the translator or optionally merged for translation.
The results of the second run of HIPAA compliance validation can be reported back to the originator of the data through a 997 Functional Acknowledgement.
The HIPAA Structural Compliance Maps, shown in the Recovery Flow of Figure 2-1, are to be provided separately in a future HIPAA Accelerator release. Contact Sybase Technical Support if you need maps in the interim.
At a minimum, the following types of errors must be filtered out of data that HIPAA Transaction Manager processes. Any one of these errors should cause the entire transaction to be rejected:
Interchange level errors. All interchange level errors, such as ISA and IEA, are reported when the map runs.
Group level errors. All group level errors, such as the GS and GE, are reported when the map runs.
Transaction level errors. All transaction level errors, such as the ST and SE, are reported when the map runs.
Missing segments. Missing segments critical to HIPAA Transaction Manager parsing are reported as errors. Such segments include but are not limited to the HL segments across various maps, such as the CLM in the 837, the INS in the 834, the TRN in the 276/277, and so on. Additionally, missing segments that begin loops will be reported as errors.
Missing mandatory HL elements. Missing mandatory elements in the HL segment are reported as an error and cause the transaction to be discarded.
HIPAA Transaction Manager's split command unbundles or splits every claim between the ST-SE segment into a single business document, which is contained in a separate ISA-IEA envelope. That is, the appropriate header, provider, subscriber, and dependent information is included for each new business document created. In an 837 transaction, the split would occur at the CLM segment:
ISA GS ST ... CLM1 CLM2 ... SE GE IEA
The control segments in each new ISA-IEA repeat individual Interchange (ISA-IEA), Group (GS-GE), and Transaction (ST-SE) control segments from the original interchange.
The input to the split command can comprise one or more files. Similarly, output can be one or more files, where each output file contains one and only one interchange containing one and only one business document, such as a claim.
X12 data input can be either accessed from disk or from memory. Similarly, the X12 data output can be stored to disk or in memory. If data is accessed from or written to disk, the inputs/outputs can be a disk file or multiple disk files in one directory. If data is accessed from or written to memory, the inputs/outputs are stored as string arrays.
When running maps through ECMap/ECRTP, an option exists for mailboxing. Based on the setup you assigned, the good and bad data are routed to specific folders. For example, if a transaction fails the HIPAA Structured Compliance Maps while running maps through ECMap/ECRTP, the transaction will be sent to the "bad" folder you assigned.
HIPAA Transaction Manager splits each of the transactions at specific points. For example, to support the CMS mandate, the 837D, 837I and 837P all split transactions at the claim level (CLM). The following table illustrates the split levels for each of the HIPAA transactions.
Eligibility or Benefit Inquiry
Eligibility or Benefit Information
Claim Submitter Trace Number
Claim Submitter Trace Number
Service Level HL
Service Level HL
Member Level Detail
Individual files comprising single business documents that result from HIPAA Transaction Manager's split command, are then reprocessed by the HIPAA compliance maps. Those that pass are then optionally merged into new transactions that are then sent back to the primary flow (as shown in Figure 2-1) as though they had never contained errors.
Input to the merge command can comprise one or many files. Similarly, output can be one or more files, where each output file contains one and only one interchange containing one and only one business document, such as a claim. Each merged file contains only one interchange. Multiple interchanges rebundle into multiple files.
For transactions that contain hierarchical (HL) segments, the values in the HL01, HL02 and HL04 data elements are resequenced in both the split and merge commands. The SBR (subscriber) segment is also manipulated for 837 transactions.