Stream: implementers
Topic: scheduling
Ewout Kramer (Mar 15 2016 at 08:30):
We are implementing a scheduling system, where a patient-facing app or portal will allow the patient to reschedule their appointments. Since the workflow for this is simple and does not need asynchronous flows, we prefer to do a straight PUT on the Appointment (and not use pub/sub or AppointmentResponse). We figure it works like this:
- The app does a PUT with the new time (start/end) + reference to the slot + status="proposed" + all participants (with all statuses set to needs-action)
- Server processes any business rules, checks availability (single system, no need for AppointmentResponses)
- On success, returns the Appointment with the status set to "booked", and updates to the participants (status =accepted)
- On failure, returns 422, with an operation outcome detailing the why (mostly non-availability of resources)
This seems to work but two things keep nagging me:
- We use the PUT to start a workflow, and the returned body will always differ from what was sent by the client. I know this is allowed by the spec, but is this the intention of how the Appointment is to be used in a synchronous workflow?
- We chose to return an OperationOutcome, and not an Appointment with participant.status="declined" (and Appointment.status=????), since there might be other reasons the rescheduling failed
Does this make sense?
Brian Postlethwaite (Mar 15 2016 at 08:45):
I would expect that the Appointment would not update (if these were the business rules) and that an OperationOutcome would be returned with the details of what went wrong, and a status of 422
Brian Postlethwaite (Mar 15 2016 at 08:46):
(as you pointed out, this is in the spec here: http://hl7.org/fhir/http.html#2.1.0.10.1)
Brian Postlethwaite (Mar 15 2016 at 08:46):
And yes, in a synchronous appointment booking that would be quite reasonable.
Mat Coolidge (Mar 28 2016 at 14:35):
Anyone have an opinion how to map checkin/arrival time for an appointment?
Mat Coolidge (Mar 28 2016 at 14:37):
just found a relevant gforge ticket: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9276
Brian Postlethwaite (Mar 28 2016 at 21:20):
When the patient arrives, the Encounter begins, and that is where you would record the checkin time. The status would be recorded as arrived.
Mat Coolidge (Apr 04 2016 at 19:18):
Looping back around to this topic, I understand the workflow and it makes perfect sense that the encounter has begun once the patient arrives. Practically speaking our developer is asking for the time in which that occured within his query of appointments. I dont see a way to reference the encounter(s) from an appointment like there is on the encounter backwards to appointment. If there was I could ask that he use _include in the query to get that back and find the start time.
Lloyd McKenzie (Apr 05 2016 at 01:23):
You can use _revinclude. (We try hard to make sure relationships only point way because otherwise things are quite complicated in REST.
Mat Coolidge (Apr 05 2016 at 14:37):
Thanks Lloyd! I guess thats workable, but I am sure other people will want to see the arrival time on upcoming appointments. This was actually driven by a feature request from a physician.
Brian Postlethwaite (Apr 08 2016 at 05:03):
Mat and I have gone through this, and jsut for others benefit, this is essentially 2 queries.
One for the appointments, and another for the Encounters.
The second is required even if doing the revinclude, as walk-ins may not be recorded as an appointment, so need the other call anyway.
Brian Postlethwaite (Apr 08 2016 at 05:04):
The appointment contains the times that are planned, then once the patient arrives, all the actual times are then entered into the encounter (including the arrival time)
Mat Coolidge (Apr 08 2016 at 13:44):
Thanks Brian, one thing we also discussed is our requirement of an estimated arrival time. Our understanding is that this would be an extension on the appointment resource. Also as an FYI, our providers dont allow walk ins. They would instead always schedule a "same day appointment" so for our use case, we will likely be implementing the _revinclude option on the appointments endpoint to return the encounter, drill into that encounters start time.
Michelle (Moseman) Miller (Apr 12 2016 at 13:21):
A couple things caught my attention in this discussion.
First, as part of http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=7873, it was previously advised that "the period that is allocated to the Encounter may be used to describe future/expected end dates." Thus, as much as I would prefer an explicit estimated period (for estimated arrival and estimated departure dates), it seems like the guidance was to use the existing period, such that I assume the status would then imply whether the dates were estimated or actuals. Has this guidance changed to using an extension now for estimated dates?
Second, I am wondering if we have the ability to calculate patient wait times based on registration date versus arrival date? Is the recommendation to use the Encounter.location.period and assume that there is a waiting room location that could be used to infer the wait time? If this is a common KPI (key performance indicator), then it seems cumbersome to understand all possible locations in order to calculate this.
Brian Postlethwaite (Apr 12 2016 at 13:29):
Patient wait times would be in the status history, the length of time in the arrived status.
Isthis is what you were looking for, the amount of time that the patient spent waiting before being seen?
Michelle (Moseman) Miller (Apr 12 2016 at 23:11):
FYI... Our system doesn't have an "arrived" status, specifically, but we do track the dates and times....which leads to the question whether we should be mapping to FHIR's "arrived" status based on some combination of dates and our status. We're internally discussing the implications of doing so....
Brian Postlethwaite (Apr 13 2016 at 02:03):
Thanks for the info. Interested to hear where you get to and if you represent tracking the arrived state anywhere in your system.
Michelle (Moseman) Miller (May 28 2016 at 04:54):
We determined that we aren't going to map to Encounter.status of arrived because the registration date/time is not a reliable way to know when the patient was seen (i.e. knowing when to change the status from arrived to in progress) as registration can happen before or after the patient is seen.
That said, we do track the patient seen date/time on the appointment (just not the encounter). I believe our wait time KPIs are all driving off the appointment, not encounter.
Last updated: Apr 12 2022 at 19:14 UTC
