Authorization (Orchestration) Prior Authorization

Prior Authorization (Orchestration) service API accepts an authorization inquiry request in the form of EDI-X12 278x215 or JSON payload, perform an authorization determination request and, based on the response, perform an authorization inquiry. The Authorization Orchestration allows you to work in conjunction to simplify the workflow.

📘

NOTE

The test transactions require rhPayerID = UHCDEMODV1, the same member ID details noted in the Inquiry Test response page will be relevant (i.e., TST1). The cpt/procedure code is also required for meaningful results.

• Get authentication/bearer token

https://sandbox-apigw.optum.com/apip/auth/v2/token

📘

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.

• Check API health

https://sandbox-apigw.optum.com/rcm/prior-authorization/v1/healthcheck

• A standard X12 EDI 278 transaction request

Formats the 278 transaction in JSON format for an authorization request. Accepts JSON with a single string 'x12' property that has a 278 EDI string and produces a JSON response with a single 'x12' property that has a 215 EDI string.

https://sandbox-apigw.optum.com/rcm/prior-authorization/v1/authorization/x12

• A JSON Inquiry request to the payer or clearinghouse

Accepts an EDI JSON object model request and produces a JSON object model response.

https://sandbox-apigw.optum.com/rcm/prior-authorization/v1/authorization

Sandbox URL

https://sandbox-apigw.optum.com/rcm/prior-authorization/v1

Production URL

https://apigw.optum.com/rcm/prior-authorization/v1

📘

NOTE

The system will automatically perform rechecks every 12 hours for anything that is not a deterministic status (e.g., it will retry those in pended state) and within 90 days of the date-of-service; as the date-of-service approaches, the frequency increases. Rechecks stop at date-of-service or when a determistic status (i.e., approved or denied) is established. The frequency increases are:

• When within 72 hours (3 days) of date-of-service, a recheck is performed every 3 hours
• When a result of payerUnavailable is seen, it will recheck again in 5 minutes, up to 5 times within an hour; after which, it will wait until the next normal recheck period
• When configured, results from rechecks will be returned asynchronously to the configured end-point

• JSON-to-EDI API Contents