Real-time scheduling is the hardest healthcare interoperability problem

Mix one part history with one part apathy with one part data security/validation

Introduction

Most futuristic healthcare demos involve a person speaking to their digital assistant (Google Assistant, Alexa, Siri, etc.) and asking “Schedule an appointment for me with my PCP at 3PM”. The assistant burns some compute cycles in a data center and then responds “Done. Your appointment is scheduled at 3PM tomorrow. Would you like me to set a reminder and schedule an Uber?”. Magic.

In reality, this is much harder to build. But why? I can schedule dinner reservations with OpenTable. I can get an Uber to come to my house in 5 minutes. Why isn’t this healthcare scheduling system something that exists and is everywhere? Why hasn’t Healthgrades/Zocdoc and others absolutely solved this problem?

To understand the challenge, you need to understand a bit of history of healthcare technology systems design along with some urban legends about empowered patients. While some of these challenges have dissipated with the adoption of new healthcare data standards like FHIR and the acceleration of digital technologies and telemedcine adoption vis-a-vis COVID, there are still some challenges at the tail end of implementation.

I know about this from a few angles. One of my first jobs was installing MyChart at Epic, which was one of the first (maybe the absolute first) piece of software that facilitated online appointment scheduling. Afterwords, running the data integration division at Datica, we powered scheduling solutions for a variety of vendors (and gave a short-form version explanation of this blog to many others).

Some history & terminology

First let’s discuss some terminology. There are “providers”, or people that users can schedule appointments with. Fun fact: the master file abbreviation in Epic for providers is SER, which stands for “Schedulable Epic Resource”. Just start saying 3 letter acronyms in bars in Madison, WI if you are here and you will immediately ingratiate yourself with the beleaguered healthcare IT staff of the populace. Providers have “schedules”, which are filled with “slots” during which are times providers are available for appointments with patients. Those “slots” are typically assigned a specific “visit type”. Providers typically schedule new patient visits, existing patient visits, procedures, well checks and a myriad of other visit types to specific slots. Depending on the health system this can be very well standardized or the number of visit types can number into the thousands as Visit Types may trigger other external logic downstream within the application. A scheduled slot with a patient becomes an “appointment”, which upon being documented on becomes an “encounter” which is the documentable/billable unit in which a provider interacts with a patient. There are a variety of scenarios where appointments and encounters do not have 1:1 ratios (admitted patients receiving scheduled care in a hospital is the textbook example), but for our use cases here, let’s assume these have a 1:1 ratio.

Once again, the lingo:

• Providers - “Who”

• Slots - “When’s Possible”

• Appointments - “When Confirmed”

• Encounters - “Billable Unit”

• Visit Types - “What”
  
  
  Now that we have the lingo down, it’s important to talk about the history of scheduling systems and EHRs. In 2021, we speak of the EHR as a monolithic system, but it’s important to remember that what we now know as the EHR is comprised of disparate systems which were not always tied together.

At the beginning of healthcare technology, these systems were all different and connected together by interfaces (HL7v2 interfaces to be specific). You know Epic as the goliath EHR vendor now, but its initial hit product was actually Cadence, the scheduling application within the EHR Suite. While most documentation was still on paper, electronic scheduling and billing had much more obvious appeal (and required much less physician workflow change) and as such they were adopted faster. When EHRs proliferated in the late 90s onwards, it was important to make scheduled appointments available in the EHR easily for clinicians to view, and as such the scheduling/registration system would push the entirety of scheduled appointments to the EHR. Conversely, if a patient no-showed or there was some change that occurred in the EHR system, the EHR could push back some signal to the scheduling system for coordination and logistical purposes.

I highlighted scheduled appointments since that is a very important differentiator. While scheduling systems speak “slots” and “visit types” from a pure tactical standpoint, the EHR didn’t or didn’t need to. The EHR mostly just cared about the fact that there was an appointment, the time it was, the user(s) it should present that information within a schedule and the visit type to drive workflow/billing requirements. As such, the most common HL7v2 interface types were the messages to create new appointments, modify appointments, cancel appointments and reschedule appointments. While there are HL7v2 interface message types for communicating open and closed slots for a disparate system to understand capacity (HL7v2.5 SIU_23 and SIU_24s, respectively), I personally have never seen these in the wild much. You have to remember that a variety of advanced features of HL7v2 exist academically and not in implementation; this is the same challenge with optional UTC-based timestamp management that plagues health systems every DST switch.

FHIR R4 supports slots out of the box, but before the prevalence of FHIR there were a variety of APIs that were all custom that did support scheduling slots and scheduling. Epic, Allscripts, Athena exposed APIs that could manage these processes. Like most EHR integration, this is a long tail problem. The major vendors have/need a plan to support this functionality but the other 450+ vendors are mostly lagging behind. There is much better support, unsurprisingly, amongst Dental/Optometry EHRs for scheduling due to the more consumer driven workflows that better drive inbound needs.

There are some other creative solutions applications can take to solve scheduling that do not involve APIs/Data Standards, but I’d like to talk about the next barrier to easy online scheduling.

“What do you mean you’re going to let patients schedule appointments whenever they want?”

There are two approaches to managing appointment scheduling at a large healthcare organization. Centralized Scheduling or De-centralized Scheduling. Once upon a time, all scheduling was de-centralized. If a patient wanted an appointment with a physician, they would call that physician’s office, the scheduler would schedule the appointment, and then the registration person would collect any information needed to accurately bill for the encounter (or, notably, to ensure that their insurance would reimburse for things before the encounter itself before seeing them #BooAmericanHealthcare). This worked relatively well, and it wasn’t that uncommon to meet couples that ran a clinic where one person was the scheduler/registrar/medical assistant/nurse and their partner was the physician who treated the patient. However, this obviously has some downfalls:

1) No way to centralize requests for appointments, putting onus on patients to understand who to call for what (which effectively penalizes the most sick patients).

2) Low “bus number” on the scheduler which impacts throughput/reduces NPS and other patient satisfaction metrics.

3) Difficult to do any triaging of patients or cross-organizational management of patients.

The rise of VOIP technology and the digitization of scheduling/EHRs made these call centers more popular and this centralized method of scheduling has become more popular over the last 20 years. And, as you can imagine, centralized scheduling is generally cheaper for most organizations after initial investments in tech. However, I would not say that centralized scheduling is 100% prevalent or that it does not have its own pitfalls or problems. Notably, there are concerns that it causes inefficiencies due to schedulers lacking an understanding of the patient which leads to extraneous appointments/testing. I couldn’t find anything that stated this empirically (of course, vendors which offer solutions on both sides have their opinions), but it passes the sniff test. Suffice it to say, there are always exceptions to centralized scheduling and its benefits that need to be managed accordingly.

Why did I just provide a 300+ word explanation on centralized scheduling? It’s because if an organization wants to earnestly provide API/open access to scheduling, it effectively has to centralize scheduling. Any business logic in scheduling or provider preferences need to be standardized as such that someone with zero training can schedule an appointment. This isn’t impossible, of course, plenty of organizations have adopted centralized scheduling. But it is step number one: an organization can’t provide digital scheduling well if it doesn’t effectively complete the transformation efforts to centralize scheduling. If there are patients calling into a call center, if there is any business logic not well codified in the system (e.g. Dr. Singh won’t see a patient for “x” condition without getting “y” lab work done first or trying “z” first) an org can try and push out some notices or communicate any nuances that exist at a specialty/clinic/provider level to the schedulers to make good decisions. In the case of online scheduling, applications can push basically zero business logic onto the patient, so as much standardization that can be done up front must be done in order to drive success.

One of the general fears of online scheduling is that “super-utilizers” or “major no show offenders” will schedule too many appointments and muck up schedules. These concerns are mostly unfounded (there are/were similar concerns about provider messaging volume too that are mostly bullshit), but they exist and products will have to answer these questions to provide open scheduling in a meaningful format.

To sum this section up in a tl;dr: an organization can’t skip the logistical work of centralizing scheduling before exposing the ability to widely schedule appointments online. This is a multi-year process. If your product wants to manage online scheduling better, plan this ahead. Of course, it’s easier to carve out some specific niche of appointment scheduling (urgent care visits for existing patients), but this gets to the next hurdle of managing appointments.

Back to tech stuff: what are the flavors of online scheduling and how do they work?

I. The Appointment Request

The most simple way to implement online scheduling is an “Appointment Request” workflow. The website/app presents a form for the user (no need to validate identity), the user fills out some demographic information, states their preferences on time for an appointment, and then submits the form.

In some cases (e.g. Epic MyChart), the form submission is actually read by a person and is scheduled. In other cases, it is sent to somewhere where it is handled within some SLO.

Hypothetically this can work well, but this is marginally online scheduling. If anything, it takes complexity for the clinician and hoists it upon the end-user. It almost always results in additional phone calls and work for the patient. Imagine going to OpenTable and requesting to see if maybe a restaurant would feed you today? F-that.

2. The Heuristics

In the absence of a real-time scheduling API available, an organization can always provide an estimation of accuracy of slots based on existing and available data. While this is not 100% accurate, it can range from “pretty good” to “at least it got the person in the door”. There are a few heuristic approaches to online scheduling.

A) Replicate the providers schedule in your application:

The easiest thing to do is that your product has a health system end user manage the providers application manually within another application. So, the schedule manager would update provider scheduling templates in both apps and then document that appointments were scheduled in both their scheduling system and the patient facing application. This doesn’t really scale, but I suppose it could work in a 1-5 doctor office situation with low volume.

B) Replicate the providers schedule in your application and manage it with existing data feeds.

A slightly better version of #1, where the product can at least reduce some of the overhead by removing the double documentation piece of things for the scheduler at the expense of a one-way HL7v2 SIU feed or some query mechanism of the providers filled schedule against a database. There may still be some failures in cases where appointments are scheduled against exceptions to the scheduling template (e.g. the provider usually works 8-5 on Tuesdays but is on vacation this Tuesday) but it’s mostly effective.

C) Replicate the provider’s schedule in your application and add fidelity through either Machine Learning analysis of filled slots or by filling the last mile with “smart” RPA

At this point, some differentiating solutions provide better fidelity on top of existing heuristics by either evaluating the likelihood of slots actually being available by analyzing existing appointments and their schedule (QueueDr has tech like this) or by using some smart RPA solutions to call offices to confirm appointments.

These solutions are admittedly suboptimal when compared just improving improving the semantics and interoperability with regards to scheduling appointments. But, many organizations have invested millions into these systems that lack this type of power. Given the potential ROI benefits to improving scheduling, there is certainly a need for these intermediary solutions.

3. Scheduling APIs

Finally, there are scheduling APIs available from vendors. Notably, Epic supports slots and appointments through its FHIR APIs that do not require an App Orchard agreement. This isn’t limited to the major vendors, of course, as Dentrix (the leading dental EHR/practice management solution) also supports scheduling APIs.

However, often the scheduling APIs exposed are just a programatic veneer of any open scheduling logic which is exposed through internal patient portals. Porting external integration can be more complicated however, due to some practical requirements in allowing patients to schedule appointments.

Practical Challenges to Online Scheduling

Even if there are APIs that can be easily integrated into applications or patient facing experiences, this doesn’t mean that human schedulers need to worry about being replaced just yet. For a product to replace person workflows, of course, the product has to either replace or remove the need for person workflows. While a technical product can do some of these items, some challenges (and their trade-offs) still remain. Here are some major ones.

Managing “New” Patients vs. Existing Patients

Most existing online scheduling targets “Existing” patients that already have patient portal accounts. Most of these accounts are validated either in person at a doctor’s office visit (e.g. sign up for MyChart today while checking in for your appointment) or through some other workflow to validate the patient’s identity. In fact, the dominant (and still existing) method to validate a patient’s identity for Epic’s MyChart is to mail a letter with a passcode to a patient’s known address. This may seem like overkill, but consider the alternatives:

1) From a compliance standpoint, if your product lets a patient create a new patient account to schedule appointments, that could hypothetically be used by a bad actor to gain access to patient data for that patient. If I knew Kim Kardashian’s SSN and address, I could hypothetically create an account and then gain access to that patient’s data if it was synched before an appointment via an HIE or if the data existed and I simply lacked an electronic record. This of course, is somewhat alarmist. But, health systems think about this and it’s often easier for health systems to say “no” instead of “yes”.

2) Assuming your product can solve the compliance issue of new patient accounts, there is then a financial side of creating new patient accounts. Typically, a clinician wants to ensure that they will be reimbursed before seeing a patient. This matters less for some situations (notably those where costs are low or cash pay is more common), but matters much more for others. For example, a dermatologist likely wouldn’t mind scheduling an initial consult with a patient without knowing likelihood to pay. But scheduling/conducting a diagnostic like a biopsy or a procedure without knowing coverage would likely directly impact the likelihood of a provider’s prioritization of seeing a patient. Is that crappy? Sure is! Is that how it is? Yes. This type of up front eligibility pre-visit can be better facilitated via services like those provided by Eligible.

3) If your product assuage Compliance and Financial concerns, then finally there is the concerns of the IT administrator that patients might create too many accounts which would lead to duplicate records without the EHR. In lieu of using a standard identifier (after all, not all US patients will have an SSN!), it is very hard to truly ensure that patients couldn’t create duplicate records. If your product built a process which made it easier for new patients to schedule appointments than existing patients, there is some concern that patients would exploit this in order to be seen faster.

Once we’ve determined “who” we want to allow to have appointments scheduled for, the next question then is “what” appointments we want to allow scheduling for.

Managing Schedulable Visit Types

Once we’ve onboarded a patient, the next challenge is designing a good system to communicate which appointments are allowed to be scheduled. For some use cases this is simple:

• Existing Patients can always schedule check ups with their PCP

• Any patient can schedule an appointment at the urgent care

• No one should be able to self-schedule a head MRI

This is where most organizations start, but true scheduling really requires more. How can your product allow patients to self-schedule with specialists? Some of this can be managed with some more specific logic: usually some more specific logic of provider type + provider specialty + visit type + new/existing patient to that provider is what determines if these visits are schedulable. On top of that, an organization can implement questionnaires to further refine the need or the type of appointment. For example, most checkup visits at St. Elsewhere Hospital may automatically be 15 minutes but the scheduling app may select a 30 minute slot if the patient indicates that they are seeking help with substance abuse.

The flip side of this is managing good workflows for allowing patients to know what can and cannot be scheduled. This is easier if an organization has a provider with a very limited bill of service (e.g. telemedicine) but this can be much more complex in other scenarios. If you don’t believe that this is true, then try scheduling an in-person appointment online right now during COVID; many organizations pulled these capabilities online as patients tried to get testing/vaccines even though they weren’t always available or the appropriate avenue for distribution.

Setting reasonable constraints on queries and writing appointments

Even if an API provides a list of slots for scheduling, your product may want to prevent scheduling appointments too far out, allowing a patient to schedule too many appointments or the window by which your product will allow patients to cancel/reschedule appointments automatically (basically, incurring a no show/non-filled appointment). Having access to an API does not mean that whatever the API allows is OK; especially in healthcare technology.

Conclusion

There’s a lot of promise in automatic scheduling and despite my thousands of words on its complexities, it’s easier to setup and more wanted than ever. Building a true, open exchange for healthcare scheduling means diving into the difficulties and not avoiding them. Hopefully this helps you understand why it’s not as easy as grabbing a reservation at your favorite restaurant.