Enhanced Eligibility – Onboarding & Configuration Guide

(For Providers & Channel Partners)

This guide explains what Enhanced Eligibility is, how onboarding works, and what must be configured before development begins.

It is written for product, implementation, and support teams.
If you are implementing APIs, see the Developer Onboarding Guide.

Use this page for business onboarding, clearinghouse model decisions, provider versus channel-partner setup, feature enrollment decisions, and support-owned configuration dependencies.

Do not use this page as the API implementation guide. For request headers, callback mechanics, example API calls, and developer persistence rules, use Getting Started and Customer Callback Example API.

---

What Is Enhanced Eligibility?

Enhanced Eligibility is a real‑time eligibility platform that provides a single integration point for submitting eligibility transactions across a broad payer ecosystem.

Customers integrate once with Enhanced Eligibility. Optum manages:

• Clearinghouse submission and routing
• Request and response normalization
• Optional discovery workflows when coverage is not initially found

Enhanced Eligibility removes the need for customers to manage multiple clearinghouse integrations or payer-specific connectivity.

For a shorter product summary and full documentation map, see Overview.

---

A Multi‑Clearinghouse Solution

Enhanced Eligibility is designed as a multi‑clearinghouse solution.

From a customer perspective:

• You submit eligibility transactions to Enhanced Eligibility
• Optum routes and submits those transactions based on configuration
• The API contract remains the same regardless of downstream routing

Medical Network (IMN) – Default & Required

All Enhanced Eligibility transactions are submitted through Medical Network (IMN) as the primary clearinghouse.

• IMN is the default and required credentialed path
• Payer enrollment requirements follow IMN rules
• Optum Product and Support own IMN onboarding and credential setup

Authoritative payer support information is available in the
IMN Supported Payer List.

---

Expanded Payer Connectivity (Beyond IMN)

In addition to standard IMN clearinghouse submission, Enhanced Eligibility can route transactions to additional payer access paths to improve coverage reach, including:

• Portal‑connected payers that do not support standard clearinghouse transactions
• Expanded commercial connectivity provided through Optum‑managed network partnerships (including FinThrive‑supported payer connections)

These routes are fully managed by Optum and do not require customers to build or maintain separate integrations.

✅

Customers always submit to Enhanced Eligibility

✅ Routing decisions are configuration‑driven
✅ No code changes are required to leverage expanded payer access

---

Clearinghouse Credentials & Authentication

Eligibility transactions require authenticated clearinghouse submission.

Default Model: Optum‑Managed IMN Credentials

For most customers:

• Optum completes IMN onboarding
• Credentials are provisioned and managed by Optum
• Customers do not interact directly with clearinghouse credentials

---

Existing IMN Customers (Bring Your Own Key)

If you are already submitting eligibility directly to Medical Network, you may use Bring Your Own Key.

With this model:

• Your existing IMN credentials are reused
• Existing payer and provider enrollments are preserved
• Optum configures Enhanced Eligibility to submit on your behalf

This is the preferred and fastest path for existing IMN customers.

🔑

IMN onboarding and credential management are owned by Product and Support, not developers.

---

Provider vs Channel Partner Perspective

Providers

• Typically operate under a single organizational configuration
• Submit eligibility for one health system or facility group
• May opt into Coverage Discovery or other value‑added features

Channel Partners

• Submit eligibility on behalf of multiple downstream customers or facilities
• Often require customer‑specific behavior or configuration
• Configuration differences are handled through onboarding, not separate integrations

Optum will guide channel partners through any additional configuration needed.

---

Feature Enrollment & Configuration

Enhanced Eligibility offers optional features that require explicit enrollment and configuration during onboarding.

This page explains whether a feature requires enrollment or support-side setup. It does not explain field-level runtime behavior. For feature behavior and developer impact, see Value-Added Features.

Coverage Discovery (Optional)

Coverage Discovery is an asynchronous workflow that attempts to identify coverage when standard real‑time eligibility does not return active coverage.

Coverage Discovery behavior is product‑configured and must be finalized before development begins.

For most customers, Coverage Discovery is implemented as an integrated extension of Real-Time Eligibility rather than as a separate starting point.

Direct Coverage Discovery submission is supported, but it is typically an advanced implementation pattern used only when a customer already has a processed eligibility request and response pair available.

• Direct JSON discovery requires canonical request and canonical response models
• Direct X12 discovery requires the processed x12-270 and x12-271

In practice, direct X12 discovery is often easier than direct canonical JSON discovery because it avoids custom mapping into two canonical models.

Coverage Discovery configuration can also include path-specific deduplication behavior. A customer may choose to enable deduplication for some paths and not others, such as leaving Medicaid without deduplication while enabling it for other paths.

Deduplication And Request Reuse Configuration

Deduplication is a product configuration decision because it changes whether Enhanced Eligibility submits a request to the clearinghouse or short-circuits the request by reusing a previous response.

During onboarding, customers can define:

• the request deduplication lookback window in days
• whether prior-month requests should be excluded from deduplication checks
• whether deduplication should apply to Real-Time Eligibility
• whether deduplication should apply to specific Coverage Discovery paths

This is especially relevant for customers whose upstream applications submit batch files or otherwise generate high duplicate volume.

This customer-configurable deduplication should not be confused with the fixed request caching used by RTCOB and Coverage Insight. That cache behavior is built into those paths, uses a 72-hour retention window, and is not customer-configurable.

Temporary Batch Delivery Option For POCs

As a proof-of-concept or temporary stop-gap measure, Optum can also produce a batch file that includes x12-271 responses created as a result of Real-Time Eligibility and/or Coverage Discovery processing.

This can be particularly helpful while a customer is still building:

• a polling-based asynchronous retrieval workflow
• a callback or postback solution

Without one of those delivery patterns, retrieving high volumes of results through the Transactions or Coverage Discovery list endpoints can require extensive pagination and become burdensome operationally.

When approved as part of onboarding, this batch output can be sent securely through ECG Quick Connect or directly to the customer through an agreed secure delivery path.

This option should be treated as a temporary delivery mechanism for validation and POC purposes, not as the long-term primary integration pattern.

For callback implementation and polling mechanics after enrollment is complete, see Developer Onboarding and Customer Callback Example API.

---

Medicare Coverage Discovery & MBI Sourcing

Medicare‑specific configuration is only required if:

• Coverage Discovery is enabled and
• A Medicare discovery path is configured

If enabled:

• Applicable NPIs must be registered with Optum’s third‑party Medicare data partner
• This registration enables sourcing of Medicare Beneficiary Identifiers (MBIs)
• Optum coordinates NPI registration as part of onboarding

✅ If Coverage Discovery is not enabled — or if Medicare discovery is not configured — no Medicare NPI registration is required.

---

Clearinghouse & Payer Enrollment Dependencies

For both real‑time eligibility and Coverage Discovery:

• NPIs and providers must be enrolled with IMN where required
• Some payers require enrollment prior to eligibility submission

Optum Product and Support validate enrollment requirements during onboarding.

---

What You Need From Your Side

Use this checklist to determine what must be completed before implementation begins.

---

Ownership and Responsibilities

---

Recommended Onboarding Sequence

1. Confirm IMN onboarding or Bring Your Own Key usage
2. Identify payer list and enrollment requirements
3. Decide on Coverage Discovery enrollment and scope
4. Register Medicare NPIs if Medicare discovery is enabled
5. Finalize configuration and customer‑specific behavior
6. Proceed to Developer Onboarding

---

Related Guides

• For technical prerequisites and developer-side production readiness, see Developer Onboarding
• For first API calls and starter tooling, see Getting Started
• For optional feature behavior, see Value-Added Features
• For short answers to common questions, see FAQs

➡️ Next: Developer Onboarding