API Requirements

Examples:

We have completed API integration with multiple EMR vendors, including:

• TELUS CHR

• TELUS Practice Solution and MedAccess

• OSCAR EMR

• Pabau

• EMERGE

Core Requirements

Our primary requirement is the ability to periodically (e.g. every 15 minutes) access all appointment data for a specific date in a read-only format. Having this ability will support 95% of CHIME use cases

There are additional requirements to support specific features:

• To support the use case of a robust self check-in process, we need to receive patient demographic data.

• To support the use case of allowing staff to check-in patients within the EMR, we need the ability to be pull appointment data updates on a more frequent basis (e.g. every 30 seconds). For efficiency reasons, this means we need to be able to check for only “recently updated” appointment data.

• To support the use case of updating appointment data within the EMR (e.g. to denote a particular patient as checked in), we need the ability to write updates to appointments back into the EMR.

Most Commonly Seen Data Fields

In broad strokes, we need to access all data fields that a clinic might use to internally manage or communicate what to do with any given patient.

A list of the most common fields that we see include:

• appointment id

• appointment status

• appointment start date and time

• appointment duration

• appointment reason

• clinician id

• clinician name

• patient name

• patient phone number

• patient email address

• patient mailing address

• patient health card information (E.g. number and version code)

• patient date of birth

Additional Data Fields To Supply

We have also seen the following fields in multiple instances. Different EMRs have different data attributes. If this type of data exists, it is important to provide as well:

• patient preferred name

• appointment “location” or “site”

• appointment “name” or “type” (both the display text, and a unique id, if available)

• appointment notes

• last updated time

• created time

• creator id

• last editor id

• patient alerts

• patient notes

Computed Attributes / GUI Elements

An issue we’ve seen on occasion involves situations where the EMR is designed to compute or check certain attributes or combination of attributes, and to present the computation to users with a GUI element. For example,

• if a patient has an outstanding or overdue invoice, a $ icon appears in the schedule

• if a patient has a “note” on file that should be read by reception staff, a ! icon appears in the schedule.

It is best if any GUI elements like this also appear in the API response so that the CHIME kiosk has access to all of the same information that a human receptionist would.

Exemplary Endpoints

Being provided endpoints that perform as follows is typically sufficient:

getAppointments

• parameters: time range, optional (updated since)

• response: the core and recommended fields for every matching appointment

updateAppointment

• parameters: id, updated fields

• response: success / failure