Open Scheduling Epic
Xena Donovan
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.
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.
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.
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.
Thanks for providing your expertise, really great article. You mentioned that there are other creative solutions applications that solve scheduling that don't involve APIs/Data standards. Can you please elaborate on what these are? Also really curious if you can please recommend other people or sources who are writing about this topic. Am keen to learn!
Most futuristic healthcare demos involve a person speaking to their digital assistant (Google Assistant, Alexa, Siri, etc.) and asking \u201CSchedule an appointment for me with my PCP at 3PM\u201D. The assistant burns some compute cycles in a data center and then responds \u201CDone. Your appointment is scheduled at 3PM tomorrow. Would you like me to set a reminder and schedule an Uber?\u201D. 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\u2019t this healthcare scheduling system something that exists and is everywhere? Why hasn\u2019t 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\u2019s discuss some terminology. There are \u201Cproviders\u201D, or people that users can schedule appointments with. Fun fact: the master file abbreviation in Epic for providers is SER, which stands for \u201CSchedulable Epic Resource\u201D. 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 \u201Cschedules\u201D, which are filled with \u201Cslots\u201D during which are times providers are available for appointments with patients. Those \u201Cslots\u201D are typically assigned a specific \u201Cvisit type\u201D. 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 \u201Cappointment\u201D, which upon being documented on becomes an \u201Cencounter\u201D 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\u2019s assume these have a 1:1 ratio.
Visit Types - \u201CWhat\u201D
Now that we have the lingo down, it\u2019s important to talk about the history of scheduling systems and EHRs. In 2021, we speak of the EHR as a monolithic system, but it\u2019s important to remember that what we now know as the EHR is comprised of disparate systems which were not always tied together.
I highlighted scheduled appointments since that is a very important differentiator. While scheduling systems speak \u201Cslots\u201D and \u201Cvisit types\u201D from a pure tactical standpoint, the EHR didn\u2019t or didn\u2019t 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\u2019d like to talk about the next barrier to easy online scheduling.
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\u2019s 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\u2019t 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).