You may need to check the status of a claim when 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/277 real-time claim status: Both endpoints return 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.

​
Headers

When constructing the request, you must include the following information in HTTP headers:
  • Authorization: Generate an API key to use for authentication.
  • Content-Type: Set to application/json.

​
Body - JSON

For best results, you should start with our recommended base request and add more information only as needed. Note that objects marked as required are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties. For example, you must always include the subscriber object in requests, but you only need to include the serviceLinesInformation object when you want to request the status for a specific service line.

​
Body - X12 EDI

Your payload must conform to 276 X12 EDI format. For best results, you should start with our recommended base request and add more information only as needed.

​
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.

​
Sample requests and responses

The following examples show a 276 claim status request and 277 claim status response for Stedi’s JSON endpoint.

​
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. 
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 '{
  "controlNumber": "222222222",
  "encounter": {
    "beginningDateOfService": "20240318",
    "endDateOfService": "20240402"
  },
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "Behavioral Services P.C.",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "dateOfBirth": "19000806",
    "firstName": "Jane",
    "lastName": "Doe",
    "gender": "F",
    "memberId": "111222333"
  },
  "tradingPartnerServiceId": "3429"
}'

​
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. 
{
  "tradingPartnerServiceId": "423",
  "controlNumber": "000000001",
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "PROVIDER NAME",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "gender": "F",
    "memberId": "XYZO9NUSPD6R",
    "dateOfBirth": "19800101"
  },
  "encounter": {
    "beginningDateOfService": "20241101",
    "endDateOfService": "20241112"
  }
}

​
Timeout

Requests to payers typically time out at 1 minute, though Stedi can keep connections open longer than that if needed. You may want to use an API client to make testing and debugging easier. We don’t recommend using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds. Visit API clients for a list of recommended clients you can use instead.

​
Best practices

We recommend following these best practices when sending a 276 real-time claim status request.

​
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 276 real-time claim status request can negatively affect the results. That’s why we recommend first sending a base request with only the following information. 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.

​
JSON base request

We recommend starting with the following properties in a request to the Real-Time Claim Status JSON endpoint:
InformationDescription
tradingPartnerServiceIdThis 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 payer ID alias listed in the payer record.
controlNumberAn integer to identify the transaction. You can set this to whatever value you prefer, and it does not need to be globally unique.
providersThe provider information from the original claim. To start, provide only the npi, organizationName, and providerType properties.
subscriberThe subscriber information from the original claim. To start, provide only the firstName, lastName, dateOfBirth, gender, and memberId properties.
dependentThe dependent information from the original claim. To start, provide only the firstName, lastName, dateOfBirth, and gender properties. If the patient is the subscriber, you can omit this object.
encounterThe encounter information from the original claim. 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. The following examples show two base request payloads: one where the patient is the subscriber and one where the patient is the dependent. They include only the minimum recommended information: 
{
  "controlNumber": "222222222",
  "encounter": {
    "beginningDateOfService": "20240318",
    "endDateOfService": "20240402"
  },
  "providers": [
    {
      "npi": "1999999984",
      "organizationName": "Behavioral Services P.C.",
      "providerType": "BillingProvider"
    }
  ],
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19000806",
    "gender": "F",
    "memberId": "111222333"
  },
  "tradingPartnerServiceId": "3429"
}

​
X12 base request

We recommend starting with the following properties in a request to the Real-Time Claim Status Raw X12 endpoint:
  • Loop 2100A NM109 (Payer Identifier): This identifier allows Stedi to route the claim status request to the correct payer. It must be a payer ID or payer ID alias listed in the Payer Network. For example, you could use 60054, HPQRS, AETNA, or any other listed payer ID alias for Aetna.
  • Loop 2100C NM109 (National Provider Identifier) and NM103 (Provider Last Name or Organization Name)
  • Loop 2000D DMG02 or Loop 2000E DMG02 (Subscriber/Patient Birth Date)
  • Loop 2100B NM1 (Information Receiver Name)
  • Loop 2100D NM103 (Subscriber Last Name), NM103 (Subscriber First Name), and NM109 (Member Identification Number)
  • Loop 2200D DTP03 (Claim Service Period) that is plus or minus 7 days from the date of service listed in the claim
  • Loop 2200D or 2200E: TRN (Claim Status Tracking Number)
If this base request fails to return results, try adding in other information like Loop 2200D REF02 (Payer Claim Control Number).

​
Claims submitted by other providers

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 generally only allow a provider organization to check the status of the claims they submitted. They impose these access controls to protect plan member privacy and confidential commercial data.

​
Claims older than 18 months

Payers 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.

​
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.

​
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.