Stream: argonaut
Topic: Scheduling Availability Operation
Cooper Thompson (Jun 08 2017 at 22:22):
Based on our recent discussions, I've roughed out a new OperationDefinintion for appointment availability search here: https://simplifier.net/Scheduling/Appointment-availability2
Grahame Grieve (Jun 08 2017 at 22:56):
does it make sense to add a parameter to ask the server to choose the first/best available as an option for the client?
Grahame Grieve (Jun 08 2017 at 22:57):
I think that an array of proposal : Appointment is better than a bundle
Grahame Grieve (Jun 08 2017 at 22:57):
(syntactical point only)
Grahame Grieve (Jun 08 2017 at 22:58):
does it make sense for a server to be able to return a recommendation for another service if there's no available appointments?
Grahame Grieve (Jun 08 2017 at 22:58):
and I think that the definition of the operation should be in the main specification, though I expect Argonaut to profile it. Yes?
Eric Haas (Jun 08 2017 at 23:27):
What does "array of proposal : Appointment" mean. BTW my idea is to return a bundle of intent = "proposed" pre-filled appt resources. the user picks one and then the app changes "proposed" to "ordered" and returns appt (as a second operation? or an update?) to server which confirms.
Eric Haas (Jun 08 2017 at 23:31):
Well I think Argo should bang on the operation a bit. don't care where it goes. Re profiling an operation. I expect will profile the Appt resource going in to define the bare minimums per use case. Never profiled an operationDef before is that technically similar to profiling an SD?
Grahame Grieve (Jun 09 2017 at 00:48):
well, the operation as proposed returns a bundle of appointments, like a search, but with a separate operationoutcome. it would be better, I think, to use parameters directly, a list of appointments, rather than putting them inside a bundle
Eric Haas (Jun 09 2017 at 01:52):
K thanks.
Cooper Thompson (Jun 09 2017 at 13:38):
FYI - I got this feedback from some folks who work with ZocDoc. This confirms ourguess that they do indeed pre-fetch availability:
What we've seen in the wild for organizations who use ZocDoc is that they aggressively prefetch slots. Initially they were fetching slots for all doctors every 10 minutes, but we had to tune that in order to reduce the load on our servers. But their preference is to build their own cache of slots.
Eric Haas (Jun 10 2017 at 02:10):
Here is an updated Interaction Diagram for the Pre-fetching work-flow
Eric Haas (Jun 14 2017 at 18:42):
@Grahame Grieve @Cooper Thompson @Brian Postlethwaite (new) What is the benefit of Parameter over a Bundle?
Grahame Grieve (Jun 14 2017 at 19:32):
there's 2 benefits. I think: it's syntactically simpler, and allows you to indicate the reason for including a resource
Brian Postlethwaite (Jun 14 2017 at 23:01):
I prefer the bundle as it then gives you the paging constructs if needed. the simple parameters can't do that.
Brian Postlethwaite (Jun 14 2017 at 23:02):
Especially if the potential list of appointments could be large, let the client choose.
Grahame Grieve (Jun 14 2017 at 23:12):
then the way the operation is defined, the only output should be the bundle, and there'll never be an option for a more refined response than 'here's the list of possible appointments'
Eric Haas (Jun 15 2017 at 01:30):
The only output is a Bundle or an OperationOutput right? On our call today we decided that using Appointment as an input parameter was not appropriate and went back to plan A. I'm updating Coopers DSTU operation to STU3 and adding some more details. I don't have a dog in this hunt on Bundle vs Parameters but brought it up today for folks to consider. Also is this operation indempotent? I'm guessing yes....
Eric Haas (Jun 15 2017 at 01:31):
plan A = listing the multiple inputs as parameters
Grahame Grieve (Jun 15 2017 at 01:44):
I proposed a parameter to ask the server to just make the appointment. That wouldn't be idempotent
Grahame Grieve (Jun 15 2017 at 01:44):
otherwise it is.
Grahame Grieve (Jun 15 2017 at 01:45):
if it's just a smart query with paging, then only document output is a Bundle, which a note that it's the same as a search bundle
Eric Haas (Jun 15 2017 at 14:41):
I will bring up your proposals on the call ( ran out of time yesterday ).
Jenni Syed (Jun 15 2017 at 18:45):
I don't think we're proposing that this makes the actual appointment - I think it returens all options the user could choose from. Even if there is only one, I think we would want confirmation before creating it.
Grahame Grieve (Jun 15 2017 at 21:33):
i'm happy if you want not to auto-create an actual appointment, and in lots of cases that makes sense. but I've seen other protocols - particularly within institutions, where that is the practice. So I think it's int the space of the operation definition even if it's not in the argonaut space
Eric Haas (Jun 15 2017 at 21:39):
"The operation" meaning a separate operation or the same one we are working on. Scheduling the next available for a client automatically seems like a great idea - but what percentages of patients/client will need to reschedule or cancel ?
Eric Haas (Jun 15 2017 at 21:58):
vs the baseline?
Grahame Grieve (Jun 15 2017 at 21:59):
depends on the business rules. Like I said, it's usually with in an institution where needing to reschedule is rare (patients don't get to have a life). In the outpatient/ambulatory context (argonaut context) it doesn't make sense
Eric Haas (Jun 20 2017 at 18:31):
Draft updated R3 appointment$find
Eric Haas (Jun 20 2017 at 18:40):
Spoke with ShareCare and ZocDoc yesterday. One thing that we the Argo scheduling team didn't discuss was whether we need some sort of 'configuration transaction' so the app can retrieve data to perform there own logic for schedule availability. in other words, providing them with enough information to screen suitable patients for a given appointment. I feel that this is in scope or at the very least we need to document it. Also, this kind of relates to the slides that @Brian Postlethwaite (new) shared.
Eric Haas (Jun 21 2017 at 20:00):
Also after creating a couple of examples for the Appointment$find discovered/created a bunch of issues for the operation.
Eric Haas (Jun 28 2017 at 17:04):
discussion about Appt Availability and indicating preferences ( e.g., My first choice is this time period, my second is this time period) using OperationDefinition could we indicate preference using an input parameter 'preference' of type integer with a nested parameter = appt template?
Jenni Syed (Jun 28 2017 at 17:18):
I know I gave my example as preferred, but I'm not sure if we need to consider that immediately. However, still worth figuring out how to represent something like that/if it's currently possible
Jenni Syed (Jun 28 2017 at 17:18):
I was trying to make sure we could handle "OR" and "AND" with the model being proposed
Eric Haas (Jun 28 2017 at 17:30):
I'm not sure that we have clarified the OR and AND when it come to the inputs.
My Assumptions:
- \>1 requested times is an OR
- \>1 Specialties or Providers or Services is unclear
- \>1 locations is an OR
(logged as an issue) We will be talking about a SPRINT on today's call to help discover and flesh out these issues.
Brian Postlethwaite (Jul 04 2017 at 03:23):
The order of the time ranges listed could have a meaning. Then don't need flags.
There is no mention that they should be sequential
nicola (RIO/SS) (Sep 07 2017 at 22:49):
Hi all, we will potentially join this project. Why availability is represented as Appointment operation, why not Slot?
Eric Haas (Sep 08 2017 at 01:02):
Since there may be codependencies of several slots for multiple physical assets for a single appointment, it doesn't sense to share them with the client and instead aggregate it into a set of avaialable Appointments. The Server deals with the slots in the backgrounds.
nicola (RIO/SS) (Sep 08 2017 at 18:43):
@Eric Haas Could you share more details and may be some examples / real cases about this?
nicola (RIO/SS) (Sep 08 2017 at 21:03):
I think, i've got it - slot is just free/busy time for specific resource or actor. An appointment could be related to many actors and these relations could be very specific - that's why you provide vendor/case specific operation $find for that.
Last updated: Apr 12 2022 at 19:14 UTC
