RFI Browser


Formal vs. Informal Help Informal Formal


Todd Cochrane


Issues: Data items which have associated code lists [ID type] and occur in more than one segment must not contain [codes] which could not meaningfully be used in every such segment. At present, where such a [code] is used to qualify a value in another field in the segment, the implication exists that the qualified field can actually contain a value of the kind suggested by the code value. This is not always the case. Data will otherwise be placed in fields, which are not appropriate to contain that data. Degenerating the standard (e.g., in the 810 Invoice, IT106 [DE 235 Product/Service ID Qualifier] can take the value MF [Manufacturer] and this is being interpreted as allowing IT107 [DE 234 Product/service ID] to take the value Motorola (or some code representation) as the maker of the part being specified. Add a syntax note to DE 353 Transaction Set Purpose to indicate which transaction sets are either included or excluded from authorized use. This will keep users from using a generic data element in an inappropriate way. This is a request for an ASC X12 interpretation of the code list for DE 103 Packaging Code. This code list is in two-part form. The element by definition in its description says that it is two data elements. Shouldn t this be two data elements, or a composite data element? This data element also seems to be in conflict with DE 211. ASC X12B Subcommittee voted to remove the code list from the Data Element Dictionary for DE 211 and refer the user to Part Two of the code list for DE 103. Could or should DE 211 reflect the second part of the DE 103 in its code list and DE 103 reflects the first part? This would require segments to be [amended]. If DE 103 became a composite, this might not require segment changes.


The current ASC X12.6 Application Control Structure defines ID data element type: An identifier data element always contains a value from a predefined list of values that is maintained by X12C Subcommittee or some other body recognized by the X12 Committee. This means that the value of the ID data element only has meaning relative to the list from which it can be selected; if the value is not a member of the approved list, the value is not valid. The X12.6 standard prohibits special characters in an ID data element value.

To eliminate any confusion on the acceptable values for the list, that list must be complete and unambiguous; there are no production rules allowed for generating values for the list.

There may be only one Appendix A reference for any ID data element external code list; multiple references allow for the possibility of duplication and confusion on the value. Those data elements with multiple Appendix A references shall be converted to the string (AN) data element type.

There is no method available to subset or divide a code list at the syntax (format) level of the code list. The use of the code list may be divided at the semantic (meaning) level. If the code list is to be divided at the data segment, a semantic note for the data segment may be used to restrict the usage of code values for this data segment. If the code list needs to be subdivided at the transaction set level, the comments column of the segment sequence list in the tables in the transaction set standard may be used to restrict the usage of the code values for this transaction set.


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/1990
Status Date 1/1/1990
Status F - Final
Primary References
Document 2040