Please note that this is preliminary documentation and is subject to change.

This is the reference documentation for version 4 of the InQuicker Platform API. You can use our API to enable patient scheduling in your business or application.

The InQuicker Platform API follows the JSON:API Specification. See their site to get started with JSON:API, and with client libraries to help build your custom solution.

Endpoints are described with an HTTP method and a path. For example:

GET /providers

Prepend your InQuicker Platform API URL to the path to get the full endpoint URL. For example, if your API URL is https://api.inquicker.com/api/v4/winter.inquicker.com, then the full URL to get a list of providers would be:

https://api.inquicker.com/api/v4/winter.inquicker.com/providers

Curly braces {} in the endpoint path represent path parameters that you must replace. For example, if the endpoint is described as:

GET /locations/{location_id}

with a location id of 1, the final request URL would be:

https://api.inquicker.com/api/v4/winter.inquicker.com/locations/1

The v4 API endpoint URL is

https://{api_hostname}/api/v4/{partner_hostname}

where:

api_hostname

api.inquicker.com for production, api.inquickerstaging.com for staging

partner_hostname

your client-facing domain name, eg. my-site.inquicker.com.

Request headers

• When developing your own integrations, be sure to set your User-Agent header to something informative, eg. MyClient/1.0.0.
• Always set the Accept header to application/vnd.api+json.

Side-Loading Related Data

The JSON:API specification allows for side-loading associated records using the include parameter. For example, the /locations/{location_id} endpoint can include related schedules. The response payload follows the specification, but is typically de-serialized by a client library. Please note that filter parameters do not apply to side-loaded resources.

InQuicker requires a JWT to authorize access to all endpoints except for /token. To use the token endpoint, InQuicker requires the API key to be included in the Authorization header:

Authorization: this-is-your-api-key

This JWT token is used to access all other endpoints.

The first example will show how to fetch the data required to display a typical Provider index page. We will be fetching Services, Appointment Types, and Insurance Plans so that they can be displayed as options for the user to filter the provider list. We are assuming that the provider list filtering will be handled by the front-end via JavaScript.

In access the API, we first have to obtain a JSON Web Token (JWT). This is done by the application server, and the JWT is forwarded to the web client This call gives us the raw JWT data that we use in the Authorization: Bearer header to create the visit. The token is valid for 30 minutes, and can only be used to create a visit for the time slot specified in the token request.

curl "https://api.inquicker.com/v4/winter.inquicker.com/token" -G -H "ACCEPT: *.*" --data-urlencode 'api_key=your-api-key'

The response is the raw JWT, eg.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJkYXRhIjp7InNjaGVkdWxlX2lkIjoiZjNjN2QwNDQtM2UyMy00YzcwLThlOTktYTUwNGExOWYyODc0IiwiYXBwb2ludG1lbnRfYXQiOiJcIjIwMTktMTAtMDNUMTQ6MTU6MDAtMDU6MDBcIiJ9LCJleHAiOjE1NzAxMTc4NDMsImp0aSI6IjcxYTg0YWQwLWMyOWYtNDNmYi1iZTVjLTJlZGUyNzBhZDQ3ZCJ9.MESqdi2QeQwcmab--ZAvRTRCMASiHtt51LLR7VfHm1M

For the rest of these examples, we will use jwt-value instead of the full JWT for brevity.

To fetch a full list of Services, we use the GET /services endpoint. Using Curl, the command is:

curl https://api.inquicker.com/api/v4/winter.inquicker.com/services -H "ACCEPT: application/vnd.api+json" -H 'Authorization: Bearer jwt-value'

This returns a Service Collection Response that looks like this:

  {
    "data": [{
      "id": "101",
      "type": "services",
      "links": {
        "self": "https://api.inquicker.com/v4/winter.inquicker.com/services/101"
      },
      "attributes": {
      "name": "Primary Care"
    }, {
      "id": "102",
      "type": "services",
      "links": {
        "self": "https://api.inquicker.com/v4/winter.inquicker.com/services/102"
      },
      "attributes": {
        "name": "Pediatrics"
      }
    }],
    "meta": {
      "record-count": 2
    }
  }

If you are used to using JSON::API services, this should look familiar, as it is a typical JSON::API response. If you are not familiar with this response structure, refer to the JSON::API specification to get a better understanding of the structure of this response.

In a similar fashion to how we fetched the service list, we will be fetching Appointment Types and Insurance Plans using the GET /appointent-types and GET /insurance-plans endpoints. This provides all the data we need to display options for the user to filter the provider list.

Fetch Providers with pagination and side-loading

To get the list of Providers, we will need to add some parameters to the query to add pagination and to side-load schedules and locations:

curl https://api.inquicker.com/v4/winter.inquicker.com/providers -H "ACCEPT: application/vnd.api+json" -H 'Authorization: Bearer jwt-value' --data-urlencode 'include=locations,schedules.location' --data-urlencode 'page[number]=1' --data-urlencode 'page[size]=10'

The response is a Provider Collection Response. The side-loaded data is included in the Relationships part of each Provider record as per the JSON::API standard. Here is a snippet of a typical response:

  {
    "data": [{
      "id": "1",
      "type": "providers",
      "links": {
        "self": "https://api.inquicker.com/v4/winter.inquicker.com/providers/1"
      },
      "attributes": {
        "affiliation": "employed",
        "appointment-types": [{
          "id": "1",
          "name": "Office Visit"
        }, {
          "id": "2",
          "name": "New Patient"
        }, {
          "id": "3",
          "name": "Physical"
        }],
        "backgrounds": [{"name": "Language Spoken"
     "description": "English"}],
        "bio": "",
        "card-image": "https://winter.inquicker.com/profile/practitioner/iqp_card_16479.jpg",
        "credentials": null,
        "gender": "f",
        "grad-school": null,
        "medical-groups": [],
        "name": "Emily Cormier",
        "profile-image": "https://winter.inquicker.com/profile/practitioner/iqp_profile_16479.jpg",
        "provider-type": "Practitioner",
        "subspecialties": [],
        "suffix": "MD",
        "ui-profile-image": "https://winter.inquicker.com/profile/practitioner/original_16479.jpg",
        "undergrad-school": null,
        "NPI": null
        },
      "relationships": {
        "locations": {
          "links": {
            "self": "https://api.inquicker.com/v4/winter.inquicker.com/providers/1/relationships/locations",
            "related": "https://api.inquicker.com/v4/winter.inquicker.com/providers/1/locations"
          },
          "data": [{
            "type": "locations",
            "id": "1"
          }]
        },
        "schedules": {
          "links": {
            "self": "https://api.inquicker.com/v4/winter.inquicker.com/providers/1/relationships/schedules",
            "related": "https://api.inquicker.com/v4/winter.inquicker.com/providers/1/schedules"
          },
          "data": [{
            "type": "schedules",
            "id": "1"
          }]
        }
      }
    }, {
      "id": "2",
      "type": "providers",

  ...

We use the GET /available-appointment-times, passing the schedule ids in the shedule_ids parameter, and the appointment type in the appointment-type parameter.

curl "https://api.inquicker.com/v4/winter.inquicker.com/available-appointment-times" -G -H "ACCEPT: application/vnd.api+json" -H 'Authorization: Bearer jwt-value' --data-urlencode 'schedule_ids[]=1' --data-urlencode 'appointment_type=annual-physical'

This returns an Available Appointment Times Collection like this:

  [{
    "schedule-id": "1",
    "appointment-type": "annual-physical",
    "times": ["2019-09-21T13:00:00-04:00", "2019-09-21T13:15:00-04:00", "2019-09-21T13:30:00-04:00", "2019-09-21T13:45:00-04:00", "2019-09-21T14:00:00-04:00", "2019-09-21T14:15:00-04:00", "2019-09-21T14:30:00-04:00", "2019-09-21T14:45:00-04:00", "2019-09-21T15:00:00-04:00", "2019-09-21T15:15:00-04:00", "2019-09-21T15:30:00-04:00", "2019-09-21T15:45:00-04:00", "2019-09-21T16:00:00-04:00", "2019-09-21T16:15:00-04:00", "2019-09-21T16:30:00-04:00", "2019-09-21T16:45:00-04:00"]
  }]

We create the visit with the POST /visits endpoint. The form data includes all required fields as described in the POST /visits endpoint documentation.

 curl 'https://api.inquicker.com/v4/winter.inquicker.com/visits' -H 'Accept: application/vnd.api+json' -H 'Authorization: Bearer jwt-value' -H 'Content-Type: application/vnd.api+json' --data-binary $'{"data":{"attributes":{"address":null,"address-2":null,"appointment-at":"2019-09-21T13:00:00-04:00","appointment-type":"annual-physical","birthdate":"1980-01-12T05:00:00.000Z","caregiver-name":null,"city":null,"comments":null,"email":"test@example.com","first-name":"John","gender":"male","has-physician":false,"is-self-pay":false,"insurance-group-number":null,"insurance-member-number":null,"insurance-plan-full-address":null,"insurance-plan-name":null,"insurance-plan-permalink":"1199-ppo","insurance-plan-phone-number":null,"last-name":"Doe","last-test-date":null,"last-test-location":null,"middle-initial":null,"new-patient":"false","optin":"0","patient-complaint":"gas","phone-number":"1231231231","pregnant":null,"primary-care-physician":null,"referring-provider-name":null,"requires-standing-assistance":null,"requires-translator":null,"state":null,"terms-tos":"1","translator-language":null,"weeks-pregnant":null,"zip":"90210"},"relationships":{"schedule":{"data":{"type":"schedules","id":"1"}}},"type":"visits"}}'

The response is a Visit Response record, which looks like this:

  {
    "data":
    {
      "id": "1",
      "type": "visits",
      "links":
      {
        "self": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1"
      },
      "attributes":
      {
        "appointment-at": "2019-09-21T13:00:00-04:00",
        "appointment-type": "annual-physical",
        "appointment-type-name": "Annual Physical",
        "confirmation-number": 1,
        "remote-visit-ids": "1234"
      },
      "relationships":
      {
        "schedule":
        {
          "links":
          {
            "self": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/relationships/schedule",
            "related": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/schedule"
          }
        },
        "location":
        {
          "links":
          {
            "self": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/relationships/location",
            "related": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/location"
          }
        },
        "provider":
        {
          "links":
          {
            "self": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/relationships/provider",
            "related": "http://api.inquicker.com/v4/winter.inquicker.com/visits/1/provider"
          }
        }
      }
    }
  }

Retrive Access Points based of a Particular Health System or region

Access to Apppointment Types for a Health System.

Available appointment times for a given schedule can be accessed using the Available Appointment Time resource.

Retrieve branding information that determines front-end visual attributes such as colours and the banner image URL.

Retrieve Custom Template that determines User-Interface for a particular formating set up for a schedule or Health System or Region.

Creates feedback records to capture user feedback after a successful visit booking.

Retriving facilities of a particular Health System or region, can be queried from the /facilities endpoint

Insurance plans are used to determine whether a patient's health insurance is accepted by a particular schedule.

Each plan belongs to an insurance company, and insurance companies can have many plans. Every health system has its own unique list of insurance companies and plans.

Each schedule, facility, region, and health system can specify which insurance plans are accepted for a particular service. If the accepted insurance plans are specified for a schedule, that will override the facility's accepted insurance plans, which overrides the region's accepted insurance plans, which overrides the health system's accepted insurance plans.

To get insurance plans available for a schedule, use the Schedules endpoint.

Health-System-specific information used in front-end implementations.

Locations, also called Facilities, correspond to the physical locations where services are provided. Locations have one or more related Schedules.

Medical Groups group Providers into logical groups.

Providers for a specific scope (hostname) can be extracted using the Provider resource.

Schedules can be queried from the /schedules endpoint, or from the locations endpoint for schedules at a specific location.

Services for a specific scope (hostname) can be extracted using the Schedule resource.

Service Lines for a specific scope (hostname) can be extracted using the Schedule resource.

The Visit API allows health systems to make their own visit creation forms, enabling them to integrate visit creation into their own websites and applications. The Health System’s application or website can collect a patient’s visit details and submit these to InQuicker through the Visit API. In the past, visit creation was handled exclusively through InQuicker’s online visit creation forms. The Visit API involves transferring patient details as shown below.

Personal and Contact Information:

• Full name

• Date of birth

• Gender

• Full address

• Phone number

• Email

• Caregiver name

Appointment and Care Information:

• Date, time, and type of appointment

• Patient complaint and comments

• Primary care physician indicator and name

• Insurance plan name, group number, member number, and insurance phone number

• Translator needed and language

• Pregnancy status and number of weeks pregnant

• Standing assistance required

• New patient indicator

Analytics:

• URL

• Referer

• User agent

Other:

• Remote UID

• Opt in

Health systems can access this feature by coordinating with their InQuicker implementation manager (IM).

The feature.api.v4_visit_create setting must be enabled at the Health System level within the InQuicker console.

Usage Notes

• Although screening questions can be used to prevent a patient from scheduling online, answers cannot be sent through the Visit Creation call.

• Since InQuicker's forms are bypassed, the Partner is responsible for doing their own validations as well as creating and linking their own "Terms of Service" form.

• Although the Terms of Service (terms-tos) and Terms 911 (terms-911) fields may be returned as required when querying Visit Settings, they must not be passed when creating a visit. It is included to remind the Partner of it's requirement.

• When setting up a schedule in InQuicker (to be used by API v4), do not require any visit fields that are not supported by API v4.

• Before using API v4 for a schedule, make sure the schedule does not require any visit fields that are not supported by the API. Doing so will cause validation to fail if the field is not submitted, but if included, will trigger an error.

• A schedule can be configured within InQuicker to use keyword filtering to prevent a visit from being created. For example, if the patient complaint contains "shortness of breath," the InQuicker scheduling page would prevent the patient from scheduling and would direct the patient to page about when to call 911. When using API v4 for visit creation the Partner is now responsible for such rules.

• If using the translator language field (translator-language), the list of available languages for the schedule can be retrieved using API V2. The API won't validate this field so the Partner is responsible for doing this if desired.

Validations

Field validations can be set up on the schedule level. However, some have behavior that cannot be changed. Please see the validation section in the Visit Settings call for more specific information.

Attributes