Stream: implementers
Topic: Schedule extension
Isabelle Gibaud (Jun 15 2018 at 15:33):
The French community of vendors are currently working on a use case focused on scheduling through a third-party application:
- The third-party application is able to obtain the following scheduling business rules
* (1) Initial load of the scheduling business rules (initial sharing of the rules)
One Schedule resource per Healthcare service associated within all the resources involved in this Shedule (Practitioner(s)/PractitionerRole, Location(s)/Device(s), etc.)
* (2) Regular notifications from the FHIR Scheduler at each schedule changes.
Once the third-party application is synchronized with the FHIR Scheduler, it controls the schedule information, can create/update/delete appointments and then send these appointments to the FHIR Scheduler.
The French vendor community thinks that the Schedule resource, as it is specified in FHIR STU3.4.0, doesn’t seem appropriate to easily exchange the scheduling business rules for the following reasons:
- In some cases, the Schedule.planningHorizon may not be fulfilled (the Schedule can be covered by a very large period),
-
The slots associated to this Schedule can be fix-sized (1 minute, 5, 10, etc.) or be variable-sized,
(1mn: it means many slots). -
We need to specify that the availability time is recurrent (every Monday, Tuesday, Thursday from 8am to 12 am) and there is no possibility to specify this notion of recurrence at the level of the Schedule resource.
For all these reasons it seems that the number of slots to exchange is too huge.
That’s the reason why the French community considers profiling the Schedule resource in the following way:
- Add an extension busyType (definition of an availibity or unavailability Schedule)
-
Add an extension period (list of periods recurrent or not)
* Rule (iCalendar format) [0..*]
* Start
* End -
Add an extension serviceDuration (specify the duration (in seconds) for the type of service)
I would appreciate your comments on this proposal.
Lloyd McKenzie (Jun 15 2018 at 16:21):
@Brian Postlethwaite
Eric Haas (Jun 15 2018 at 17:07):
Take a look at the Argonaut Scheduling id. This is something we discussed a lot but decided moved out of band for this version.
Isabelle Gibaud (Jun 15 2018 at 19:47):
@Eric, I've read the Argonaut Scheduling IG, thanks for the link, it's very interesting. When you say that you decided moved out of band for this, you mean that you know the issue but the Argonaut team has not solved it and at the moment we have no solution?
Eric Haas (Jun 18 2018 at 21:53):
Is not in scope and handled by some other means ( for example sharing a spreadsheet, off line conversations)
Brett Esler (Jun 21 2018 at 13:59):
Sounds like a 'ScheduleDefinition' i.e. rules to generate schedule instances (which have explicit period); this is out of band for my implementation also at this stage but would like to think about it...
Schedule/Slot aligns with the direct usage search and display for simple stuff e.g demo at http://oridashi.com.au/site/scheduling.html but think synchronising calendar availability definitions is a different thing than Schedule/Slots sets out to achieve
Brian Postlethwaite (Jun 25 2018 at 06:33):
With the proposed variation you will need quite a lot more than you've got described there.
- Timezones (where the system services more than one timezone) - which then apply to your start/end
- exceptions to the general rule (including cancellations for every second thursday of a month due to some meeting)
- cancellations of specific slots
- what happens when slots are filled - they become unavailable - how is that represented with the schedule?
I do agree with your analysis that the number of slots is huge, this is true under any approach - even yours, once you consider the above factors, which always occur. Every slot is realized at some point, if it occurs or not - hence everything is eventually processed.
So what you are pointing at as being large, is what actually occurs, even if you provide the recurring information.
The extensions for busy type, little confused by this, is that to imply that the schedule is always available or not?
I would have thought that the busyType should be in the rule, as that could permit you to include exceptions, when it is available, and when it is not (exceptions), you would also want the recurrence information for the rule (and timezone - so that daylight savings can be calculated)
Is this work that you're proposing documented somewhere? (I'd be happy to collaborate to do more of a write-up and review other issues you may encounter as you progress)
Brian Postlethwaite (Jun 25 2018 at 06:38):
These complications are the same reason why we chose to leave the recurrent definitions from the core appointment, and instead indicate that multiple appointment resources should be created when considering a recurring appointment (and is left outside the specification at this point)
Last updated: Apr 12 2022 at 19:14 UTC
