Institutional Claims FAQs

How do I access the Institutional Claims APIs?

The Institutional Claims APIs enables healthcare providers to submit institutional healthcare claims for a service or encounter.

• Institutional Claims
• API environments
• Try our APIs
• API URLs and endpoints

What information goes in the API Request header?

Please see example in API Request Header.

How do I check the Operating Status of the API?

/institutionalclaims/v1/healthcheck endpoint checks the operating status of the Institutional Claims API engine. See example in API Health Check.

Do you have a sandbox that I can test with before signing a contract?

Yes, we do, see Sandbox FAQs and API environments.

What does a typical Institutional Claims API request look like?

The Institutional Claims Submission API uses the POST request. 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. This is especially true since institutional claims can have hundreds of line items in the claimInformation object (Loop 2300 in the EDI spec), each of which reflects payer decisions on payment.

Our APIs translate back and forth between JSON and X12 EDI when the information departs into and returns from the medical network. All fields and JSON objects conform to the EDI 837i transaction standard.

📘

NOTE

See example in Institutional Claims API example.

Institutional Claims v1 request example

Here is a brief example compared to what can apply in a real-world transaction: Institutional Claims API example.
✍️ In the sandbox request, using value: test00005 (lower case and not uppercase), for
fieldName: patientControlNumber returns EDITS canned response.

In its header section, the request body supports use of either the tradingPartnerServiceId or the serviceId as the required payer identification.

The submitter object describes the information for the medical institution submitting the transaction. The core claimInformation object follows the provider information. It contains the insurance coding for the claim. For error messages, see Institutional Claims Error Messages.

What does a typical Institutional Claims API response look like?

The primary elements of a medical claims submission response consist of the aforementioned meta object and a claimReference object. It contains a number of tracking values. Please see Institutional Claims API Example.

The first response you get back from the clearinghouse does not indicate if the claim is being paid; it indicates that the clearinghouse has accepted the claim and is getting ready to forward it to the payer.

What do Institutional Claims error responses look like?

Please see example in Institutional Claims Error Response.

If something is wrong with the syntax of the data, you may get a response from our validation endpoint. See example in Institutional Claims syntax error response.

📘

NOTE

We recommend using the Validation API before sending the claim request to the payer. The Validation rules help prevent claims with incorrect information from being sent to the payer, such as a typo in the NPI, errors in calculations, or poor formatting and syntax in the claim. You can use the /institutionalclaims/v1/healthcheck endpoint to check the operating status of the service endpoint before sending the claim.

What is the difference between an Institutional claim and a Professional claim?

• Professional billing typically uses the 837p transaction (or the CMS-1500 form in hard copy)
• Institutional billings use the 837i transaction

We support both types of electronic claims and transactions. Institutional billing also sometimes encompasses collections while Professional Claims and billing typically do not.

Professional billing controls the billing of claims generated for work performed by physicians, suppliers, and other non-institutional providers for both outpatient and inpatient services. One commonality: our APIs help support and automate insurance coding for both Institutional and Professional claims.

What is the claimReference field in the Submission response?

The claimReference field is an object containing the list of identifiers that you can use to track an Institutional Claim. Please see example in ClaimReference Field in Submission Response.

How to create EDI 837p 5010 claim for a client that has both Primary and Secondary insurances?

Please see example in Create an EDI 837p 5010 Claim for a Client-Primary and Secondary Insurances.

Primary, Secondary, and Tertiary Claims

Primary and secondary claims must be sent separately. Once the primary payer sends a remit on the claim, you can file a claim to the secondary payer.

For the secondary claim to be paid electronically, the payer must accept secondary claims.

You can verify that through ConnectCenter >> Payer Tools >> Payer Search. Those that have the green check mark under the column labeled '2nd CL', indicate that they accept them.

The primary claim information goes in otherPayerName, otherSubscriberInfomation, and the active payer details are submitted as normal. We do not have any documentation on what is required for secondary claims as this would be billing-specific and situational information.

For the secondary claim to be paid electronically, the primary payer must accept secondary claim.

If the Primary claims are sent electronically, will the Secondary/Tertiary claims be sent electronically as well all the time?

For the secondary claim to be paid electronically, the primary payer must accept secondary claim.

These payers can be reviewed in npd or cap.
The ‘Accepts Secondary’ column is not automatically displayed.

1. Click the gear icon (highlighted below) at the top-right of the list.

2. From the menu that shows, select the Accepts Secondary checkbox.

3. Save your settings.

This will display an additional column. Those with a ‘Y’ designation, accept secondary claims.

However, the secondary payer must also process claims electronically; and the appropriate payer ID must be included within the claim for the process to be fully electronic.

Can we electronically bill Worker's Compensation?

Our APIs can transmit accident and worker's compensation claims.

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 caching/drafting feature. Customers can develop and automate this feature. Customers should hold the claims at their end, and programmatically set up a console to separate working on claims from submitting them.

For EDI claims, where can I put the session times in Loop 2400 for each individual line in the claim request when using the claims API?

In the developers portal's JSON-to-EDI API Mapping, scroll down to Loop 2400 to view different SV segments.

How to avoid the error "OTHER PAYER PRIMARY ID# IS MISSING OR INVALID" when the other payer doesn't have a payer ID and for which the claims are set up to be sent by paper?

Please see error message description in Other Payer Primary ID is Missing or Invalid. See Claim Payer Identification (CPID) list (for claims process only) for paper claims.

What is the Claim submission Flow?

Please see steps in Claim Submission Workflow.

Do you support appeals for denials? Are there any APIs through which these appeals can be submitted?

Please see example in Corrected Claim in Appeals and Denials.

How do you re-submit a claim that was denied – Appeal & Denial

Please see example in Corrected Claim in Appeals and Denials.

Can we submit multiple claims at once, in batches?

We do offer batch submissions through SFTP only, our current API does not allow for batch submissions. These would have to be 5010-compliant EDI files. Please reach out to your sales representative to discuss pricing options for SFTP submissions.

When a claim is submitted via the API, the API returns a payer-assigned claim ID. What API can I use to fetch the payer's claim number before we receive the ERA, ideally the next day after the claim is submitted successfully?

The payer-assigned claim ID would be returned through the SD and SF Reports Mapping we provide through the responses and reports API. Additionally, you may be able to check the provider portal for the payer for this information.

Can you provide the source to obtain the master list related to CMS1500/UB04 Claims forms?

Optum does not have a master list of information.

• 1500 is a medical claim (Professional) – When paper is sent, this form is used for Medical claims
• UB04 is hospital claim (Institutional) – For Hospital
• 837P is a 1500 Medical Claims
• 837I is a UB04 Hospital claims

The information is common across the medical industry and there are many crosswalks or sites you can find that map the paper claim locations to a 837.

Is the usageIndicator field something that is respected by the clearinghouse and/or payers? Is submitting real data with a "T" usageIndicator value a valid way to test production data without actually submitting it for processing? How is this field interpreted?

Please see example in Test Production Data without Submitting for Processing.

Can you provide example/sample data and best testing approach to test rejected/denied claims?

Testing claims in the sandbox is limited to predefined data values. Please see example in Test Rejected/Denied Claim.

EDI NM103 1000b organization name could be either the insurance company payer or a clearinghouse, should the organization name here be the insurance payer?

Correct, this field can typically contain either the clearinghouse or payer name. We advise you send the payer name when available. Additionally, if a payer were to require specific information be present, we would make any necessary adjustments prior to submission.

How to include condition codes to the claim information?

Please see example of Institutional Claims use conditional codes in Institutional Claims.

Is there a comprehensive list of outpatient facility codes?

Find a complete list of POS codes here. Please use these to identify the place of service information.

This would mean that if when the type of bill is from the above list and the claim also contains the code R6889, this edit would not be triggered within our system.

How does the type of bill (Box 4) on UB04 get represented on the institutional claim submission request? If my type of bill code is "0123" does this mean that the Facility Code is "12" and the Frequency code is "4"?

This four-digit alphanumeric code provides three specific pieces of information after a leading zero. This three-digit alphanumeric code gives three specific pieces of information. The facility code will become the claimInformation.placeOfServiceCode and the frequency code becomes the claimInformation.claimFrequencyCode.

• First Digit = Leading zero. Ignored by CMS (not included on claim)
• Second Digit = Type of facility
• Third Digit = Type of care
• Fourth Digit = Sequence of this bill in this episode of care. Referred to as a "frequency" code

The following is from CMS:

Type of Care: CMS processes this as second digit

Frequency: CMS processes this as third digit

What clearinghouse does Optum use when using Claim Submission API?

Optum uses multiple clearinghouses for our products (for example, IMN, Exchange). You need not specify a clearinghouse to use when utilizing the APIs for the Medical Network Submitter APIs (i.e. Eligibility, Claims Submissions, etc.), you would be using the Exchange clearinghouse.

Regardless of the clearinghouse used, there are no separate charges associated, other than the regular charges for fees and transactions that you have contracted for. Information on billing and contracting is best discussed with your Sales/Account representative.

Include Primary Claim information for Secondary Claim in the API

Send any payer-specific information in the otherPayerName object.

Use otherSubscriberInformation to convey details for the member specifically.

For more information about primary, secondary, and tertiary claims, Institutional Claims API JSON-to-EDI contents.

Institutional Claims for Medicare

Medicare payers accept claims only for subscribers. If you want to submit a dependent claim with a Medicare payer, submit the dependent as a subscriber in the claim request.

Do the doctors need to be re-registered in each Medicare variant to return benefits correctly?

A couple things here: now that the old PokitDok APIs is no longer supported, the best PayerList for you is accessible through ConnectCenter npd or cap. You can also access this behind the log in and export to .CSV format. For this, filter to Eligibility and Medicare before your search.

Most Medicare have the Eligibility ID/Realtime ID of CMSMED. If there are specifics that do not, such as, a Medicare Advantage plan, might require separate enrollment. In this situation, submit a ticket to our Registrations team through ConnectCenter or email to [email protected].

Related Topics

• API Reference
• Troubleshoot APIs with Metadata