REST API
DexCare provides a RESTful service for customers to access business information and perform actions against their DexCare managed environments.
For the purposes of this documentation, we will reference DexCare’s service, web sites, and configuration.
Domains
Each DexCare customer is provided with two tiers, each with a specific domain to access the APIs.
There will be a user acceptance testing (UAT) tier, and a production (PRD) tier. This document presents all URL examples with the DexCare demo tier, Acme.
Using Acme as an example health system, there would be two tiers and the would be named the following:
-
UAT: api.care-uat.dexcarehealth.com
-
PRD: api.care.dexcarehealth.com
Because Acme is a demo tier, the UAT version of Acme doesn’t exist and is presented as an example. The PRD version of Acme will be used in all examples below and can be used to try out the calls.
Your health system will be provided with the domain to use in your URLs.
Authentication
Many of the APIs provided by DexCare do not require authentication. This is particularly true of APIs that return publicly-available information about clinics, providers or other public-facing elements of the healthcare system, which is also available from directories, mapping services and so on.
However, API calls that work with personal healthcare information (PHI) or personally identifiable information (PII), require a JSON web token (JWT) for authentication, obtained through either an OAuth 2 or single sign-on (SSO) process. DexCare API calls require the JWT to be provided as a “bearer” token in the Authorization header of each protected request.
In this documentation, the calls that require a JWT in the header will be indicated with the annotation:
AUTH TOKEN REQUIRED
Generally, the process for obtaining these JWT tokens closely follows the OAuth 2 Authorization Code Grant flow. This flow helps to ensure that the patient or their authorized caregiver is aware that permission to access sensitive healthcare information is being given, that they understand the nature of the permissions being granted, and that they have an opportunity to approve or deny sharing of the data by the healthcare provider.
While DexCare does exchange PHI and PII in its role as an intermediary in the care booking process, it relies on the healthcare provider to manage this information. For that reason, the process for obtaining JWTs is specific to each healthcare system. Developers working with the APIs for care booking must consult with each individual healthcare system to obtain application keys and secrets necessary for obtaining JWT tokens to access sensitive data.
Booking APIs
The DexCare offers booking of in-clinic visits through its APIs.
Types of Booking
Two factors come into play when booking.
- provider type: provider-agnostic / provider-direct
- booking type: scheduled / on-demand
These two items define the four base booking mechanisms supported by the DexCare platform.
Provider Specific, Scheduled
This is for when the patient is booking for a specific timeslot and a specific provider.
Examples include primary care office visits and specialist office visits.
Provider Specific, On-Demand
This covers the use cases where the patient is getting in a queue to be seen as-soon-as-possible and are booking with a specific provider.
Provider Agnostic, Scheduled
Covers the use cases where the patient is booking a specific timeslot but are not booking with a specific provider.
Examples include low acuity clinics run with physicians from a pool and another would be physician’s office that support scheduled flu shots, vaccines, or COVID19 tests.
Provider Agnostic, On-Demand
Covers the use cases where the patient is getting in a queue to be seen as-soon-as-possible but are not booking with a specific provider.
Examples include DexCare’s virtual product where the patient enters the waiting room immediately upon booking.
Another example would be a patient “getting in line” or walking into an Urgent Care clinic.
Additional Use Case Support
In many of the calls to the DexCare platform you will see a product parameter.
This parameter is optional but allows DexCare to better support different use cases.
For instance, if you make timeslot calls from a Find A Doctor section you might make “product=findadoctor”.
If you were calling from a Get a Flu Shot web page you might make “product=flushot”.
Doing this allows DexCare to quickly identify which of your use cases are having issues.
API Pages
Below are links to the different functionality and uses cases supported by our API.
Provider Agnostic Time Slots API
Provider Specific Time Slots API