What if booking clinical appointments looked more like booking airline tickets?
| Status |
|---|
| Draft proposal for discussion |
"SMART Scheduling Links" is a standards-based specification enabling patients to:
We are parsimonious in our use of standards, so that:
This specification defines four functional roles:
Slot Discovery Client: the booking tool of a patient's choice. This system discovers appointment slots on a patient's behalf, and helps the patient choose the best slots to book (e.g., by evaluating trade-offs of travel distance or wait time).
Slot Publisher: the API service offered by a healthcare provider, advertising available slots. Critically, advertising a slot should be low-risk, since the mere fact that a slot is advertised does not guarantee that any given patient will be allowed to book the slot; instead, sophisticated rules can be implemented by the...
Provider Booking Portal: the UI service offered by a healthcare provider, enabling a user to book a selected slot. This is the place where provider-specific rules can be implemented, e.g. to ensure that patients booking a specialty appointment are appropriate candidates for that specialist's care. (In many implementations, this UI will be housed within a general-purpose provider-hosted patient portal.)
Slot Aggregator: an API service offered by public health authorities or other third parties, aggregating data from multiple Slot Publishers or from other healthcare provider APIs. Slot Aggregators otherwise act in a similar capacity to Slot Publishers.
Examining the SMART Scheduling Links workflow described above, there are some potential user-experience challenges:
After the hand-off from a Slot Discovery Client into a healthcare provider's system, the user might have to sign into the healthcare provider's system, or create a new account; and might have to answer all sorts of provider-specific questions in order to complete a booking.
Appointment slot data might become stale, so that by the time a patient signs into the provider's system, the slot is already taken.
Once an appointment booking is completed, the Slot Discovery Client might not have an easy way to learn about the details of the booking (e.g., was it successful; what is the specific location and timing).
In other words, compared with a deeply-integrated scheduling paradigm where a booking tool could guide the user through every step of the process, SMART Scheduling Links provides a more loosely-coupled user experience. But we have strong evidence that this is a viable UX trade-off, because it works just like a very familiar and highly successful booking system...
Cross-industry standards analogies can sometimes be misleading -- but to build up an intuition, it's worth comparing the SMART Scheduling Links workflow with the consumer airline booking experience. Briefly: the Slot Discovery Client plays the same role as a travel booking tool like KAYAK or Hipmunk. These systems help their users search for relevant options across multiple service providers, and help users evaluate trade-offs among these options. Once the user makes a selection, a deep link takes them to a service provider to complete the workflow. The Provider Booking Portal plays the same role as an airline like United or Delta. These systems manage user accounts and enable a booking-completion workflow. They also serve as gatekeepers, e.g. to collect data about a user's background as well as identifiers such as a Known Traveler Number or redress number. They can "call off" the workflow at any point (e.g., if a user is unable to provide the required information, or if a previously-available slot has been booked by another user).
This pattern works well in airline booking, and could dramatically reduce the difficulty of healthcare appointment booking.