Stream: patient empowerment
Topic: Patient workflow: appointment booking
Josh Mandel (Sep 16 2019 at 22:24):
I'm not sure if this is interesting/relevant for a patient workgroup discussion, but I figured I'd share: https://github.com/smart-on-fhir/smart-scheduling-links has some thoughts I drafted this morning about an API for scheduling -- including some user experience considerations for a patient-facing workflow. I'm trying to figure out whether the "airline booking" UX is "good enough" for clinical appointment booking, or whether we really need to enable deeper integrations.
Dave deBronkart (Sep 16 2019 at 22:44):
good enough
Whom are we trying to please - other developers, or consumers, or providers, or?
Josh Mandel (Sep 16 2019 at 22:49):
It's a balancing act. I guess that's the art of all this -- needs to meet everyone's constraints in terms of feasible-to-implement; provides-good-pre-booking-data; ux...
Josh Mandel (Sep 16 2019 at 22:51):
My quick take has been: the 2017 attempt tried to please the scheduling app developers but wasn't widely adoptable by healthcare providers or EHR vendors.
Josh Mandel (Sep 16 2019 at 22:53):
But I was asking here specifically about the patient UX.
Dave deBronkart (Sep 16 2019 at 23:12):
Well heck yes the patient WTF will have opinions. We'll need some expertise, not just e.g. my opinion
Josh Mandel (Sep 16 2019 at 23:13):
Anyway, this isn't an hl7 project, just a few thoughts I have drafted informally -- so I would certainly be happy for your own informal perspective :-)
Dave deBronkart (Sep 16 2019 at 23:27):
Later.. remind me if necessary.
As it happens 10 years ago I worked for TimeTrade Systems, which makes appointment systems. So I have some familiarity with the messiness of the back end. But UX .... I'd start by surveying what the consumer people like ZocDoc and CVS (and the new Walmart Health) are doing.
Josh Mandel (Sep 16 2019 at 23:34):
Ok, thanks. (Yes, I'm familiar with this work -- some do links out, but they clearly prefer tight integration where possible; the problem for most apps is scaling the tight integration in terms of cost/effort, so I'm very interested in identifying a lower-end spot on the functionality-vs-"price" curve.)
Grahame Grieve (Sep 16 2019 at 23:39):
the 2017 attempt tried to please the scheduling app developers but wasn't widely adoptable by healthcare providers or EHR vendors
That's the existing Argonaut scheduling IG? do we have hard numbers on the adoption? By the EHR vendors? Why do you say 'not adoptable'?
Grahame Grieve (Sep 17 2019 at 09:35):
ok now I've read it... I feel as though I missed a few things:
booking-referral: a correlation handle for this specific booking referral
What does it correlate with? This is incomplete or my understanding is incomplete because where does it appear again?
Providers have no way to set rules/expectations about which patients are good candidates for a given slot
I feel as though your proposal doesn't really change this?
This pattern works well in airline booking
Is this based on protocol analysis? I suspect that there's more to the API for expedia etc than you've described here, and other protocol parts are critical to the business integrity
the user might have to sign into the healthcare provider's system, or create a new account
That seems to me to be more of an issue in healthcare than elsewhere?
Cooper Thompson (Sep 17 2019 at 12:56):
The 2017 Argonaut IG covered three use cases: 1) EHR-to-EHR booking, 2) Patient-to-EHR booking and 3) Syncing slot information between a scheduling client (e.g. ZocDoc) and an EHR.
Epic has implemented #1. Cerner was interested in #2, though I'm not sure if they have implemented the IG or not. As far as I know, nobody has done #3.
Josh Mandel (Sep 17 2019 at 13:31):
Thanks @Grahame Grieve for the close read-through!
Josh Mandel (Sep 17 2019 at 13:31):
booking-referralis a small nod toward recognizing that it'd be nice for the Appointment Search Client to learn when slots are booked -- but I don't want to try to specify how this happens. So thebooking-referraljust ensures that there's a clear way to talk about the referral, in the event that providers and search clients want to communicate about it in the future. (In the analogy: Expedia doesn't necessarily learn when I book a flight, but on the back-end maybe they have some granularity of tracking in place with the airlines.)
Josh Mandel (Sep 17 2019 at 13:31):
- Re: Providers setting rules: they have complete control over this because the workflow says: "redirect the patient to a UI hosted by the provider"; it can ask any questions, collect any data needed, etc. No need to encode the rules or business logic with standards, because providers host the Provider Booking Portal UI. (This is what I meant by "step 3 requires no standardization, enabling flexible and provider-specific rules to govern the completion of the booking process" -- but I guess I didn't get it across.)
In other words: we try to avoid things like this from the 2017 Argonaut IG:
Josh Mandel (Sep 17 2019 at 13:31):
- Re: "Is this based on protocol analysis?" definitely not. It's based on UX offered by the protocol --> FHIR API design to accommodate that UX.
Josh Mandel (Sep 17 2019 at 13:31):
- Re: "more of an issue" for patients to sign in, vs. airline customers... perhaps practically, but not for fundamental reasons, and this is generally becoming more streamlined.
Grahame Grieve (Sep 17 2019 at 13:50):
they have complete control over this because the workflow says
well, but that's more in principle than in practice, since the user will end up looking at a long list of options that aren't actually options
Josh Mandel (Sep 17 2019 at 13:52):
It's way better than googling, finding phone numbers, and making serial 5-45min calls, which is how I scheduled my last 4 appointments. I'd far rather know up front who has slots/capacity.
Josh Mandel (Sep 17 2019 at 13:52):
And I actually think providers will care about promoting their brand/service levels here, and will think harder about how to make this easier if/when there's a patient flow into the booking system.
Grahame Grieve (Sep 17 2019 at 13:58):
ok, well, I agree it's better, that's for sure. But I wonder whether the protocol needs to have some capacity for tagging slots, and tagging patients, so that the client can apply some inteligence. Of course, you might want to crawl before sprinting to the far end.
Josh Mandel (Sep 17 2019 at 14:13):
Agreed -- tagging slots (beyond just appointment type/class/specialty) could be a big help, once we learn from experience where the opportunities lie. (And it's something that could begin to happen organically if/when the connections are in place. I've added a note mentioning that HealthcareService.eligibility can be used for this.)
Mikael Rinnetmäki (Sep 18 2019 at 07:57):
FYI, In Finland CGI has implemented FHIR scheduling into their EHR, at least taking influences from the Argonaut IG. There are apps using that interface, for he use case 2 mentioned by @Cooper Thompson, the Patient-to-EHR booking. App providers have also built matching adapters so the same interface can be used with other EHR systems with non-FHIR native scheduling interfaces. Some of the other EHR vendors are building a native FHIR implementation too.
Last updated: Apr 12 2022 at 19:14 UTC
