RFI Browser

Back  RFI # 45: ISA14 (DE I13) CODES

Formal vs. Informal Help Informal Formal

Submitter

Todd Cochrane

Description

ISA14 is the Acknowledgement Requested data element DE I13. This DE is defined as Code indicating sender's request for an interchange acknowledgement. This DE s code list consists of two codes as follows: 0 No Interchange Acknowledgment Requested, 1 Interchange Acknowledgment Requested (TA1). Since the name of this DE indicates it is a request for a TA1 Interchange Acknowledgement to either be sent or not, does requested as used in these code definitions have the force of must , must not , should , should not , etc. as defined in RFC 2119? Key words for use in RFCs to Indicate Requirement Levels, defined as follows: 1. MUST - This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2.MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In other words, if an industry organization which creates various business/operating/usage rules which are voluntarily adopted by various organizations in that industry establishes a requirement that would have the effect of overriding either code value in ISA14 by requiring that a TA1 be returned ONLY when the receiver of the Interchange rejects the Interchange cause the implementers of this rule to be violating the X12 standard? Ideally, there is a need for a third code value for DE I13, i.e., 2 Interchange Acknowledgement Requested ONLY for Rejections, which doesn t presently exist in v00501 of the Interchange Control segment. In the absence of such a code, would the creation of a voluntarily adopted industry rule addressing this gap be considered a violation of X12 standards?

Response

You ask three separate questions, but there is an implied general question regarding an interchange receiver s actions regarding the TA1. In regard to the defined code values of DE I13: 0 No Interchange Acknowledgment Requested X12.5 in Section 3.2.2 states: If the value in this data element position indicates no acknowledgment, the interchange receiver shall not return that acknowledgment. 1 Interchange Acknowledgment Requested (TA1) The standards are silent on the interchange receiver s actions. X12.5 Section 3.2.2 states only that ISA14 provides a mechanism to request that the receiver transmit an interchange acknowledgement: The preparer of the interchange header and trailer indicates the level of acknowledgment requested in the acknowledgment requested data element. Regarding your specific questions: First, regarding the DE I13 code definitions and the definitions of RFC 2119, X12.3 and X12 5 do not explicitly reference RFC 2119. The only relevant statement in the X12 standards that use this terminology is sentence from X12.5 section 3.2.2 noted above: the interchange receiver shall not return that acknowledgment. Secondly, regarding an industry rule in effect overriding either code value in ISA14, requiring that a TA1 be returned ONLY when the receiver of the Interchange rejects the Interchange, this rule conflicts with section 3.2.2 of X12.5 which states that no TA1 shall be generated if one was not requested. Your final question asked in the context of the need for a third code value for DE I13, i.e., 2 Interchange Acknowledgement Requested ONLY for Rejections, which doesn t presently exist in v00501 of the Interchange Control segment, asks if there can be a voluntary rule in the absence of such a code. Use of a code that is not included in the X12 standard is not permissible. The X12 standards are silent regarding interchange receiver actions when an interchange acknowledgment is requested. An industry rule specifying when an interchange acknowledgement is requested the interchange receiver shall generate a TA1 only for interchange rejections would not violate the X12 standards. (see Health Care Implementations below)

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.

The X12 standards intentionally do not specify how X12 transactions are to be communicated, as such specification would reach beyond the scope of the X12 Committee charter. There is no guarantee that an X12 interchange will reach its intended recipient. Some communication protocols do provide communication protocol level acknowledgments, but they do not generate X12 protocol acknowledgments. Application level software on both the sender and receiver ends of a communication channel lie outside the communication layer, and these may fail to process data that was successfully communicated between communication endpoints. Many EDI communication paths utilize third party EDI service providers, in which case two or more independent communication sessions participate in the routing of interchanges from sender to end recipient. In some circumstances one or more EDI service providers may generate TA1 s for interchanges the service provider for some reason is unable to identify or otherwise deliver or forward the interchange for delivery to the intended recipient. Since the X12 TA1 is intended to be generated by the ISA-addressed recipient, the generation of a TA1 by a service provider is outside the scope of the X12 standard. Note that this does not mean this practice is a violation of the X12 standard, it is simply a value added service provided on behalf of a sender or receiver. Considering these facts, the value of the TA1 may not be obvious. The TA1 provides the following: Prompt receipt of a positive acknowledgment may be used to turn off a non-response alarm requiring exception processing. Prompt receipt of a negative acknowledgment may be used to expedite investigation of the reason for non-delivery. Query/Rapid Response scenarios, which implicitly provide acknowledgment receipt need not be encumbered with the added overhead of TA1 acknowledgments. Whether an X12 Interchange Acknowledgment (TA1) is requested or not, the sending X12 application system should (not must) be prepared to handle any possible outcome of the transmission of the interchange, including the presence or absence of a returned TA1, both when TA1 s are requested or not requested. Health Care Implementations Although the X12 standards do not specify how X12 transactions are to be communicated, a Technical Report Type 3 (TR3) Implementation Acknowledgment for Health Care Insurance (999) 005010X231 does give specific guidance concerning the use of the TA1 within the health care industry. It is recommended that any voluntary rule concerning the TA1 for health care comply with this TR3 and any associated errata.
Submission 1/1/2009
Status Date 1/1/2009
Status F - Final
Primary References
Document 5010