Back to Pilotfish Home

EDI 999 Format Example

EDI 999 Implementation Acknowledgment for Healthcare Insurance

What is EDI 999 Implementation Acknowledgment?

The 999 Implementation Acknowledgment has been specified by HIPAA 5010 as the standard acknowledgment document for healthcare. It confirms a file was received and is used to provide additional validation reporting. The EDI 999 is used to report both syntactical errors and implementation guide conformance. The 999 Acknowledgement reports three results:

1) A – Accepted
2) R – Rejected
3) E – Accepted with Errors

The EDI 999 provides specifics on any syntax-related issues that caused errors and on whether the transaction is in compliance with HIPAA requirements. EDI 999 allows a trading partner to report implementation guide edits and edits against the base X12 standard, allowing the submitter to correct and resubmit problematic transactions.

Note: Version 5010 of the HIPAA EDI standards established EDI 999 as the standard acknowledgment document for healthcare, designed to replace the 997 Functional Acknowledgement. However, you may encounter both the 997 and 999 in use. HIPAA 5010 also established 277 Healthcare Status Notification Transaction that explicitly confirms the receipt of a 276 Health Claim Status Request Transaction.

EDI 999 Transaction Format in PilotFish Data Mapper

EDI 999 Implementation Ack in Data Mapper
(Click to enlarge)

 

EDI 999 Workflow Example

EDI Healthcare Transaction Workflow Diagram with PilotFish Integration Engine

(Click to enlarge)

 

The HIPPA 5010 X12 EDI 999 Implementation Acknowledgment is the standard EDI acknowledgment document for healthcare.

Providers or third-party services send the EDI 837 Healthcare Claim to payers. The optional EDI 275 Additional Patient Information (Unsolicited) may also be sent with attachments. The payer or clearinghouse system returns an EDI 999 Implementation Acknowledgment to confirm receipt of the incoming EDI 837 Healthcare Claim. The payer may send an EDI 277 Claim Acknowledgement of all claims received in the payer’s pre-processing system.

An EDI 276 Claim Status Request is sent to verify the status of the claim. The EDI 277 Claim Status Response is sent by the payer. The payer may also send an EDI 277 Request for Additional Information.  The EDI 275 Additional Information (Solicited) is sent in response and may include patient record attachments.

With aspects of the claim verified, the payer sends the EDI 277 Claim Pending Status Information. The EDI 835 Claim Payment/Advice is used to make payments to healthcare providers and/or provide Explanations of Benefits (EOBs). The EDI 835 is used to detail and track the payment to the claim.

 

EDI 999 Format Example

The following example describes a 999 transaction set that is responding to a functional group that was received containing three 837 transaction sets. The first transaction set conformed fully to the X12 standard, while the second and third contained errors.

Transmission Explanation

ISA*00*          *00*          *ZZ*123456789012345
*ZZ*123456789012346*080503*1705*>*00501*000010216*0*T*:~
GS*FA*1234567890*2345678901*20080503*1705*20213*X*005010X231A1~
The Interchange Control and Functional Group segments (ISA, GS, GE, and IEA) are required in the ASC X12 message.
ST*999*2870001*005010X231A1~The ST segment indicates the beginning of the 999 transaction set, control number 2870001.
AK1*HC*17456*005010X222A2~The AK1 segment describes the functional group to which this 999 is responding.
AK2*837*0001~
IK5*A~
The first Transaction Response Loop indicates that the received transaction set, control number 0001, was accepted with no errors.
AK2*837*0002~
IK3*CLM*22**8~
CTX*CLM01:123456789~
IK4*2*782*1~
IK5*R*5~
The second Transaction Response Loop indicates that the received transaction set, control number 0002, was rejected due to a missing CLM02 data element. The CTX segment identifies the Business Unit (i.e. the claim) that was in error.
AK2*837*0003~
IK3*REF*57**3~
CTX*SITUATIONAL TRIGGER*CLM*43**5:3~
CTX*CLM01:987654321~
IK5*R*5~
The third Transaction Response Loop indicates that the received transaction set, control number 003, was rejected due to a missing REF (Original Reference Number ICN/DCN) segment. This segment is required by the implementation guide when CLM05-3 = 6, 7, or 8. The IK3 segment indicates the missing REF segment and the first CTX segment indicates the CLM05-3 as the reason for the missing REF segment. The second CTX identifies the Business Unit (i.e. the claim) that was in error.
AK9*P*3*3*1~
SE*16*2870001~
GE*1*20213~
IEA*1*000010216~
The Trailer section provides a summary of the disposition of the received functional group and ends the transaction set.

Source
Accredited Standards Committee X12. ASC X12 Standard [Table Data]. Data Interchange Standards Association, Inc., McLean, VA. ASC X12 Examples

X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.

This is a unique website which will require a more modern browser to work! Please upgrade today!