There is an additional cost for COB checks. Please reach out to support for API access and pricing information.
This endpoint submits a real-time coordination of benefits (COB) check request for a patient. When a patient has active coverage through multiple health plans, COB checks can help ensure that you submit claims to the correct payer and avoid claim denials.
Call this endpoint with a JSON payload. Each check must be for a Stedi-supported payer with which the patient has coverage. For example, if the patient has coverage from Cigna and UnitedHealthcare, a COB check to Aetna will return an error.
Stedi searches a national database containing 245+ million patient coverage records from 45+ health plans, ASOs, TPAs, and others, including participation from the vast majority of national commercial health plans. Data is updated weekly to ensure accuracy.
Stedi returns information about the patient’s active health plans, the responsibility sequence number for each payer if available (such as primary or secondary), and whether coordination of benefits is required.
We recommend performing COB checks for all new patients who have coverage through one of Stedi’s supported payers. Visit the Payer Network for a complete list.
COB checks are significantly more sensitive to data accuracy than eligibility checks. To perform successful COB checks, the patient information you provide in the check must match the payer’s data exactly.
For example, if a payer has a patient’s name stored as “Jonathan Doe”, they may return benefits information when you submit an eligibility check for “Jon Doe”, as long as they can identify the patient through the other information provided. However, a COB request for “Jon Doe” will fail because the name doesn’t match the payer’s records exactly.
To avoid unnecessary COB check failures, we strongly recommend that you first submit an eligibility check request for the patient. Then use the following data from the successful payer benefit response to build the COB request: firstName, lastName, dateOfBirth, memberId.
The COB response includes information about the patient’s active health plans, subscriber information, and coordination of benefits.
Unlike standard eligibility checks, the COB response shape is standardized across all supported payers. There are no payer-specific variations in what information is included or how the response is structured.
Visit Interpret COB response for information and examples for using the COB response to inform claim submissions, including how to determine payer primacy.
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.
If you don't specify a service date (either a single day or a range of dates), Stedi defaults to using the current date.
An object containing information about the entity requesting the COB check. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider. You must provide the organizationName (if the entity is an organization) or firstName and lastName (if the provider is an individual). You must also provide the provider's National Provider ID (npi).
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.
The member ID for the subscriber's insurance policy.
You must provide at least one of the memberId or ssn properties in the request. However, we recommend including both if possible. This allows Stedi to do an additional search for patient information when the memberId doesn't return a match.
You must provide at least one of the memberId or ssn properties in the request. However, we recommend including both if possible. This allows Stedi to do an additional search for patient information when the memberId doesn't return a match.
This is the Payer ID. Visit the Payer Network for a complete list of supported payers for COB checks.
Each check must be for a participating health plan for which the patient has coverage. For example, if the patient has coverage from Cigna and UnitedHealthcare, a COB check to Aetna will return an error.
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.
Dates associated with the benefits. All properties may either be expressed as a single date, formatted as YYYY-MM-DD or as a range of dates, formatted as YYYY-MM-DD/YYYY-MM-DD. Dates listed only apply to the benefitsInformation object in which this benefitsDateInformation is provided.
Coverage start date. If multiple coverage start dates exist due to different start dates on various coverage/service types, this date applies to the medical coverage.
Contains either information about another payer with which the patient has coverage or information about the subscriber associated with the additional health plan.
For example, if you submit a COB check for a dependent to Cigna and Stedi finds additional coverage through Aetna, the benefitsRelatedEntity would include subscriber details for the Aetna plan.
An overview of the COB response. It indicates whether there is a coverage overlap, whether that overlap creates a coordination of benefits instance, and whether Stedi was able to identify payer primacy (when a COB instance exists).
If set to true, the COB response contains benefits overlap. A benefits overlap indicates that the patient has active coverage from two or more payers for the same service type code, including the subtypes of medical coverage.
The classification for the benefits that have been discovered in the COB response. Stedi returns one of the following values:
- CobInstanceExistsPrimacyDetermined: COB Instance Exists and Primacy was determined
- CobInstanceExistsPrimacyUndetermined: COB Instance Exists and Primacy was NOT determined
- CoverageOverlapNoBenefitOverlap: Coverage Overlap detected with no Benefit Overlap
- CoverageOverlapExistsNotSubjectToCob: Coverage Overlap exists and is not subject to COB
- MemberFoundNoCob: Member found, no COB found
If set to true, the COB response contains a coverage overlap, meaning that the patient has active coverage with two or more payers during the service date submitted in the COB request.
- Coverage overlap can be for coverages from the same payer if the member ID is different between the two coverages.
- A coverage overlap is necessary for a COB instance to exist.
- A coverage overlap can exist without there being a COB instance if either of the two coverages is not subject to COB for any reason.
If set to true, Stedi was able to determine the primary payer for the patient. If Stedi was unable to determine the primary payer, you must contact the payers directly to determine primacy.
When a COB request fails, the response contains one or more AAA errors that specify the reasons for the rejection and any recommended follow-up actions.
The number assigned to each family member born with the same birth date, such as twins or triplets. Indicates the birth order when there are multiple births associated with the provided birth date.
For the dependent, this can be 01 - Spouse, 19 - Child, 20 Employee, 21 - Unknown, 39 - Organ Donor, 40 - Cadaver Donor, 53 - Life Partner, or G8 - Other Relationship.
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 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 coordination of benefits request. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider. This object will always include the provider's NPI.
When a COB request fails, the response contains one or more AAA errors that specify the reasons for the rejection and any recommended follow-up actions.
When a payer rejects your request, the response contains one or more AAA errors that specify the reasons for the rejection and any recommended follow-up actions.
The number assigned to each family member born with the same birth date, such as twins or triplets. Indicates the birth order when there are multiple births associated with the provided birth date.
