Stream: implementers
Topic: Appointment Request
Isabelle Gibaud (Jun 11 2018 at 14:40):
There is an AppointmentResponse resource in the FHIR spec but no AppointmentRequest. So my question is : what resource do I need to use use to make an appointment? Is it the Appointment resource (with a particular status)? If yes, how do we differentiate the Appointment resource as the object of appointment from the Appointment resource as the request of the appointment?
Jose Costa Teixeira (Jun 11 2018 at 14:43):
good point, @Isabelle Gibaud the resource seems to be Appointment,
Jose Costa Teixeira (Jun 11 2018 at 14:43):
but I am not at ease where it says "The Appointment request pattern used is different from the order-response pattern used elsewhere in FHIR. This is due to the close relationship to the iCal standard."
Lloyd McKenzie (Jun 11 2018 at 14:43):
Appointment works sort of like iCal. When an appointment is scheduled, all of the participants are invited. They can then indicate whether they're planning to come or not.
Lloyd McKenzie (Jun 11 2018 at 14:43):
You can check people's calendars by querying for open slots before scheduling the appointment
Jose Costa Teixeira (Jun 11 2018 at 14:44):
an iCal invite seems considerably consistent with the request pattern
Lloyd McKenzie (Jun 11 2018 at 14:44):
With the request pattern, there's essentially an "order" that can then be fulfilled. That's not what happens with an appointment.
Jose Costa Teixeira (Jun 11 2018 at 14:45):
hmmm, from a user perspective, i'd say that iCal works with a request (invite) and a response (confirmation). How does it differ?
I may have to read on iCal.
Jose Costa Teixeira (Jun 11 2018 at 14:47):
(note, i am not interested in forcing the pattern, but it just seems quite aligned)
Jose Costa Teixeira (Jun 11 2018 at 14:48):
this sounds like a good excuse not to miss the workflow call today.
Lloyd McKenzie (Jun 11 2018 at 14:51):
The confirmation isn't an Event. It's essentially an update of the Request indicating someone who plans to attend.
Jose Costa Teixeira (Jun 11 2018 at 14:52):
yep.
Isabelle Gibaud (Jun 11 2018 at 14:55):
Thank you for your answers. So I understand that I must use the Appointment resource, OK. In some use cases, the application will exchange an Appointment and in other use cases the application will exchange an appointment request (same resource = Appointment). How the receiving application will make the difference between the two use cases (same resource used, but the two resources have not same semantic)?
Jose Costa Teixeira (Jun 11 2018 at 14:58):
Right. I am looking at ordering workflows (we will have many scenarios where there is an update without having an event - this is why in my mind an update is an event itself.). It's worth a later discussion for this. for now...
Jose Costa Teixeira (Jun 11 2018 at 14:58):
@Isabelle Gibaud :
12.11.1.1 The basic workflow to create an appointment
Making the Appointment Request
When an appointment is required, a requester creates new Appointment resource with the Appointment.status="proposed".
All included participants (optional or mandatory) should have the status="needs-action" to allow filtering and displaying appointments to user-participants for accepting or rejecting new and updated requests. Based on internal system business rules, certain statuses may be automatically updated, for example: "reject because the requested participant is on vacation" or "this type of user is not allowed to request those specific appointments".
Replying to the request
The reply process is simply performed by the person/system handing the requests updating the participant statuses as needed. If there are multiple systems involved, then these will create AppointmentResponse entries with the desired statuses.
Once all participants have their participation status created/updated (and the main system marking the appointment participant records with the AppointmentResponse statuses) then the overall status of the Appointment is updated.
Lloyd McKenzie (Jun 11 2018 at 14:59):
Status of "proposed" vs. "booked" I guess
Isabelle Gibaud (Jun 11 2018 at 15:02):
Thank you lloyd and Jose, your answers are very clear :relaxed:
John Moehrke (Jun 11 2018 at 15:23):
Hence why it is not useful for FHIR to re-invent other standards... Where iCal standard satisfies, we should not be duplicating. At least without defining exactly why and how we interact with that standard.
Last updated: Apr 12 2022 at 19:14 UTC
