Kiosk

Ocean Kiosks allow patients to check-in using an automated kiosk in the clinic waiting room, either by swiping their health card or entering an equivalent identifier using an on-screen keypad.

The kiosk will reject a check-in when the patient does not have an appointment that day within an appropriate (customizable) time window. In order to provide this functionality, the Ocean kiosk regularly performs a "schedule synchronization" with the EMR/EHR every 30 minutes, typically looking one or may days ahead in the schedule to ensure these patients are pre-loaded in the system.

The check-in usually shows a summary screen of the patient's contact information and allows the patient to update this information.

The kiosk also typically shows a series of check-in Ocean forms. The variety of forms hugely varies across clinics, but often includes administrative forms such as email/SMS/virtual care consent, clinic policy review forms, intake forms, and clinical history forms.

The kiosk can also use customizable Javascript heuristics to show forms only at certain times, such as a smoking cessation form only for patients who have smoked, or a flu shot form only at certain times of the year. Furthermore, certain forms, such as the Medication Reconciliation, will present the patient with a summary of their medications. These heuristics require more information than the Patient endpoint provides, so Ocean requests a more fullsome chart summary using the $everything endpoint.

Sequence of Connections With FHIR Resources

0. Kiosk Configuration Queries

In order for end users to configure their clinic's kiosk check-in options, Ocean first needs to read some metadata from the FHIR server, particularly to determine which providers, and appointment types are used by the clinic. These values are read as part of a regular "synchronization", which is done when it is first connected in Cloud Connect and then automatically every half hour. You can also request an immediate synchronization in the Cloud Connect portal.

The following endpoints are called in particular:

  • GET Practitioner?active=true

Check the Profiles in this implementation guide for more information about each endpoint operation.

After a successful synchronization, you should be able to activate and configure bookable schedules inside Ocean's Online Booking app within the portal. Proceed to set up at least one schedule and one booking link for testing purposes.

1. Schedule Synchronization / Daysheet Population

Ocean maintains a read-only copy of the appointment schedule in the Ocean portal (located under "Day Sheet" in the Patients tab). This Day Sheet schedule is a helpful reference view for the secretarial/receptionist team to monitor the status of upcoming patient appointments.

The Day Sheet is also used as a reference when patients attempt to check in via the kiosk.

Full Synchronizations

To populate the Day Sheet, Ocean starts with a "full synchronization" of the schedule. A full synchronization is also repeated every subsequent night, soon after midnight.

The full synchronization starts by querying for any appointments within the lookahead period, for all of the practitioners selected during the Cloud Connect configuration:

  • GET Appointment?date=ge{startDateTime}&date=le{endDateTime}&slot.schedule={scheduleId}

(see the FHIR Search reference for an example of how these range searches work)

Performance Warning: The lookahead range is typically 1 day, but can be customized in the Cloud Connect portal. Naturally, increasing the lookahead range will increase the load on the integrated system, not just to load appointments, but more significantly to load the patient chart. To prevent overloading the database and consequent downtime, it is very important to ensure the integrated system can keep up with the load of these synchronizations. As a preventive measure, the system may consider supporting a maximum lookahead period of 1 day.

For each matching appointment with a patient, the synchronization calls the Patient//$everything endpoint to load relevant resources. See this guide's operation definition of $everything for details.

Partial Synchronizations

In addition to the full synchronization every night, every 30 minutes, Cloud Connect will conduct the same Appointment query every 30 minutes. However, with the partial synchronization, patients will not be reloaded using the $everything operation (which tends to be the far more expensive aspect of the synchronization).

Each appointment is compared against a local cache within Cloud Connect. If an appointment is missing from the result, or it is marked as cancelled, the appointment is removed from the Day Sheet. If an appointment appears for a new, previously unloaded patient, the patient is loaded using the $everything operation.

2. Initial Patient Check-In

If the kiosk is configured to permit walk-ins, it will naturally allow patients to check in despite not having an appointment in the schedule. In this circumstance, the kiosk waits for Cloud Connect to request that the patient be uploaded from the integrated system. To do so, it conducts the following query:

  • GET Patient?identifier={healthNumber} Followed by:
  • GET Patient/{patientId}/$everything

(Note that this request is the same as the one initiated by the "Upload from EMR" action in the Ocean Portal's Patients tab.)

If the patient however already exists within the Day Sheet (i.e., it's not a walk-in appointment), the check-in is handled without an additional call to the integrated system.

3. Demographic Changes

Once the patient confirms their birth date, the kiosk and Ocean tablet often start by presenting the patient's demographics (contact information) for editing. These changes are uploaded to the EHR within a patch-like FHIR Patient resource:

  • PUT Patient/{patientId}

3. Kiosk Form Completions

Refer to the Form Completions section of this guide to see the full list of potential updates that may be performed by the kiosk, along with other core Ocean products. At a minimum, the kiosk forms will POST to a DocumentReference to record a clinical note summarizing the forms.

4. Marking as Arrived

After completing the check-in, the kiosk attempts to mark a patient showing as "Arrived" in the appointment schedule for the relevant appointment(s). To do so, it first calls:

  • GET /Appointment?patient={patientId}&date=ge{now - 12 hours}&date=le{now + 12 hours} To find a list of candidate appointments. Next, it checks whether any of these appointments are within a customizable time window (e.g. any appointments within the next 2 hours). For any matches, it will PUT the /Appointment with a status "arrived"; the Patient in the Appointment.participant will also have its status set as "accepted".