RFI Browser

Back  RFI # 19: ISA02 AND ISA04 CONTENT

Formal vs. Informal Help Informal Formal

Submitter

Todd Cochrane

Description

What follows is a request for an interpretation regarding the authorized content of data elements ISA02 and ISA04. Must ISA02 or ISA04 contain a non-space character when ISA01 and ISA03, respectively, contains code 00? Comment: Although a string is defined as a sequence of any characters from the basic or extended character sets that contains at least one non-space character, this section also speaks to left justification and suppression of non-significant trailing characters, e.g., spaces . If the ISA01 and ISA03 content is code 00, is there truly any significant difference in suppression of the entire field of spaces verses one significant character followed by suppressed spaces ? The definition for string applies to the AN data element type. Does this definition also apply to control structures and control data elements? If this requirement applies equally to all AN data element types, then should X12.6 be changed to permit the content of all spaces in the above situations?

Response

In your letter, you referenced only X12.6 Version 004 Release 010. However, the ISA segment definition is governed primarily by the X12.5 Interchange Control Structures Version 004 Release 010 document and the data elements used to construct the ISA segment are defined in X12.3. X12.5 makes reference to X12.6 for some syntactic constructs, including the string construct referenced in your letter. The X12.6 string construct requires that at least one non-blank character appear in any instance of the construct. The x12.6 document also provides other syntactic construction rules, including rules for suppression of trailing blanks, and rules for presence of mandatory fields in segments. However, these rules are not in scope in the context of X12.5, as the scope of X12.6 ranges only from the GS segment through the GE segment defined in X12.6, including all constructs embedded therein. The ISA segment defined in X12.5 lies outside the scope of X12.6, such as the BNF construct. Prior to approval of X12.5 as an X12 Standard, a fixed length segment ICS was defined to address some interchange routing needs now addressed by X12.5. As x12.5 was being developed, debate ensured as to whether the new ISA segment should be defined as a fixed length segment or as a variable length segment. A compromise was reached that was intended to allow the segment to be parsed either as a fixed length segment or as a delimited segment. When parsed as a delimited segment, the data element delimiter could be found at a fixed place in the segment, and the segment terminator could be found at a fixed place in the segment relative to its preceding data element delimiter. This intention was not explicitly stated in the X12.5 document. Sometime after X12.5 was approved as a Draft Standard for Trial Use, it was noted that the Control Number in the ISA was not restricted to positive numbers and that common usage of certain fields in the ISA segment did not conform to X12.6 rules for construction of segments. In particular, fields ISA02 and ISA04 were often filled with blanks when ISA01 and ISA03 respectively contained the value 00 . Also, fields ISA06 and ISA08 were right filled with blanks to the fixed field length, whereas X12.6 rules would have required left fill. The definition for I01 Authorization Information Qualifier code value 00 is: No Authorization Information Present (No Meaningful Information in I02) The definition for I03 Security Information Qualifier code value 00 is: No Security Information Present (No Meaningful Information in I04) In the ISA segment ISA02 (DE I02) and ISA04 (DE I04) are defined as Mandatory. The code definitions that infer information is not always present. The X12 Committee observes that there are both shortcomings and inconsistencies in the Standards governing the syntax of the ISA segment. The responsible Subcommittee X12C, Communications and Controls, is undertaking corrective actions in future versions of the X12.5 and X12.3 documents. These actions are expected to support common practice, as the current Subcommittee X12C membership feels that such practice was intended by the original authors of the ISA segment to be valid syntactic constructs. The X12 Committee concludes that the shortcomings and inconsistencies in the referenced X12 standards render ambiguous certain syntactic constructs in the ISA segment, among them the ISA 02 and ISA04 fields which form the basis of this request for interpretation. The X12 Committee therefore responds to the specific questions asked in your letter as follows: Must ISA02 or ISA04 contain a non-space character when ISA01 and ISA03, respectively, contains code 00? No. The inconsistency between X12.5 and X12.3, when code value 00 is used in ISA01 and ISA03, respectively, makes it unclear whether the field is Mandatory or Optional and no advice is provided in the relevant standards as to which syntactic rule should govern in this case of conflict. For all other code values, at least one non-blank character must appear, as there is no inconsistency in those cases. However, it is noted that the content of these fields may be right-blank filled, as the X12.6 rule for blank suppression is out of scope, and X12.5 is ambiguous whether such fill is permissible. The Subcommittee X12C Communications and Controls intends to take action to modify X12.5 and X12.3 to resolve existing inconsistencies in the standard. The definition for string applies to the AN data element type. Does this definition also apply to control structures and control data elements? Yes, by specific reference in X12.5 to this construct. If this requirement applies equally to all AN data element types, then should X12.6 be changed to permit the content of all spaces in the above situations? No. The inconsistency relates only to the requirement for field presence.

Recommendation

The official response to a formal RFI is a letter from the current ASC X12 chair. This website often displays a summary of the RFI. Click here to view a PDF of the letter for this RFI.
Submission 1/1/2001
Status Date 1/1/2001
Status F - Final
Primary References
Document 4010