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 connectivity
• 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 supports Optum-managed payer connectivity across multiple access paths.

From a customer perspective:

• You submit eligibility transactions to Enhanced Eligibility
• Optum manages the underlying delivery model
• The API contract remains the same regardless of the underlying connectivity used

Medical Network (IMN) – Default & Required

IMN onboarding is currently required for all Enhanced Eligibility customers.

• IMN is the required onboarding and 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.

---

Additional Managed Connectivity

In some scenarios, Optum may also enable additional managed connectivity paths to expand payer coverage beyond the standard IMN onboarding path.

These scenarios can require additional onboarding and configuration, and Optum will advise customers when that applies.

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

✅

Customers always submit to Enhanced Eligibility

✅ IMN onboarding is still required
✅ Additional managed connectivity may be enabled when needed
✅ No separate customer integration is required for those options

---

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

---

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 descriptions and enrollment context, see Value-Added Features. For API-visible runtime behavior, see Getting Started.

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.

• Direct JSON discovery uses canonical eligibility models
• Direct X12 discovery requires the processed x12-270 and x12-271

Coverage Discovery configuration can also include feature-specific reuse settings based on customer needs.

Deduplication Configuration

Deduplication is a product configuration decision because it affects when prior results may be reused.

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.

Some add-on features also include platform-managed reuse behavior that is separate from customer-configured deduplication.

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 QuickConnect 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

This is an optional add-on. It is not included automatically with Coverage Discovery and is only required when the customer elects Medicare discovery and the related Medicare onboarding support.

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 through the Optum-managed Medicare onboarding process
• 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.

RTCOB And Coverage Insight Add-Ons

RTCOB and Coverage Insight are optional add-on discovery paths. They are not included automatically with Coverage Discovery.

If elected by the customer:

• each add-on must be agreed upon, enabled, and onboarded separately
• Optum manages those add-on connections on the customer's behalf
• customers do not build separate direct integrations to those services through this API

---

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 descriptions and enrollment context, see Value-Added Features
• For short answers to common questions, see FAQs

➡️ Next: Developer Onboarding