Articles & Case Studies / Articles
API Requirements
CHIME is a clinic workflow management system. It involves the deployment of a variety of hardware throughout a clinic, including waiting room screens and wall-mounted room tablets. It can also involve API integration with EMR software.
Core Requirements
Our primary requirement is the ability to periodically (e.g. every 15 minutes) access:
appointment data for a specific date in a read-only format.
patient demographic data for these appointments.
Having this access will support 95% of CHIME use cases.
In the best case, we can access all of the above information (appointment data + corresponding patient demographic data) in a single query instead of needing multiple queries.
There are additional requirements to support specific features:
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 appointment and 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 id
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
As noted previously, being able to access all of this information in a single query is very advantageous.
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
Including this information in the aforementioned single query is again very advantageous.
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.
Including this information in the aforementioned single query is again very advantageous.
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
If the getAppointments endpoint does not return patient data, it needs to return patient IDs for each appointment and a separate endpoint - getPatientsbyIDs - will be needed.
A endpoint that only accepts a single patient ID (instead of patient IDs) is likely problematic as it will require too many queries to access to required information (e.g. a separate call for every appointment).
Contact Us
For questions about our software license, please contact:
1 (833) 891-1203
Chime Technology Inc.
418 Eglinton Ave West, Suite 202
Toronto ON, Canada, M5N 1A2