Capabilities

The EDI

The original EDI can include one or more interchanges, functional groups, or transaction sets or messages from any version X12 or EDIFACT that can be validated by Instream.

The Responses

Based on functional group

Foresight Response Generator will generate any of these in response to EDI validated by Instream, based on the functional group.

Input EDI Output files created by Foresight
Response Generator
  277CA

277U

824

997

999
(5010)

TA1

CONTRL
Syn 3,4

Custom report

HIPAA EDI except 837

 

 

 

✓

 

 

✓

 

 

✓

 

 

✓

 

 

 

✓

270, 276, 277CA,
277U (4010 only), 277X228, 278, 820x218, 820x306, 834, 835, 837

HIPAA 837

 

✓

 

 

✓

 

✓

 

 

✓

 

 

✓

 

 

✓

 

 

 

✓

 

Non-HIPAA X12 EDI

 

 

 

✓

 

✓

 

 

✓

 

 

✓

 

 

 

EDIFACT
except inbound CONTRL

 

 

 

 

 

 

 

✓

 

 

Based on a whole document

Foresight Response Generator generates properly-formatted 277, 824, 997, 999 (5010 only), and TA1 response documents for the following X12 versions, based on a whole document:

Based on mixed X12 source

Response documents can be generated from mixed X12 source within a single interchange, provided the source contains all of a single transaction type.

Note that:

If no valid response documents can be created, such as requesting a 277 on a document that contains no 837s, an error is presented. This error can be overridden by using the -floose_src_check flag.

Use of the -fver_pass command

Response documents can be generated for any X12 version (2000 – 5010) by using the Response Generator command -fver_pass. This command causes Response Generator to pass the ISA and GS version numbers for the source document unchanged. See -fver_pass in Command Line Format

Output Version

Source document ISA12

Output document version

00401

X12-4010   (Exception: 999 is always X12-5010 errata)

anything else

X12-5010    

You can override the output version on the command line.

X12 HIPAA Responses

277CA Health Care Claim Acknowledgement (277CA)

Note: A 277CA is generated only when responding to HIPAA 837 transactions.

The 277 CA is sent by a payer in response to an 837 to report on whether pre-adjudication validation found them acceptable for adjudication.

Claims failing pre-adjudication validation are not sent for adjudication and therefore are never reported in an 835. Claims that pass this step are forwarded for adjudication and generate an 835.

To generate a 277CA, use these command line parameters:  -o277 or -fca277

If requested, the 277CA is created regardless of whether the 837 contained errors. It lists all claims, good and bad because they are needed for balancing.

The 277CA will be version 5010 (only) and can be accompanied by a 999. It cannot be generated along with a 277U.

It is based on the Foresight guideline 5010-277CAX214, which you can view in TIBCO Foresight® HIPAA Validator® Desktop’s Library.

277U Unsolicited Health Care Claim Status Notification (277U)

Note: A 277U is generated only when responding to HIPAA 837 transactions.

Instream will validate a 277U. Response Generator will generate a response in X12 versions 3040 to 5010.

The 277U transaction is used in addition to the 997 and 824 to report which claims are not being paid because they (or their ‘parent’) have errors. Any claim that contains an error or whose owner (subscriber, provider, etc.) contains an error will be included in this response. Which error level determines a rejection is identified with the use of the -er command line parameter (it is Severity 3 by default).

The 277 is not good at describing why a claim is being rejected – the 824 is best for that.

If no errors are present in the 837, an empty 277 will be generated unless you use Response Generator’s -fsa command line parameter. You can delete any zero-byte files with Response Generator’s -nz command line parameter.

There is no HIPAA 277U implementation guide, so there are no HIPAA code sets or HIPAA rules to describe it. See on page Appendix E: Response Document Contents for the structure and contents of TIBCO Foresight’s 277U.

824 Application Advice

Note: An 824 is generated when responding to HIPAA EDI (including 837) and non-HIPAA X12 EDI transactions.

The 824 transaction reports on error type 3 and above. These include application errors. One or more RED segments follow each TED segment. By default, each RED01 element will contain a claim number if the error occurred in a claim. Otherwise, it will contain “Not Claim Specific.”

You can use a setup file to request all RED01 elements containing claim numbers, regardless of where the error occurs. See RED Segments.

If no errors (types 3 and above) are present in the 837, an empty 824 will be generated unless you use Response Generator’s -fsa command line parameter. You can delete any zero byte files with Response Generator’s -nz command line parameter.

An 824 can be requested for any X12 transaction except a 997 or another 824.

997 Functional Acknowledgement

Note: A 997 is generated when responding to HIPAA EDI (including 837) and non-HIPAA X12 EDI transactions.

The 997 transaction acknowledges the receipt, and acceptance, and/or rejection, of functional groups and transaction sets. It also reports some errors - typically X12 syntax errors (types 1 and 2). It can be requested for any X12 transaction except another 997 or a 999.

Response Generator cannot generate a 997 and 999 for the same input file.

See 997 Structure and Data Sources for information about the structure and contents of TIBCO Foresight’s 997.

999 Implementation Acknowledgement

Note: A 999 is generated when responding to HIPAA EDI (including 837) and non-HIPAA X12 EDI transactions.

Per HIPAA rules, the Response Generator will not generate a 997 and 999 for the same input file.

The 999 created by Response Generator is based on the Implementation Acknowledgement for Health Care Insurance, 005010X231A1 errata. The only difference between this 999 and the previous non-errata 999 is the contents of the GS08 and the ST03 (now 005010X231A1). To produce a non-errata 999, use the -dav command line qualifier to specify 005010X231.

It can be used as a response to any HIPAA X12-5010 data, and it answers these questions:

By default, it reports all errors that the guideline detected during validation. Response Generator’s -s command line option causes the output 999 to report only types 1-2 errors.

For example, run V_RG_837I_5010_999 in the Scripts directory of Instream.

See 999 Structure and Data Sources for information about the structure and contents of TIBCO Foresight’s 999.

TA1 Interchange Acknowledgment

Note: A TA1 is generated when responding to HIPAA EDI (including 837) and non-HIPAA X12 EDI transactions.

The TA1 response acknowledges the receipt of an interchange, and reports on whether the interchange was accepted, accepted with errors or rejected. This is a single segment that you can choose to have placed within the 997 or 999, or surrounded by ISA and IEA in a separate file.

Guidelines for the Response Generator 824 and 997 guidelines are described in Doc directory of Instream in a file called RSGN4010.SEF. If you have TIBCO Foresight® EDISIM®, you can import it into Standards Editor for review.

Custom Report

Note: A custom report can be generated when responding to HIPAA EDI transactions for 270, 276, 277CA, 277U (4010 only), 277X228, 278, 820x218, 820x306, 834, 835, and 837 validations only.

A text report is generated with the -otext command. Its purpose is to capture output as text and then, using a user-built template (as specified with the -tpl parameter), format a custom report. See Report Templates

EDIFACT Responses (CONTRL Document)

Note: A CONTRL document is generated when responding to EDIFACT validation (except Inbound CONTRL).

Response Generator will generate a CONTRL document in response to an EDIFACT validation performed by Instream. The CONTRL document will be syntax level 3 or 4, based on the originating interchange’s UNB01.

Based on the value in the original EDI’s UNB01, the CONTRL will be:

X12 Non-HIPAA Responses

Response Generator will generate the following in response to non-HIPAA EDI validated by Instream. It can create any or all of these (described in the previous section):