POST
/
change
/
medicalnetwork
/
claimstatus
/
v2
/
raw-x12
curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2/raw-x12 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "x12": "ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *240710*2300*^*00501*000000001*0*T*>~GS*HR*SENDERGS*RECEIVERGS*20240710*230011*000000001*X*005010X212~ST*276*0001*005010X212~BHT*0010*13*ABC276XXX*20050915*1425~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*3429~HL*2*1*21*1~NM1*41*2*XYZ SERVICE*****46*X67E~HL*3*2*19*1~NM1*1P*2*BEHAVIORAL SERVICES P.C.*****XX*123456789~HL*4*3*22*0~DMG*D8*19301210*M~NM1*IL*1*JANE*DOE****MI*111222333~TRN*1*222222222~REF*BLT*111~REF*EJ*SM123456~AMT*T3*238.44~DTP*472*RD8*20050831-20050906~HL*5*2*19*1~NM1*1P*2*BEHAVIORAL SERVICES P.C.*****XX*123456789~HL*6*5*22*1~NM1*IL*1*DOE*JANE****MI*345678901~HL*7*6*23~DMG*D8*19951101*M~NM1*QC*1*DOE*JOHN~TRN*1*222222222~REF*EJ*MA345678~SVC*HC>99203*238.44*****1~DTP*472*D8*20050501~SE*28*0001~GE*1*000000001~IEA*1*000000001~"
}'
{
  "claims": [
    {
      "claimStatus": {
        "amountPaid": "95.55",
        "claimServiceDate": "20240325",
        "effectiveDate": "20240329",
        "paidDate": "20240329",
        "patientAccountNumber": "3333333",
        "statusCategoryCode": "P5",
        "statusCategoryCodeValue": "Pending/Payer Administrative/System hold",
        "statusCode": "3",
        "statusCodeValue": "Claim has been adjudicated and is awaiting payment cycle.",
        "submittedAmount": "238.44",
        "trackingNumber": "222222222",
        "tradingPartnerClaimNumber": "5332034153-KK"
      },
      "serviceDetails": [
        {
          "service": {
            "amountPaid": "95.55",
            "procedureId": "90837",
            "serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
            "serviceIdQualifierCode": "HC",
            "submittedAmount": "238.44",
            "submittedUnits": "1"
          },
          "status": [
            {
              "effectiveDate": "20240329",
              "statusCategoryCode": "P5",
              "statusCategoryCodeValue": "Pending/Payer Administrative/System hold",
              "statusCode": "3",
              "statusCodeValue": "Claim has been adjudicated and is awaiting payment cycle."
            }
          ]
        }
      ]
    }
  ],
  "controlNumber": "222222222",
  "meta": {
    "applicationMode": "production",
    "traceId": "bf27223e-46c3-451e-b2b4-46f3f0b6fe3b"
  },
  "payer": {
    "organizationName": "UNITEDHEALTHCARE",
    "payerIdentification": "3429"
  },
  "providers": [
    {
      "organizationName": "Behavioral Services P.C.",
      "providerType": "BillingProvider",
      "taxId": "123456789"
    },
    {
      "npi": "1234567890",
      "organizationName": "Behavioral Services P.C.",
      "providerType": "ServiceProvider"
    }
  ],
  "reassociationKey": "000000001",
  "status": "success",
  "subscriber": {
    "firstName": "JANE",
    "lastName": "DOE",
    "memberId": "111222333"
  },
  "tradingPartnerServiceId": "3429"
}

This endpoint sends 276 Claim Status requests to payers in raw X12 EDI format. This is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi’s API.

  • Call this endpoint with a payload in 276 X12 EDI format.
  • Stedi validates the EDI and sends the status request to the payer.
  • The endpoint returns a synchronous response from the payer in JSON format. The response contains information about the claims matching the criteria you provided in the request and their current status.

The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.

Best practices

We recommend the following best practices to increase your chances of receiving status information.

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 request with only the following information:

  • Loop 2100C: NM109 (National Provider Identifier) and NM103 (Provider Last Name or Organization Name)
  • Loop 2000D or 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).

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.

Character restrictions

Only use the following characters as delimiters: ~, *, : and ^. The X12 format doesn’t support using escape sequences, so you can’t include delimiters or special characters as part of the request data. Stedi returns a 400 error if you include restricted characters as anything other than delimiters in the request.

Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause validation and HTTP 400 errors.

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.

Timeout

Requests to payers typically time out at 1 minute, though Stedi’s API can keep connections open longer than that if needed.

Authorizations

Authorization
string
header
required

A Stedi API Key for authentication.

Body

application/json
x12
string
required

Response

200
application/json
ClaimStatusRawX12 200 response
controlNumber
string

The control number the payer provided in the claim status response. This is used to identify the transaction.

tradingPartnerServiceId
string

An ID for the payer you identified in the original claim status request. This value may differ from the tradingPartnerServiceId you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.

payer
object

Information about the payer listed in the referenced claim.

providers
object[]

Information about the billing and/or service providers related to the referenced claim.

subscriber
object

Information about the subscriber listed in the referenced claim.

dependent
object

Information about the dependent listed in the referenced claim.

claims
object[]

The status information for the claim referenced in the original claim status request.

The payer may return multiple claims in the response if they have more than one claim on file that matches the information you provided.

Information about the claim and its status.

reassociationKey
string

The control number for the transaction.

errorResponse
object
status
string

The status of the entire claim.

transactionSetAcknowledgement
string

The acknowledgment code in the 999 Implementation Acknowledgment, an EDI file generated by the payer to acknowledge receipt of the claim status request. It indicates whether the claim status request was accepted or rejected due to errors in the EDI request syntax.

implementationTransactionSetSyntaxError
string

The syntax error code in the 999 Implementation Acknowledgment. It indicates the type of error (if present) in the EDI request syntax. Visit IK502 in the Implementation Acknowledgment specification for a complete list.

x12
string

The raw X12 response from the payer.

meta
object

Metadata about the response.