POST /coordination-of-benefits

A dependent for which you want to check coordination of benefits.

• An individual qualifies as a dependent when they are listed as a dependent on the subscriber's insurance plan AND the payer cannot uniquely identify them through information outside the subscriber's policy. For example, if the dependent has their own member ID number, you should identify them in the subscriber object instead.
• The demographic information you provide must patch the payer's data exactly. For example, if the payer has the dependent's name as Jonathan Doe, a COB request for Jon Doe will fail because the name doesn't match the payer's records.

Information about the encounter.

• You can submit COB checks with the 30 service type code for Health Benefit Plan Coverage. This is the broadest service type code that covers all medical services and subtypes included in the patient’s health plan.
• The service dates you provide must be within the past 2 years. COB checks don't support requests with dates outside of this range.
• Don't send service dates that are in the future. Future service dates typically result in errors from the payer.
• If you don't specify a service date (either a single day or a range of dates), Stedi defaults to using the current date.

Information about the entity requesting the coverage.

The primary policyholder for the insurance plan or a dependent with a unique member ID. If a dependent has a unique member ID, include their information here and leave dependent empty.

The demographic information you provide must match the payer's data exactly. For example, if the payer has the subscriber's name as Jonathan Doe, a COB request for Jon Doe will fail because the name doesn't match the payer's records. Also note that:

• Any prefix on the member's card is considered part of the memberID used for the search.
• Mismatches in the memberId are one of the most common causes of Member Not Found errors. We strongly recommend first performing an Eligibility Check and using the memberId in the response to populate your COB check.
• We recommend including the ssn property in addition to the memberId if possible. This allows Stedi to do an additional search for the patient when the memberId doesn't return a match.
• Stedi can identify coverage overlap for the same payer if the member ID differs between the two coverages.

Information about the patient's healthcare benefits, including:

• Active coverage with the health plan identified in the COB request
• Coverage overlap (if it exists) with one or more payers
• Payer primacy details (if Stedi was able to determine)
• Benefits details, such as coverage dates and service types

Information about the dependent listed in the original COB request.

If the COB request fails, the COB response contains one or more AAA errors that specify the reasons for the rejection and any recommended follow-up actions.

Dates associated with the patient's health plan coverage. This information is used to determine their eligibility for benefits.

• The provided dates apply to every benefit within the patient's health plan unless specifically noted within a benefitsInformation[].benefitsDateInformation object.
• If the payer sends back date(s) that are different for the subscriber and dependents, Stedi includes only the dates for the dependent in this object and omits the subscriber's date(s). Dependents can have different coverage dates than the subscriber due to qualifying life events, such as starting a new job or passing the age limit for coverage through their parent's plan.

Information about the entity that submitted the original eligibility check request. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider.

Information about the primary policyholder for the insurance plan listed in the COB request.