ASC X12 Version: 005010 | Transaction Set: 824 | TR3 ID: 005010X186
Example 3: Partial Transaction Set Reject Reporting
Standard X12 envelope. Note that it is Version 5010, so the ISA11 instead of being the typical U you find under HIPAA, now contains the “repeat” delimiter, with a default of “^”. The X12 envelope is created by the creator of the 824 transaction.
ISA*00* *00* *ZZ*RECEIVERS ID*ZZ*123456789012345
The X12 Transaction Set starts with the ST. Again, since this is version 5010, there is an ST03.
The submitter of the 824 is “Consolidated Insurance” and the original 837 was received from Dr. Phil Good by Consolidated Insurance.
N1*41*CONSOLIDATED INSURANCE CO*46*00000~
N1*40*PHIL GOOD, M.D.*46*TXX23~
We start by reporting at the Transaction Set level that the entire Transaction Set has been accepted by Consolidated Insurance into their “production” system. The REF02 comes from the BHT03 of the 837, which typically is the “Tape/Reel Serial Number”. For additional validation and reconciliation, the total dollar amount of all the claims in the 837 Transaction set is given in AMT02 and the count of all claims in the 837 is given in QTY02. The 837 Transaction Set submitter is identified as Phil Good. In addition, there is a Warning message attached to this Transaction Set that reports that the segment terminators were followed by new-lines. Since this is only a warning, it did not cause rejection of the 837 Transaction Set. This Transaction Set summary is important in reconciling the 824 with the 837 that it is responding to.
NM1*41*2*PHIL GOOD, M.D.*****46*TXX23~
Next comes a “Batch” level summary. Since the 837 only had one billing provider, there is only one batch reported, but if the 837 had contained several Billing Providers there would have been one batch reported for each Billing Provider loop in the 837. This batch allows the quick identification of acceptance or rejection for all the claims for that billing provider, and gives a claim count for this Billing Provider and the total dollar amount for those.
NM1*85*2*GOOD AND ASSOCIATES*****24*555667777~
Here comes the first claim. This claim was accepted and contained no errors. The information given here helps identify the claim for reconciliation purposes. The Patient Account Number of the claim is given in both OTI03 and in the REF*EJ segment. If this claim had been an institutional claim perhaps it could have had additional reconciliation elements in the REF segment such as the Medical Record Number and the Bill Type. In addition, if the payer can assign an Internal Claim Control Number during the application that validates the claims, the ICN would be reported in another REF segment.
The second claim is “Accepted with Error” and the error is noted as an invalid ZIP code. The invalid ZIP code is 10407 as reported in TED07.
The third claim is rejected. This one, in addition to an invalid ZIP code error, also reports a missing UPIN for the referring provider. The missing UPIN would have been in a REF segment. The REF segment is not required by the implementation guide, but is required by the transaction receiver’s business application to adjudicate the claim. Since the REF segment is missing, we report (in the TED) the position where it was expected. Since the need for the UPIN (in the REF segment) is due to the specific payer requirement for this type of claim and the presence of the 2310A Referring Provider loop, we indicate these “contexts” in several CTX segments to show that this triggered the need for the missing REF segment.
CTX*2310A REFERRING PROVIDER*NM1*65*2310~
CTX*2010BB PAYER NAME*NM1*18*2010~
CTX*CLAIM FILING INDICATOR CODE - MB*SBR*13*2000*9~
Another perfectly clean claim reported as accepted.
The last claim was also “Accepted with errors” and the two error messages for the two invalid ZIP codes are reported.
Standard end of transaction envelope.