Check claim status
You may need to check the status of a claim if you don’t receive a 277CA or 835 ERA response from the payer within your expected timeframe. You may also want to check the status of a claim submitted by another entity. For example, a billing agency may want to check the status of a claim submitted by their customer, who is a provider.
Claim Status API
Call one of the following endpoints to send a 276 Claim Status Request:
- Claim Status to send requests in JSON
- Claim Status Raw X12 to send requests in X12 EDI
The endpoint returns a synchronous claim status response from the payer in JSON format. The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.
Supply a date of services range
Supply a date range that is at least plus or minus 7 days from the date of the services listed in the claim. The payer may have stored a different date for the encounter than the one in your records, so providing a date range increases the likelihood that the payer will find a match.
We also recommend keeping the dates of service range to 30 days or less. Some payers may reject requests with a date range that is too wide.
Don’t provide too much information
Providing too much information in a claim status request can negatively affect the results. That’s why we recommend first sending a base request with only the following information:
| Information | Description |
|---|---|
tradingPartnerServiceId | This is the Payer ID. Visit the Payer Network for a complete list. You can send requests using the Primary Payer ID, the Stedi Payer ID, or any alias listed in the payer record. |
controlNumber | An integer to identify the transaction. You can set this to whatever value you prefer, and it does not need to be globally unique. |
providers | The provider information from the original claim. To start, provide only the npi, organizationName, and providerType properties. |
subscriber | The subscriber information from the original claim. To start, provide only the firstName, lastName, dateOfBirth and memberId properties. |
encounter | The encounter information from the original claim status request. To start, provide only the beginningDateOfService and endDateOfService properties. Remember that you should provide a date range that is plus or minus 7 days from the date of service listed in the claim for best results. |
If this base request fails to return results, try adding in other information like encounter.tradingPartnerClaimNumber and providers.taxId.
You will eventually learn payer-specific nuances and can build logic in your system to supply additional information to specific payers. For example, some payers may have better success rates when you include the claim number.
The following examples shows a base request payload where the patient was the subscriber. It includes only the minimum recommended information:
Character restrictions
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause validation and HTTP 400 errors.
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: ~, *, :, and ^. X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a 400 error if you use these restricted characters improperly.
- JSON endpoint: Don’t include delimiter characters anywhere in your request data.
- Raw X12 endpoint: You can use these characters as delimiters, but not in the body of the request data.
Payer limitations
Payers generally only allow a provider organization to check the status of the claims they submitted. This means that you likely won’t be able to check the status of a claim submitted by a different provider organization or by the patient themselves, even if you have all of the details about the claim. Payers impose these access controls to protect plan member privacy and confidential commercial data.
Payers also often archive claims older than 18 months, but this varies by payer. If you try to check the status of a claim from several years ago, the payer may return an error even if the information you submit matches a real historical claim.
Sample requests and responses
The following examples show a claim status request and response for Stedi’s JSON API.
Accepted claim
The following example shows a claim status request and response for a claim that has been accepted by the payer and is awaiting payment.
Denied claim
The following example shows a claim status request and response for a claim that has been denied by the payer. Note that in this example, the subscriber in the request is actually a dependent using the subscriber’s member ID.
Code lists
You may need to reference the following code lists when working with the claim status request or response.
Claim status
Used in the claims.claimStatus.statusCode property. This is the status code used to identify the status of an entire claim or a service line. For example, code 20 means Accepted for Processing.
This is either a Health Care Claim Status Code or a National Council for Prescription Drug Programs (NCPDP) Reject/Payment Code, when the status is related to pharmacy claims.
- Visit Claim Status Codes in the official X12 documentation for a complete list of Health Care Claim Status Codes.
- Visit the National Council for Prescription Drug Programs website for access to the Reject/Payment Code list.
Claim status category
Used in the claims.claimStatus.statusCategoryCode property. For example, code F1 means Finalized/Revised - Adjudication information has been changed.
Visit Claim Status Category Codes in the official X12 documentation for a complete list.
Product or service ID qualifier
Used in the serviceLineInformation.productOrServiceIDQualifier request property and the claims.serviceDetails.service.serviceIdQualifierCode property in the response.
Was this page helpful?