Claim Status FAQs

What is the API header format/domain?

Please see example in API Request Header.

How can I use X12 EDI as the coding for my API request?

📘

NOTE

Before using the claimstatus /raw-X12 endpoint, contact your Optum implementation analyst. Our Raw-X12 service requires custom headers with credentials, and other information specific to each customer's contracted Payer List relationships that you will need to obtain from your analyst contact.

The Claim Status raw-X12 endpoint supports the X12 EDI standard if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.

We support a traditional X12 EDI request if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.

Please see example in Claim Status X12 EDI 276 Request & 277 Response.

HL segments

The transaction example contains five hierarchical levels (HL) segments. The first field of each HL segment identifies its position in the hierarchical levels in the claim. Here is the simple segment list shown in the example:

This sequence will change based on different claim factors. See pages 8 to 10 of the ASC X12 276/277 Implementation Guide for details.

Sequence of segments

• An NM1 segment follows each HL segment in the request body. It separately describes each of these five entities in our example. A Demographic information (DMG) follows for the subscriber and dependent records. The 276 submission requires all of this information to help ensure the payer/information source can locate the claim and send an informative response.

• The TRN segment is required when the patient has their own policy ID number (the subscriber, or a dependent that has a unique policy ID).

• The Reference Information (REF) segment appears whenever the information receiver knows the specific payer-assigned claim number, and is inquiring about that claim. The REF segment takes several different forms depending on the type of claim, but is always defined as the Claim Status Tracking Number. See pages 59 through 65 of the ASC X12 276/277 Implementation Guide to find out more details about how this works.

Integrity of X-12 transmissions

📘

NOTE

Ensuring Integrity of X12 Transmissions

When you create and send your X12 content through our API, ensure that the final field in the ISA header, ISA16, contains the colon character (":"). ISA16 is a single-character field that defines the component element separator in the ISA header. For your X12 EDI transactions to work in your contracted APIs you must use the colon character in this field. It should be used only in ISA16 and not for any other X12 header or trailer. See Appendix C of the ASC X12 276/277 Implementation Guide for more information about the Claim Status transaction structure.

Zooming in on the STC Codes

The first element of all STC segments, STC01, is named Health care status claim. Field STC01 is a composite field that holds several code values. Consider the following snippet:

```javascript
    STC*F1:65:1E*
```

This is the first part of the substantial STC segment. In a composite field, the colon (:) is used as a separator to isolate each coding value. It is another use of the composite element delimiter.

What is the Tracking Number field?

The trackingNumber field is a tracking value that you can use at your discretion. It will accept any value and is not required. It exists so that you can link the 277 response back to your original request, and the payer will always echo this value back exactly as you sent it.

How often can I check the status of pending claims?

Our general recommendation is every 5 to 7 days. Customers can determine if that fits their needs and adjust as necessary.

Do you bill for a failed claim due to technical error?

Every transaction that makes it to the clearinghouse is billable. All errors at the API level, and some errors at the ingress of the clearinghouse, are considered non-billable.

What does a typical Claim Status API request look like?

The Claim Status API uses a POST request. You provide the input as JSON in the body of the request. The Claim Status request body is usually relatively brief, if the optional dependent is not involved in the medical encounter, the request body will be even shorter. Please see example in Claim Status Request & Response.

What does a typical Claim Status API response look like?

Responses to our Medical Network APIs can be lengthy due to the many data points that a payer or trading partner provides in the query response. Our APIs translate back and forth between JSON and X12 EDI when the information departs into, and returns from, the medical network. We also support Raw X12 APIs should you wish to directly communicate using that data format. Please see example in Claim Status Request & Response.

What is the difference between Claim Status and Claims Responses and Reports?

Claim Status API checks the status of a claim in the payer’s system. If a provider has not received a payer report on a claim, or has not received payment, a claim status request helps to find out the most recent status of that claim.

Claims Responses and Reports is a fetching tool for claims information from your mailbox.

Both APIs support Professional and Institutional Claims.

For more information, see Claims Responses and Reports guide and Claims Responses and Reports API reference.

How does EDI to JSON translation work?

Please see example in EDI to JSON Translation.

I am retrieving the claim's status and in the sandbox response returns an array of claims, how can I get the status for a specific claim? Do I use the checkNumber and trackingNumber properties to find the claim? (I submit the claim using the Professional API and have saved the traceId (from meta). Is this the correct number to save so I can look for it in the Status API response?)

Regarding the Claim Status API, match all of this information closely to the actual submission. Please see example in Retrieve Specific Claim Status.

The Contents of the Claim Status API Request page states: Different payers have different recommendations for what you must include in a request, for example, Blue Cross affiliates such as BCBSNC require the NPI (provider identifier) in EDI 276 requests, and recommends adding the Patient Account Number (in Loop 2200D, element REF01) to associate submitted requests to correct responses. When we use the sandbox, how is validation completed? Are you hitting sandboxes of each payer? If not, how can we validate that we have all of the fields each payer requires?

📘

NOTE

The sandbox returns a canned response based on the received data. There is not a validation check or confirmation of specifically required information. These checks would only happen in production. You would need to manually review the companion guides offered by the specific payers to confirm what is required for each.

How to manage adjustment codes from payer in claim status API?

Codes, such as the following are returned by the payer and it is payer dependent. Not all payers return the same information. We have examples of what a typical response looks like in our documentation. Please see codes in Manage Adjustment Codes from Payer in Claim Status API.

Does the Claim Submission or Claim Status APIs return Customer Account number from the Insurance record?

It will have the memberID for the patient, not necessarily their account number from the billing system.

I cannot uniquely identify individual service item in staging Claim Status API Response?

Refer to the API JSON to EDI mapping, contents of the Claim Status API Request and Response.

Can you explain what the Claim Status API is? Is it different from the professional and institutional claims APIs?

The submitter uses a Claim Status request to ask about the status of a previously submitted claim. The payer returns the response as an X12 EDI 277 transaction, which is translated back to JSON by the API gateway. It describes where the claim is in the adjudication process (for example, Pending or Finalized).
If the claim is finalized, the response provides the disposition of the claim (for example, Paid or Denied). For denied or rejected outcomes, the response includes the reasons for the denial or rejection.

Claim status response message: "Patient eligibility not found with entity. Usage: This code requires use of an Entity Code". What does this mean?

Please see Patient Eligibility not Found with Entity in the error messages section.

This means that the payer (entity: Insurer) cannot find the patient in their system. This would either indicate that you are calling the wrong payer or there could be a typo in the request that is sending wrong information.

Here are the claim status codes. Reverify the patient's insurance information and make sure all the details are correct.

A provider has two different teams; one enters the claim and the other verifies and submits it. Before submitting, can they enter the claim, save it, and have it released when ready?

Our APIs do not have a cache/drafting feature. Customers can develop and automate this feature. Customers should hold the claims on their end and programmatically set up a console to separate working on claims from submitting them.

How could I get the submitted claim status with Claim Status API ? Need I put controlNumber or patientControlNumber in get status API request?

Please be aware that payers do require time to process the claims before Claim Status may be available. Here is a sample Claim Status request that is used for the majority of payers: Check Submitted Claim Status.

Can we use UUID for the tracking number? If not, what should we use?

Yes, you can. The trackingNumber in a Claim Status request is only used to tie the request to the response, it does not impact how the payer pulls the claim.

Do we need to use same control ID for a claim in submission and checking its claim status?

The controlNumber should be unique for each individual submission.

If a claim is rejected after submission, should we submit the same claim with frequency code '7' or can we submit the same claim with modified data in a new submission with code '1'?

Code '1' is typically used for rejected claims. Code '7' is only used when submitting a corrected claim. A correct claim is only submitted when the payer has actually adjudicated the submission and processed the claim for payment. That is, a claimFrequencyCode '1' should be used for all original submissions even if a claim has been rejected. claimFrequencyCode '7' is only used specifically if a payer denies a claim and corrections need to be made.

Some Payers have a blank 'Claim Type' and some Payers do not have a Payer ID, what do these signify?

This indicates that there is not a claim connection available with this payer. If on ConnectCenter, you can slide the bar over and see that there is not a green check mark under the 'C' column, which indicates Claims. Payers that have Payer ID indicates that there is not a claim connection with the payer.

When a Payer has a Payer ID, is the Transmission Type classified as 'Paper' and if there is a Payer ID, is the Transmission Type classified as 'Electronic'?

Yes, correct.

Do we need to be enrolled at Remitter to receive 277 Claim Status? We have enrolled through ConnectCenter as a Submitter, is 277 claim status response dependent on us being enrolled as the Remitter for a payer?

Claim Status responses do not depend on being enrolled for Remittance.

There are two types of 277 Claim Status responses, solicited and unsolicited:

A solicited 277 would be a response from the payer to a submitted claim status request through the API. Depending on the payer, this can either be returned in a real-time response or it would be received in a batch file. If the 277 is received through batch, the response would be returned through the Response and Reports API as an X3 file-277 Claim Status Response Data File (X12 format, JSON conversion available) – this report returns the solicited claim status X12 raw data that matches exactly what is returned by the payer and can be translated into JSON. This file is received from payers when claim status is requested and not returned in real time. Please see example in Solicited Attachments Transaction and Solicited Attachment Response to a 277R Transaction.

An unsolicited 277 response would be returned through the Response and Reports API in a SF file-Payer Report Data File (Pipe Delimited) – this report is a proprietary pipe delimited file that returns claim level payer acceptance and rejections. Please see example in Unsolicited Attachments Transaction and Unsolicited Attachments for a 275 Claim Transaction.

The SR you received is the human-readable version of the SF report mentioned above.

Please keep in mind that 277s will only provide information up to the point when the claim has been processed. Most payers will not provide payment details through Claim Status. For more information, see difference between solicited and unsolicited attachment.

What are the prerequisites for sending attachments with the claim and details about the PWK Segment.

Refer to this information in the dev portal.

• Unsolicited Medical attachment

  • The Claim would be sent with a PWK06 – Attachment Control Number (you assign this number).
  • The attachment would also be sent with the same Attachment Control Number.
  • An unsolicited Medical attachment requires the electronic claim be sent with a Medical attachment Control number.

• Report Type/PWK01 – OZ = Support for Claim

• Transmit Code/PWK02 – EL = Electronically Only

• ID/Control #/PWK06 = Attachment Control Number (do not use special characters)

When the payer gets the claim with a PWK06 segment (Attachment Control number), the payer is advised about that advises them about that, and an Attachment is also being sent Electronically. Then, when the Payer gets a Medical Attachment with the same Attachment Control number that was sent in the PWK06 segment of the claim, they can match the claim to the Medical Attachment for processing, see here.

• Solicited Medical Attachment

The Payer sends (mails) to the provider a request for a Medical Attachment in order to process the claim for payment.

The Medical attachment would then be sent to the payer with Payer attachment control number. The payer advises what Payer Attachment Control number needs to be.

How to check all claim status, once submitted?

Claim Status API's main task is to check the status of a claim in the payer's system. When the claim adjudication is complete, the response provides the result of the claim (for example, Paid or Denied). For denied or rejected outcomes, the response includes the reasons for the denial. Review our Claim Status API developer portal page and the associated Claim Status FAQs page.

When applying the bearer token code to try to run the example, we are getting 406 error, how can this be resolved?

Please see error description in 406 Error when running Auth Token Example.

Related Topics

• API Reference
• Troubleshoot APIs with Metadata