TA1, 999, and 824, as described below.
TA1 interchange acknowledgments: This acknowledgment file is intended to communicate the file status of the inbound 837 file. A TA1 file will be made available only when either the inbound 837's ISA14 element is "1" or there is an error at the interchange level, which warrants rejection. Within each TA1, the TA104 element provides the status of the file and the TA105 element notes the reason. If an interchange is rejected, we reject the entire file; neither a 999 Functional acknowledgment nor an 824 acknowledgment will be made for that file.
999 functional acknowledgments: This acknowledgment file communicates how well the 837 file adheres to the IAIABC Implementation Guide. The 999 file is generated by the receiver of the inbound 837 file and made available to the sender of the inbound 837 file. If we reject a transaction set, it is rejecting only that set and the set's bills will not appear in the 824 acknowledgment. Trading partners are responsible for monitoring the status of their files and the errors or status indicators included in the functional acknowledgments. Trading partners must respond to these acknowledgments by correcting the errors and submitting corrections as appropriate. The 999 acknowledgment replaces the 997 acknowledgment (for syntax and Implementation Guide adherence) in Release 2.0.
824 detail acknowledgments: This acknowledgment is sent when we accept at least one transaction set in an EDI ANSI 837 file. That acknowledgment provides results of applying the edits found in Appendices A and B to the data. If any transaction set is rejected, the EDI ANSI 837 application will indicate whether individual items (medical bills) were accepted or rejected. Trading partners are responsible for monitoring the status of their files and the errors or status indicators included in the detail acknowledgments.
Both a 999 (functional acknowledgment) and an 824 (detail acknowledgment) will be available to the trading partner if the file passes structural edits. The acknowledgments will identify any errors that need to be corrected and resubmitted. Files with structural or detail (data) errors must be corrected and resubmitted within 60 days of the date of payment or denial.
An 837 transaction set consists of a Transaction Set Header (ST) segment, one or more medical bills, and a Transaction Set Trailer (SE) segment. If the transaction set does not contain all three components, it is rejected.
The 837 application first checks every inbound file for structural validity. Any error outside of a functional group, or in the GS segment, will cause a rejection and a TA1 will be available to the sender. No further processing of the file will occur.
If invalid syntax is found below the interchange level, the 999 file will indicate a rejection for the transaction set containing the error. The data in those transaction sets will not be edited and those transaction sets will not be acknowledged in the 824 file. At least one transaction set must pass the 999 edits in order for an 824 file to be created. A trading partner must monitor its SFTP directories for acknowledgments and delete processed acknowledgments.
If the 837 application has passed the structural validity of at least one transaction set in an inbound file, the application then checks the transaction sets and individual items (bills) in the accepted transaction sets by validating each field (data element) in each transaction set and transaction using the edit rules.
Each data element must meet the defined edits and validation rules included in the Element Requirements Table.
If a data element fails to pass any edit validation, the appropriate error message will be listed in the 824. All data element errors will be included in the 824. We will return only Item Accepted (IA) or Item Rejected (IR) acknowledgments in the detail acknowledgment file. Item Accepted with Error (IE) is not used in Oregon.