EDI X12 - UnWrapped --> The ISA/IEA

 There has always been a curiosity as to what is NEEDED as opposed to what is incorporated into the enveloping structure of an X12 document.  As you saw in my previous essay, the envelope contains the ISA-GS-ST and ends with the SE-GE-IEA. 

Consider the ST to SE as the actual documents.  The GS to GE like a big manila envelope addressed to a specific department.  And the ISA to IEA like the FexEd Mailer box with the corporate address.  If you think of it in this manner, it makes a lot more sense than to just think of it all as individual segments.

OK, now, let’s discuss JUST the ISA in depth.  What is in it, what is optional, what is mandatory.

ISA*00*          *00*          *12*SENDERID       *ZZ*RECEIVERID     *100325*1113*U*00403*000011436*0*T*>~

 ISA01 through ISA04

The segment ID (ISA) is always first, of course.  The ISA01, in this case the data is 00, which means there is No Authorization Information Present.  I personally have never had an instance where this is use in the transportation or retail industry, as this is seldom used in the healthcare (HIPPA) documents.  This can be used as an alternative to “logging in” to a system or “authorizing” a document into a system.  The ‘00’ signifies there is no useful information in ISA02 so the translator will ignore that element.

This is the same for the ISA03 and ISA04 only the ‘00’ signifies there is No Security Information Present.  The ‘00’ in both instances are mandatory but the ISA02 and ISA04 are blank, however, because the ISA segment is character specific, there needs to be spaces to fill in the ISA02 and ISA04.  Ten spaces in each to be exact.

ISA05 through ISA08

This is the SENDER and RECEIVER information.  The ISA05 and ISA07 are identifiers (qualifiers) for the ISA06 and ISA08.  Common qualifiers ‘01’, ‘ZZ’, ‘12’; 01 = Dun and Bradstreet Company ID, 12 = Telephone Number, and ZZ = Mutually Defined.  These can be whatever you want them to be, but be consistent.  Changing a lot can lead to confusion, not by your trading partner, but by you.  As I mentioned, this is the COMPANY ID.  So have one ISA ID for your COMPANY.  If you need to designate additional department, or entities, use the GS segment.  We will discuss that in a bit.

It was brought to my attention it cannot be whatever you want and after working with certain big-box companies I know this is not true, since they frequently create their own qualifiers as a whim.  I know, I have had to fabricate their “standard” qualifier in order to do business with them.  Not difficult, but unique, a one-off.  To define what I meant, there are qualifiers listed in the standard, a LOT of them, try to use one of them.  Pick the one you want and/or better yet first look at the data it will identifies then find a qualifier that best describes the data.  The 05 and 06 and the 07 and 08 relationship should...you know, relate.

ISA09 through ISA10

ISA09 and ISA10 are the document creation date and time.  As you can see, the date is 6-byte.  So the century is not use.  The date November 21, 2016 would be depicted as 20161121 for anywhere in the document EXCEPT in the ISA.  Here is you be 161121.  The date in ISA has not been changed to be Y2K compliant by DISA for some reason.  I personally feel it is because of the 106-character mandatory segment length, can you imagine how much work it would be to change all translators to use 2 additional characters?  So, suffice it to say, 6-byte date in the ISA will be there for a LONG time.  As long as you are aware of it, it’s normal….right? 

As for the TIME, well that is military time in HHMM; so 4:15pm would be depicted as 1615.  Simple enough.

ISA11

This is a ’U’, which means the U.S. EDI Community of ANSI X12, TDCC and UCS standards.  Just knowing it is a ‘U’ is enough.

It was brought to my attention it cannot be whatever you want and after working with certain big-box companies I know this is not true, since they frequently create their own qualifiers as a whim.  I know, I have had to fabricate their “standard” qualifier in order to do business with them.  Not difficult, but unique, a one-off.  To define what I meant, there are qualifiers listed in the standard, a LOT of them, try to use one of them.  Pick the one you want and/or better yet first look at the data it will identifies then find a qualifier that best describes the data.  The 05 and 06 and the 07 and 08 should relate.

ISA12

This is the Interchange Control Version, as in version 4010, or version 4030, or even version 5010.  The translator uses this as a reference to validate the data it is receiving.  In the ISA12, this version is a 5-character field, so the above versions in the previous sentence would be written as 00401, 00403, and 00501.

ISA13

This is the Interchange Control Number, a 9-character field. This is zero-filled before the number so the ID of 2468 would be written as 000002468.  In the IEA, at the VERY bottom of the document, this number is in the IEA02.  The translator uses this to verify it has the end of the correct document.  If they do not match, the translation fails.

ISA14

This is a fun code for new people.  It generates a TA1 acknowledgement in the receiving system.  What is a TA1 acknowledgement you ask?  Well, unless you are using X12 for Healthcare documents, there is no reason to put anything other than a zero in this spot.

So, The TA1 interchange will indicate that the file was successfully received; as well as indicate what errors existed within the envelope segments of the received X12 file.  If you and your trading partner require a 997, there is no need for this.  It verifies the envelope structure only, not the document.  If you are transferring documents successfully, why would you need to know that THIS document arrived and the envelope processed ok.  

My recommendation, leave it a ‘0’.

ISA15

Called the Usage Indicator.  Can be either a ‘T’ or a ‘P’ and yes, you guessed correctly.  It stands for TEST and PRODUCTION.

Some translators look at this and if it is a production system and it receives a ‘T’ the document is ignored as if the sender sent it to the wrong system.  Essentially, in this instance, the document can get lost.  To locate the document will…may…require the use of both time and a forensics EDI person.  Well, not really.  Most systems have a place where bad data in dropped if the translator cannot translate it.  Looking in there will be what the EDI team will do first.

Some companies with a single communications server use this to move the inbound data to either the TEST or PROD server.  I have seen others ignore it completely.  

ISA16

This is the last ELEMENT in the ISA, but the second last piece of data in the ISA.  This is known as the Component Element Separator or the Sub-Element Separator. Most use a ‘>’ character here since in the world of EDI that character is not commonly in the data itself.

SEGMENT TERMINATOR (position 106)

This is the end of the ISA, position 106 to be EXACT. This is where the translator goes to see where to parse the data, the segments.  In this case it will see a tilde (~) and it will know that each time it ‘sees’ a tilde that the very next character begins a new segment. 

Other Important Information Tidbits

The IEA*1*000011436~

• This is the last record in the EDI X12 document and needs to match the ISA (control number.
• The IEA01 (in this case the number 1) signifies there is only one GS to GE combination with in this document.
• The IEA02 must match the ISA13 exactly.

As the translator receives the inbound EDI it looks at position 106, then 105, then 104. 

This is how is knows what and how to parse the data.

• Position 106 tells it what separates the segments.
• Position 105 tells it how to parse out sub-elements (if you even use them that is)
• Position 104 tells it how to parse out the individual data elements with-in the segments.

If you are looking for how many characters are in each ISA elements, here it is:

1. 2
2. 10
3. 2
4. 10
5. 2
6. 15
7. 2
8. 15
9. 6
10. 4
11. 1
12. 5
13. 9
14. 1
15. 1
16. 1

 Looking at the example at the beginning of this essay, you can determine if the data is left justified, right justified, or zero filled.

Since this is a longer document than I anticipated, I am creating a separate essay for the GS and ST.  They are a lot shorter and will be looped in together