Value-Added Features
Pre-Processing
Below are a set of capabilities that enhance or augment the 270 request process prior to sending it to the clearinghouse.
Deduplication
Before dispatching your 270 transaction to the clearinghouse, this capability saves your organization transaction costs by querying past transactions you've submitted and returning their response. A transaction is considered a 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 Payer ID derived from an Electronic Health Record (EHR) or Health Information System (HIS) 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 Payer ID to an Optum Payer ID 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:
- Request matches on Customer, Payer, and Facility
- Request matches on Customer and Facility
- Request matches on Customer and Payer
- Request matches on Customer
- Fallback to supplied NPI value in the original request
Post-Processing
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.
Medicare
The Medicare path evaluates demographic data to inform a patient's candidacy for Medicare discovery.
HMO
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.
Medicaid
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.
Search Option Cascading
Some payers have strict requirements for patient demographic information to match the patient to their records. Each payer publishes the specific field combinations they support that will yield a positive eligibility interaction. If a submitter (API sender) includes additional fields that the payer does not expect, it can result in a false response, such as "Patient Unknown."
The goal of Search Option "Cascading" is to store all the payer-specific combinations and iterate through them one at a time, in priority order. This process involves submitting new eligibility transactions with the minimal required data points until an eligible or ineligible response is received, or all combinations have been exhausted.
Benefits of Search Option Cascading
Increased Accuracy and Improved Success Rates
By submitting eligibility transactions with only the required data points and using payer-specific combinations, the chances of receiving accurate responses from payers are higher. This reduces the likelihood of false "Patient Unknown" responses and increases the likelihood of matching patient records correctly.
Efficiency and Reduced Manual Effort
Cascading allows for a systematic approach to eligibility checks, prioritizing the most likely successful combinations first. This saves time and resources by avoiding unnecessary data submissions and reduces the need for manual adjustments and interventions, streamlining the workflow for submitters.
Flexibility
The system can adapt to different payer requirements without manual intervention. It automatically tries different combinations until a valid response is received or all options are exhausted.
Coverage Insight
Coverage Insight uses analytics-driven insurance verification software that integrates advanced discovery into this workflow. You can expect that this path will take between 24-72 hours to determine coverage.
Minimum Required Data
In order to successfully send requests to Coverage insight, the required fields below must be present on the incoming request. If any of the below requirements are missing, the transaction will be ignored.
- Patient Account Number
- Patient's First Name
- Patient's Last Name
- Date of Birth
- SSN or Address
Previously Processed Encounter
If an encounter was previously processed (identified by the Patient Account Number), the request will be ignored by Coverage Insight. A new Patient Account Number (PAN) must be submitted on the request in order to have the transaction processed.
For more information about Coverage Insight, take a look at the following documentation: https://www.changehealthcare.com/revenue-cycle-management/financial-clearance/coverage-insight
Looking for the homepage? Return to Enhanced Eligibility Overview here.
Updated 4 days ago