Frequently Asked Questions
How To Use This Page
This page is for short answers only.
Use it when you want a quick clarification or a pointer to the right guide.
Do not use it as the source of truth for onboarding, implementation, feature behavior, or support procedures.
For source material:
- Product and support onboarding: Onboarding for Providers & Channel Partners
- Developer prerequisites and delivery-model choices: Developer Onboarding
- API requests, headers, and examples: Getting Started
- Feature behavior: Value-Added Features
- Callback implementation: Customer Callback Example API
- Production issue handling: Troubleshooting and Support
Enhanced Eligibility & Coverage Discovery – Common Questions
Do I need to call Coverage Discovery separately?
Usually no.
Most customers should start by calling the real-time Enhanced Eligibility endpoint and using Coverage Discovery as part of the enrolled workflow when applicable.
Direct Coverage Discovery is supported, but it is usually an advanced pattern rather than the default integration path.
Use direct discovery only when your implementation already has the required processed eligibility data available:
- direct JSON discovery uses canonical eligibility models
- direct X12 discovery uses the processed
x12-270andx12-271
If you need direct discovery, the X12 path is often easier because it avoids mapping into two canonical models.
For the technical workflow options, see Getting Started and Customer Callback Example API.
Do I always need canonicalEligibilityResponse when calling the JSON Coverage Discovery endpoint directly?
canonicalEligibilityResponse when calling the JSON Coverage Discovery endpoint directly?No.
canonicalEligibilityRequest is always required.
Whether canonicalEligibilityResponse is also needed depends on the enrolled workflow and the request pattern you are implementing.
For direct JSON and X12 request guidance, see Getting Started.
When does Coverage Discovery run?
Coverage Discovery runs only when the customer is enabled and configured for it and the workflow calls for asynchronous follow-up.
For enrollment and configuration decisions, see Onboarding for Providers & Channel Partners.
Is Coverage Discovery synchronous?
No.
Enhanced Eligibility is synchronous.
Coverage Discovery is asynchronous by design.
Coverage Discovery results are not returned in the same HTTP response as the initial eligibility request.
What response times should I expect?
Real-Time Eligibility is synchronous, but payer and clearinghouse timing dominates the response time.
Current RTE metrics:
- end-to-end
p95: 20.7 seconds - end-to-end
p99: 30.6 seconds - Enhanced Eligibility touch time
p95: 91.3 ms - Enhanced Eligibility touch time
p99: 171 ms - downstream clearinghouse timeout: 2 minutes
Coverage Discovery is asynchronous. Discovery paths and add-ons are enabled per customer and are not included automatically.
Practical guidance:
- most non-Coverage-Insight paths are near-real-time
- customers who are highly sensitive to turnaround time should avoid enrolling in Coverage Insight
For the fuller timing discussion, see Getting Started and Developer Onboarding.
How do I receive Coverage Discovery results?
Coverage Discovery results are delivered after the initial eligibility response using one of the following patterns, depending on your integration:
- Push – Results are posted to a customer‑provided, OAuth2‑secured callback endpoint
- Pull – Results are retrieved later using identifiers returned from the original request
- Temporary batch delivery – For some proof-of-concept or stop-gap scenarios, Optum can provide a secure batch file containing
x12-271responses produced from Real-Time Eligibility and/or Coverage Discovery processing
The available mechanism is determined during onboarding and configuration.
For implementation details, see Developer Onboarding and Customer Callback Example API.
This batch option can be especially helpful while polling or postback delivery is still being built, or when high-volume pagination through the Transactions or Coverage Discovery list endpoints would be burdensome.
I didn’t receive any Coverage Discovery results. Did something fail?
Not necessarily.
Coverage Discovery may have completed without producing an alternate coverage result.
This does not mean Coverage Discovery failed to run.
For support triage, see Troubleshooting and Support.
What results does Coverage Discovery produce?
Coverage Discovery results can include successful, unsuccessful, pending, and skipped outcomes, depending on the enrolled workflow and the final task state.
For the callback payload model, see Customer Callback Example API.
What is the realTime object in a Coverage Discovery callback or poll response?
realTime object in a Coverage Discovery callback or poll response?realTime contains related Real-Time Eligibility context.
It is only present when consolidated callback delivery is enabled.
Use it to review the related real-time eligibility context when that option is enabled.
Which status should I use for retry decisions?
Use the returned task and transaction statuses together with your operational workflow.
For the full operational interpretation, see Customer Callback Example API.
What does the Coverage Discovery name field mean?
name field mean?The root Coverage Discovery record name is the configured task name assigned for your enrolled workflow.
Examples:
Medicaid + HMOCommercial + HMO + RTCOB
The per-path names under discoveryPaths.*[].name tell you which specific path was associated with each result record.
Will Coverage Discovery return ineligible, conditional, or pending coverage?
Coverage Discovery does evaluate and categorize ineligible, conditional, pending, and patient‑unknown results.
Only discovery paths categorized as Success (eligible coverage) are surfaced as successful Coverage Discovery results.
Other outcomes are available for auditing, analysis, and operational insight but are not promoted as coverage‑found results.
What types of coverage can Coverage Discovery find?
Coverage Discovery may identify:
- Medicare coverage (including MBI and Medicare Advantage)
- Medicaid coverage
- Commercial coverage using demographic‑based searches
- HMO enrollment associated with discovered coverage
Exact discovery paths and categorization depend on configuration and payer capabilities.
For configured discovery paths and enrollment scope, see Onboarding for Providers & Channel Partners. For feature descriptions, see Value-Added Features.
Is Coverage Discovery the same as Coverage Insight?
No.
| Feature | Coverage Discovery | Coverage Insight |
|---|---|---|
| Execution | Near real‑time, workflow‑driven | Batch, analytics‑driven |
| Lifecycle | Pre‑service / registration | Post‑service |
| Trigger | Eligibility failure | Scheduled or batch processing |
| Integration | API‑based | File‑based (typically SFTP) |
They are complementary but serve different phases of the patient journey.
For Coverage Insight details, see Value-Added Features.
Why didn’t Coverage Discovery run for my request?
Coverage Discovery is conditional, not guaranteed on every eligibility request. Enrollment, configuration, and request completeness all affect whether it runs.
For developer-side request handling, see Getting Started. For support investigation, see Troubleshooting and Support.
TL;DR for Developers
- Start with Enhanced Eligibility and integrated Coverage Discovery
- Coverage Discovery runs asynchronously
- Coverage Discovery results can include different outcome categories
- No coverage-found result does not mean Coverage Discovery didn’t run
- Direct discovery exists, but it is an advanced pattern
For the detailed developer guide, see Getting Started.
What does "Enhanced" mean?
The submission of an eligibility request to a clearinghouse is a complicated process. It takes an expert to understand the nuance of a 270 request/271 response and how the submission data informs the response of the target Payer.
Enhanced Eligibility makes that interaction simpler by providing common pre and postprocessing rules that augment the submitted transaction and the returned response.
For the product overview, see Overview. For feature specifics, see Value-Added Features.
Why do I need/want "Enhanced Eligibility"?
Healthcare data is not consistent across providers, facilities, and patients and the 270/271 EDI contracts exposed by payers do not follow the specification to the letter. If your organization faces unknown or incomplete patient data, or requires automation to increase your eligibility response rate, you will benefit from the Enhanced Eligibility API.
Can I opt-out of enhanced features of the Enhanced Eligibility API?
Yes, at its core, our engine interfaces directly with the clearinghouse. If you have scenarios that require enhanced processing, and some scenarios that don't, the Enhanced Eligibility API can accommodate the needs of your organization.
For value-added feature descriptions and enrollment context, see Value-Added Features. For API-visible runtime behavior, see Getting Started.
What is "Core" Eligibility Processing?
The backbone of our product is the integration with the Medical Network interface to the clearinghouse. Click here for more information.
Looking for the homepage? Return to Enhanced Eligibility Overview here.
Updated 4 days ago