Stream: implementers
Topic: Appointment $find vs Slot.search
Brendan Keeler (Jan 26 2021 at 01:45):
If I look at Epic's fhir.epic.com, I see an Appointment.$find operation that seems functionally equivalent to Slot.Search (which is what Cerner CODE has) - both seem to expose the schedule availability.
I would imagine the right way to find booked appointments is Appointment.search and the right way to find availability is Slot.Search, so just wanted to confirm that. I don't see Appointment.$find as a FHIR R4 or DSTU3 operation, but some mention of something similar in Argonaut scheduling documentation.
Eric Haas (Jan 26 2021 at 01:51):
Eric Haas (Jan 26 2021 at 01:53):
Not every implementation uses/exposes Slots so this operation smooths over that
Brendan Keeler (Jan 26 2021 at 03:44):
What's interesting is that Epic does expose the Slot resource, just not for searching (only read)
Cooper Thompson (Jan 26 2021 at 14:28):
The issue with slot.search is that the rules around managing slots are very complicated. E.g. a provider might have a rule that says they only want 2 "new patient" appointments per day, so once two slots are used for new patients, the rest become unavailable. That is complicated to communicate in Slot.search (at least in the workflows that folks actually use Slot.search for). The key difference between $find and Slot.search is that $find delegates the identification of appropriate slots to the server, where Slot.search lets the client determine which slots are appropriate. it is similar in concept to Patient.search vs. $match.
Brendan Keeler (Jan 26 2021 at 14:47):
That makes sense. @Jenni Syed does Cerner see it that way as well? Or will there be divergent approaches to FHIR based scheduling?
Jenni Syed (Jan 26 2021 at 17:16):
We haven't implemented the STU3 Argonaut standard (we don't have an STU 3 FHIR server). cc @Drew Torres
Eric Haas (Jan 26 2021 at 18:06):
I believe Meditech is using it as well, but it is an STU3 IG. Briefly discussed updating it to R4, but no decision on that and whether there is critical mass to do it.
Brendan Keeler (Jan 26 2021 at 20:11):
Okay, so definitely some divergent approaches there. I see eClinicalWorks/Healow using the Slot oriented method.
Cooper Thompson (Jan 26 2021 at 20:13):
Also, our use of $find is only for provider-to-provider scheduling, not for patient-facing scheduling.
Brendan Keeler (Jan 27 2021 at 00:43):
Can you elaborate? Provider to provider as in cross-organization? Or as in a "provider app" (provider/system-level auth)? Couldn't a health system (or developer) create a fhir.epic.com app using those APIs and deploy it with that health system's authorization/acceptance?
Brendan Keeler (Jan 27 2021 at 00:43):
Totally understand that slot/appointment isn't USCDI / patient auth, if that's what you mean.
Cooper Thompson (Jan 27 2021 at 14:36):
We built it for cross-organization scheduling, so you could schedule a specialist visit from a PCP office at a nearby partner organization. So referral-adjacent type stuff. A fhir.epic.com developer could build an app with those. However it requires close partnership with the health system. Behind the scenes there is build needed to determine which visit types, departments, specialties, pools, etc. are considered when identifying candidate slots for $find. Many organizations don't want to open up their entire schedule for either cross-org or even internal scheduling. For some departments/providers they'll always want scheduling to go through their schedulers.
Cooper Thompson (Jan 27 2021 at 14:37):
However, our current support of $find is not built to work in the patient-facing context. So the fhir.epic.com apps would be for providers. We have other options for patient-facing scheduling, but just not $find (at least not now).
Michael Donnelly (Jan 27 2021 at 14:38):
There are also a bunch of special rules in $find. You pass in a patient (and diagnosis I think?), and it finds slots for you that are appropriate for that situation.
Last updated: Apr 12 2022 at 19:14 UTC
