Leveraging FHIR for appointment booking system

There are multiple ways how you can architect a solution for appointment management. You can start from scratch or reuse community knowledge in this area. In this article, I am going to highlight the most known issues with the scheduling system I faced and how FHIR-driven architecture helps you avoid them.

Here are the 3 most common issues I faced after working with multiple scheduling solutions.

The booking system is a standalone solution

It means the administrator or practitioner himself should define the schedule in this system separately and make sure it’s up to date and does not interfere with all other systems, that the practitioner is using in his daily clinical practice.

What does it mean in reality? The patient books an appointment for a convenient time, but when then it appears, that the time is already booked by another way (maybe by a phone call to a clinic, etc). Then, someone should contact the patient to find another appropriate time and re-schedule the appointment. It is simply wasting resources and drastically makes the patient experience worse.

To avoid this issue, please, make sure, that the appointment booking engine you use is integrated with all other systems that might impact the practitioner schedule. And make sure, that this is bi-directional real-time integration (meaning, when some appointment is scheduled - this time will be marked as booked across all systems and vice versa).

When you are building a fhir-native solution, you get the interoperability layer for free. All elements in your applications are available for reading and writing. Your system is API first. Furthermore, you don't need to reinvent a suitable API, since FHIR is your internal and external API. It simplifies integration with any other solutions since FHIR is an industry standard adopted by many vendors.

The slot management is not flexible enough

Slot management is a part of the system, where you can define when the practitioners are available (days of the week, time ranges, etc), what kind of services they provide, what is the duration for each type of service, what are the prerequisites for each type of the service.

If you are unable to customize these parameters or to define your own, your clinical workflows will be limited to the provided options and you won’t be able to optimize them (more routine actions required to be done by a practitioner, more time spent with each patient, etc).

To avoid this issue, please, make sure, that slot management can be implemented as a system extension. There are many ways to define a specialist's availability. It is not possible to implement all of them in the standardized interface. The solution should provide a way to customize slot definition.

This topic is coupled with a previous statement about the benefits of an API-first system. FHIR provides Slot and Schedule resources that are used to define the availability of a specialist, room, device, etc. So you can implement any logic of slots generation as a system addon and upload slots to the system via FHIR API. If you would like to generate slots by some definition you can use Timing datastructure to save logic about slot repetitions.

For more simple cases like a static slot definition for the upcoming week. You may want to have a simple form used by an administrator to define a schedule. FHIR SDC IG provides guidance about defining forms and multiple ways how form results could be converted to an FHIR resource or bundle of resources. With SDC IG you can define a form and logic that convert its values into a set of Slot resources. This approach could be combined with a previous one. The interface that shows the availability works on the Slot and Schedule abstraction level, so it doesn't care about how this resource was created int he system originally.

No customizable pre-check-in flows

Pre-check-in flows typically help the practitioner to gather the information that helps to prepare for the appointment and spend time with a patient very efficiently. Depending on the practitioner's specialization, patient demographics, background diseases, and other related health profile data, different types of information might be required to provide.

If the customization is not supported by the system (you can’t add your requirements, adjust the questions, etc), your staff will highly likely spend this time with the patient when he is already in the facility (before or during the appointment).

To avoid this issue, please ensure the pre-checking flow is configurable for each appointment type, specialty, and even practitioner. Also, filled-in forms should be easily accessible by a doctor in the EMR.

To address this feature we need to use two technologies from the FHIR infrastructure. The first one is already mentioned above FHIR SDC IG. When receptionists create an appointment, they use a form. This form should be defined as a Questionnaire. Since the questionnaire is just data, it could be easily modified to include additional information. For example, you can add a control to select questionnaires that a patient should fill out before the appointment. Once the form is saved, information about selected questionnaires is used to create CommunicationRequest resources. Each CommunicationRequest is linked with the Patient, Appointment, and Questionnaire. The final piece is sending a notification to a patient. For this part, you can use FHIR topic-based subscription. You can define a handler that subscribes to the new CommunicationRequest being created. Then you load information about the patient and the questionnaire. As a result, you have all the data to compose an email with a secure link to the web form and send it.

In this article, I demonstrated how you can reuse existing FHIR IGS to make the scheduling system very flexible. Also, all this enhancement could be done externally to the original system if it supports all the defined IGS. You can modify the questionnaire on your own, you can implement any kind of business logic in a subscription. It is the flexibility that FHIR to provide an extendable rich API for application development.