x12 – Eligibility Inquiry (270) & Eligibility Results (2

[Ron Myers]

We are attempting to pass X12 (270s) and X12 (271s) through the engine via Raw (Translation Mode) with a Static Route.  The X12s are Version 4010.

—  When we attempt to use the Testing Tool (X12) – Test Parser, we always get “no IEA segment after ISA”.  Test Numbers works okay.  We’ve tried other X12 (271) files, but they give the same error message.  

—  We checked and re-checked the ISA Interchange Control Header (e.g., length; location; segment delimiter).

—  Is there anything unique about the Testing Tool for X12?

—  Since we’re using Raw/Static, do we need to consider splits/builds when processing these messages through the system.

—  Does anyone have a X12 (271 & 270) test file that has been processed throught the engine.  We’re on Release 5.4.1.

Thanks,

Ron

Topic

[Bob Schmid]

getting same thing……something stupd probably…..what is the reason ?

Bob

[Bob Richardson]

Greetings,

Running CL 5.8.7.0

The X12 testing tool cannot handle the ISA segment as part of the message.   We have tcl procs that use the standard Cloverleaf library of X12 split and build procs that split out each X12 from the message into separate messages (transactions).  We have some eligibiity interfaces and to test xlate changes we do a tps “test” to create the separate X12 messages – use the output (now separate X12s) to run thru the xlate testing tool.

BE SURE TO CHECK “Run at startup” to get the package loaded for your test!!!

The Cloverleaf modules are (we create our own Tcl shell to invoke) – partial code here:

Note: in the Tcl startup do: package require X12lib

(1) foreach STmh [X12lib::splitX12 $mh ST]  <— we do some other stuff in our Tcl proc hence the foreach bit here.

The handle $STmh is your split X12 now – its userdata contains the ISA and IEA segments with other details

(2) Save this output and now run as your messages thru the xlate testing tool.

(3) To rebuild after Xlate time you use another post xlate Tcl proc

that has this module in it: X12lib::joinX12 $mh

Note: uses the USERDATA now to glue back the ISA and IEA segments.

By the way the 5010 standard is required for HIPAA compliant eligibility transactions – 4010 expired about January 2010.

Not developer friendly I admit but then Cloverleaf’s strength is HL7 V2 in our humble opinion.

Good luck!

[Jim Kosloskey]

Bob,

I have found the X12 Tester works fine with properly structured X12 messages – however the Xlate tool may complain about the ISA/IEA set – that I don’t recall.

What I have seen is many of the source systems terminate each X12 segment in a file with a hex 0a or some other terminator. This is not legal in X12 – only a ~ can terminate a segment. That will cause the X12 Tester to complain and perhaps not parse properly.

I do agree that the handling of headers/trailers for both X12 AND HL/7 should be better in Cloverleaf. One should not have to utilize Tcl at all to handle batches.

Moreover with X12 the ISA/IEA set can be used to envelope a single Transaction Set or multiple Transaction Sets so in my opinion the ISA/IEA should be allowed to travel with the message if needed in addition to stored off in the metadata.

As X12 handling for Healthcare becomes more critical I believe Cloverleaf will need to improve in this area.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Bob Richardson]

Jim,

Thanks for adding the detail about the segment terminator.

We do have a “normalize” Tcl proc that converts the newline

or windows terminated X12 data to tilde.

Pretty versus what the engine can swallow.

BobR

[Jim Kosloskey]

One of the ways I handle the X12 envelope issue for the purposes of Xlate Testing if I want to test an entire file is to set up an IB thread with the split proc then Static Raw route to a Fileset Local Outbound thread and don’t apply the proc to replace the Envelope.

The result is a file of messages sans ISA/IEA (and perhaps GS if that is what is specified).

Normally I just want to Xlate test with a few messages many times just one. In that case I use an editor to remove the mesages I want from the source.

I understand we can accomodate the shortomings of source system and many times that is what is necessary.

However, I am pretty sure the source systems are not in compliance with the files they are providing and I seem to recall the ANSI X12 folks don’t have the same relaxed attitude about compliance that the HL/7 folks do. In those cases I try very hard to make the source system comply (in the past I have reported source vendors who do not comply with the X12 standard – and suddenly the messages, etc. were in compliance).

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Peter Heggie]

Lawson is one of those vendors…. S3 HR Benefits component does not create compliant 834 transaction output. We are going down the same path of pre-processing the file.

Peter Heggie
PeterHeggie@crouse.org

[Author]

Replies