Stream: implementers
Topic: recurring appointments
Yagami L (Mar 18 2021 at 18:57):
Hi all. We need to have recurring appointments in our system, e.g. an appointment that is every Monday from 2 PM to 3 PM. Based on the appointment documentation: "The resource only describes a single meeting, a series of repeating visits would require multiple appointment resources to be created for each instance." we intend to create an appointment for each date that meets the recurrence in a time window (6 months). But we also need to mark the appointment as recurring (using an extension). What is the right thing to do for creating these recurring appointments?
Lloyd McKenzie (Mar 18 2021 at 19:44):
@Brian Postlethwaite
Yagami L (Mar 19 2021 at 14:00):
What is the best way to handle recurring appointments? Any advice please?
Lloyd McKenzie (Mar 19 2021 at 14:03):
As I re-read your question, I'm not actually clear on the question. You've decided to use an extension to flag them as recurring. (You could also just point to the ServiceRequest the appointments are based on.) There's no 'special' mechanism to create them - the system either generates them itself or you create them one at a time over the REST interface or create them in bulk using 'batch'.
Yagami L (Mar 19 2021 at 14:28):
Currently we create appointments in our ehr from outlook appointments, but we ignored the recurring ones. Our idea is to create these recurring appointments in a bundle transaction in a time window (6 months). If a recurring appointment changes in Outlook, we update and delete it if necessary on our side (in real time). But we also need to mark these appointments in some way so that our system treats them differently.
We wanted to know if this approach is correct? Or any advice? Thanks
Lloyd McKenzie (Mar 19 2021 at 14:38):
The overall appointment that says "this needs to happen ever Tuesday at noon for the next 2 years" wouldn't be an Appointment - it would be a ServiceRequest (or possibly a different request resource). Individual appointments would then be 'basedOn' that ServiceRequest. When the ServiceRequest is revised, future Appointments scheduled based on that ServiceRequest would be modified (or cancelled and re-created). However, the fact that an Appointment points to a ServiceRequest isn't enough to tell you that it's part of a repeating set. Your notion of using an extension to distinguish them seems reasonable. I don't know enough about the space to say whether there's a better way.
Lloyd McKenzie (Mar 19 2021 at 14:38):
@Brian Postlethwaite @Irma Jongeneel
Yagami L (Mar 19 2021 at 14:48):
Thanks @Lloyd McKenzie :+1:
Brian Postlethwaite (Mar 19 2021 at 20:23):
That does indeed sound quite reasonable.
We havent tackled recurring appts yet for many of the reasons above.
If I was doing that mapping I would be including the id from Outlook appt in the apps so you could directly get to them to update. Including doing the variations/cancellations of specific instances.
And while I'm here take extra care on timezones with your start/ends, recurrences may make that painful if you don't consider that the appt is in a state that has daylight savings time, and you're storing utc. That would make your recurring 9am go to 10am, (or worse if it was an international appt where you could get a 2 hour shift, like I get for hl7 meetings with us folks)
Brian Postlethwaite (Mar 19 2021 at 20:24):
A 3pm is eastern US appt is 5am (Australia) during winter for me, and 7am during summer, and 6am during the changeover intervals which changes over the years too.
Lloyd McKenzie (Mar 19 2021 at 21:37):
@Brian Postlethwaite - do you think there's enough known to propose defining a standard extension at this point or should we wait for more experience first?
Brian Postlethwaite (Jun 23 2021 at 20:06):
PA is now starting to consider defining recurring appointments, if you want to join in on the fun, come to our weekly calls, Wed 3p eastern, or just track things on the project page here
https://confluence.hl7.org/display/PA/Recurring+Appointments
Last updated: Apr 12 2022 at 19:14 UTC
