Value-Added Features

How To Read This Page

This page is intended for product and operational audiences.

Use this page for:

• feature purpose
• customer-facing terminology
• enrollment and configuration considerations
• support validation hints

Do not use this page for request fields, response fields, headers, callback payload structure, or other API contract details. For those topics, use Getting Started together with the API reference and downloadable OpenAPI specification. For enrollment and onboarding decisions, see Onboarding for Providers & Channel Partners.

Pre-Processing

Deduplication

Deduplication helps reduce repeated transaction costs by recognizing when a materially identical request was already submitted recently and reusing the earlier result instead of sending a new clearinghouse transaction.
This is useful when upstream systems generate repeated eligibility checks for the same encounter or patient workflow.

Configured by Optum:

• the deduplication lookback window in days
• whether prior-month requests should be excluded
• which Coverage Discovery paths should use deduplication and which should not

Operational notes:

• best for customers who want to reduce repeated payer traffic
• depends on stable request demographics and payer identity
• For implementation details, see Getting Started

Payer Aliasing

Payer Aliasing allows a customer to keep using the payer identifier already used in their source system, even when it differs from the identifier used within the Optum workflow.
This acts as a payer crosswalk, so customers can keep their existing payer IDs instead of reworking upstream payer catalogs or payer master data.

Configured by Optum:

• the mapping between a customer payer identifier and the Optum-clearinghouse payer identifier is configured outside the request payload

Operational notes:

• best for customers whose source systems cannot reliably send the IMN payer ID
• For implementation details, see Getting Started

National Provider Identifier (NPI) Management

NPI Management allows Optum to apply or override the NPI used on the outgoing eligibility transaction based on enrolled customer configuration.
This is useful when different payers or facilities need different rendering or billing NPIs, but the upstream system cannot reliably provide the correct value in every case.

Configured by Optum:

• default and override behavior can be set at different levels such as customer, payer, and facility context

Operational notes:

• Best for customers with payer- or facility-specific rendering and billing requirements
• Depends on accurate customer, payer, and facility metadata
• For implementation details, see Getting Started

Post-Processing

Below is a set of capabilities that enhance or augment the 271 response after it is received from the clearinghouse.

Payer-Response Normalization

Payer-Response Normalization converts the raw 271 response into a more consistent JSON response model for application use.

Operational notes:

• best for customers who want a more stable JSON contract than raw EDI parsing
• For implementation details, see Getting Started

Coverage Discovery

Coverage Discovery can search for additional coverage when real-time eligibility does not return the desired result.

Product notes:

• Coverage Discovery is not a single feature toggle. It is a configured set of paths, delivery patterns, and operational expectations.
• Discovery paths are not included automatically. Each path must be elected, agreed upon, and enabled as part of onboarding.
• Product teams should decide which discovery paths matter, how quickly results are needed, and whether callback consolidation is needed.

Configured by Optum:

• enrolled paths
• the customer-specific inputs and options needed for the enrolled workflow

Important enrollment note:

• Medicare, Commercial, Medicaid, HMO, Search Option Cascading, RTCOB, Coverage Insight, and consolidated callback behavior are all optional capabilities
• customers should work with Product and Support to select only the paths and add-ons needed for their workflow
• For developer implementation details, use Getting Started and Customer Callback Example API

Medicare

The Medicare path is used when a patient may have Medicare coverage that should be checked as part of discovery.
Medicare discovery may also require additional onboarding when Medicare-specific add-ons are enabled.

Configured by Optum:

• whether Medicare discovery is enabled
• whether Medicare-specific add-ons, such as MBI sourcing support, are enabled and onboarded for the customer

Operational notes:

• best for populations where Medicare eligibility is plausible based on demographics
• depends on accurate patient demographic data

HMO

The HMO path is used when the real-time response indicates that the patient may be covered through an HMO that should be queried directly.

Operational notes:

• best when the eligibility workflow indicates additional HMO follow-up may be needed
• depends on usable plan context from the eligibility workflow

Medicaid

The Medicaid path is used when the request and coverage context suggest that a Medicaid check may be appropriate.

Operational notes:

• Best for customers who need additional validation against Medicaid scenarios
• Depends on the submitted eligibility context and enrolled configuration

Commercial Payers

Commercial discovery allows Optum to check additional commercial payers that are relevant to the enrolled customer.

Configured by Optum:

• which commercial payers are included
• whether the commercial payer list varies by facility

Facility-Specific Commercial Targeting

For customers with multiple facilities, commercial discovery can be configured so that different facility NPIs target different commercial payer lists.

RTCOB Add-On*

RTCOB is an optional add-on under Commercial Payers for broader commercial coverage research through a connected data-lake-style workflow.

Configured by Optum:

• RTCOB must be specifically elected, agreed upon, enabled, and onboarded for the customer
• RTCOB requires separate onboarding and activation

Operational notes:

• best for customers who want to uncover additional active coverage to support stronger upfront financial clearance
• Optum handles setup and configuration, and customers receive results through the same discovery workflow
• For implementation details, see Getting Started

Search Option Cascading

Search Option Cascading is designed to improve coverage search performance for customers that need broader discovery support.

Operational notes:

• best for customers whose traffic frequently returns unresolved eligibility outcomes

Coverage Insight

Coverage Insight is an optional discovery path for broader insurance verification. It can improve discovery reach, but it may take materially longer than other near-real-time paths.
Coverage Insight is an add-on capability. It is not included automatically with Coverage Discovery and should be elected only when the use case justifies the added workflow.

Operational Requirements

Coverage Insight works best when the customer can provide strong patient identity and encounter data consistently from the source workflow.

The original real-time eligibility request should include the strongest available patient and encounter data. This typically includes:

• patient account number when available
• patient first name
• patient last name
• date of birth
• either SSN or address information

Previously Processed Encounter

If an encounter was previously processed and identified by the patient account number, the request may be ignored by Coverage Insight.

For more information about Coverage Insight, take a look at the following documentation: https://business.optum.com/en/operations-technology/revenue-cycle-management/patient-access/coverage-insight.html

Configured by Optum:

• whether Coverage Insight is enrolled
• any customer-specific scope applied during onboarding
• Coverage Insight must be specifically elected, agreed upon, enabled, and onboarded for the customer
• Coverage Insight requires separate onboarding and activation

Operational notes:

• best for customers who can provide strong patient identity data and tolerate delayed completion
• Product teams should confirm that patient account numbers are unique and that minimum demographic completeness is achievable in the source workflow
• For request-field and response-behavior details, see Getting Started

Consolidated Callback Response for Coverage Discovery Customers

Organizations enrolled in Coverage Discovery now have the option to enable a consolidated response model via their callback API.

What Is the Consolidated Response?

When this option is enabled, the Real-Time Eligibility (RTE) response is embedded directly within the Coverage Discovery response record. This allows your system to receive both eligibility and coverage information in a single, unified callback payload.

Key Benefits

• Simplifies integration by reducing the number of separate API responses
• Provides a complete view of member eligibility and coverage in one response
• Streamlines downstream processing and data handling

In this model, your callback consumer can process both the Coverage Discovery task result and the abbreviated real-time eligibility result from a single payload rather than joining data from multiple response channels.

This option is useful when the downstream workflow prefers one asynchronous payload over separate real-time and discovery responses.

For callback payload structure and field interpretation, use Customer Callback Example API.

↪️

Looking for the homepage? Return to Enhanced Eligibility Overview here.

For enrollment and configuration decisions, go to Onboarding for Providers & Channel Partners.
For runtime implementation, go to Getting Started.