Product Overview

Enhanced Eligibility is a RESTful interface to submit enhanced 270 transactions and receive enhanced 271 transaction responses that improve response quality and accuracy. All endpoints have well-structured JSON definitions and use standard HTTP verbs, headers, and response codes.

Core Resources


A transaction is an individual Eligibility 270 request and its associated 271 response. This is our primary resource. You can submit new transaction requests and query previous transaction responses.

When submitting a new request to our processing engine, your customer configuration will drive the "enhancement", or augmentation, of your requests and responses.

See "Customer Configurations" and Value-Added Features" for more information.

Coverage discovery

(This is an opt-in feature; you must be enrolled in order to use these endpoints)

Coverage discovery is an automated process to submit eligibility requests on your behalf.

If enabled, coverage discovery will use automation to determine likely coverage candidates by evaluating request data against a proprietary Rules Engine. This only occurs if the transaction response returned from a submission result is ineligible or unknown coverage.

Stand-alone coverage discovery is available in cases where no coverage information can be found for the patient prior to submission. This capability provides discovery automation immediately rather than as a step in eligibility transaction processing.

See "Value-Added Features" for more information.

Payer Aliases

This resource provides CRUD operations for managing customer specific PayerID mappings. Each mapping associates a Customer PayerID to an Optum (formerly, Change Healthcare) PayerID. Each mapping can define a date range that the Payer Alias will remain effective. This provides the ability to prepare new mappings before they are used by the system.

See "Value-Added Features" for more information.

National Provider Identifier (NPI) Management

This resource provides CRUD operations for managing customer-specific NPI mappings. A mapping can associate an NPI value to a PayerID, FacilityID, and/or a PayerID + FacilityID. In the event you are enrolled in Payer Alias, the PayerID is the Optum PayerID, otherwise it is the Customer PayerID.

During transaction processing, a hierarchical order is used to determine which mapping to use. Furthermore, each mapping can define a date range that the mapping will remain effective. This provides the ability to prepare new mappings before they are used by the system.

See "Value-Added Features" for more information.

Value-Added Features


Below are a set of capabilities that enhance or augment the 270 request process prior to sending it to the clearinghouse.


Before dispatching your 270 transaction to the clearinghouse, this capability saves your organization transaction costs by querying past transactions you have submitted and returning their response. A transaction is considered duplicate when key fields in the request have been previously submitted by the same customer to the same payer. The window of time for querying duplicate requests is within your control. We call this the "lookback" period.

If a duplicate transaction request is found, your new request will short-circuit the transaction workflow. The response returned will be an enhanced 271 response associated to the matching duplicate request.

Payer Aliasing

The PayerID derived from an EHR (Electronic Health Record) or HIS (Health Information System) is the Payer naming convention that your organization uses to refer to that Payer. In most cases, it does not match the clearinghouse identifier for that Payer. Payer Aliasing provides a mapping to from EMR/HIS PayerID to an Optum (formerly, Change Healthcare) PayerID so that you can continue submitting the ID as it relates to your system.

National Provider Identifier (NPI) Management

This feature provides the ability to automatically apply NPIs to your outgoing transaction request based on the information you provide in your request. You can define a default value for every transaction or more granular values based on the combination of Payer and Facility.

The mappings you choose to define are evaluated in a hierarchical order. Based on that order, the system will select the most specific mapping to use during transaction processing. In priority order, the hierarchy is as follows:

  1. Request matches on Customer, Payer, and Facility
  2. Request matches on Customer and Facility
  3. Request matches on Customer and Payer
  4. Request matches on Customer
  5. Fallback to supplied NPI value in the original request

If you want to prioritize the NPI value in the original request above any defined mappings, reach out to the Enhanced Eligibility team to set up this functionality.


Below are a set of capabilities that enhance or augment the 271 response after to receiving a response from the clearinghouse.

Payer-Response Normalization

After clearinghouse processing, the Enhanced Eligibility API molds the 271 response into a developer-friendly JSON-based response by normalizing EDI segments into a named benefit field using Optum’s database of normalization rules.

Coverage Discovery

Below are a set of discovery "paths" that facilitate automated discovery of patient coverage when the conditions are met.


The Medicare path evaluates demographic data to inform a patient's candidacy for Medicare discovery.


HMO discovery evaluates the 271 response for data that indicates enrollment with an HMO. The Enhanced Eligibility API will submit a transaction with the HMO payer to see if the patient is eligible.


The Medicaid path evaluates provided insurance coverage to inform a patient's candidacy for Medicaid discovery.

Commercial Payers

Optum works with the Customer to determine an appropriate list of commercial discovery Payers based on historical transaction volume and provider data.

Coverage Insight

Coverage Insight uses analytics-driven insurance verification software that integrates advanced discovery into this workflow. You can expect that this path to take about 24 to 72 hours to determine coverage.

For more information about Coverage Insight, see this documentation.

Data Tenancy

Enhanced Eligibility is a multi-tenant solution, but you will only ever have access to your data. Every request requires the presence of an HTTP header called x-chng-tenant-id that specifies the ID of the tenant associated with your authentication token. This header is automatically applied on your behalf to enforce secure access to your data. If you provide this header yourself, it will automatically be stripped during authentication.

If you receive a 403 Forbidden: "invalid tenant id", please reach out to Optum, as it indicates a misconfiguration during onboarding.


This section describes how pagination is implemented across the API. More information is coming soon!

Getting Started

See the Security section on the developer portal to learn more about securely using our APIs. Most of our APIs are private and require credentials to gain access.

Release NotesFAQ
View the API Release Notes for information about the API.Check out our FAQ for help with specific questions about this API.