EDI 999 Implementation Acknowledgment

Functional Group FA

X12C Communications and Controls Subcommittee

This X12 Transaction Set contains the format and establishes the data contents of the Implementation Acknowledgment Transaction Set (999) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical and relational analysis of the electronically encoded documents, based upon a full or implemented subset of X12 transaction sets. The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.

What is an EDI 999?

An EDI 999 Implementation Acknowledgment serves as a response to healthcare-related EDI messages or groups of messages. Like the EDI 997 Functional Acknowledgment, it contains important information about the receipt of the upstream document (AK2 segment), and whether or not the receiver accepts or rejects the document as presented (IK5 and AK9 segments). It must be HIPAA 005010 complaint.

How is an EDI 999 used?

For example, Employer A sends Insurance Provider B an EDI 834 Benefit Enrollment and Maintenance to enroll a new employee into a healthcare benefits plan. Insurance Provider B responds with a 999 to confirm that the EDI 834 Benefit Enrollment and Maintenance was received with no errors.

Heading

1. 0100 · ST · Transaction Set Header · Max 1 · Mandatory

   To indicate the start of a transaction set and to assign a control number

   Neither the 997 nor the 999 Acknowledgment shall be acknowledged, thereby preventing an endless cycle of acknowledgments of acknowledgments. Nor shall a Implementation Acknowledgment be sent to report errors in a previous Implementation Acknowledgment.
   There is only one Implementation Acknowledgment Transaction Set per acknowledged functional group.
   Only one acknowledgement, either a single Transaction Set 997 or a single Transaction Set 999, should be generated for a functional group unless mutually agreed upon.

2. 0200 · AK1 · Functional Group Response Header · Max 1 · Mandatory

   To start acknowledgment of a functional group

   AK1 is used to respond to the functional group header and to start the acknowledgment for a functional group. There shall be one AK1 segment for the functional group that is being acknowledged.
   The Implementation Acknowledgement is generated at the point of translation, intended for the originator (not any intermediate parties).
   The Functional Group Header Segment (GS) is used to start the envelope for the Implementation Acknowledgment Transaction Sets. In preparing the functional group of acknowledgments, the application sender's code and the application receiver's code, taken from the functional group being acknowledged, are exchanged; therefore, one acknowledgment functional group responds to only those functional groups from one application receiver's code to one application sender's code.

3. AK2 Loop Optional Repeat >1

   1. 0300 · AK2 · Transaction Set Response Header · Max 1 · Mandatory

      To start acknowledgment of a single transaction set

      AK2 is used to start the acknowledgment of a transaction set within the received functional group. The AK2 segments shall appear in the same order as the transaction sets in the functional group that has been received and is being acknowledged.

   2. IK3 Loop Optional Repeat >1

      1. 0400 · IK3 · Implementation Data Segment Note · Max 1 · Mandatory

         To report implementation errors in a data segment and identify the location of the data segment

         The data segments of this standard are used to report the results of the syntactical analysis of the functional groups of transaction sets; they report the extent to which the syntax complies with the standards or proper subsets of transaction sets and functional groups as expressed in compliant implementation guides. They do not report on the semantic meaning of the transaction sets (for example, on the ability of the receiver to comply with the request of the sender).

      2. 0500 · CTX · Context · Max 10 · Optional

         Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated

      3. IK4 Loop Optional Repeat >1

         1. 0600 · IK4 · Implementation Data Element Note · Max 1 · Mandatory

            To report implementation errors in a data element or composite data structure and identify the location of the data element

         2. 0700 · CTX · Context · Max 10 · Optional

            Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated

            The CTX Segment shall be used to disambiguate a reported error that is dependent on context.

   3. 0800 · IK5 · Implementation Transaction Set Response Trailer · Max 1 · Mandatory

      To acknowledge acceptance or rejection and report implementation errors in a transaction set

      If any implementation guide errors have been reported in IK3 or IK4, then code I5 shall be reported in the IK5 Segment.

4. 0900 · AK9 · Functional Group Response Trailer · Max 1 · Mandatory

   To acknowledge acceptance or rejection of a functional group and report the number of included transaction sets from the original trailer, the accepted sets, and the received sets in this functional group

5. 1000 · SE · Transaction Set Trailer · Max 1 · Mandatory

   To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)