LIBERTY Dental Plan
Interoperability and Patient Access API


LIBERTY Dental Plan's Interoperability APIs are developer-friendly, standards-based APIs that enable third party application vendors to connect their application programs to access LIBERTY Dental Plan's data .

  • The Patient Access API will allow developers to retrieve, with the approval and at the direction of an applicable member or the members personal representative, certain data, as applicable, concerning adjudicated claims, if LIBERTY Dental Plan maintains any such data.
  • The Provider Directory API will allow developers to retrieve, as applicable, certain provider and directory information.
Overview:
LIBERTY Dental's interoperability APIs enable members to consent to have their data shared with third-party applications. It also allows third-party application owners to connect to provider directories, further referred to as “public non-member specific data.” LIBERTY's Interoperability APIs provide the functionality listed below:
Steps needed before you can get access to the Production Environment
Authorization:
To use the interoperability APIs a developer must register their application. An organization must register as a user by completing the registration application through the Developers Application below. A registered application is given a client ID and a client secret. The secret should only be used if it can be kept confidential, such as communication between your server and the interoperability APIs. For insecure implementations, such as mobile apps, PKCE (Proof Key for Code Exchange) is available. LIBERTY Dental Plan also supports non-authenticated public directory endpoints such as Provider Directory and Medication Directory (We do not have Medication Data for our members). Please see core resources documentation section in HL7 for further details.
API permissions and scopes:
Access tokens have scopes, which define permissions and the resources that the token can access. Scopes are primarily utilized to determine the type of data an application is requesting. Scopes must be explicitly declared; wildcards are not supported. In the current release the following scopes are available for the following types of requests:
Note: Any scope not currently listed is not supported.

Patient access:

  • patient/Condition.read
  • patient/Coverage.read
  • patient/Encounter.read
  • patient/ExplanationOfBenefit.read
  • patient/Claims.read.
  • patient/Immunization.read
  • patient/MedicationDispense.read
  • patient/MedicationRequest.read
  • patient/Observation.read
  • patient/Patient.read
  • patient/Procedure.read

Public access

Provider Directory:

  • public/Organization.read
  • public/OrganizationAffiliation.read
  • public/Practitioner.read
  • public/PractitionerRole.read
  • public/Network.read
  • public/Location.read

This gives access to the correct FHIR Endpoints. Our OAuth2 authentication screen requires members consent to share different types of data. Your application will need to handle the return of a HTTP status codes from the endpoints if there are authentication or configuration failures. If the member declines to share information that your application needs, you may display a message explaining why that information is needed and request re-authorization or handle the collection of that information elsewhere within your application. The default selection will be to share the scopes included in the initial request with your application. If a member declines a scope but later decides they want to change that selection, they’ll need to re-authenticate and make a different choice from the OAuth2 screen. It is important to explain to members why you need certain data. If information limited by a scope is required for your application to properly function and it is not possible to get the information in another endpoint, we recommend providing an explanation about why certain data is needed in your user flow. For example, if you use demographic information to help members autofill tedious data-entry, you might want to explain that benefit before they reach the authorization screen. It is essential, however, that you give members the full picture. If they do share data with your application, they should know how long you keep it and if it is used for any other purposes.

Developers Access Process:

  • Please complete the form below
  • A questionnaire will be sent to the email provided, fill it out completely and email it back to the email that you received
  • We will review your questionnaire and provide you with Test Credentials
  • When you are done completing your testing in Sandbox Environment, we will provide Production Credentials

Please populate the below form to start the Developer's Access to the APIs:



FHIR API Developer Resources: