Booking Appointments

Once a user has selected a time slot for a retail or a provider specific appointment, there are two primary ways of booking / scheduling an appointment.

For in-person retail appointments, control of the application may be handed off to DexCare’s web user interface to complete the booking flow.

Alternatively, for in-person provider specific visits, an API call may be made to our providerbooking endpoint through which all the relevant patient, visit, and billing information can be passed.

For virtual visits, please see Creating Virtual Visits

Starting the Scheduling Flow for Retail Appointments

Once the user has selected a time slot for an in-person retail visit, you may hand off control to the DexCare scheduling application with the identifier of the selected time slot.

To do, send end users to a URL with the following structure.<slotDateTime>&departmentUrlName=<urlName>&brand=<brand>

For example, to start scheduling a retail appointment for the 3:40pm time slot at the AcmeC4 clinic

Note: The slot provided will not work if the date & time has passed. In this case, the user will be presented with a dialog to pick a new time slot.

Note that brand is a required parameter for this call.

Booking from the Care Options API

For clients working with DexCare through the Care Options API additional parameters are necessary for the booking flow.

In this case, time slots are aggregated across multiple providers

  • aggregate — a boolean flag that should be set to true for clients using the Care Options API
  • searchContext — a parameter returned by the Care Options API that allows search queries for timeslots and providers to be re-run in the case of a time slot conflict so that alternate time slot options can be shown

Note that the departmentIdentifier parameter is not necessary for this aggregate case, as it is redundant.<slotDateTime>&brand=<brand>&aggregate=true&searchContext=<yourSearchContext>

Booking with Providers through the API

Once you have selected the time slot for a specific provider, it is possible to create the booking through your own booking flow and submit all the information to DexCare’s booking endpoint.


This is a POST so the arguments are in the body. The required body structure is:

  	    "actor": {                                    <-- required
          "email": "string",
          "firstName": "string",
          "lastName": "string",
          "gender": "male",
          "dateOfBirth": "string",
          "relationshipToPatient": "string",
          "phone": "string"
       "billingInfo": {
          "paymentMethod": "creditcard",
          "declaration": "self",
          "firstName": "string",
          "lastName": "string",
          "gender": "male",
          "dateOfBirth": "string",
          "couponCode": "string",
          "insuranceType": "string",
          "insuranceProviderId": "string",
          "insuranceMemberId": "string",
          "stripeToken": "string"
	   "patient": {
          "patientGuid": "string",                  <-- required, see above
          "address": {													       
              "line1": "string",
              "line2": "string",
              "city": "string",
              "state": "string",
              "postalCode": "string"
	   "visitDetails": {                             <-- all fields required
          "declaration": "self",                    <-- "self" | "other"
          "departmentId": "string",                 <-- acquired from previously described call
          "ehrSystemName": "string",                <-- acquired from previously described call
          "nationalProviderId": "string",           <-- acquired from previously described call
          "slotId": "string",                       <-- acquired from previously described call
          "visitReason": "string",                  <-- reason entered by patient
          "visitTypeId": "string"                   <-- acquired from previously described call

When the visitDetails.declaration is “other” the “actor” structure must also be present. If visitDetails.declaration is “self” the “actor” structure is optional and any values sent will be ignored.

When the visitDetails.declaration is “other” the product operates as if a guardian is making an appointment for someone else. The guardian information is passed in using the actor structure. In this case the actor information is required.

The billingInfo data is always required. Depending on what paymentType, other fields will be required.