A quick start guide to real-time claim status checks

A real-time claim status check tells you where a claim stands with the payer. Billing teams use these checks to follow up on submitted claims that haven't been paid and to catch denials early.

Other ways of checking a claim's status – like calling the payer or logging into a payer portal – tend to take minutes each, are expensive, and don't scale across payers.

Claim status checks return results in seconds, cost pennies per check, and are designed to run at scale. They're also standardized; the same request and response format works across every payer, which makes them easy to automate.

If you're building an AI agent or automated workflow, this guide covers the basics in under 15 minutes: what claim status checks are, when to use them, how to run them, and how to handle common responses.

What is a claim status check?

A real-time claim status (RTCS) check is a standardized healthcare transaction that returns the current status of one or more claims.

Other transactions, like the 277CA claim acknowledgment and the Electronic Remittance Advice (ERA), also return information about a claim's status. But those responses arrive asynchronously, whenever the payer sends them. In many cases, they arrive days or weeks after claim submission.

A real-time claim status check is synchronous: you send a request and get the status back in seconds.

What do 276 and 277 mean?

HIPAA is a U.S. federal law that, among other things, requires that certain electronic healthcare transactions, including claim status checks, use X12 EDI.

276 and 277 refer to the underlying X12 transaction sets for claim status checks:

276 Claim Status Request for requests
277 Status Request Response for responses

In everyday usage, people may refer to a claim status request as a "276" or the response as a "277."

You don't have to work in X12 to run claim status checks with Stedi. Submit and receive them as JSON, and Stedi handles the translation to X12.

Note: Claim acknowledgments use a different implementation of the 277 X12 transaction set, called the 277CA Claim Acknowledgment. While both indicate the claim's status, there are major differences in the implementations. Claim acknowledgments and claim status checks serve different use cases. In most of these use cases, they're not interchangeable.

When to run a claim status check

Most payers send a 277CA claim acknowledgment after a claim reaches their system; it tells you whether the claim was accepted for processing. Wait for the 277CA before running a claim status check, since a status check on a claim the payer hasn't received yet returns nothing. A 277CA isn't required, though, and some payers don't send one. If you don't have a 277CA to go on, we recommend running your first claim status check 7 days after submission.

You can run a check whenever you need a claim's current status and don't want to wait for the payer's next response. For example, if you've received a 277CA but no ERA yet, a check tells you whether the claim is still in adjudication. Billing teams also run a check to confirm the payer received a claim before resubmitting it, which avoids creating duplicates.

How to run a claim status check

You can run claim status checks using Stedi's JSON Real-Time Claim Status API. In the request, include:

The payer ID, used to route the check to the payer. Look it up with the Payers API or the Stedi Payer Network.
The billing provider's name, NPI, and provider type.
The patient's identifiers from the original claim: first name, last name, date of birth, gender, and member ID.
The total submitted amount, the sum of all service line charges in the claim. Several payers require it.
A date of service range that brackets the claim's service date. We recommend plus or minus 7 days, up to a 30-day maximum. Don't use future dates. Payers sometimes store a different service date, so a range improves the odds of a match.

Start with the minimum. Too much information in the first request can cause the payer to return no matches. Add fields only if a check comes back empty.

An example JSON Real-Time Claim Status API request:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "tradingPartnerServiceId": "3429",
    "encounter": {
      "beginningDateOfService": "20240318",
      "endDateOfService": "20240402",
      "submittedAmount": "150.00"
    },
    "providers": [
      {
        "providerType": "BillingProvider",
        "organizationName": "Behavioral Services P. C.",
        "npi": "1999999984"
      }
    ],
    "subscriber": {
      "firstName": "Jane",
      "lastName": "Doe",
      "dateOfBirth": "19000806",
      "gender": "F",
      "memberId": "111222333"
    }
  }'

You can also run real-time claim status checks using:

See our docs for best practices.

What does a claim status check return?

A claim status response includes a result for each matching claim. A result can carry more than one status – up to three. Each status has two codes:

Claim status category code, which indicates the broad state of the claim, such as accepted, rejected, pending, or finalized.
Claim status code, which is a more specific status for the claim. For a rejected or denied claim, claim status codes often indicate a reason for the rejection or denial.

Together, these codes show exactly where your claim stands with the payer. For example, in a JSON Real-Time Claim Status API response:

{
  "claims": [
    {
      "claimStatus": {
        "statusCategoryCode": "F1",  // Finalized/Payment - The claim/line has been paid.
        "statusCode": "65",          // Claim/line has been paid.
        ...
      },
      ...
    }
  ],
  ...
}

Some status codes also require an entity identifier code that names who or what the status refers to. For example:

{
  "claims": [
    {
      "claimStatus": {
        "statusCategoryCode": "F2",  // Finalized/Denial
        "statusCode": "88",          // Entity not eligible for benefits for submitted dates of service.
        "entityCode": "QC",          // Patient
        ...
      },
      ...
    }
  ],
  ...
}

Most payers don't return status for individual service lines or payment details in claim status responses. To get that, retrieve the ERA for the claim.

What do I do if a claim status check doesn't return useful results?

When a check comes back without the status you need, the cause is usually in the request, not the claim. A no-match still returns a 200 HTTP status, so read the claim status codes, not the HTTP status.

The category code and status code together point to the cause. Payers don't always send precise codes, so work through the fixes even when a code looks vague. Common combinations:

Category code	Status code	What it means	What to do next
`D0`	`35`	Data search unsuccessful; the payer found no matching claim.	Confirm the claim was accepted, widen the date of service range, and add the submitted amount.
`D0`	`97`	The payer can't find the patient.	Run an eligibility check to confirm the member ID and demographics, and that you're using the right payer.
`E1`	n/a	Response not possible; the payer's system is temporarily unavailable. Some payers also return `E1` when the request data was incorrect.	Retry with an exponential backoff. If retries keep returning `E1`, treat it as a possible request-data problem and verify the patient and provider details rather than continuing to retry.

For more tips, see the troubleshooting guide in our docs.

Which payers support claim status checks?

Stedi supports real-time claim status checks for hundreds of payers. You can check whether a payer supports claim status checks using the Stedi Payer Network or the Payers API.

It's uncommon, but some payers require transaction enrollment before they accept claim status checks. This is separate from enrollment for claim submission or ERAs.

For example, a payer record from the Payers API:

{
  "items": [
    {
      "payer": {
        "stediId": "60054",
        "transactionSupport": {
          "claimStatus": "ENROLLMENT_REQUIRED" // Supported. Enrollment is required.
        }
      }
    }
  ]
}

If you don't see a payer listed or if a payer doesn't support real-time claim status checks, reach out. The payer may be listed under a different name. We're also actively working with payers to add support for claim status checks.

Get started with Stedi

To get started with Stedi, 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.

Twitter LinkedIn