Claim edit: Adjudication date at both the claim and service line level
Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report a previous payer's adjudication date at both the claim level and the service line level.
Adjudication dates
When a patient has more than one insurance plan, claims go to the primary payer first, then the secondary, and so on. The process is called coordination of benefits (COB).
Claims sent to non-primary payers must report the date on which each previous payer adjudicated – or determined how to pay – the claim. This date is called the adjudication date.
Claim-level adjudication date
| Claim type | JSON API field | X12 element |
|---|---|---|
| 837P professional | claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerAdjudicationOrPaymentDate | DTP*573 (Claim Check or Remittance Date) of Loop 2330B (Other Payer Name) |
| 837D dental | claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerAdjudicationOrPaymentDate | DTP*573 (Claim Check or Remittance Date) of Loop 2330B (Other Payer Name) |
| 837I institutional | claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerAdjudicationOrPaymentDate | DTP*573 (Claim Check or Remittance Date) of Loop 2330B (Other Payer Name) |
Service line adjudication date
| Claim type | JSON API field | X12 element |
|---|---|---|
| 837P professional | claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate | DTP*573 (Line Check or Remittance Date) of Loop 2430 (Line Adjudication Information) |
| 837D dental | claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate | DTP*573 (Line Check or Remittance Date) of Loop 2430 (Line Adjudication Information) |
| 837I institutional | claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate | DTP*573 (Line Check or Remittance Date) of Loop 2430 (Line Adjudication Information) |
How the edit works
Per X12 standards, a claim can report a previous payer's adjudication date at the claim level or on each service line, but not both. When both are present, the payer receiving the claim can't tell which date to use and may reject the claim.
This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.
The edit evaluates each previous payer separately, so a claim-level date for one payer and a service line date for a different payer is valid.
Rejection errors
If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:
{
"errors": [
{
"code": "33",
"description": "Invalid Coordination of Benefits (COB) Structure. The claim-level Check or Remittance Date (20240115) should not be submitted when at least one service line contains COB adjudication information for the same payer. Correct and resubmit.",
"followupAction": "Please Correct and Resubmit"
}
]
}If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:
STC*A8>516>SEP*[DATE]*U*[AMOUNT]********Invalid Coordination of Benefits (COB) Structure. The claim-level Check or Remittance Date ([CLAIM-LEVEL DATE]) should not be submitted when at least one service line contains COB adjudication information for the same payer. Correct and resubmit.~The entity identifier code reflects the previous payer's position in the COB sequence: PRP for primary, SEP for secondary, TTP for tertiary, and PR otherwise.
Related claim edits
Stedi has another edit for COB claims that omit a previous payer's adjudication date entirely. See Missing other payer adjudication date in COB claims.