Security and Authorization V3

Security and authorization v3

This documentation describe how to use the platform's standard security API to request an access token that can be used to access other APIs on the platform. A downloadable OpenAPI specification is available as a reference to this implementation.

Access control via web tokens

All Optum APIs on this platform are secured using JSON Web Tokens (JWT).

Security via TLS

All calls to Optum APIs are encrypted over HTTPS. Our APIs support connections using TLS version 1.2 or higher.

Authorization via OAuth2

Access to Optum APIs is controlled via OAuth2 using the client credentials grant. This is a secure authorization workflow that allows consumers to obtain a short-lived (two hours) access token that must be transmitted with subsequent API requests.

To obtain a token, consumers first need a client_id and client_secret. These credentials are provided during the customer onboarding process. To request access credentials, use either the Request Sandbox Access link or the Contact Us link to contact the Product Manager of a specific API.

API environments

Please see.

Create a sandbox account

Please see.

Generate a bearer token

Please see.

Obtaining an Access Token

This section describes how to get an access token in a particular environment.

Test API through security and authorization token

  1. Use token generated using client ID and secret key for sandbox or production.
  2. Download API specs from overview page - every API overview section provides links to download the file in a JSON format, which generates our documentation for developers to use.
  3. Hit API endpoint through the following options:
    -Use [Try It] page to request complete API response or customize response for
    Sandbox API endpoint only.

OR
-Use Postman to request complete API response or customize response for Sandbox and
Production API endpoint.

NOTE: Do not submit PHI or PII data in the [Try It] page.

Sandbox use for mock data testing

  1. The customer will retain the ability to query mock responses from a sandbox environment by using an optional request header called “environment”. By placing the value “sandbox" in the optional header, the request return mock responses.
    NOTE: Do not submit PHI or PII data in the TRY IT page.

End-to-End API invoking Workflow Pointers

  • Capability APIs give details like:
    - “what this system can do” before even start using it
    - Which APIs are available
    - What actions you can perform (submit, check status, attach docs, etc.)
    -What formats and rules are supported
  • DTR Capability API tells your system what form-related features (questions, flows, formats) are supported before you start using DTR APIs.
  • PAS Capability API shows how you can use PAS APIs and what features are supported before you start submitting requests.
  • Operation Definition API explains how a specific API (PAS/DTR ) works — what input to send and what response to expect.
    NOTE: Input to Operation Definition API comes from the response of PAS/DTR Capability APIs.
  • Discovery API tells what checks and recommendations are available for CRD request.

CRD → checks if approval is needed → DTR → collects required info via forms → PAS → submits request for decision → CDEX → sends any additional documents if needed.


Provider subscribes to Prior Auth API on AI marketplace: Provider receives client ID and secret. Use the client ID and secret for Token generation which then must be used to invoke all API endpoints Prior Auth API bundle includes listed below.

Base URLs and Path Params

Integration workflow table for UHC Payer

StepModuleAPIEnpoint
precase searchcase searchbaseURL/fhirpa/R4/{PayerID}/{LOB}/Claim/$inquire
1CRDGet Available CDS Services (FHIR)baseURL/cdsHooksServer/{PayerID}/{LOB}/api/cds-services
2CRDCoverage Requirement Discovery (FHIR)baseURL /cdsHooksServer/{PayerID}/{LOB}/api/cds-services/{service.id}
3DTRDTR Capability Statement (FHIR) OptionalbaseURL/fhirpa/R4/{PayerID}/{LOB}/dtr/metadata
3a/7aDTROperation Definition for Capability Statement (FHIR)OptionalbaseURL//fhirpa/R4/{PayerID}/{LOB}/operation-definition/claim-submit
4DTRGet Questionnaire Package (FHIR)baseURL/fhirpa/R4/{PayerID}/{LOB}/Questionnaire/$questionnaire-package
5DTRGet Next Question (FHIR)- Optional (For UHC Payer Only)baseURL/fhirpa/R4/{PayerID}/{LOB}/Questionnaire/$next-question
6DTRGet Document Reference (FHIR) - OptionalbaseURL/fhirpa/R4/{PayerID}/{LOB}/document-reference
7PASPAS Capability Statement (FHIR)OptionalbaseURL/fhirpa/R4/{PayerID}/{LOB}/pas/metadata
7a/3aPASOperation Definition for Capability Submit (FHIR) OptionalbaseURL/fhirpa/R4/{PayerID}/{LOB}/operation-definition/claim-submit
8PASSubmit Case (PAS)baseURL/fhirpa/R4/{PayerID}/{LOB}/Claim/$submit
9PASSubmit Attachment (CDEx)baseURL/fhirpa/R4/{PayerID}/{LOB}/Claim/$submit
postcase searchcase searchbaseURL/fhirpa/R4/{PayerID}/{LOB}/Claim/$inquire

Integration workflow table for NON UHC Payer

StepModuleAPIEnpoint
TBD*********

API Endpoint

Notes:
DO NOT perform load testing or production data testing in the sandbox environment. Please use the sandbox ONLY to view sample API responses to HTTP requests using our predefined values and to familiarize yourself with our APIs.

To perform load testing and production data testing, we recommend using our APIs in the production environment.

API health check

The health check endpoint checks the operating status of our API. It is a ping for the API entry point to ensure the entry points are accessible. This is the first thing you can do if something goes wrong.

  • To run the health check of an Optum Real API - the Real Pre Service Eligibility API, go to
    Healthcheck If the API engine is working correctly and if the entry points are accessible, the API operating status response shows "OK."

NOTE If you receive a response other than 200 OK, the health check failed.
Please submit a service ticket with Optum.


Did this page help you?