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

Position
Segment
Name
Max use
  1. 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 can be sent for each functional group. The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners. Different Functional Groups may have different acknowledgements, e.g. some Functional Groups, within the same interchange, may be acknowledged with the 997 and others with the 999.
  2. 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. 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. 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. 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. To report implementation errors in a data element or composite data structure and identify the location of the data element

        2. 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. 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. 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. To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)

Stedi is a registered trademark of Stedi, Inc. Stedi's EDI Reference is provided for marketing purposes and is free of charge. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.