Stream: patient administration WG
Topic: Slots
René Spronk (Mar 19 2020 at 11:00):
If one has slots of various kinds/types, how would one identify that a slot 'can be booked by a patient (using a patient facing App)' as opposed to other slots where this is not the case? Slot.appointmentType would seem like an appropriate place, but it's 0..1, so we'd need a precoordinated new value set to add the 'patient bookable' dimension. @Brian Postlethwaite ?
Martin Grundberg (Apr 02 2020 at 06:16):
We (in Sweden) have the same requirement.
I am not sure it belongs on a Slot.appointmentType though, I dont feel it matches the descriptions, and the preferred codes are for something else than whether the patient can book or not.
We are currently planning for an extension on Slot, called something like patientPermittedActions with a set of booleans. We have requirements to not only configure if a patient can book, it is also if they can rebook, cancel and I also think send a cancellation message (not exactly sure about this last one, it's a national requirement in some way).
We see that we will actually define this sometimes already on the HealthcareService level that we create Slots from. We need a full HealthcareService reference from our slots, it is not enough with the existing Slot.serviceType and Slot.serviceCategory, so I think we have an extension for that as well on the Slot (Slot.healthcareService as a reference or similar).
Need to check if we have Slot.patientPermittedActions as well, but I think so.
I think this is something that should belong as a standard extension in some way. Potentially we should change it to a patientPermittedActions 0..* codeable concepts so it is a bit more flexible rather than our booleans. It is still work in progress. So would be great to hear more about your requirements in detail!
René Spronk (Apr 04 2020 at 09:59):
These are all more or less 'static properties' of a slot. CodeableConcept elements would indeed provide more flexibility, as one could pre-coordonate commonly used settings. My take on it would be to create a complex extension for 'patientBookingProperties'. If we have a lot of settings we might even think of using a special Basic resource (to capture the patientBookingProperties). The advantage of using basic would be that we could reference it from Slot, but also from Schedule (i.e. all slots in that schedule). BTW, my use case in the context of a scheduling scenario in a training course context, as such I don't have any real life implementation feedback.
Cooper Thompson (Apr 06 2020 at 19:27):
This aligns more or less with our (Epic's) concept of "blocks". Being patient schedulable is only one type of block. You might also have blocks for same-day visits, new vs. existing patients, etc. There are also considerations where you may have rules that control how many of a certian type of visit can be scheduled per day. For example, maybe a given practitioner only allows 4 slots per day to be patient-schedulable, but they can be any time of day. Once they have 4 slots filled, then all of the other slots are now no longer patient-schedulable.
Ultimately, for some systems, slots just don't work very well RESTfully, so for the Argonaut scheduling IG, we made an operation that understands who is asking for what when, and then just returns the slots that are appropriate for that recipient.
René Spronk (Apr 08 2020 at 06:36):
I certainly understand the use of operations in this use case. However, in my case the persistence of the FHIR (Slot-) resources is on one server, and the scheduler runs on another server (which itself solely acts as a FHIR Client app). As such I can't use an operation to 'hide' the decision logic as to which slots are patient-schedulable. Something on the Slot (or referenced by the Slot) will need to inform the scheduler.
Last updated: Apr 12 2022 at 19:14 UTC
