InstreamÂ® Validation Technical Manual

TIBCO Foresight™ Instream®

Instream® Validation Technical Manual

Software Release 8.2.0

January 2013

Two-second advantage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO

SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED

TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY

OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT

FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE

AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR

INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE

LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE”

FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE

HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc.

TIB, TIBCO, TIBCO Adapter, Predictive Business, Information Bus, The Power of Now, TIBCO ActiveMatrix BusinessWorks, TIBCO

Foresight HIPAA Validator, and TIBCO Foresight Instream are either registered trademarks or trademarks of TIBCO Software Inc. in the

United States and/or other countries.

EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the

U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM

PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README.TXT FILE FOR

THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT

NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-

INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE

PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF

THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE

PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER

DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND

"READ ME" FILES.

Please see TIBCO <product> <edition> <version> TIBCO EULA and TPS Notices.pdf for licensing information.

Copyright © 1999-2013 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information

Contact Information

TIBCO Software Inc. Confidential

TIBCO Software Inc., Foresight Group

655 Metro Place South

Suite 900

Dublin OH 43017

Phone: (614) 791-1600

Fax: (614) 791-1609

Web: http://foresight.tibco.com/

E-mail: [email protected]

Contents

Introduction

1

Intended Audience ................................................................................................. 1

System Requirements ............................................................................................ 1

Recommended Software ....................................................................................... 1

Checking Instream’s Version .................................................................................

2

License File ............................................................................................................ 2

Capabilities ............................................................................................................. 2

Delimiters and Separators ............................................................................... 2

Command Line Overview ................................................................................ 3

API Overview ................................................................................................... 3

Customizing for Specific Partners ................................................................... 3

Customizing for Specific Guidelines ................................................................ 4

CCI Edits.......................................................................................................... 4

Input and Output .................................................................................................... 5

Typical Inbound Implementation - X12 and EDIFACT Example ............................ 7

Typical Inbound Implementation

– HIPAA Example ..............................................

8

Typical Outbound Implementation - X12 and EDIFACT Example ......................... 9

Typical Outbound Validation - Docsplitter Implementation .................................. 10

Acknowledgements .............................................................................................. 11

Conditions that will Stop Validation ...................................................................... 11

Performance ......................................................................................................... 11

Windows Tutorials ................................................................................................ 12

HIPAA Windows Tutorial ............................................................................... 12

EDIFACT Windows Tutorial........................................................................... 14

X12 Windows Tutorial .................................................................................... 16

UNIX Tutorials ...................................................................................................... 18

HIPAA UNIX Tutorial ..................................................................................... 18

EDIFACT UNIX Tutorial ................................................................................. 19

X12 UNIX Tutorial .......................................................................................... 21

TIBCO Foresight-Supplied Guidelines ................................................................. 22

Customizing Guidelines ....................................................................................... 22

Validating with Instream

23

Methods of Execution........................................................................................... 23

Validating from a Command Line ......................................................................... 24

Command Line Examples ............................................................................. 28

Sample Batch or Script Files ......................................................................... 28

Document-Only Processing ........................................................................... 28

Specifying Alternate INI Files ........................................................................ 29

Application Program Interface .............................................................................. 29

Contents



i Instream Validation Technical Manual

Validation Results

30

Results Files ......................................................................................................... 30

Summary Results .......................................................................................... 30

Detail Results ................................................................................................ 31

TA1 ................................................................................................................ 31

Line Numbers ....................................................................................................... 32

Record Definitions ................................................................................................ 33

CSEG: Current Segment Data Record .......................................................... 33

CTX: Context Record for Response Generator 999 ..................................... 34

DTL: Detailed Message Record .................................................................... 36

EDAT: EDI Error Data Record ....................................................................... 41

EDTL: Detailed Message Record for XML Data ........................................... 42

EDTL: Detailed Message Record for Flat File Data ...................................... 44

ELOC: Error Location Record........................................................................ 47

EMSG: Error Message Record ...................................................................... 49

END: End Validation Record ......................................................................... 50

ENDS: End Record for Transaction Set or Message .................................... 51

ESEG: Error Segment Data Record .............................................................. 52

ETYPE: Error Type Summary Record for File ............................................... 53

ETYPS: Error Type Summary Record for Transaction Set or Message ....... 54

EVALU: Element Value Record ..................................................................... 55

GEN: General Message Record .................................................................... 57

IDENT: Unique Identifier Record ................................................................... 59

STRT: Start Validation Record ...................................................................... 61

STRUE: Structure End Record ...................................................................... 62

STRUS: Structure Start Record .................................................................... 64

SVALU: Segment Value Record ................................................................... 66

SVRTS: Error Severity Summary Record for Transaction Set or Message .. 68

SVRTY: Error Severity Summary Record for File ......................................... 69

VER: Version Record .................................................................................... 70

Z: Custom Data Record ................................................................................. 71

Displaying Version Information in the Results File .............................................. 72

HIPAA External Code Tables

73

Table File Server .................................................................................................. 73

Extending or Modifying Code Tables ................................................................... 73

Creating your own Code Tables .......................................................................... 73

Appendix A: Return Codes

74

Appendix B: Table File Server

75

fscint.ini Setup ...................................................................................................... 76 fsFileServer.ini Setup ........................................................................................... 77

Starting the Table File Server .............................................................................. 77

How to tell if the Table File Server is running ...................................................... 78

Instream Validation Technical Manual Contents



ii

Appendix C: SVALU Record Structure IDs

79

Structure IDs ........................................................................................................ 79

HIPAA Structure ID Chart .................................................................................... 80

Appendix D: Record Definition Summary

102

Record Layout Summary, Version 2.0 ............................................................... 102

Instream Validation Technical Manual Contents



iii

Introduction

Intended Audience

This document is intended for technical staff who are implementing TIBCO

Foresight™ Instream® validation. A general familiarity with EDI is assumed.

System Requirements

Please see System_requirements.pdf.

Recommended Software

Recommended software for Instream® sites:



TIBCO Foresight™ EDISIM® 6.6 or later.

This will let you develop your own business rules for use with Instream .

Look for EDISIM® under Start | Programs | Foresight | EDISIM .

To check your version of EDISIM, open Standards Editor and choose Help |

About EDISIM.

To get a later version, go to http://download.tibco.com

, click Support, and log in.



TIBCO Foresight™ HIPAA Validator® Desktop

This will let you view errors, the corresponding EDI, and guideline information in a graphical user interface. Look for it under Start | Programs | Foresight |

Desktop.

Instream Validation Technical Manual Introduction



1

Checking Instream’s Version

Execute the Version file in Instream’s Scripts directory.

License File

Beginning with Instream version 8.0.0, a license file is no longer is no longer required.

Capabilities

The validation module of Instream is a command line validator for many different file formats, including (but not limited to) HIPAA (health care) data, other X12 formats,

EDIFACT, TRADACOMS, HL7, flat files, and XML.

Please see FileFormatsAtForesight.pdf for a complete list.

For UNICODE handling information, see UNICODE_at_Foresight.pdf.

You can add your own edits to these formats with the help of EDISIM, TIBCO

Foresight’s guideline authoring tool.

This document describes validation with Instream. The other Instream modules are documented separately in Instream’s Doc directory.

Delimiters and Separators

Instream can validate data with separators and delimiters that are keyboard characters or

ASCII up to hex equivalent 252.




2

Command Line Overview

If you start Instream from a command line, you will take data files as input and write result files. See page

24

for details about starting from the command line.

Your calling software can scan the resulting summary report to determine if the data passed validation.

If your software determines that the data failed validation, the calling software can:



Use the detail results file to generate e-mails or response documents. The detail results file is consistently formatted and contains information needed to fill out all optional and mandatory elements.

 Call Instream’s Docsplitter module to split good data from bad, and/or call

Instream’s Response Generator module to generate a response for the sender.

API Overview

You can integrate Instream validation with another software package by using Instream’s

C++, C#, VB.NET, or Java API.

Please see InStreamAPI.pdf in Instream’s Doc folder.

Customizing for Specific Partners

Instream validation lets you customize for specific partners by:

 Using different TIBCO Foresight-supplied guidelines to strengthen or weaken compliance checking.



Using guidelines with partner-specific edits that you define with EDISIM, the

TIBCO Foresight guideline-authoring tool.



Customizing diagnostic messages.

 Adjusting error severity levels for a partner or group of partners. This controls the conditions that cause a data to be rejected and the response generated after rejection.

 Creating and enforcing new external code lists.



Amending the contents of TIBCO Foresight-supplied external code lists.

Trading Partner Automation: To automatically select a guideline or profile based on some information in the EDI data, see InStreamTPAutomation.pdf and APF.pdf in

Instream’s Doc directory.




3

Customizing for Specific Guidelines

You can save the profile you want to use for a specific standard or guideline and have

Instream automatically load it whenever you use that standard for validation. See

Specifying which APF File to Use in APF.pdf in Instream’s Doc directory.

CCI Edits

Instream will enforce:



Correct Coding Initiatives (CCI) for Part B Medicare Carriers from the Centers for

Medicare and Medicaid Services (CMS).



National Correct Coding Initiative (NCCI) edits for Hospital Outpatient Prospective

Payment System (OPPS).

TIBCO Foresight guidelines that enforce CCI are marked with *CCI in

ForesightHIPAAguidelinelist.pdf in Instream’s Doc directory. You can enforce CCI in your own guidelines by merging them with these or by using BusinessRules.CCI as described in BusinessRules.pdf.

TIBCO Foresight CCI checking includes:



Check CCI pairs to see if they can go together.

 For pairs that need a modifier to go together:

 Is a modifier provided in the data?

 Are the modifiers legal CCI modifiers?

 Both members of a pair cannot use the same anatomical modifier.

CCI and NCCI checking significantly reduce speed of validation.

Please refer to the National Correct Coding Policy Manual for information about modifiers.




4

Input and Output

The validation program is HVInStream (for UNIX) or HVInStream.exe (for Windows).

Input

Instream validation reads data in various formats (see FileFormatsAtForesight.pdf).

When running from the command line, EDI data includes one or more complete interchanges per file. Each interchange can contain one or more functional groups, each with one or more transactions or messages.

For X12-based data, when using the C++ API, the data need not have ISA, GS, GE, or

IEA if you use DocumentLevelOnly or FSDOCUMENTONLY.

Output

Instream validation creates two files or output streams:

 Detail results describing each error and warning found during validation, plus general messages and statistics. You can include custom records that contain actual values from the data. For example, you can output claim number s or patient numbers so that post-processors can identify the specific claim or patient to which

an error applies. Please see Detail Results on page 31 .




5



Summary results containing a summary of the validation, including validation start and end times and number of errors, warnings, and other messages. Please see

Summary Results on page 30 .

For validation, Instream uses:



(for HIPAA data) More than 50 TIBCO Foresight-supplied data code tables such as

Taxonomy and ICD-9. For directions on changing these tables, see

ExtendingCodeTables.pdf in Instream’s Doc directory.



(for EDI data) TIBCO Foresight-supplied guidelines containing the rules from the underlying standard (such as X12, EDIFACT, or TRADACOMS); for HIPAA data, this includes the HIPAA rules. For a list, see ForesightHIPAAguidelinelist.pdf in

Instream’s Doc directory.

 (Optional) Your own rules. You can use the TIBCO Foresight guideline-authoring tool EDISIM to add your own rules to a guideline. Call TIBCO Foresight Technical

Support for details.




6

Typical Inbound Implementation - X12 and EDIFACT

Example

Your

Communication

System

EDI

Back to sender

Instream

Validator

Validation

Highlighter

HTML report

Validation detail results

All bad

EDIFACT

Split bad

X12

ISErrors

check for errors

All bad

EDI

TPARouter

check if

X12

X12

DocSplitter

Split sets into good-bad

All good EDI

Split good

X12

Your

Translator

The bold objects above are part of Instream or are generated by Instream.




7

Typical Inbound Implementation – HIPAA Example

Instream can validate inbound data as it comes into your organization to protect your translator and application systems from bad data.

Your

Communication

System

Instream is designed to be highly configurable, with several components that work together. This example shows Instream’s Validator, Response Generator, and

Docsplitter working together to process inbound EDI.

Validation comes first



EDI



Instream

Validator

Validation

Summary

Results

Validation

Detail



Response

Generator to sender

277CA/U,

824, 997,

999, TA1,

Custom reports

Results

Valid

EDI

EDI



Docsplitter

Invalid

EDI

XML

Report



Your

Translator



Your Customer

Support System


Typical Steps as shown above:

 EDI comes in through your company communication system.

 Instream Validator reads the EDI and creates detail and summary results.

The dotted outline in the graphic above indicates these steps, which precede use of

Docsplitter or Response Generator.

After Validator creates the detail results file, either Docsplitter or Response

Generator can start in any order or simultaneously. Assume that Response

Generator starts first:

 Response Generator reads the detail results created by Validator and generates the appropriate response document. Your application dispatches it to the sender.

 Docsplitter reads the detail results created by Validator and the original

EDI file and generates a file containing the valid EDI, a file containing the invalid EDI, and an XML report.

 The valid EDI goes to your translator.

 The invalid EDI and the XML report go to your customer support system.




8

Typical Outbound Implementation - X12 and EDIFACT

Example

Your

Communication

Good EDI

System

ISErrors

check for errors bad

EDI

Validation

Highlighter

HTML report

Validation detail results

Instream

Validator

Back to your staff

EDI

Your

Translator





9

Typical Outbound Validation - Docsplitter

Implementation



Your

Comm. Sys.



Your Customer

Service Sys.

This example shows Instream and Docsplitter working together to validate outbound

EDI data as a final check before it goes into the world.

Valid

EDI

Invalid

EDI

XML

Report



Docsplitter

Validation

Summary

Results

Validation

Detail

Results



Instream

Validator

EDI



Your

Translator

Appl. Data



Your Application

System


Typical Steps:

 Your application system creates application data.

 Your translator reads the application data and creates EDI.

 Instream Validator reads the EDI and creates summary and detail results files.

 Docsplitter reads the detail results file and the EDI file and splits the data into valid and invalid EDI. It also creates an XML report.

 The valid EDI is sent to your communications system so that it can be sent out to the recipient.

The invalid EDI and the XML report go to your customer service system.




10

Acknowledgements

You have two choices for generating acknowledgements:



Use your own acknowledgement handling procedures, which can make use of the summary and detail results files created by validation.



Use Instream’s Response Generator (X12- and EDIFACT-based data).

Response Generator can create:



HIPAA data: 277CA and 277U (for 837 only), 824, 997, 999 (5010 only), and TA1s in addition to custom text reports

 Non-HIPPA data: 824, 997, 999 (5010 only), and TA1s



EDIFACT data: CONTRL message

You have control of many aspects of the response, including the severity of errors that cause a response.

Please see page

8

for an example of where Response Generator might fit. Also see

ResponseGeneratorTechnicalManual.pdf in Instream’s Doc directory.

Conditions that will Stop Validation

Instream validation will send a return code of 140 and stop validating if it cannot fulfill your requests for APF, guideline, partner automation, error file, database lookup, or other setup information or resources.

Errors in data will not stop validation.

Examples that will stop validation:

 You ask for guideline ABC, which does not exist.



You ask for partner automation, but the setup file is not in a usable format.

 Your APF file is a Microsoft Word document.



A business rule points to a database that cannot be accessed.

 Your business rule queries a database table that does not exist.

Performance

If you do NOT use HIPAA guidelines, you can improve the efficiency of Instream by putting this line in the [Options] section of the $dir.ini, or by removing any colon in front of the line if it is already there:

HipaaCodeTable=0




11

Windows Tutorials

HIPAA Windows Tutorial

1. Go to Instream’s DemoData directory and look at the EDI data in

837I_4010_H_ErrorEvenClms.txt.

This contains one 837I transaction set with one provider, one subscriber, and 10 claims. The claims are numbered from 1 to 10 and the even-numbered claims have errors.

2. Validate the data:

Go to Instream’s Scripts directory and double-click on V_837I_4010_H_1.bat.

This batch runs Instream validation with GuidelinePlus PDSA837I, the HIPAA

X12-4010 addenda. When it finishes successfully, you should see the message

Validation Return code = 100.

3. Go to Instream’s Output directory and use a text editor to look at the validation summary file

Summary_837I_4010_H_ErrorEvenClms_results_out.txt.

It has 7 errors:

For details about the format of the summary file, see Summary Results on page 30 .




12

4. Look for the specific errors in the detailed validation results file:

Open 837I_4010_H_ErrorEvenClms_results.txt.

Search for DTL. This line and the next three explain an error. This error is on line 69 of the EDI file, a DTP segment. The segment is missing.

DTL 69 2300 DTP 66 2

10811 3 1731 3 1007 488

EMSG 69Missing Segment DTP (Statement Dates) at 2-135, though marked "Must Be Used"

Search for the other DTL segments and see what other errors were found.

For details about the format of the detail file, see Detail Results on page 31 .

Create your own Batch File

Create a batch file to validate 834_4010_H_2members.txt, which is in Instream’s

DemoData directory.

Since its GS08 contains 004010X095A1, you know it is based on an 834 Addenda (see

ForesightHIPAAguidelinelist.pdf in Instream’s Doc directory).

Your job is to create and execute a batch file to validate this 834.

1. Go to Instream’s Scripts directory and copy V_837I_4010_H_1.bat to

V_834_4010_H_1.bat.

2. Open the new file in a text editor like Notepad and make these changes:

"%InStreamRoot%\Bin\HVInStream.exe"

-i"%InStreamRoot%\DemoData\ 834_4010_H_2members.txt"

-o"%InStreamRoot%\Output\ 834_4010_H_2members_out.txt"

-gPDSA834

3. Save, close, and run V_837I_4010_H_1.bat.

4. View the new output files added to Instream’s Output folder:

The Instream validation command format is described on page

24 .




13

EDIFACT Windows Tutorial


ORDERS_D93A_UN_1.txt.

This contains one simple ORDERS message that we are going to check for errors.

2. Validate the ORDERS data:

Go to Instream’s Scripts directory and double-click on

V_ORDERS_D93A_UN_1.bat.

This batch file uses Instream to validate this data against the EDIFACT standard

D93A. When it finishes successfully, you should see the message Return code =

100.

3. Go to Instream’s Output directory and use a text editor to look at the validation summary file Summary_ORDERS_D93A_UN_1_Results.txt.

It has two errors:

For details about the format of the summary file, see Summary Results on page 30 .




14


Open ORDERS_D93A_UN_1_Results.txt.

Search for DTL. This line and the next two explain an error. This error is on line 4 of the EDI file, the BGM segment. There is an excess sub-element separator:

DTL 4 BGM1225 1 3 0

10623 3 21 8 6848

EMSG 4Sub-element separator seen in elementary data element at BGM03 (D.E. 1225) at col. 17. Excess ignored.

ESEG 4BGM+220+KC11111+9:'

The next DTL line is about line 7 in the EDI file, a NAD segment with a bad code value in the NAD01.

For details about the format of the detail file, see Detail Results on page 31 .

Create your own Command Line Batch File

We are going to create a batch file to validate

INVOIC_D96A_UN_1.txt

in Instream’s

DemoData directory.

Copy V_ORDERS_D93A_UN_1.bat to V_INVOIC_D96A_UN_1.bat. Adjust the bold parts below to point to the input file (-i), the output file (-o), and the guideline

(-g).

"%InStreamRoot%\Bin\HVInStream.exe" i"%InStreamRoot%\DemoData\INVOIC_D96A_UN_1.txt "

-o"%InStreamRoot%\Output\INVOIC_D96A_UN_1_Results.txt"

-gD96A

(The guideline D96A must be in Instream’s Static directory, since it is a basic, unmodified EDIFACT standard. Modified guidelines go in the Database directory.)


24 .




15

X12 Windows Tutorial


810_5040_X_1.txt.

This contains one simple X12-5040 810 invoice that we are going to check for errors.

2. Validate the 810 data:

Go to Instream’s Scripts directory and double-click on V_810_5040_X_1.bat.

This batch file uses Instream to validate this data against standard

X12-5040. When it finishes successfully, you should see the message Return code

= 100.

3. Go to Instream’s Output directory and use a text editor to look at the validation summary file Summary_810_5040_X_1_Results.txt.

It has one error:





16

4. Look for the specific error in the detailed validation results file:

Open 810_5040_X_1_Results.txt.

Search for DTL. This line and the next three explain an error. This error is on line 26 of the EDI file, the IEA segment. The control number doesn’t match the one in the ISA.

DTL 26 IEA I12 23 2 0

10912 3 01-100011

EMSG 26Interchange Ctl No. 000000003 in IEA doesn't match

ISA's 000000001

EDAT 26000000003

ESEG 26IEA*1*000000003!

This is the only error. If there had been others, they would be documented similarly, starting with a DTL line.


Create your own Command Line Batch File

We will make a batch file to validate an 850 purchase order: 850_4010_X_1.txt.

Copy V_810_5040_X_1.bat to a new name V_850_4010_X_1.bat. Adjust the bold parts below to point to 850_4010_X_1.txt for the input file (-i) and modify the output filename accordingly (-o). The guideline is X12-4010.


-i"%InStreamRoot%\DemoData\850_4010_X_1.txt"

-o"%InStreamRoot%\Output\850_4010_X_1_Results.txt"

-gX12-4010


24 .




17

UNIX Tutorials

Each TIBCO Foresight-supplied script identifies the location of Instream with

LIBPATH.

Setting LIBPATH on UNIX

AIX

SUN

Red Hat

Enterprise

Linux 4 or

5 export LIBPATH=/HVInStream/bin:$LIBPATH

LD_LIBRARY_PATH=/HVInStream/bin:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH export FSINSTREAMINI=/HVInStream/bin export LD_LIBRARY_PATH=/HVInStream/bin:$LD_LIBRARY_PATH

HIPAA UNIX Tutorial


837I_4010_H_ErrorEvenClms.txt.

This contains one 837I transaction set with one provider, one subscriber, and 10 claims. The claims are numbered from 1 to 10 and the even-numbered claims have errors.

2. Validate the data:

Go to Instream’s Scripts directory and look at the contents of

V_837I_4010_H_1.sh. Execute this script by typing its name.

This script runs Instream validation with GuidelinePlus PDSA837I. When the script finishes successfully, you should see the message validation return code=100.

3. Go to Instream’s Output directory and use a text editor to look at the validation summary file Summary_ 837I_4010_H_ErrorEvenClms_results.txt.

The SVRTY line shows that it has 7 errors (the 4 th

number is the error count).


In 837I_4010_H_ErrorEvenClms_results.txt, find the first line that starts with DTL.

This line and the next three explain an error. This error is on line 69 of the EDI file, a

DTP segment. The segment is missing.

Search for the other DTL segments and see what other errors were found.

For details about the format of the detail file, see Detail Results on page 31 .




18

Create your own Script File

Create a script file to validate 834_4010_H_2members.txt, which is in Instream’s

DemoData directory.

Since its GS08 contains 004010X095A1, you know it is based on an 834 Addenda (see

ForesightHIPAAguidelinelist.pdf in Instream’s Doc directory).

Your job is to create and execute a script file to validate this 834.

1. Go to Instream’s Scripts directory and copy V_837I_4010_H_1.sh to

V_834_4010_H_1.sh.

2. Make these changes to the new file


-i"%InStreamRoot%\DemoData\ 834_4010_H_2members.txt"

-o"%InStreamRoot%\Output\ 834_4010_H_2members_out.txt"

-gPDSA834

3. Save, close, and run V_837I_4010_H_1.sh.

4. View the new output files added to Instream’s Output folder:


24 .

EDIFACT UNIX Tutorial


ORDERS_D93A_UN_1.txt.

This contains one simple ORDERS message that we are going to check for errors.

2. Validate the ORDERS data:

Go to Instream’s Scripts directory and double-click on

V_ORDERS_D93A_UN_1.sh.

This script file uses Instream to validate this data against the EDIFACT standard

D93A. When it finishes successfully, you should see the message Return code =

100.

3. Go to Instream’s Output directory and look at the validation summary file

Summary_ ORDERS_D93A_UN_1_Results.txt. The SVRTY line shows two errors (the fourth number in the line).



Open ORDERS_D93A_UN_1_Results.txt.

Search for DTL. This line and the next two explain an error. This error is on line 4 of the EDI file, the BGM segment. There is an excess sub-element separator:




19

DTL 4 BGM1225 1 3 0

10623 3 21 8 6848

EMSG 4Sub-element separator seen in elementary data element at BGM03 (D.E. 1225) at col. 17. Excess ignored.

ESEG 4BGM+220+KC11111+9:'

The next DTL line is about line 7 in the EDI file, a NAD segment with a bad code value in the NAD01.



Copy V_ORDERS_D93A_UN_1.SH to V_INVOIC_D96A_UN_1.SH. Adjust the bold parts below to point to the input file (-i), the output file (-o), and the guideline (-g).

"%InStreamRoot%\Bin\HVInStream.exe" i"%InStreamRoot%\DemoData\INVOIC_D96A_UN_1.txt " o"%InStreamRoot%\Output\INVOIC_D96A_UN_1_Results.txt"

-gD96A

(The guideline D96A must be in Instream’s Static directory, since it is a basic, unmodified EDIFACT standard. Modified guidelines go in the Database directory.)


24 .




20

X12 UNIX Tutorial


810_5040_X_1.txt.

This contains one simple X12-5040 810 invoice that we are going to check for errors.

2. Validate the 810 data:

Go to Instream’s Scripts directory and double-click on V_810_5040_X_1.sh

This batch file uses Instream to validate this data against standard

X12-5040. When it finishes successfully, you should see the message Return code

= 100.

3. Go to Instream’s Output directory and look at the validation summary file

Summary_810_5040_X_1_Results.txt. The SVRTY line shows one error (the fourth number in the line).

For details about the format of the summary file, see Summary Results on page

30 .

4. Look for the specific error in the detailed validation results file:

Open 810_5040_X_1_Results.txt.

Search for DTL. This line and the next three explain an error. This error is on line 26 of the EDI file, the IEA segment. The control number doesn’t match the one in the ISA.

DTL 26 IEA I12 23 2 0

10912 3 01-100011

EMSG 26Interchange Ctl No. 000000003 in IEA doesn't match

ISA's 000000001

EDAT 26000000003

ESEG 26IEA*1*000000003!

This is the only error. If there had been others, they would be documented similarly, starting with a DTL line.





21


We will make a batch file to validate an 850 purchase order: 850_4010_X_1.txt.

Copy V_810_5040_X_1.sh to a new name V_850_4010_X_1.sh . Adjust the bold parts below to point to 850_4010_X_1.txt for the input file (-i) and modify the output filename accordingly (-o). The guideline is X12-4010.


-i"%InStreamRoot%\DemoData\850_4010_X_1.txt"

-o"%InStreamRoot%\Output\850_4010_X_1_Results.txt"

-gX12-4010


24 .

TIBCO Foresight-Supplied Guidelines

Instream ships with a database of EDI guidelines that contains information about the valid X12 and EDIFACT syntax and rules.



Some X12 guidelines contain HIPAA validation rules. Please see

ForesightHIPAAguidelinelist.pdf in Instream’s Doc directory for a list of

HIPAA guideline names.



Please see ForesightGeneralguidelinelist.pdf in Instream’s Doc directory for a list of general guideline names supported by Instream on TIBCO BusinessConnect™

Insight.

Customizing Guidelines

You can use EDISIM Standards Editor to add your own rules to TIBCO Foresightsupplied guidelines.

HIPAA customers can merge a guideline that they customize with the corresponding

TIBCO Foresight-supplied HIPAA guideline. This yields a guideline that contains all

X12 and HIPAA rules plus your own rules.

See BusinessRules.pdf and fseditor.pdf in EDISIM’s Documentation directory for details.




22


Methods of Execution

Instream validation can be:



Run as a command line, usually from within a batch file or script

 Executed from another program via a system call

Instream Validation Technical Manual Validating with Instream



23

Validating from a Command Line

The command line to start validation is usually in a script or batch file.

Instream can issue return codes (see page

74 ) when the validation is complete.

The executable for the command line is:

Windows

HVInStream.exe

UNIX

HVInStream

It is a standalone executable in Instream’s Bin directory. Control returns when the validation completes, and your own procedures then examine the output files to determine the success or failure of the validation.

The command line has the following case-sensitive parameters. Use quotation marks around paths or filenames that contain spaces.

InstreamExecutable

-i

InFile

-o

Outpath

-g(or –xg)

Guideline

-s

StartupProfile

–a –c –D –d -f –m –r -u

I mportant

All HVInStream options are case sensitive.

Spaces are significant.

Use double quotation marks around paths that have spaces.

InstreamExecutable

Instream executable, including path:

HVInStream.exe (Windows)

HVInStream (UNIX)

i i

nput file - path and filename of an EDI data file.

Required.

o o

utpath - desired path and filename for the results file.

Required.

The detail file will use the filename that you specify and the summary file will use the same filename preceded with “Summary_”.

The directory must already exist. If the output files already exist, they will be overwritten.

Filename is optional. Default output filenames are

FS_Output and Summary_Output.




24

g xg

Instream Validation Technical Manual

guideline – guideline to use for validation.

Required for flat file data. Optional but recommended for EDI data. For XML data, use the xg parameter instead.

If using a standard, it must be located in Instream’s

Static directory. If using a guideline, it must be in

Instream’s Database directory.

If -g is omitted, Instream checks to see if trading partner automation is enabled and if a match can be found that way.

If not, it checks the $dir.ini or fsdir.ini for a

GuidelineBestFit=0 setting. If it finds it, validation is cancelled and a return code of 140 is issued.

Otherwise, Instream picks the guideline that best fits:

 For X12-based data, it matches the data’s GS08

(X12) or UNG07 (EDIFACT) with the VRI of a guideline.

 For EDIFACT-based data, it matches the UNG

UNG07 (01 and 02, plus 03 if it exists). If there is no UNG, it uses the UNH02 (02, 03, and 05 if available).

The detail results file shows a message confirming the guideline for each GS or UNH segment for which a best fit guideline is used.

If you are using envelope-based partner automation (see

InStreamTPAutomation.pdf in Instream’s Doc directory), using –g on the command line causes

Instream to ignore the partner automation entirely.

If you are using content-based partner automation, you can use –g to load the guideline that has the contentbased partner automation rules.

Recommendation: Since TIBCO Foresight distributes

HIPAA guidelines that include types 1 and 2 and also

HIPAA guidelines for types 1 through 7, it is advisable to use –g.

XML guideline – guideline to use for validating XML data. Optional but recommended.

See XMLatForesight.pdf for details.




25

c d a

D f

(Primarily for TIBCO Foresight use)

Automator mode – uses these file extensions for output, regardless of what is specified with the –o parameter:

DTL

RPT

SUM for the detailed results file for the report card for the summary file

configuration file location – the high-level directory containing $dir.ini (Windows) or fsdir.ini (UNIX). See

Specifying Alternate INI Files on page 29 .

Not available for EDIFACT-based data.

Document-only validation – ignore the ISA and GS and only validate the segments between ST and SE.

If you use -d, you must also use -D).

Please see Document-Only Processing on page 28

for details.

Not available for EDIFACT-based data.

Delimiters for document-only validation (segments ST-

SE, no ISA and GS).

Parameters:

”segTerminator,elemSeparator,componentSeparator”

Possible formats: integer Example:

-D”29,30,31” hexadecimal Example:

-D”0x1E,0x1F,0x1D” character Example:

-D” ~*:”

Important: -D must come before –d in the commandline.

Please see Document-Only Processing on page 28

for details. table file server – use the Table File Server.

This gives faster processing if you are validating many very small files. See page

75 .




26

m r s u

Original file information - lets you insert the literal date and hour of file creation, the EDI file’s size, and its path name into a GEN record with number 15077. This is for your own use; Transaction Insight displays it and lets you use it in searches on the Transmissions page.

Parameters:

”mm/dd/yyyy hh:mm:ss fileSize pathName”

Example:

-m"02/14/2005 14:55:19 2032

C:/HVInStream/DemoData/835-DEMO1.TXT"

Instead of -m on the validation command line, you can use useinputfileasoriginal=1

in Importer.ini.

This collects the information from the STRT record in the validation detail file.

report card – creates a formatted report summarizing the results. The report card will be in a file called

Report_resultsfilename.txt.

startup profile – profile (APF) file.

Optional; default is $fsdeflt.apf (Windows and UNIX)

Parameter:

”

path

”

Example:

-s”S:\shared profiles\MyProfile.apf”

Please see APF.pdf in Instream’s Doc folder for details.

user message – free-form text. Allows you to insert whatever text you’d like in a GEN record with number

15078. This is for your own use. Transaction Insight can display it.

Parameter:

”

some text

”

Example:

-u"From Sock 2"

Resulting GEN record:

GEN 015078 1 0From Sock 2

If you execute Instream with no parameters, you will see the version and a list of parameters.




27

Command Line Examples

The commands below validate this file:

And creates these results files:

EDI.txt

Results.txt

Summary_Results.txt

Windows Example

All input and output files are in the C:\Files directory.

"C:\Foresight\Instream\Bin\HVInStream.exe" -i"C:\Files\EDI.txt"

-o"C:\Files\Results.txt" -gPDSA837I

UNIX Example

All input and output files are in the /Files directory. export FSINSTREAMINI=/HVInStream/bin export LIBPATH=/HVInStream/bin:$LIBPATH

/HVInStream/bin/HVInStream -i"/Files/EDI.txt" -o"/Files/Results.txt"

-gPDSA837I

Sample Batch or Script Files

The files that TIBCO Foresight installs in Instream’s Scripts folder contain examples of validation. Some also execute Docsplitter, DataSwapper, or Response

Generator after validating. Please see Demo_Index.pdf for details.

Document-Only Processing

Available for X12 messages only.

The command-line parameters -D and -d work together to validate EDI with no delimiters as follows. If the command-line has -d, it must also have -D.

ISA/GS present in data

-D on command-line

-d on command-line

Delimiters used for validation





-D







-D



-D







 

ISA

Error Error




28

Specifying Alternate INI Files

Many configuration features of Instream are defined in the $Dir.ini file (Windows) and the fsdir.ini file (UNIX). This file allows you to specify the name and location of error message files, set up partner automation, and set certain other options.

Instream automatically reads this file from the Instream Bin directory when you request a validation.

When you do not want to use the settings in your usual $Dir.ini or fsdir.ini file in the Instream Bin directory, you can point to a different one with the -c commandline parameter.

The format is:

-c”

path

”

Where path is the high-level directory containing a Bin directory which must contain:



$Dir.ini or fsdir.ini

 fscint.ini (only needed here if you are using the table file server)

Example

set InStreamRoot=C:\Foresight\Instream


-i"%InStreamRoot%\DemoData\Tutorial837IA.txt"

-o"%InStreamRoot%\Output\Tutorial837IA_Results.txt"

-gPDSA837I -c"C:\OtherINI"

C:\OtherINI\Bin contains:

 $dir.ini or fsdir.ini

Application Program Interface

You can integrate Instream validation into another of your applications either statically (for C/C++) or dynamically (for C/C++, C#, and Java).

An advantage of an API interface: you can read and act on results as they come back, rather than waiting for a file to be created. You can also stop the validation anytime, based on the type or number of errors.

The API can pass both the inbound data and resulting output via common memory or file. Common memory is normally the most efficient way of connecting, but

large documents should be called as files.

For details, see InStreamAPI.pdf in Instream’s Doc folder.




29

Validation Results

Results Files

Instream Validator writes a summary and a detail results file for each EDI file validated.

Summary File Check it to see how many errors, warnings, etc., were found. See

Summary Results below.

Detail File Check it to see specifics about the validation: error and warning

messages, general messages, etc. See Detail Results on page 31 .

Both files:

 Consist of records that start with a one- to five-character record identifier or “tag,” left justified in a field five characters wide.

 Contains the output from the validation of a single EDI data file.

Summary Results

This file is named Summary-xxx where xxx is the name of the detail output file. This file contains these five records that summarize the validation results:

VER Version number of the output file format

see page 70

STRT

see page 59

SVRTY

Date and time when validation started, name and location of file validated

Message count by severity

see page 69

ETYPE

END

Message count by type

Information about the file just validated

see page 53

see page 50

To see an example, run one of the files in Instream’s Scripts directory and then look in

Instream’s Output directory for a filename that contains the word Summary.

Instream Validation Technical Manual Validation Results



30

Detail Results

The detail results file contains the details of the validation. Its name and location are specified with the -o command line parameter.

The file has the following structure.

VER

STRT

body (GEN, DTL, EDAT, EMSG, ESEG, SVRTS, ETYPS, Custom Z records)

SVRTY

ETYPE

END

Each DTL record will be followed by an EMSG and ESEG and possibly an EDAT.

Don’t assume the order of EMSG, ESEG, and EDAT.

TA1

Instream produces a TA1 file under these conditions:



GuidelineBestFit=0 in the $dir.ini/fsdir.ini

 No guideline is provided on the command line



No guideline is identified by trading partner automation (GS01 or GS08 is missing)




31

Line Numbers

Line numbers appear throughout Instream’s validation detail file, XML report, and delimited report.

Example from detail file

DTL 21 2100 NM11036 18 4 ...

EMSG 21Element NM104 (D.E. 1036) at col. 18 ...

Example from validation XML report

This is the line number where the error was discovered, but not always the line number where the problem actually occurred. In some cases, it cannot be determined that a segment has an error until later in the transaction.

For example, balancing rules have to be run at the end of a loop. Instream becomes aware of the loop ending when it encounters the first segment after the loop ends. It then makes the balancing comparison and uses its current line number – the first segment after the loop. This is the line number that will appear in the DTL record.




32

Record Definitions

CSEG: Current Segment Data Record

The CSEG record is variable length and contains the actual contents of the EDI segment currently being processed.

By default, CSEG records are not output since their presence inflates the size of the detail file. To output CSEG records, set CSEG=1 in the APF file. For details, please see the Detail Record Output section of the APF.pdf in Instream’s Doc directory.

CSEG Record Layout

Field

Record Tag (CSEG)

Line #

Segment Data

Length Start

5 1

10

n

6

16

End

5

15

EOL

Record Tag

Contains CSEG to identify the type of record.

Line #

Contains the number of physical lines in the EDI data file up to the point where this record is generated. If the EDI data is wrapped to fixed length blocks, or has segment terminators that do not include a new-line character, the physical line number may not be a segment count.

Segment Data

Contains the complete EDI segment.




33

CTX: Context Record for Response Generator 999

In previous releases, Response Generator created a CTX segment in the 999 if the

IK403 started with “I” for Implementation syntax errors. Now, you have three options for 5010 999 Errata CTX records:

 No CTX records (the default)



Foresight-supplied CTX records



Your own custom CTX records

These are explained in CTX.pdf.

Example

The underlined information is static text.

CTX record in a DTL file:

CTX 19|CTX02|14,32001

Corresponding segment in a 999:

CTX*SITUATIONAL TRIGGER*SBR*14**2*1069~

CTX Record Layout

Field

Record Tag (CTX)

Line #

Vertical Bar

CTX02

Vertical Bar

Line # for 1st seg.

, (comma)

Error #

Length Start End

5

10

1

6

5

15

1

5

1 varies

1

5

16

17

22

23

17

21

23

Record Tag

Identifies the type of record: CTX.

Line #


CTX02

Currently, this is always CTX02.




34

Line # for 1st seg

Line number in the EDI file for the first segment in the situational relationship. The ST is segment 1.

Error #

Error number generated when the situational relationship is violated. This must be in the

[RespGen Overrides] section of the validation APF used with Response Generator.

Example:

CTX50001=CTX,32001,SBR,,2,,,1069




35

DTL: Detailed Message Record

The DTL record is fixed length and contains detailed information about a warning, error, or information message generated by Instream validation.

The DTL record will be followed by an EMSG and ESEG record. It may also be followed by an EDAT record and one or more EMSG, EDAT, and ESEG records, depending on the error encountered.

DTL Record Layout

Field

Record Tag (DTL)

Line #

Loop/Group ID

Seg ID

Elem ID

Comp ID

Seg Pos

Elem Pos

SubElem Pos

Loop/Group Repeat

Count

10

10

2

2

5

4

4

10

6

4

Element Repeat

999 IK3-04

999 IK4-03

Filler

Error #

Severity

Seg Ordinal

Number

HIPAA Type

997 AK304

2

5

4

5

10

3

3

997 AK403

824 TED01

824 TED02

277 STC01-02

Filler

Application Data

3

5

5

20

2

3

1

2

Length Start End Notes

34

44

46

48

1

6

16

22

26

30

5

15

21

25

29

33

43

45

47

57

58

68

71

74

78

83

85

90

91

93

95

98

101

106

111

67

70

73

77

82

84

89

90

92

94

97

110

130

4020 or later not in EDIFACT or TRADACOMS not in EDIFACT or TRADACOMS not in EDIFACT or TRADACOMS not in EDIFACT or TRADACOMS not in EDIFACT or TRADACOMS not in EDIFACT or TRADACOMS

100 not in EDIFACT or TRADACOMS

105 not in EDIFACT or TRADACOMS right justified




36

Record Tag

Contains DTL to identify the type of record.

Line #


Loop/Group ID

Contains the identifier of the lowest level loop or group when the DTL record was generated. This field will be blank when the message is associated with an object that is outside any loop or group.

Seg ID

Contains the segment identifier in effect when the DTL record was generated. This segment ID may not be the one that caused the error. Instead, it is the segment being processing when the error was detected.

Example: An N2 segment is required in the NM1 loop. Instream does not know that it is missing until it encounters the N3 segment and notices that the N2 segment was not seen. The Segment ID in the ‘Missing Segment’ message will be N3, not N2. Also see the Segment Ordinal Number field, below.

Elem ID

Contains the element identifier corresponding to the message in the DTL record. If the message is not related to an element, this field is blank.

Comp ID

Contains the composite identifier corresponding to the message in the DTL record. If the message is not related to a composite, this field is blank.

Seg Pos

Contains a sequential number indicating where the segment is located in the input file.

This is the segment being processed when the error was detected, not necessarily the segment that caused the message to be generated. The numbering starts at 0 at each ST or UNH and increments through the set or message. It starts over at the next ST or

UNH.

Elem Pos

Contains the position number of the element or composite in the segment that caused the message, starting with 1. If the message is not related to an element, this field is blank.




37

SubElem Pos

Contains the position number of the subelement within the composite that caused the message, starting with 1. If the message is not related to a composite, this field is blank.

Loop/Group Repeat Count

Shows the iteration of the loop or group. For example, if the error is within the second iteration of the claim loop for a particular dependent, then this value is 2.

Element Repeat

X12-4020 and later. Shows which position a repeating element occupies. Example: If the element repeats three times and the error is in the second one, this field will contain 2.

999 IK3-04

Used in X12 999 responses only. The Implementation Segment Syntax Error Code for this error number. This field is mapped from the Warning Levels section of the APF file used. See APF.pdf in Instream’s Doc directory.

999 IK4-03

Used in X12 999 responses only. The Implementation Data Element Syntax Error Code for this error number. This field is mapped from the Warning Levels section of the

APF file used. See APF.pdf in Instream’s Doc directory.

Filler

Blank field reserved for future development.

Error #

Contains the ID number of the error.

Severity

Contains the severity of the error, one of these:

0 Ignore

1 Informational

2 Warning

3 Error

4 Fatal Error

5 User Level 1

6 User Level 2




38

Seg Ordinal Number

Contains the ordinal (internal key) number of the segment that caused the message. The ordinal number is mainly for internal use by TIBCO Foresight. Unlike the Seg ID field, this segment will actually be the one that is referenced by the message, not the current segment being processed.

Let’s use the same example from the Seg ID field above. An N2 segment is required in the NM1 loop. Validator does not know that it is missing until it encounters the N3 segment and notices that the N2 segment was not seen. The Segment Ordinal Number in the ‘Missing Segment’ message will be for the N2, not the N3.

HIPAA (WEDI SNIP) Type

The WEDI SNIP Type field contains the HIPAA type of the error. The valid types and their meanings are:

0 General messages. TIBCO Foresight assigns messages to Type 0 if they do not deal with WEDI SNIP type errors or warnings.

1 EDI Syntax

2 Syntactical Requirement (within HIPAA Validator® Desktop, this is combined with 1)

3 Balancing

4 Situation

5 Code Set

6 Product Types or Lines of Service

7 Payer Specific

8 Partner Specific (within HIPAA Validator Desktop, this is shown as a P)

997 AK304

Used in X12 997 responses only. The Segment Syntax Error Code for this error number.

This field is mapped from the Warning Levels section of the APF file used. See

APF.pdf in Instream’s Doc directory.

997 AK403

Used in X12 997 responses only. The Element Syntax Error Code for this error number.

This field is mapped from the Warning Levels section of the APF file used. See

APF.pdf in Instream’s Doc directory.

824 TED01

Used in X12 824 responses only. Application Error Condition Code for this error number. This field is mapped from the Warning Levels section of the APF file used.

See APF.pdf in Instream’s Doc directory.




39

824 TED02

Used in X12 824 responses only. Technical Error Description Free Form Message for this error number. This field is mapped from the Warning Levels section of the APF file used. See APF.pdf in Instream’s Doc directory.

277 STC01-02 code

Used in X12 277 responses only. Health care claim status code. This field is mapped from the Warning Levels section of the APF file used. See APF.pdf in Instream’s Doc directory.

Application Data

For your use. This field is mapped from the APF file’s Warning Levels section. It is the last item in the error’s definition. The data is right-justified in the field.

Example usage: Store your own error number that corresponds to the TIBCO Foresight error number. See APF.pdf in Instream’s Doc directory.




40

EDAT: EDI Error Data Record

The EDAT record is variable length and contains the actual data that caused the warning, error, or information message referred to by the preceding DTL record.

The EDAT record follows, and further describes, a DTL record. Only one EDAT record occurs for a DTL record.

If no specific data is involved in the error (example: missing segment), then no EDAT record is written; since there would be no data to show.

EDAT Record Layout

Field

Record Tag (EDAT)

Line #

Error Data


5

10

n

1

6

16

5

15

EOL

Record Tag

Contains EDAT to identify the type of record.

Line #


Error Data

Contains the data that caused the error.




41

EDTL: Detailed Message Record for XML Data

For details about XML, see

XMLatForesight.pdf

The EDTL record is variable length and contains detailed information about a warning, error, or information message generated by Instream when validating XML or flat file data.

The flat file format is documented separately on page

44 .

The EDTL record will be followed by an EMSG record ESEG record and may be followed by an EDAT record, depending on the error encountered.

Example:

EDTL 16|/PO/BT_COUNTRY/||BT_COUNTRY|13|||||18244|3|

EDTL Record Layout

Field Length Start End

Record Tag (EDTL)

Line #

5

10

1

6

5

15

The remaining fields are variable length and each is preceded with a vertical bar

Path from root

Group Repeat Count

“Segment” ID

Position

Not used for XML

Not used for XML

Not used for XML

Not used for XML

Error #

Severity

17

Record Tag

Contains EDTL to identify the type of record.

Line #

Contains the number of physical lines in the XML data file up to the point where this record is generated.




42

Path from root

Contains the path from the root to the element containing the error. Slashes separate each part of the path. If this element had an error, the EDTL would contain a path of

/PO/PO_NUMBER/ :

Group Repeat Count

The iteration of the group, if applicable.

“Segment” ID

The ID of the “segment” to which the message pertains:

Position

The first character position where the error was detected. In this example, USA is not an acceptable value so the position is 13 because the “U” is the 13 th

position from the start of the tag:

<BT_COUNTRY>USA</BT_COUNTRY >



Error#


Severity


0 Ignore

1 Informational

2 Warning

3 Error

4 Fatal Error

5 User Level 1

6 User Level 2


For your use. This field is mapped from the APF file’s Warning Levels section. It is the last item in the error’s definition. Example usage: Store your own error number that corresponds to the TIBCO Foresight error number. See APF.pdf in Instream’s Doc directory.




43

EDTL: Detailed Message Record for Flat File Data

For details about flat files, see

FlatFilesAtForesight.pdf

The EDTL record is variable length and contains detailed information about a warning, error, or information message generated by Instream when validating XML or flat file data.

The XML version of this record is documented separately on page

42 .

The EDTL record will be followed by an EMSG record ESEG record and may be followed by an EDAT record, depending on the error encountered.

Example:

EDTL 5||0|PETS|SPEC|2||0|2|10605|3|

EMSG 5Code Value "PARAKEET" not found in the dictionary ...

EDAT 5PARAKEET

ESEG 5PETS*JENNY*PARAKEET*BLUE!

EDTL Record Layout

Field

Record Tag (EDTL)

Line #

Length

5

10

Start

1

6

End

5

15


Loop ID

Loop Repeat Count

Segment ID

Element ID

Element Position

Subelement ID

Subelement Position

17

Ordinal Number

Error #

Severity

Application Data




44

Record Tag

Contains EDTL to identify the type of record.

Line #

Contains the number of physical lines in the data file up to the point where this record is generated.

Loop ID

Contains the identifier of the lowest level loop where the EDTL record was generated.

This field will be blank when the message is associated with an object that is outside any loop.

Loop Repeat Count

Shows the iteration of the loop containing the error. For example, if the error is within the second iteration of a repeating loop, then this value is 2.

Segment ID

Contains the record identifier in effect when the EDTL record was generated. This segment ID may not be the one that caused the error. Instead, it is the segment being processing when the error was detected.

Element ID

Contains the field tag that generated the message. This may not be what caused the error, but it was being processed when the error was detected.

Element Position

The position number of the field in the record that caused the message, starting with 1.

If the message is not related to an element, this field is blank.

Subelement ID

Contains the identifier of the field within a complex field.

Subelement Position

Contains the position number of the field within the complex field that caused the message, starting with 1.

Ordinal Number

Contains the ordinal (internal key) number of the record that caused the message. The ordinal number is mainly for internal use by TIBCO Foresight. This will actually be the one that is referenced by the message, not the current record being processed.




45

Error #


Severity


0 Ignore

1 Informational

2 Warning

3 Error

4 Fatal Error

5 User Level 1

6 User Level 2


For your use. This field is mapped from the APF file’s Warning Levels section. It is the last item in the error’s definition. Example usage: Store your own error number that corresponds to the TIBCO Foresight error number. See APF.pdf in Instream’s Doc directory.




46

ELOC: Error Location Record

The ELOC record is variable length and contains the names of elements, composites, segments, and loops to identify the location of errors. For errors in the 10000-19999 range, it shows the error location in business language rather than for an EDI specialist.

If ELOC=1 in the validation APF:



An ELOC record appears in the detail file after each EMSG record.



An ELOC record appears in a Response Generator custom report if the custom report template contains the

%

ErrMsg_NonTech% variable.



Transaction Insight Portal users will see this information if they selects Nontechnical messages.

Demo V_RG_837P_4010_textrpt_ELOC in Instream’s Scripts directory.

Output Examples using ELOC=1 in APF

1. Detail file entry. Data is EDI.

Example:

EMSG 6Element NM103 (D.E. 1035) at col. 10 is missing, though marked "Must Be Used"

ELOC 6\Name Last or Organization Name\\Submitter Name

2. Response Generator custom report entry with %ErrMsg_NonTech% variable in report template. Data is EDI.

Example:

%ErrMsg%

Clm: The field Name Last or Organization Name field of the Other Payer Name

%ErrMsg_NonTech%

Clm: The field Name Last or Organization Name field of the Other Payer Name information in the

Claim Information/Other Subscriber Information area at col. 10 is missing though it was marked

in the guideline as "Must Be Used".

3. Detail file entry. Data is XML with error in tag.

Example:

EDTL 13|/PO/ST_CITY/||ST_CITY|25|||||18202|3|

EMSG 13Expected end of tag 'ST_CITY'

EDAT 13

ESEG 13<BT_CITY>DAMASCUS</BT_CITY>

ELOC 13ST_CITY/PO/ST_CITY/




47

Record Layout

ELOC Record Layout


Record Tag (ELOC)

Line #

Location Text

5

10

n

1

6

16

5

15

EOL

Record Tag

Contains ELOC to identify the type of record.

Line #


Location Text

A variable length field that contains the name of the loop, segment, composite, and element referred to by the preceding DTL record.




48

EMSG: Error Message Record

The EMSG record is variable length and contains the actual text of the warning, error, or information message referred to by the preceding DTL record.

The EMSG record only occurs after a DTL record. It further describes the DTL record.

One EMSG record occurs for each DTL record.

EMSG Record Layout

Field

Record Tag (EMSG)


5 1 5

Line #

Error Message Text

10

n

6

16

15

EOL

Record Tag

Contains EMSG to identify the type of record.

Line #


Error Message Text

A variable length field that contains the text of the error, warning, or informational message referred to by the preceding DTL record.




49

END: End Validation Record

The END record is variable length and occurs once at the end of the detail and summary files. It contains various pieces of information about the file just validated.

END Record Layout

Field

Record Tag (END)

Line #

Error #

Severity

Date/Time

FileName Msg

2

17

n


5 1 5

10

5

6

16

15

20

21

23

40

22

39

EOL

Record Tag

Contains END to identify the type of record.

Line #

The number of physical lines in the EDI data file. If the EDI data is wrapped to fixed length blocks, or has segment terminators that do not include a new-line character, the physical line number may not be a segment count.

Error #

Contains the error number of the ‘Analysis Completed’ message (by default, this is

10006).

Severity

Contains the severity code of the ‘Analysis Completed’ message (by default, this is 1).

Date/Time

Contains the data and time that the validation completed in the format MM/DD/YY

HH:MM:SS (a single space separates the date and time).

FileName Msg

Contains the name and size of the EDI data file just validated. The format of this message is ‘Analysis of file filename complete’ where filename is the full path and filename of the EDI data file.




50

ENDS: End Record for Transaction Set or Message

The ENDS record is fixed length and occurs once at the end of each transaction set or message.

ENDS Record Layout

Field

Record Tag (ENDS)

Line #

Segment Count

ST/SE Control #


5 1 5

10

10

9

6

16

26

15

25

34

Record Tag

Contains ENDS to identify the type of record.

Line #


Segment Count

The actual number of segments in this transaction set or message, including:

X12: ST and SE

EDIFACT: UNH and UNT

This is NOT simply a repeat of the value in the SE01 or UNT01 and it does not include:

X12: ISA, GS, GE, or IEA

EDIFACT: UNB, UNG, UNE, and UNZ

ST/SE Control #

X12: The SE02 value for the transaction set for this ENDS record.

EDIFACT: The UNT02 value for the message for this ENDS record.




51

ESEG: Error Segment Data Record

The ESEG record is variable length and contains the actual contents of the EDI segment that caused the warning, error, or information message referred to by the preceding DTL record.

If the message refers to specific data, then an ESEG record will follow, and further describe, a DTL record. Only one ESEG record will occur for a DTL record.

Some errors don’t refer to particular data, and these will have no ESEG record. For example, a missing segment won’t generate a EMSG record since it has no data to show.

ESEG Record Layout


Record Tag (ESEG)

Line #

Segment Data

5

10

n

1

6

16

5

15

EOL

Record Tag

Contains ESEG to identify the type of record.

Line #


Segment Data

Contains the complete EDI segment where the message was generated.




52

ETYPE: Error Type Summary Record for File

The ETYPE record is fixed length and occurs once at the end of the detail and summary files. It contains a count of messages by type, including messages referring to enveloping segments.

You can see an error’s type in the Warning Levels section of the APF file being used for the validation. See APF.pdf in Instream’s Doc folder.

ETYPE Record Layout

Field

Record Tag (ETYPE)

Line #

Type 0 Count

EDI Syntax Count

Syntactical Requirement

Balancing Count

Situation Count

Code Set Count

Product Count

Payer Count

Partner Count type 0 type 1 type 2 type 3 type 4 type 5 type 6 type 7 type 8

10

10

10

10

10

10

10

10

10

Length Start

5

10

1

6

76

86

96

46

56

66

16

26

36

55

65

75

25

35

45

End

5

15

85

95

105

Record Tag

Contains ETYPE to identify the type of record.

Line #

Contains the number of physical lines in the entire EDI data file, including all enveloping. If the EDI data is wrapped to fixed length blocks, or has segment terminators that do not include a new-line character, the physical line number may not be a segment count.

Type 0 Count

Contains the number of Type 0 messages in the entire EDI data file. TIBCO Foresight uses Type 0 for general messages that do not deal with EDI errors or warnings.

Error Type Count Fields

Contain the number of errors for each error type in the entire EDI data file.




53

ETYPS: Error Type Summary Record for

Transaction Set or Message

The ETYPS record is fixed length and occurs on every SE or UNT segment in the EDI data file. It contains the total number of errors, by type, in the transaction set or message. It does not include errors in interchange or functional group enveloping.

ETYPS Record Layout

Field

Record Tag (ETYPS)

Line #

Type 0 count

EDI Syntax Count

Syntactical Requirement

Balancing Count

Situation Count

Code Set Count

Product Count

Payer Count

Partner Count type 0 10 type 1 10 type 2 10 type 3 10 type 4 10

Length Start

5

10

1

6

16

26

36

46

56 type 5 10 type 6 10 type 7 10 type 8 10

66

76

86

96

25

35

45

55

65

End

5

15

75

85

95

105

Record Tag

Contains ETYPS to identify the type of record.

Line #


Type 0 Count

Contains the number of Type 0 messages in the transaction set or message. TIBCO

Foresight uses Type 0 for general messages that do not deal with EDI errors or warnings.

Error Type Count Fields

Contain the number of errors, by type, in the transaction set or message.




54

EVALU: Element Value Record

EVALU records display the data in an EDI element. Currently, no TIBCO Foresight guidelines create EVALU records and TIBCO Foresight programs do not use them after they are created in the validation detail results file.

They will be generated if:

 The APF file used for validation contains EVALU=1.

 You have added EVALU records to the guideline with EDISIM Standards Editor

(see below).

To create EVALU records for your own use:

1. Right-click on an element in Standards Editor and select DSR Mark.

A pop-up box allows you to change the default structure ID. You will need the

Standards Editor that ships with EDISIM 5.14 or later.

2. (if HIPAA)

Merge the guideline.

Use Instream to validate with the merged guideline.

3. (if not HIPAA)

Copy the guideline to Instream’s Database directory and validate with it.

Example: This displays the data for the data in the ST-02 element. It shows that the element is in the segment at line 3 in the data; the second element in the segment; and has a value of 0386.

EVALU 3|ST_02|1|2|0|0386

You can prevent EVALU segments from being created by setting EVALU=0 in the

APF file.

EVALU Record Layout

Field

Record Tag (EVALU)

Length

5

Start

1

End

5

Line # 10 6 15


Structure ID 17

Segment Position

Element position

Subelement position

Element value end of record




55

Record Tag

Contains EVALU to identify the type of record.

Line#

The number of physical lines in the EDI data file up to the point where the EVALU is generated. If the EDI data is wrapped to fixed length blocks, or has segment terminators that do not include a new-line character, the physical line number may not be a segment count.

Structure ID

The variable name assigned to the element. See page

80 .

Segment Position

The ordinal position of the segment that contains the element. This is roughly equal to the position of the segment in the guideline when used and unused segments are all taken into account. See the SEF 1.6 documentation for details about ordinals.

Element position

The position of the element within its segment.

Subelement position

The position of the subelement within its composite, if the data is in a subelement.

Otherwise, this will be 0.

Element data

The data in the element.




56

GEN: General Message Record

The GEN record is fixed length and contains informational messages generated by the validation. They mark such things as start of interchange.

Please see Displaying Version Information in the Results File on page

72

for some additional fields that Instream can add to the end of GEN records.

Please see ICD-10_at_Foresight.pdf for the format of the GEN record created by ICD business rules.

GEN Record Layout

Field

Record Tag (GEN)

Line #

Error #

Severity

Type

Message

2

2

n


5

10

5

1

6

16

5

15

20

21

23

25

22

24

EOL

Record Tag

Contains GEN to identify the type of record.

Line #


Error #

Contains the ID number of the error message that is included within the GEN record.

Severity

Contains the severity of the error message that is included within the GEN record, one of the following numbers:

0 Ignore

1 Informational

2 Warning

3 Error

4 Fatal Error

5 User Level 1

6 User Level 2




57

Type

Contains the type of the informational message encountered. Generally, this will be 0 in a GEN record, but you can map the error number to a HIPAA type in the APF file. The valid type codes and their meanings are:

0 General message; not an EDI error or warning

1 EDI Syntax

2 Syntactical Requirement (within HIPAA Validator Desktop, this is combined with 1)

3 Balancing

4 Situation

5 Code Set

6 Product Types or Lines of Service

7 Payer Specific

8 Partner Specific (within HIPAA Validator Desktop this is shown as a P)

Message

A variable length field containing the actual message text.

If you have this line in the [Options] section of your $Dir.ini in Instream’s Bin directory, this will be a FSUID. Please see FSUID_and_AppDocs.pdf.

GEN record 17021

Document types and message references:



EDIFACT

Document type(1), Message reference(UN)



FlatFile

Document type(2), Message reference(flatfile)

 XML

Document type(3), Message reference(XML)

 TRADACOM

Document type(4), Message reference(DT)

 X12

The message is not written out




58

IDENT: Unique Identifier Record

The IDENT record contains a unique identifier (TIBCO Foresight Unique ID or

FSUID) to identify a part of the input data passed to Instream.

In this example, an IDENT record is generated for each subscriber CLM segment:

IDENT Record Layout

Field Length Start

Record Tag (IDENT)

Line #

5

10

The remaining fields are separated by vertical bars

1

6

RuleID

FSUID

SystemID

Reserved

1 varies varies varies

17

19

End

5

15 at vertical bar at vertical bar end of record

Record Tag

Contains IDENT to identify the type of record.

Line #

The number of physical lines in the EDI data file up to the point where the IDENT is generated. If the EDI data is wrapped to fixed length blocks, or has segment terminators that do not include a new-line character, the physical line number may not be a segment count.

RuleID

Shows which business rule created it. Contains:



M if the record was created by a Match business rule

 I if the record was created by an Identify business rule

FSUID

TIBCO Foresight User ID, a unique 37-character ID. Should never be repeated in an

IDENT record.




59

SystemID

ID to identify Instream system used for validation. It always contains 1 for the initial

Instream run (this is the only system defined by default in TI). If the record contains a

SystemID other than 1, define the system in TI under Settings | External System Setting before attempting to import the detail file.

Reserved

Reserved for future development.




60

STRT: Start Validation Record

The STRT record is variable length and occurs once in the detail and summary results files. It is the second record in the file. It contains the date and time that validation started and the name, location, and size of the EDI data file.

STRT Record Layout

Field

Record Tag (STRT)

Line #

Error #

Severity

Date/Time

FileName Msg

2

17

n


5

10

5

1

6

16

5

15

20

21

23

40

22

39

EOL

Record Tag

Contains STRT to identify the type of record.

Line #

Always contains 0, since this record is generated before validation of any segments.

Error #

Contains the error number of the ‘Analysis Requested’ message (10002).

Severity

Contains the severity code of the ‘Analysis Requested’ message (1 by default).

Date/Time

Contains the data and time that the validation was started in the format MM/DD/YY

HH:MM:SS (a single space separates the date and time).

FileName Msg

Contains the name and size of the EDI data file being validated. The format of this message is ‘Analysis requested on file filename, size bytes long’ where filename is the full path and file name of the EDI data file, and size is the number of bytes in the file.




61

STRUE: Structure End Record

STRUE records mark the end of every interchange, functional group, transaction set or message, and loop or group.

They will be generated if the APF file used for validation contains STRUE=1. This is true regardless of which guideline is used for validation.

The start of the structure is marked with a STRUS record.

Example

This marks the end of loop 1000A, which occurs at line 8 in the EDI data:

STRUE 8|1000A|0|1|337|0:0:0:0:0:0:0|0:0:0:0:0:0:0:0:0|PER

STRUE Record Layout


Record Tag (STRUE)

Line #

5

10

1

6

5

15

The remaining fields are variable length and each is preceded with a vertical bar.

Structure ID

Document flag

17

Instance

Ending position

Errors by severity

Errors by type

ID of ending segment end of record

Record Tag

Contains STRUE to identify the type of record.

Line #


Structure ID

Contains the ID of the segment or loop/group that starts the structure. This field starts at character position 17 and ends with a vertical bar. See page

80 .




62

Document flag

This marks structures that you designate as application documents. The flag will match the one in the corresponding STRUS record (see page

64 ).

Document flags are for your own use and for future enhancements within TIBCO

Foresight products.

Instance

The first instance of the structure that is ending will be 1, the second will be 2, etc.

Ending position

The number of bytes from the beginning of the EDI data to the end of this structure.

Errors by severity

The number of errors of each severity in the structure that is ending. Colons separate each severity.

Errors by type

The number of errors of each type in the structure that is ending. Colons separate each type.

Ending segment ID

The segment tag for the last segment in the structure.




63

STRUS: Structure Start Record

STRUS records mark the start of every interchange, functional group, transaction set or message, and loop or group. A corresponding STRUE record marks the end of each structure.

They will be generated if the APF file used for validation contains STRUS=1. This is true regardless of which guideline is used for validation.

You can change the document flag in a STRUS record as described under Document

flag below.

Example: This marks the start of loop 1000A, which occurs at line 6 in the EDI data:

STRUS 6|1000A|0|1|255

STRUS Record Layout

Field

Record (STRUS)

Length

5

Start

1

End

5

Starting line # 10 6 15


Structure ID 17

Document flag

Instance

Starting position end of record

Record Tag

Contains STRUS to identify the type of record.

Starting line #


Structure ID

Contains the ID of the segment or loop/group. This field starts at character position 17

and ends with a vertical bar. See Appendix C: SVALU Record Structure IDs on page 79 .




64

Document flag

This marks loops or groups that you consider application documents. The flag is set to 0 by default, and is set to 1 if you have designated this loop as an application document.

To designate this loop or group as an application document:

1. Right-click on the loop or group in Standards Editor and select DSR Mark. You will need the Standards Editor that ships with EDISIM 5.14 or later.

2. Merge the guideline with a TIBCO Foresight PD guideline.

3. Validate with the merged guideline. The document flag for this STRUS will be 1 in the detail results file.

Document flags are for your own use and for future enhancements within TIBCO

Foresight products.

Instance

If the structure occurs more than once in the transaction set or message, the instance identifies which one is being shown. For example, the first instance of a claim loop will be 1, the second instance will be 2, etc.

Starting position

This is the number of bytes from the beginning of the EDI data to the beginning of this structure.




65

SVALU: Segment Value Record

SVALU records display the data in an EDI segment.

They will be generated if:

 The APF file used for validation contains SVALU=1.



The guideline used for validation is a PD guideline, a user guideline that generates

SVALU records (see below), or a guideline merged from either of them.

To create SVALU records for your own use:

1. Right-click on a segment in Standards Editor and select DSR Mark. A pop-up box allows you to change the default structure ID. You will need the Standards Editor that ships with EDISIM 5.14 or later.

2. (if HIPAA)

Merge the guideline.

Use Instream to validate with the merged guideline.

3. (if not HIPAA)

Copy the guideline to Instream’s Database directory and validate with it.

Example: This displays the data for a claim segment, which has been given Structure ID

S009 and is 37 lines and 464 bytes from the beginning of the EDI data.

SVALU 37|S009|464|CLM*1*100.00***11:A:1*N*A*N*A*********N**1

You can prevent SVALU segments from being created by setting SVALU=0 in the APF file. Do not do this if you are using Docsplitter.

SVALU Record Layout


Record Tag (SVALU)

Line #

5

10

1

6

5

15


Structure ID

Structure position

Segment data varies varies varies

17 varies varies varies varies end of record




66

Record Tag

Contains SVALU to identify the type of record.

Line#


Structure ID

Contains the ID of the structure. This matches the ID of the corresponding TIBCO

Foresight-supplied Z-record that was discontinued in Instream version 4.5.

Appendix C: SVALU Record Structure IDs on page 79

shows where records with each

Structure ID are generated.

Structure position

The ordinal position of the segment within the transaction set or message, according to the guideline.

Segment data

The entire EDI segment.




67

SVRTS: Error Severity Summary Record for

Transaction Set or Message

The SVRTS record is fixed length and occurs on each SE or UNT segment. It contains the number of messages generated in that transaction set or message for each severity.

Severities are set in the validation’s APF file. See APF.pdf in Instream’s Doc folder for details.

SVRTS Record Layout

Field

Record Tag (SVRTS)

Line #

Ignore Count

Info Count

Warning Count

Error Count

Fatal Count

User1 Count

User2 Count severity 0 10 severity 1 10 severity 2 10 severity 3 10 severity 4 10 severity 5 10 severity 6 10

Length

5

10

46

56

66

16

26

36

76

Start

1

6

55

65

75

25

35

45

85

End

5

15

Record Tag

Contains SVRTS to identify the type of record.

Line #


Severity Error Count Fields

Contain the number of errors for each severity level.




68

SVRTY: Error Severity Summary Record for File

The SVRTY record is fixed length and occurs once toward the end of the summary and detail results file. It contains a count of messages by severity level.

It is usually the next-to-last record in the file, just before the End record.

SVRTY Record Layout

Field

Record Tag (SVRTY)

Ignore Count

Info Count

Warning Count

Error Count

Fatal Count

User1 Count

User2 Count

Length

5 severity 0 10 severity 1 10 severity 2 10 severity 3 10 severity 4 10 severity 5 10 severity 6 10

Start

1

6

16

26

36

46

56

66

Record Tag

Contains SVRTY to identify the type of record.

Count Fields

Contain the number of errors for each severity.

End

5

15

25

35

45

55

65

75




69

VER: Version Record

The VER record is variable length and occurs once in the detail and summary results files. It is the first record in the file and contains the version number of the output file format.

VER Record Layout

Field

Record Tag (VER)

Version


5

n

1

6

5

EOL

Record Tag

Contains VER to identify the type of record.

Version

Contains the version number of the output file in the format n1.n2, where n1 is the major version number, which can be one or more digits, and n2 is the minor version number.




70

Z: Custom Data Record

You can include the contents of actual data fields in the output file. See CustRec in

BusinessRules.pdf in Instream’s Doc directory.

Z Record Layout

Field

Record Tag (Zaaaa)

Line #

Field 1 Data

Field n Data


5 1 5

10 6 15

Record Tag

Identifies the type of record. For this record, this field always starts with Z followed by one-to-four alphanumeric characters.

Line #


Field Data

Contains the contents of the specified variable name as defined in the guideline.




71

Displaying Version Information in the Results File

You can display version, date, and time information at the end of the GEN records at the top of the validation detail results file. To do this, change this line in the $dir.ini file:

:ShowVersion=0 to:

ShowVersion=1

Be sure to remove the leading colon.

This causes:

 Version information to appear at the end of these GEN records near the top of the file:

GEN 015074 1 0Message file loaded :

C:\Foresight\InStream\bin\FSANERRS.TXT (Version=6.2.0

Date=2007/09/26 13:44)


C:\Foresight\InStream\bin\FSBRERRS.TXT (Version=6.2.0

Date=2007/09/26 13:44)


C:\Foresight\InStream\bin\CustomerFSBRERRS.TXT (Date=2004/08/26

14:27)

GEN 311001 1 0Loaded Message ORDERS from Standard myorders (Date=2007/10/01 15:03)



This record to appear:

GEN 015073 1 0HIPAA table loaded

C:\Foresight\InStream\Bin\fs_hipaa.dat (Version=6.1.0.1)

This information refers to the version and date of the file mentioned in the message.




72

HIPAA External Code Tables

Table File Server

The Table File Server is an application that loads the external code tables used during

HIPAA validation. It provides faster processing of many very small EDI files, since it preloads the code tables used during validation. It may slow processing for large files.

For details, see page

75 .

Extending or Modifying Code Tables

You can add to or override codes in the HIPAA external code tables provided by

TIBCO Foresight.

Example situations where you might want to do this:



You receive an error message indicating that a code is invalid, but you are accepting the code.

 Instream does not flag a code as an error, and you want to have it flagged.

For details, see ExtendingCodeTables.pdf in Instream’s Doc folder.

Creating your own Code Tables

You can create your own code tables and use EDISIM Standards Editor to create rules that enforce them.

This is explained in detail in BusinessRules.pdf, which is in Instream’s Doc directory.

Instream Validation Technical Manual HIPAA External Code Tables



73

Appendix A: Return Codes

Refer to the document Return_Codes_and_Troubleshooting.pdf for Instream validation return code information.

Instream Validation Technical Manual Appendix A: Return Codes



74


HIPAA only

The Table File Server is an application that loads the external code tables that can be used during HIPAA validation. It provides faster processing of many very small EDI files by preloading code tables used during validation.

For best performance when processing medium or large files, do not use the Table File

Server. Instream processes files larger than 1048578 bytes without using the file server.

When using an API to run Instream validation, the Table File Server is used if it has been started before the application program that uses the API.

These files are associated with the Table File Server:

Windows UNIX Purpose

fsFileServer.exe fscint.ini fsFileServer fscint.ini

Table File Server executable. Installed in

Instream

’s Bin folder but can be moved to another machine.

INI file that Instream uses to locate

fsFileServer or fsFileServer.exe on local machine or on one or more remote server locations. Must stay in Instream

’s Bin folder. fsFileServer.ini fsFileServer.ini INI file that goes in same folder as

fsFileServer or fsFileServer.exe. Specifies the number of connections and the port to which it listens. fsFileServerDebugMode.bat n/a n/a n/a

RunServDemo startfServer shutdownfServer

Batch file to start the Table File Server in debug mode.

Instream

’s API\FsServer directory. Script file to test your Table File Server setup.

In Instream

’s API\FsServer directory. Script files to start / stop the Table File Server.




75 Instream Validation Technical Manual

fscint.ini Setup

As installed, the Table File Server runs from Instream’s Bin directory. You can configure it to run on a different machine on the network as long as it is accessible by the main Instream installation.

To adjust its location, edit fscint.ini, which must be in Instream's Bin directory. The file lists servers and ports where Instream can find the Table File Server running. For example, you might replace

LocalHost 5850

with one or more IP addresses and ports. Multiple machines could be set to the same port.

If you list multiple machines and ports, the Table File Server will try to access the top

one. If it is accessible and the maximum number of users (see MAXCONNECTION on

page

77 ) hasn’t been exceeded, then it uses that one. Otherwise, it continues down the

list until it finds one that it can use.

It will look only if fscint.ini has USINGFSFILESERVER=ON.

Sample Windows fscint.ini

(in Instream’s Bin directory)

#list of host and port to connect to

# using fsFileServer USINGFSFILESERVER should be set to ON/OFF

USINGFSFILESERVER=ON

LocalHost 5850

255.255.255.0 5855

Sample UNIX fscint.ini

# using fsFileServer USINGFSFILESERVER should be set to

ON/OFF

USINGFSFILESERVER=ON

#list of host and port to connect to

YOURCOMPUTER 5850

255.255.255.0 5855

255.255.255.1 5855

Instream Validation Technical Manual Appendix B: Table File Server



76

fsFileServer.ini Setup

The server configuration specifies the port to which the server is “listening” and the number of connections you are allowing. The server port number must match in

fscint.ini and fsFileServer.ini. It can listen on only one port.

Example fsFileServer.ini.

(put in same directory as File Server)

#server port

PORT 5850

#max connection

MAXCONNECTION 8

Starting the Table File Server

Windows

1. Start the Table File Server by running fsFileServer.exe.

Debug mode: Run fsFileServer.exe with a –d parameter and start it from a batch file so the Table File Server maintains control of the console window.

To do this, you can use fsFileServerDebugMode.bat in Instream’s API\FsServer directory.

2. Run Instream with the Table File Server by including the -f command line parameter when starting Instream.

3. Stop the Table File Server by running ShutdownfsFileServer.bat in the

API/FsServer directory.

UNIX

1. Start the Table File Server by running ./startfServer from Instream’s

API/FsServer directory.

2. Run Instream with the Table File Server by including the -f command line parameter when starting Instream.

3. Stop the Table File Server by running shutdownfServer in the API\FsServer directory.




77

Table File Server Start-up Scripts

These scripts are installed under Instream’s API/FsServer directory.



Starting the Table File Server with Debugging Turned On

Windows:

UNIX: fsFileServerDebugMode.bat startfServer



Running Instream with the Table File Server

Windows:

UNIX:

RunFileServerDemo.bat

RunServDemo

This should yield detail and summary files in Instream’s output directory. If your

Dir.ini file has ShowVersion=1, your detail files will have a GEN record like this:

GEN 015080 1 0Connect to fsFileServer on Host



Stopping the Table File Server

Windows:

UNIX:

ShutdownfsFileServer.bat shutdownfServer

How to tell if the Table File Server is running

Use Task Manager to see whether fsFileServer.exe is running.




78

Appendix C: SVALU Record

Structure IDs

Structure IDs

HIPAA only

The SVALU record in the detail results file contains a Structure ID (see page

64 ) that

identifies where the record was generated.

Example:

STRUS 6|1000A|0|1|255

This ID matches the ID of the old custom Z records that were generated by Instream

4.4 and earlier.

The sources of SVALU records are:



Your own SVALU records that you created in EDISIM Standards Editor by rightclicking on a record and choosing DSR Mark:

In this case, you assign a variable to the location. This variable appears as the structure ID in the SVALU record.

 Certain HIPAA guidelines that place SVALU records in the detail results file. The chart below lists each structure ID supplied by these guidelines and shows where they are generated.

Instream Validation Technical Manual Appendix C: SVALU Record Structure IDs



79

HIPAA Structure ID Chart

All Documents

ID

Called on segment …

ISA1

GSSG

STST

TRSE

Interchange Information (ISA)

Functional Group Header (GS)

Transaction Set Header (ST)

Transaction Set Trailer (SE segment)

270 Eligibility, Coverage or Benefit Inquiry (PDSA270 and PDSA5010270X279)

ID


0021

ISST

HLIS

ISNM

HLIR

IRNM

SBST

SUBTRN

SBNM

SUBPRV

SBSV

DPST

DEPTRN

DPNM

DEPPRV

DPSV

Transaction Type Code (BHT)

Information Source Level (Loop 2000A, HL segment)


Information Source Name (Loop 2100A, NM1)

Information Receiver Level (Loop 2000B, HL segment)

Information Receiver Name (Loop 2100B, NM1 segment)

Subscriber Level (Loop 2000C, HL segment)

X12_5010:

Subscriber Trace Number (Loop 2000C, TRN segment)

Subscriber Name (Loop 2100C, NM1 segment)

Provider Information (Loop 2100C, PRV segment)

Subscriber Eligibility (Loop 2110C, EQ segment)

Dependent Level (Loop 2000D, HL segment)

X12_5010:

Dependent Trace Number (Loop 2000D, TRN segment)

Dependent Name (Loop 2100D, NM1 segment)

Provider Information (Loop 2100D, PRV segment)

Dependent Eligibility (Loop 2110D, EQ segment)




80

271 Eligibility, Coverage or Benefit Response to Inquiry (PDSA271 and

PDSA5010271X279)

ID


0021 Transaction Set Purpose Code (BHT segment)

IHLIS

ISNM

HLIR

IRNM

SBST

SUBTRN

SBNM

SBSV

DPST

DEPTRN

DPNM

DPSV

Information Source Level (Loop 2000A, HL segment )

Information Source Name (Loop 2100A, NM1 segment)




X12_5010:

Subscriber Trace Number (Loop 2000C, TRN segment)


Subscriber Eligibility (Loop 2110C, EB segment)


X12_5010:

Dependent Trace Number (Loop 2000D, TRN segment)


Dependent Eligibility (Loop 2110D, EB segment)




81

275 Patient Information (PDSA5010275X210.STD and PDSX5010275X210.STD)

ID


BGNSEGMENT Beginning Segment (BGN segment)

1000APAYER

1000BSUBMITTER

1000CPROVIDER

1100CPROVIDERID

1000DPATIENT

Payer Name (Loop 1000A, NM1 segment)

Submitter Information (Loop 1000B, NM1 segment)

Provider Name Information (Loop 1000C, NM1 segment)

Provider Identification (Loop 1100C, NX1 segment)

Patient Name (Loop 1000D, NM1 segment)

1000DCONTROLNUMBER Patient Control Number (Loop 1000D, REF segment)

2000ATRN

Payer Claim Control Number/Provider Attachment Control Number

(Loop 2000A, TRN segment)

2000ANUMBER

2000ASTC

Assigned Number (Loop 2000A, LX segment)

Status Information (Loop 2000A, STC segment)

2100ADTP

2100BDTP

2110BEFI

Service Line Date of Service (Loop 2100A, DTP segment)

Additional Information Submission Date (Loop 2100B, DTP segment)

Electronic Format Identification (Loop 2110B, EFI segment)




82

276 Health Care Claim Status Request (PDSA276 and PDSA5010-276X212)

ID


0021 Beginning of Hierarchical Transaction (BHT segment)

HLIS

ISPN

HLIR

IRNM

HLSP

SPNM

HLSB

SBNM

SBTN

SPCREF

SDOS

SBSV

HLDP

DPNM

DPTN

DPCREF

DDOS

DPSV

Information Source Level Starts (Loop 2000A, HL segment)


Information Receiver Level Starts (Loop 2000B, HL segment)


Service Provider Level Starts (Loop 2000C, HL segment)

Provider Name (Loop 2100C, NM1 segment)

Subscriber Level Starts (Loop 2000D, HL segment)

Subscriber Name (Loop 2100D, NM1 segment)

Claim Submitter Trace Number (Loop 2200D, TRN segment)

Payer Claim Identification Number (Loop 2200D, REF segment)

Claim Service Date (Loop 2200D, DTP segment)

Service Line Information Starts (Loop 2210D, SVC segment)

Dependent Level Starts (Loop 2000E, HL segment)

Dependent Name (Loop 2100E, NM1 segment)

Claim Submitter Trace Number (Loop 2200E, TRN segment)

Payer Claim Identification Number (Loop 2200E, REF segment)

Claim Service Date (Loop 2200E, DTP segment)

Service Line Information Starts (Loop 2210E, SVC segment)




83

277 Health Care Claim Status Response (PDSA277 and PDSA5010277X212)

ID



HLIS

ISPN

HLIR

IRNM

HLSP

SPNM

HLSB

SDMG

SBNM

IRTRN

IRSTC

Information Source Level Starts (Loop 2000A, HL segment)


Information Receiver Level Starts (Loop 2000B, HL segment)


Service Provider Level Starts (Loop 2000C, HL segment)


Subscriber Level Starts (Loop 2000D, HL segment)

X12-4010:

Subscriber demographic Information (Loop 2000D, DMG segment)


X12-5010:

Information Receiver Trace Identifier (Loop 2200B, TRN segment)

X12-5010:

Information Receiver Status Information (Loop 2200B, STC segment)

SPTRN

SPSTC

X12-5010:

Provider of Service Trace Identifier (Loop 2200C, TRN segment)

X12-5010:

Provider Status Information (Loop 2200C, STC segment)

SBTN

SSTC

SPCREF

Claim Submitter Trace Number (Loop 2200D, TRN segment)

Claim Level Status Information (Loop 2200D, STC segment)

X12-4010:

Payer Claim ID (Loop 2200D, REF segment)

X12-5010:

Payer Claim Control Number (Loop 2200D, REF segment)

SLREFCLAIMID X12_5010:

Claim Identification Number For Clearinghouses and Other Transmission

Intermediaries (Loop 2200D, REF segment)

SBTREF

SDOS

SBSV

HLDP

Institutional Bill Type Identification (Loop 2200D, REF segment)

Claim Service Date (Loop 2200D, DTP segment)

Service Line Information Starts (Loop 2220D, SVC segment)

X12-4010:

Dependent Level Starts (Loop 2000E, HL segment)




84

277 Health Care Claim Status Response (PDSA277 and PDSA5010277X212)

ID


DDMG

DPNM

DPTN

X12-4010:

Dependent demographic Information (Loop 2000E, DMG segment)


Claim Submitter Trace Number (Loop 2200E, TRN segment)

DSTC

DPCREF

Claim Level Status Information (Loop 2200E, STC segment)

X12-4010:

Payer Claim ID (Loop 2200E, REF segment)

X12-5010:

Payer Claim Control Number (Loop 2200E, REF segment)

DLREFCLAIMID X12_5010:

Claim Identification Number For Clearinghouses and Other Transmission

Intermediaries (Loop 2200E, REF segment)

DBTREF Institutional Bill Type Identification (Loop 2200E, REF segment)

DDOS

DPSV


Service Line Information Starts (Loop 2220E, SVC segment)




85

277CA (5010) Health Care Claim Acknowledgement (PDSA5010277CAX214.STD and

PDSX5010277CAX214.STD)

ID


0021

HLIS

ISPN

InfoSourceTRN

HLIR

IRNM

IRTRN

IRSTC

HLBP

BPNM

BPTRN

BPSTC

HLPT

PTNM

PTTN

PTSTC

PTPCREF

PTREFCLAIMID

PTBTREF

PTDOS

PTSV

Beginning of Hierarchical Transaction (BHT segment)



Transmission Receipt Control Identifier (Loop 2200A, TRN segment)



Information Receiver Application Trace Identifier (Loop 2200B, TRN segment


Billing Provider of Service Level (Loop 2000C, HL segment)

Billing Provider Name (Loop 2100C, NM1 segment)

Provider of Service Information Trace Identifier (Loop 2200C, TRN segment)

Billing Provider Status Information (Loop 2200C, STC segment)

Patient Level (Loop 2000D, HL segment)

Patient Name (Loop 2100D, NM1 segment)

Claim Status Tracking Number (Loop 2200D, TRN segment)

Claim Level Status Information (Loop 2200D, STC segment


Claim Identifier Number For Clearinghouse and Other (Loop 2200D, REF segment)

Institutional Bill Type Identification (Loop 2200D, REF segment)

Claim Level Service Date (Loop 2200D, DTP segment)

Service Line Information (Loop 2220D, SVC segment)




86

277U (5010) Health Care Claim Status Response ( PDSX5010-277UX212 only )

ID



HLIS

ISPN

HLIR

IRNM

IRTRN

IRSTC

HLSP

SPNM

SPTRN

SPSTC





Information Receiver Application Trace Identifier (Loop 2200B, TRN segment


Service Provider Level (Loop 2000C, HL segment)


Provider of Service Trace Identifier (Loop 2200C, TRN segment)

Provider Status Information (Loop 2200C, STC segment)

HLSB

SBNM

SBTN

SSTC

SPCREF

Subscriber Level (Loop 2000D, HL segment)


Claim Status Tracking Number (Loop 2200D, TRN segment)

Claim Level Status Information (Loop 2200D, STC segment


SBTREF Institutional Bill Type Identification (Loop 2200D, REF segment)

SLREFCLAIMID Claim Identifier Number For Clearinghouse and Other (Loop 2200D, REF segment)

SDOS

SBSV

Claim Level Service Date (Loop 2200D, DTP segment)

Service Line Information (Loop 2220D, SVC segment)

HLDP

DPNM

DPTN

DSTC

DPCREF

Dependent Level (Loop 2000E, HL segment)


Claim Status Tracking Number (Loop 2200E, TRN segment)

Claim Level Status Information (Loop 2200E, STC segment)

Payer Claim Control Number (Loop 2200E, REF segment)

DBTREF Institutional Bill Type Identification (Loop 2200E, REF segment)

DLREFCLAIMID Claim Identification Number For Clearinghouses and Other Transmission

Intermediaries (Loop 2200E, REF segment)

DDOS

DPSV


Service Line Information (Loop 2220E, SVC segment)




87

HLUM

UMNM

HLRQ

RQNM

SBST

HLSB

SBTN

278 Health Care Services Review Information Request (PDA278RQ and PDSA5010-

278X217Q)

ID



UMST

SBNM

HLDP

DPTN

DPNM

HLPELevel

PETRN

PEDATE

Utilization Management Organization (UMO) Level Starts (Loop 2000A, HL segment)

Utilization Management Organization (UMO) Level (Loop 2000A, HL segment)

Utilization Management Organization (UMO) Name (Loop 2010A, NM1 segment)

Requester Level (Loop 2000B, HL segment)

Requester Name (Loop 2010B, NM1 segment)

Subscriber Level Starts (Loop 2000C, HL segment)


XX12:4010:

Patient Event Tracking Number (Loop 2000C, TRN segment)

X12-5010:

Not used

X12-4010:

Subscriber Name (Loop 2010CA, NM1 segment)

X12-5010:



X12-4010:

Patient Event Tracking Number (Loop 2000D, TRN segment)

X12-5010:

Not used

X12-4010:

Dependent Name (Loop 2010DA, NM1 segment)

X12-5010:


X12-4010:

Not used

X12-5010:

Patient Event Level (Loop 2000E, HL segment)

X12-4010:

Not used

X12-5010:

Patient Event Tracking Number (Loop 2000E, TRN segment)

X12-5010:

Event Date (Loop 2000E, DTP segment)




88

278 Health Care Services Review Information Request (PDA278RQ and PDSA5010-

278X217Q)

ID


PEProvName X12-4010:

Not used

X12-5010:

Patient Event Provider Name (Loop 2010EA, NM1 segment)

HLSP

SPNM

HLSS

Service Provider Level (Loop 2000E, HL segment)

Service Provider Name (Loop 2010E, NM1 segment)

Service Level (Loop 2000F, HL segment)

ServProvName X12-4010:

Not used

X12-5010:

Service Provider Name (Loop 2010F, NM1 segment)

SSTN Service Trace Number (Loop 2000F, TRN segment)




89

HLRQ

RQNM

RQAA

HLSB

SBTN

SBA1

SBNM

278 Health Care Services Review Information Response (PDA278RP and PDSA5010-

278X217R)

ID


0021

HLUM

UMA1

UMNM

UMA2

SBA2

HLDP

DPTN

DPA1

DPNM

DPA2

HLSP

Beginning of Hierarchical Transaction (BHT segment)

Utilization Management Organization (UMO) Level (Loop 2000A, HL segment)

Request Validation (Loop 2000A, AAA segment)

Utilization Management Organization (UMO) Name (Loop 2010A, NM1 segment)

Utilization Management Organization (UMO) Request Validation (Loop 2010A,

AAA segment)

Requester Level (Loop 2000B, HL segment)

Requester Name (Loop 2010B, NM1)

Requester Request Validation (Loop 2010B, AAA segment)


Patient Event Tracking Number (Loop 2000C, TRN segment)

Subscriber Request Validation (Loop 2000C, AAA segment)

X12-4010:

Subscriber Name (Loop 2010CA, NM1 segment)

X12-5010:


X12-4010:

Subscriber Request Validation (Loop 2010CA, AAA segment)

X12-5010:

Subscriber Request Validation (Loop 2010C, AAA segment)


Patient Event Tracking Number (Loop 2000D, TRN segment)

Dependent Request Validation (Loop 2000D, AAA segment)

X12-4010:

Dependent Name (Loop 2010DA, NM1 segment)

X12-5010:


X12-4010:

Dependent Request Validation (Loop 2010DA, AAA segment)

X12-5010:

Dependent Request Validation (Loop 2010D, AAA segment)

X12-4010:

Service Provider Level (Loop 2000E, HL segment)

X12-5010:

See HLPELevel




90

278 Health Care Services Review Information Response (PDA278RP and PDSA5010-

278X217R)

ID


HLPELevel

PEAAA1

X12-4010:

Not used

X12-5010:

Patient Event Request Validation (Loop 2000E, AAA segment)

SPNM Service Provider Name (Loop 2010E, NM1 segment)

PEProvName X12-4010:

Not used

X12-5010:

Patient Event Provider Name (Loop 2010EA, NM1 segment)

(See ProvAAA1 also)

ProvAAA1

SPAA

HLSS

SSTN

SSAA

SPNM

SPAA

X12-4010:

Not used; see HLSP

X12-5010:

Patient Event Level (Loop 2000E, HL segment)

X12-4010:

Not used

X12-5010:

Patient Event Provider Request Validation (Loop 2010EA, AAA segment)

Service Provider Request Validation (Loop 2010E, AAA segment)

Service Level (Loop 2000F, HL segment)

Service Trace Number (Loop 2000F, TRN segment)

Service Request Validation (Loop 2000F, AAA segment)

X12-4010:

Not used

X12-5010:

Service Provider Name (Loop 2010FA, NM1 segment)

X12-4010:

Not used

X12-5010:

Service Provider Request Validation (Loop 2010FA, AAA segment)




91

820 Premium Payments (PDSA820)

ID


0010 Financial Information (BPR segment)

TRNTRACE

0002

0004

0007

0006

0011

0013

0008

0014

0016

Trace (Header Table 1, TRN segment)

Premium Receiver (Loop 1000A, N1 segment)

Premium Payer (Loop 1000B, N1 segment)

Individual Remittance Starts (Loop 2000, ENT segment)

Organizational Summary Remittance Starts (Loop 2000A, ENT segment)

Organization Summary Remittance Detail (Loop 2300A, RMR segment)

Organization Summary Remittance Level Adjustment (Loop 2320A, ADX01 segment)

Individual Remittance (Loop 2000B), ENT segment)

Individual Premium Remittance Detail (Loop 2300B, RMR segment)

Individual Premium Adjustment (Loop 2320B, ADX01 segment)




92

834 Benefit Enrollment (PDSA834 and PDSA5010-834)

ID


ZMLD

0010

ZPER

ZN3

N4

ZDMG

ZIMN

ZIDG

ZDSB

BGNS

ZTPN

ZFED

0002

0004

0006

0007

0008

ZDDT

PTHD

HDDT

HCPN

0013

0014

ZCOB

ZCN1

ZCDT

ZPMN

Beginning segment (BGN segment)

Transaction Set Policy Number (REF segment)

File Effective Date (DTP segment)

Sponsor Name (Loop 1000A, N1 segment)

Payer Name (Loop 1000B, N1 segment)

TPA/Broker Name Starts (Loop 1000C, N1 segment)

Member Level Detail Starts (Loop 2000, INS segment)

Subscriber Number (Loop 2000, REF segment)

Member Level Dates (Loop 2000, DTP segment)

Member Name (Loop 2100A, NM1 segment)

Member Communications Numbers (Loop 2100A, PER segment)

Member Residence Street Address (Loop 2100A, N3 segment)

Member Residence City, State, ZIP Code (Loop 2100A, N4 segment)

Member Demographics (Loop 2100A, DMG segment)

Incorrect Member Name (Loop 2100B, NM1 segment)

Incorrect Member Demographic (Loop 2100B, DMG segment)

Disability Information (Loop 2200, DSB segment)

Disability Date (Loop 2200, DTP segment)

Health Coverage Starts (Loop 2300, HD segment)

Health Coverage Dates (Loop 2300, DTP segment)

Health Coverage Policy Number (Loop 2300, REF segment)

Provider Information (Loop 2310, LX segment)

Provider Name (Loop 2310, NM1segment)

Coordination of Benefits (Loop 2320, COB segment)

X12-4010:

Other Insurance Company Name (Loop 2320, N1 segment)

X12-5010:

Coordination of Benefits Related Entity (Loop 2330, NM1 segment)

Coordination of Benefits Eligibility Dates (Loop 2320, DTP segment)

Member Policy Number (Loop 2000, REF segment where REF01='1L')




93

835 Health Care Claim Payment/Advice (PDSA835, PDSX835, PDSA5010835,

PDSX5010835)

ID


0002 Financial Information (BPR segment)

STRN

SREF

0004

0006

0020

0007

TS3

TS2

0009

0011

Patient

Insured

2100DTM

REND

2110DTM

MIA

0017

0014

0018

Re-association Trace Number (Header TRN segment)

Receiver Identification (Header REF segment)

Payer Name and ID (Loop 1000A, N1 segment)

Payee Name and ID (Loop 1000B, N1 segment)

Payee Additional Identification (Loop 1000B, REF segment)

LX (Loop 2000, LX segment)

Provider Summary Information (Loop 2000, TS3 segment)

Provider Supplemental Summary Information (Loop 2000, CLP segment)

Claim Payment Information (Loop 2100, CLP segment)

Claim Adjustment (Loop 2100, CAS segment)

Patient Name (Loop 2100, NM1 Patient Name segment)

Insured Name (Loop 2100, NM1 Insured Name segment)

Claim Date (Loop 2100, DTM segment)

Rendering Provider (Loop 2100, NM1 Service Provider name)

Service Date (Loop 2100, DTM segment)

Inpatient Adjudication Information (Loop 2100 Inpatient Adjudication Information)

Service Payment Information (Loop 2110, SVC segment)

Service Adjustment (Loop 2110, CAS segment)

Provider Adjustment Starts (Table 3, PLB segment)




94

837 – All 837s (PDSA837D and PDSA5010837D, PDSA837I and PDSA5010837I,

PDSA837P and PDSA5010837P)

These records are used by Docsplitter, by Transaction Insight, and by Response Generator, which uses them to create 277s from data in 837s.

In the chart below, “Subscriber loop” means 2000B and “Dependent loop” means 2000C.

ID


0021

ZRTR

Transaction Type Code (BHT segment)

Transmission Type Identifier (Header REF segment)

ZRT

ZRP

PRST

2000APRV

Trading Partner Information (Loop 1000A, NM1 segment)

Payer information (Loop 1000B, NM1 segment)

Billing/Pay-to Provider HL (Loop 2000A, HL segment)

Billing Provider Specialty Information (Loop 2000A, PRV segment)

0001

2010AAN3

Billing Provider information (Loop 2010AA, NM1 segment)

Billing Provider Address (Loop 2010AA, N3 segment)

2010AAN4

Billing Provider City, State, Zip Code (Loop 2010AA, N4 segment)

2010BBREFBILL

ING

Proprietary Provider ID (Loop 2010BB, REF segment for Billing Provider

Secondary Identification) 5010 only.

ZREF Billing Provider Secondary Identification (Loop 2010AA, REF segment)

ZRFB

0002

X12-4010:

Pay-to-Provider Secondary Identification (Loop 2010AB, REF segment)

Pay-To provider information (Loop 2010AB, NM1 segment)

Pay-To Address

– ADDRESS (Loop 2010AB, N3 segment)

2010ABN3

2010ABN4

SBST

Pay-To Address City, State, ZIP Code (Loop 2010AB, N4 segment)

Subscriber HL (Loop 2000B, HL segment)

SBRInfo

0003

ZRSG

ZSRF

SPWK

S020

RFPV

RNPV

Subscriber Information (Loop 2000B, SBR segment)

Subscriber Name (Subscriber loop 2010BA, NM1 segment)

Subscriber DMG information (Subscriber loop 2010BA, DMG segment)

Subscriber Secondary Identification (Subscriber loop 2010BA, REF segment)

Subscriber Claim Supplemental Information (Subscriber loop 2300, PWK segment)

Subscriber Clearinghouse Claim Number (Subscriber loop 2300, Subscriber

Claim Identification Number for Clearinghouses REF)

Attending/Referring Physician Name (Subscriber loop 2310A, NM1 segment)

Operating/Rendering Provider Name (Subscriber loop 2310B, NM1 segment)




95

837 – All 837s (PDSA837D and PDSA5010837D, PDSA837I and PDSA5010837I,

PDSA837P and PDSA5010837P)

PSPV Service Facility Location (Dependent loop 2310C, NM1 segment)

S2330ANM1 Other Subscriber Name (Loop 2330A, NM1 segment)

S2330BNM1

S2330BREF

ZRSM

ZRSS

ZRSV

PATInfo

ZRSI

DPST

ZRDI

0006

ZRDG

ZPRF

P009

PPWK

P020

ZRDM

RFPC

RNPC

PSPC

P2330ANM1

P2330BNM1

P2330BREF

0005

ZRDV

Other Payer Name (Loop 2330B, NM1 segment)

Other Payer Contact Information (Loop 2330B, REF segment)

Subscriber Claim Medical Rec # (Subscriber loop 2300, Medical Record

Number REF)

Service information (Subscriber loop 2400; SV1, SV2, or SV3 segment)

Service Date information (Subscriber loop 2400, Service Date DTP)

Patient Information (Dependent loop 2000C, PAT segment)

Original Reference Number ICN/DCN (Subscriber loop 2300, REF segment)

Dependent HL loop (Dependent loop 2000C, HL segment)

Original Reference Number ICN/DCN (Dependent loop 2300, REF segment)

Dependent Patient Name (Dependent loop 2010CA, NM1 segment)

Dependent DMG information (Dependent loop 2010CA, DMG segment)

X12-4010:

Subscriber Secondary Identification (Dependent loop 2010CA, REF segment)

Dependent Claim (Dependent loop 2300, CLM segment)

Dependent Claim Supplemental Information (Dependent loop 2300, PWK segment)

Dependent Clearinghouse Claim Number (Dependent loop 2300, Dependent

Claim Identification Number for Clearinghouses REF)

Dependent Claim Medical Rec # (Dependent loop 2300, Medical Record

Number REF)

Attending/Referring Provider Name (Dependent loop 2310A, NM1 segment)

Operating/Rendering Provider Name (Dependent loop 2310B, NM1 segment)

Purchased Service Provider Name (Dependent loop 2310C, NM1 segment)

Other Subscriber Name (Dependent loop 2330B, NM1 segment)

Other Payer Name (Dependent loop 2330B, NM1 segment)

Other Payer Secondary Identifier (Dependent loop 2330B, REF segment)

Dependent Service Line (Dependent loop 2400, LX segment)

Service Date information (Dependent loop 2400, Service Date DTP)




96

837 Dental (PDSA837D and PDSA5010837D)

The “All 837s” information above is the same for the 837 Dental except for the following.

ID


SubmitterPER Submitter EDI Contact Information (Loop 1000A, PER segment)

0004

SREFREF

S2310BPRV

SREND

PREFREF

Payer Name information ( Subscriber loop 2010BB, NM1 segment)

Referring Provider Secondary Identification (Subscriber loop 2310A, REF segment)

Rendering Provider Specialty Information (Subscriber loop 2310B, PRV segment)

Rendering Physician Secondary Identification (Subscriber loop 2310B, REF segment)

Service Date (Subscriber loop 2300, DTP segment where DTP01=472) S010

S011

S012

Subscriber Service Line information (Subscriber loop 2400, SV3 segment)

Subscriber Claim date information (Subscriber loop 2400, DTP segment)

SREFLINEITEM Line Item Control Number (Subscriber loop 2400, REF segment)

P2310BPRV Rendering Provider Specialty Information (Subscriber loop 2310B, PRV segment)

Referring Provider Secondary Identification (Dependent loop 2310A, REF segment at dependent level)

PREND Rendering Provider Secondary Identification (Dependent loop 2310B, REF segment)

P010

P011

Service Date (Dependent loop 2300, DTP segment where DTP01=472)

Dependent Patient Service Line information (Dependent loop 2400, SV3 segment)

P012 Dependent Patient Claim date information ( (Dependent loop 2400, DTP segment)

PREFLINEITEM Line Item Control Number (Loop 2400 in 2000C, REF segment)




97

837 Institutional (PDSA837I and PDSA5010837I)

The “All 837s” information above is the same for the 837 Institutional except for the following.

ID



2010AAPER

0004

S009

S010

S020

SATTEND

SOPER

S2330BREF9F

Subscriber Claim Date (Subscriber loop 2300, DTP segment)

Subscriber Claim Identification Number For Clearinghouses (Subscriber loop

2300, REF segment)

Attending Physician Secondary Identification (Subscriber loop 2310A REF segment)

Operating Physician Secondary Identification (Subscriber loop 2310B REF segment)

Service Facility Name (Subscriber loop 2310E, NM1 segment) SPPV


SSERVFAC Service Facility Secondary Identification (Subscriber loop 2310E, REF segment )

S2330BREFG1 X12_5010:

Other Payer Prior Authorization Number (Subscriber loop 2330B, REF segment)

X12_5010:

Other Payer Referral Number (Subscriber loop 2330B, REF segment)

S2330BREFT4

Billing Provider Contact Information (Loop 2010AA, PER segment)

Payer Name (Subscriber loop 2010BC, NM1 segment)

Subscriber Claim (Subscriber loop 2300, CLM segment)

S2330BREFF8

0007

S011

P010

P020

PATTEND

POPER

X12_5010:

Other Payer Claim Adjustment Indicator (Subscriber loop 2330B, REF segment)

X12_5010:

Other Payer Claim Control Number (Subscriber loop 2330B, REF segment)

Subscriber Service Line (Subscriber loop 2400, LX segment)

Subscriber Service Line information (Subscriber loop 2400), SV2 segment)

Dependent Claim Date (Dependent loop 2300, DTP segment)

Dependent Claim Identification Number For Clearinghouses (end of

Dependent loop 2300)

Attending Physician Secondary Identification (Dependent loop 2310A REF segment)

Operating Physician Secondary Identification (Dependent loop 2310B REF segment)




98

P2330BREFG1

P2330BREF9F

P2330BREFT4

X12_5010:

Other Payer Prior Authorization Number (Dependent loop 2330B, REF segment)

X12_5010:

Other Payer Referral Number (Dependent loop 2330B, REF segment)

X12_5010:

Other Payer Claim Adjustment Indicator (Dependent loop 2330B, REF segment)

P2330BREFF8 X12_5010:

Other Payer Claim Control Number (Dependent loop 2330B, REF segment)


SPPC

PSERVFAC

P011

Service Facility Name (Dependent loop 2310E, NM1 segment)

Service Facility Secondary Identification (Dependent loop 2310E, REF segment )

Dependent Service Line (Dependent loop 2400, SV2 segment)




99

837 Professional (PDSA837P and PDSA5010837P)

The “All 837s” information above is the same for the 837 Professional except for the following

ID



2010AAPER

0004

SREFREF

S2310BPRV

SREND

Billing Provider Contact Information (Loop 2010AA, PER segment)

Payer Name information (Loop 2010BB, NM1 segment)

Referring Provider Secondary Identification (Subscriber loop 2310A, REF segment)

Rendering Provider Specialty Information (Subscriber loop 2310B, PRV segment)

Rendering Physician Secondary Identification (Subscriber loop 2310B, REF segment)

SPPV

SSUPPRV

S2330BREFG1

S2330BREF9F

S2330BREFT4

S2330BREFF8

X12_5010:

Other Payer Referral Number (Subscriber loop 2330B, REF segment)

X12_5010:

Other Payer Claim Adjustment Indicator (Subscriber loop 2330B, REF segment)

X12_5010:

Other Payer Claim Control Number (Subscriber loop 2330B, REF segment)

Subscriber Service Line (Subscriber loop 2400, SV1 segment) S011

S010 Subscriber Claim Date (Subscriber loop 2400, DTP segment)


PREFREF

Referring Provider Secondary Identification (Dependent loop 2310A, REF segment at dependent level)

SPPC

P2310BPRV

Supervising Provider Name (Dependent loop 2310E, NM1 segment)

Rendering Provider Specialty Information (Dependent loop 2310B, PRV segment)

PREND

PSUPPRV

Supervising Provider Name (Subscriber loop 2310E, NM1 segment)

Supervising Provider Secondary Identification (Subscriber loop 2310E, REF segment)

X12_5010:

Other Payer Prior Authorization Number (Subscriber loop 2330B, REF segment)

Rendering Provider Secondary Identification (Dependent loop 2310B, REF segment)

Supervising Provider Secondary Identification (Dependent loop 2310E, REF segment)




100

P2330BREFG1

P2330BREF9F

P2330BREFT4

P2330BREFF8

P011

X12_5010:

Other Payer Prior Authorization Number (Dependent loop 2330B, REF segment)

X12_5010:

Other Payer Referral Number (Dependent loop 2330B, REF segment)

X12_5010:

Other Payer Claim Adjustment Indicator (Dependent loop 2330B, REF segment)

X12_5010:

Other Payer Claim Control Number (Dependent loop 2330B, REF segment)

Dependent Patient Service Line (Dependent loop 2400, SV1 segment)

P010 Dependent Patient Claim Date (Dependent loop 2400, DTP segment)


AK1

AK2

IK3

IK4

IK5

AK9

997 Functional Acknowledgement (PDSA997 and PDSX5010997X231)

ID


AK1

AK2

AK3

AK4

AK5

Functional Group Response Header (AK1 segment)

Transaction Set Response Header (AK2 segment)

X12-4010:

Data Segment Note (AK3 segment)

X12-4010:

Data Element Note (AK4 segment)

X12-4010:

Transaction Set Response Trailer (AK5 segment)

Functional Group Response Trailer (AK9 segment) AK9

999 Application Acknowledgement PDSA5010997X231 and PDSX5010999X231)

ID


Functional Group Response Header (AK1 segment)

Transaction Set Response Header (AK2 segment)

Error Identification (IK3 segment)

Implementation Data Element Note (IK4 segment)

Implementation Transaction Set Response (IK5 segment)

Functional Group Response Trailer (AK9 segment)




101

Appendix D: Record Definition

Summary

Record Layout Summary, Version 2.0

For details about each record, see page

32 .

CSEG

Field

Record (CSEG)

Line #

Segment Data

Length Start

5

10

n

1

6

16

End

5

15

EOL

DTL

Field

Record (DTL)

Line #

Loop/Group ID

Seg ID

Elem ID

Comp ID

Seg Pos

Elem Pos

SubElem Pos

Loop/Group

Repeat Count

Element Repeat

999 IK3-04

999 IK4-03

Filler

Error #

Severity

Seg Ordinal

WEDI SNIP Type

997 AK304

997 AK403

824 TED01

824 TED02

277 STC code

Filler


EDAT

2

3

3

5

1

5

2

2

5

5

20

10

3

3

4


10

2

2

10

5

10

4

4

6

4

1

6

16

22

26

30

34

44

46

48

43

45

47

57

5

15

21

25

29

33

101

106

111

93

95

98

78

83

85

90

91

58

68

71

74

Notes

67

70 Not in EDIFACT


77

82

84

89







110

130 Right justified

Instream Validation Technical Manual Appendix D: Record Definition Summary



102

Field

Record (EDAT)

Line #

Element Data

ELOC

Field

Record (ELOC)

Line #

Location Text


5

10

n

1

6

5

15

16 EOL

EDTL

Field

EDTL for XML


Record Tag

(EDTL)

Line #

Group Repeat

Count

5

10

1

6

5

15

The remaining fields are variable length and each is preceded with a vertical bar

Path from root 17

“Segment” ID

Position

Not used for XML




Error #

Severity

EDTL for Flat File


Record Tag

(EDTL)

Subelement ID

5 1 5

Line # 10 6 15

The remaining fields are variable length and each is preceded with a vertical bar

Loop ID

Loop Repeat

Count

17

Segment ID

Element ID

Element Position

Subelement

Position

Ordinal Number

Error #

Severity


5

10

n

1

6

5

15

16 EOL




103

EMSG

Field

Record (EMSG)

Line #

Error Message

END

Field

Record (END )

Line #

Error #

Severity

Date/Time

FileName Msg


5

10

n

1

6

5

15

16 EOL


5

10

17

n

5

2

1

6

16

21

23

5

15

20

22

39

40 EOL

ENDS

Field

Record (ENDS)

Line #

Seg Count

ST Control #


5

10

10

9

1

6

16

26

5

15

25

34

ESEG

Field

Record (ESEG)

Line #

Segment Data

ETYPE/ETYPS

Field

Record Tag

(ETYPS )

Line #

Type 0 count

EDI Syntax Count

Syntactical

Balancing Count

Situation Count

Code Set Count

Product Count

Payer Count

Partner Count

Length

5

10

10

10

10

10

10

10

10

10

10

End

5

15

EOL

Start

1

End

5

56

66

76

86

96

6

16

26

36

46

65

75

85

95

105

15

25

35

45

55

EVALU

Field

Record (EVALU)

Line #


5

10

1

6

5

15

The remaining fields are variable length and each is preceded with a vertical bar.

Structure ID

Segment

Position

Element position

Subelement position

Element value

17

EOL




104

GEN

Field

Record (GEN )

Line #

Error #

Severity

Type

Message

Length Start

2

2

n

5

10

5

21

23

25

1

6

16

IDENT

IDENT Record Layout

Field Length

Record Tag

(IDENT)

Line #

5

10

Start

1

6

End

5

15

The remaining fields are separated by vertical bars

RuleID 1 17

FSUID 19

SystemID

Reserved

SBST

Field

Record (SBST )

Starting line #

Delimiter |

Loop/Group ID

Delimiter |

SegId

Delimiter |

ElmPos

Delimiter |

SubElmPos

Delimiter |

ReplaceValue

Delimiter |

MetaData


5 1 5

1

1

1

1

1

10

1

6 15

SBSTA

Field

Record ( SBSTA )

Line # of segment

Delimiter

Loop/Group ID

Delimiter

SegId

Delimiter

ElmPos

Delimiter

SubElmPos

Delimiter

Old value

Delimiter

New value

Delimiter

MetaData

1

1

1

1

1

1

1

Length Start

5 1

10 6 15

End

5

End

22

24

EOL

5

15

20




105

SBSTD

Field

Record (SBSTD)


Delimiter |

MetaData

Delimiter |

Loop/GroupID

Delimiter |

SegmentID

1

1

1

Length Start

5 1

10 6 15

End

5

SBSTF

Field

Record (SBSTF )


Delimiter

Key

Delimiter

Loop/Group ID

Delimiter

SegId

Delimiter

ElmPos

Delimiter

SubElmPos

Delimiter

MetaData

1

1

1

1

1

Length Start

5 1

10 6 15

End

5

SBSTI

Field

Record (SBSTI )


Delimiter

MetaData

Delimiter

Loop/Group ID

Delimiter

SegmentID

Delimiter

Element Data

Delimiter

Element Data

1

1

1

1

1

10

Length

5

6

Start

1

15

End

5

16 16

SBSTR

Field

Record (SBSTR )


Delimiter

Key

Delimiter

ReplaceValue

Delimiter

Length Start

5

10

1

6

1

1

1

End

5

15




106

STRT

Field

Record (STRT)

Line #

Error #

Severity

Date/Time

FileName Msg

Length Start

2

17

n

5

10

5

21

23

40

1

6

16

STRUE


Record (STRUE) 5

Line # 10

1

6

5

15


Structure ID

Document flag

Instance

Ending position

Errors by severity

Errors by type

ID of ending segment

17

EOL

STRUS

Field

Record (STRUS)

Starting line #


5

10

1

6

5

15


Structure ID

Document flag

Instance

Starting position

17

EOL

SVALU


Record (SVALU) 5

Line # 10

1

6

5

15


Structure ID

Structure position

Segment data

17

EOL

End

22

39

EOL

5

15

20




107

SVRTS

Field

Record (SVRTS )

Line #

Ignore Count

Info Count

Warning Count

Error Count

Fatal Count

User1 Count

User2 Count


10

10

10

5

10

10

10

10

10

1

6

16

26

36

46

56

66

76

35

45

55

5

15

25

65

75

85

SVRTY

Field

Record (SVRTY )

Ignore Count

Info Count

Warning Count

Error Count

Fatal Count

User1 Count

User1 Count


10

10

10

10

5

10

10

10

1

6

16

26

36

46

56

66

45

55

65

75

5

15

25

35

VER

Field

Record (VER )

Version


5

n

1

6

5

EOL

Z

Field

Record (Zaaaa)

Line #

Field 1 Data

Fiend n Data

Length Start

5

10

n1

n2

1

6

16

n

End

5

15

n

n

(Note: aaaa represents the Custom Record

Tag assigned to the record when it is defined in EDISIM. Examples: ZCLM, ZPATN, etc.)




108

No results