Onboarding with Prior Authorization API

Feature Enrollment

Work with the Enhanced Eligibility Support Team to enroll in the Value-Added Features that best aligns with your business needs. For more information on the available pre/post-Clearinghouse processing rules, please see the Value-Added Features section.

Authentication with Client Credentials

Authentication for the API utilizes OAuth Client Credentials flow. Please supply the onboarding team with an email to attach to your credentials. We can support user-based credentials or system-based credentials, where user-based refers to each discrete Developer or API Consumer has their own unique credentials, and system-based refers to a single set of credentials used by your Applications. Once credentials are created, they will be delivered via Secure email to the provided email address. See Prior Authorization security and authorization section below. For information about Enhanced Eligibility API and next steps, see Getting Started.

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-optum-tenant-id that specifies the ID of the tenant associated with your authentication token. This header is automatically applied via your unique credentials to enforce secure access to your data. If you provide this header yourself, it will automatically be stripped during authentication.

Existing Medical Network Customers

If you are an existing customer of the Medical Network Eligibility API, then you can opt-into our "Bring Your Own Key" feature. With this feature, Enhanced Eligibility will submit transactions to Medical Network using your existing credentials. By submitting with your credentials, you maintain your existing Provider enrollments and billing. Please work with the Enhanced Eligibility Support Team to configure this 'Bring Your Own Key' feature.

Eligibility Payer List

For the current payer list supported by Medical Network, please download the list supplied in the IMN Real-Time Eligibility. Use this document to find the "IMN Payer ID" to submit as the tradingPartnerServiceId on the Eligibility Request. If the specific payer requires enrollment, please submit a support request to begin the enrollment process as mentioned above. To verify if enrollment is required, refer to "Enrollment Req'd" column.

If you are unable to send the "IMN Payer ID", please enroll in the Value-Added Feature "Payer Alias".

Prior Authorization Security and Authorization

Security through TLS

All APIs calls are encrypted over HTTPS. Our APIs support connections using Transport Layer Security (TLS) version 1.2 or later.

Bearer token through OAuth2

Optum uses OAuth2 to create a secure connection with our API users, which requires a bearer authorization token to obtain access.

📘

BEARER TOKEN LIFESPAN

The lifespan of a Bearer token is one hour (3600 seconds) for both sandbox and production environments.

We recommend automating transactions to use the tokens generated over the token lifespan. Obtaining tokens for each transaction is less efficient and does not improve the security criteria for any transactions.

Callback Requirements for Coverage Discovery

Customer's Callback API

Due to the long-running nature of the Coverage Discovery process, all concluded task responses will be communicated asynchronously back to the customer through a provided callback URL. If enrolled in Coverage Discovery, a Callback API with an OAuth2 authentication endpoint must be built in order to receive task responses. For the expected request body, check out the "Callbacks" tab next to "Parameters" in the Coverage Discovery POST endpoint (download OpenAPI spec from the Overview Page).

In addition, the Customer Callback Example API (link) provides sample responses that will be sent back from Coverage Discovery.

Whitelisting

Both the OAuth2 token endpoint and the callback endpoint must be whitelisted by Optum in order for Coverage Discovery to securely send responses to the Customer's provided callbackUrl. A Firewall Rule must be configured for the Customer's domains which is a process with a 2-week SLA. We recommend wildcard whitelisting for domains (for example: \*.api.providercompany.com)

APIs components

OAuth - Authentication with Client Credentials

A “token” endpoint must be provided that conforms to the OAuth2 specification. This endpoint should return an “Access Token” that Enhanced Eligibility can use to sign our Callback requests (ref). In addition, the token endpoint must use the Client Credentials grant_type (ref). Finally, the auth token URL must be within your pre-existing whitelisted domain from the step above. If not, then a new Firewall Rule must be configured that will come with a 2-week SLA.

API credentials

1. Your API credentials include the following information in an API request.

📘

NOTE

You should have two sets of credentials:

• One for the sandbox — to help you test our APIs before signing a contract
• One for production — provided after signing a contract or after processing a subscription

These credentials are specific and unique to an API environment and to your company.

📘

NOTE

Optum strongly recommends that you carefully guard your API access credentials. Avoid sharing them with others.

After receiving your client_id and client_secret for the sandbox environment, you can try or test our APIs by using one of these options:

• (Preferred method) A third-party application, such as a Postman tool/platform or any tool of your choice
• Our Try our APIs interactive view
• Your own development console

3. Generate a bearer token by using your sandbox credentials.

Reference

• Prior Authorization V1 Getting Started
• Enhanced Eligibility API Guides
• Enhanced Eligibility API Reference