How to track payment after an IDR determination

A patient has surgery at an in-network hospital, but the anesthesiologist who provides care is out of network.

The anesthesiologist sends a claim to the payer for the patient's health plan. Because the anesthesiologist is out of network, there isn't a contracted rate that determines how much the payer pays. In these cases, the payer may only pay part of the charge.

If the provider thinks this payment is too low, they can challenge it. If the two sides still can't agree, an arbitrator decides how much the payer should pay. That arbitration process is known as Independent Dispute Resolution (IDR).

If the arbitrator decides that the payer owes more than it originally paid, the payer must reprocess the claim and pay the additional amount. The provider then needs to know: did the payer actually pay it?

If you file and manage disputes on the provider's behalf – the submitter – you often won't see their remittances at all, since paper remits get mailed to the provider and the Electronic Remittance Advice (ERA) goes to whichever clearinghouse the provider is enrolled with.

If you build workflows that file and manage out-of-network disputes for providers, this guide is for you. It explains how IDR works and how to track payment after an arbitrator's decision.

How IDR works

In cases where a patient can't choose their provider, federal law limits what the patient pays. This means that the patient only owes their normal in-network cost share. The provider and payer handle the rest.

The process follows this format:

1. The payer sends a payment that's less than what the provider billed. Both sides enter into a negotiation period.
2. If the provider and payer can't agree, either side can send the case to an arbitrator for IDR.
3. A certified IDR entity – the arbitrator – reviews the case, and each side submits a proposed payment amount.
4. The IDR entity selects one of the proposed amounts. The selection is called a determination, which is binding upon both parties.

Afterward, the payer has 30 calendar days to pay the difference. Payers don't always pay on time. If the money hasn't arrived after 30 days, the recourse is a complaint to CMS – but you can't file one without knowing the payment never came.

What changes on the claim

If a payer issues payment after a determination, the provider doesn't need to submit a new claim. Instead, the payer reopens the original claim and processes it again. If you check the claim's status in the payer portal or using a claim status check, you'll only see the claim's current status, so the status it had before the dispute isn't visible. And since nothing was submitted, there's no new 277CA claim acknowledgment. The existing ERA won't change either.

To determine whether the payer followed the determination, look for new activity on the original claim: a new ERA showing payment after the determination, or a real-time claim status response. Both are keyed to the Patient Control Number (PCN), the identifier assigned on the original claim. The payer's own identifier – the payer claim control number – can change when a claim is reprocessed, but the PCN doesn't, which makes it the reliable way to tie later activity back to the original claim.

Start with the ERA if you have it

Payers don't change ERAs they've already sent. If the payer needs to correct a payment – as it does after a determination – it reports the correction as an adjustment in a new ERA, and it does that one of two ways. Some payers reverse the original payment in full, reporting the amounts as negative with claim status code 22 on the 835, then send a replacement at the new amount. Others skip the reversal and send only the additional amount owed.

Two things to keep in mind when you build this workflow:

• Wait until you have all ERA activity for a claim before making a decision. A reversal and its replacement can show up on separate ERAs, but both use the same PCN. To get the net adjustment, group by PCN and add them together.
• Don't require the reversal. If your workflow waits for one, it will miss the payment from a payer that sends only the additional amount, and it will fail to reconcile. There's no error message to alert you when this happens.

If you don't have the ERA, run a claim status check

If you don't have access to the provider's ERAs, you can check the status of an IDR claim using a real-time claim status check. A real-time claim status check works by sending identifiers from the original claim, and in return, the payer sends back its current status.

Note that a claim status response is different from an ERA. A claim status response tells you what the payer says happened to the claim, and by using this response, you can tell whether a post-IDR claim was revised or marked paid. However, you won't be able to confirm whether the payment was actually sent.

Running the check

Run the check as you would any real-time claim status check, with a few differences.

Time the checks off the determination date rather than the submission date – the claim was processed before the dispute, so its submission date tells you nothing. The determination date isn't part of the request; it just sets your schedule. Check about a week after the determination, again at 21 days, and once more at 30 days.

Payers usually won't return anything for a claim submitted by a different provider organization, even with complete claim details. Make sure the original claim was filed under your own organization.

{
  "tradingPartnerServiceId": "87726", // UnitedHealthcare
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "ACME Health Services",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19850412",
    "gender": "F",
    "memberId": "111222333"
  },
  "encounter": {
    "beginningDateOfService": "20260420",
    "endDateOfService": "20260506"
  }
}

For the dates of service, use the original claim's service dates, and set the range to start at least 7 days before and end at least 7 days after to account for differences in the payer's records. Keep the total span under 30 days, since some payers reject wider ranges.

Otherwise, only include the necessary fields, since extra details can reduce the likelihood of a match.

You can find a match using the PCN from your original claim, which payers return as patientAccountNumber. If you don't see that field in the status check, try the other identifiers you included in your request.

{
  "claims": [
    {
      "claimStatus": {
        "patientAccountNumber": "12345678", // The PCN from the original claim
        "statusCategoryCode": "F1", // Finalized/Payment
        "statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
        "statusCode": "65", // Health Care Claim Status Code
        "statusCodeValue": "Claim/line has been paid.",
        "submittedAmount": "12500.00",
        "tradingPartnerClaimNumber": "0123456789"
      }
    }
  ]
}

What the check tells you

The claim status response shows how the payer currently reports your claim. The codes it returns don't guarantee the payer processed the determination, so treat them as signs that the claim was revised and confirm payment with the ERA when it arrives.

If you're tracking payment after IDR, these are the status category codes to watch:

You can find the full list in X12's Claim Status Category Codes, and Claim status codes in plain English explains how to use them.

Get started with Stedi

You can use Stedi to get the current status of a claim – including IDR claims – directly from the payer.

To get started, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.