Stream: patient administration WG
Topic: Appointments
René Spronk (Mar 05 2020 at 13:47):
If we have an Appointment [request] associated with 3 actors, and one of these (or rather: their scheduling application) decides to reject because of a conflict, the overall scheduler would need to set the status of one of the other actors to needs-action, notably for the actor that initiated/proposed the scheduling. However, this is not known to the scheduler. The scheduler will know that Actor '#3' has rejected it. Actors #1 and #2 may already have accepted it. So would the scheduler just set the status of both to 'needs-action' ?
We may need an actor-status parameter, to query for participant-status for some specified actor.
Brian Postlethwaite (Mar 09 2020 at 10:43):
That would depend on your systems requirements. The spec is silent on the behaviour here.
It could be that the appointment would be cancelled, rescheduled, or otherwise and could also incur costs, or not, maybe depending on timing.
Not an easy area.
Brian Postlethwaite (Jun 23 2021 at 20:04):
PA has started a project to define how recurring appointments, requirements are being collated here on Confluence https://confluence.hl7.org/display/PA/Recurring+Appointments
Brian Postlethwaite (Jun 30 2021 at 21:11):
The iCal spec has some good detail on recurring appointments, will review that on the next call too...
https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.5
Have started the draft of the changes for recurring appointments
Brian Postlethwaite (Jul 07 2021 at 20:29):
The base draft is looking in reasonable shape on the working page, enough that we're going to put something into the core specification for discussion and review.
Of note is the choice to define the recurrence properties not using the Timing datatype - will want feedback on that.
And propose to do some sample resource drafting of what using the timing datatype would look like in comparison.
Last updated: Apr 12 2022 at 19:14 UTC
