Propose an Appointment

[Mikhail Polatov]

Hi,

When our scheduler wants to *propose* an Appointment, it needs to specify Practitioner reference along with Patient and Location, rather than your engine choosing an available Practitioner at a specified time slot.

This is currently not supported by Cerner, but should be within HL7 scope.

Any chance you could you into it?

Thank you!

-Mikhail

[Richard Leaf]

Hi Mikhail,

With Millennium scheduling we don't take in the Practitioner reference when creating either a booked or proposed appointment.  We derive the Practitioner from the Slot ID when booking the appointment.  The FHIR specification does include that reference in the actors, however we would not have the ability to return the reference information to the FHIR consumer to identify which Practitioner is associated to a specific serviceCategory, and we would not want proposed appointments being creating in FHIR for serviceCategories that the Practitioner is not associated with.

-Richard

[Mikhail Polatov]

Richard,

Booking is not a problem. As you stated, booking is done into a slot already tied to a Practitioner ID - no issues here.

But proposing is a problem.

If we build a schedule by querying available slots for a given serviceCategory (and hence we derive Practitioner Set supporting that category), why it is a problem to propose a time slot to a Practitioner from that derived set?

To be more specific, we want to propose to double-book into a specific Appointment, so we know that specific Practitioner has/had a Slot associated with it.

This is crucial functionality for us and our clients, so we much appreciate any help on this topic.

Thank you!

-Mikhail

[Mikhail Polatov]

Bumping this up.

Just to reiterate - this is very crucial piece of functionality to offer double booking into a specific slot based on our algo.

The slot we're double-booking into already matching serviceCategory/Practitioner, and obviously have Slot resource associated with it ("booked" status).

All you need to do is just take provided Practitioner into consideration (with a validation of course), and don't try to propose to any other random/free slot.

Really appreciate your help on this issue.

Thank you!

-Mikhail

[Richard Leaf]

Hi there, I'm not 100% tracking what you're trying to accomplish.  When you say "double book" what are you referring to? Our FHIR resources do not allow for double booking - once a Slot is occupied with a booked appointment, it cannot be utilized for other purpose.  Similarly, we do not have any workflows where we update or change participants on any Appointment booked in millennium in a FHIR workflow.

[Mikhail Polatov]

Almost every practice double-books some time slots - widely known old method to deal with no-show rates, and practices actively use it.

I'm finding hard to believe (well, unless you say so :) that your Millennium Front-End does not allow to put two patients into a single time-slot...

You are correct - we cannot create "booked" Appointment into already occupied Slot.

Hence we're trying to "propose".

When we create "proposed" appointment,  we cannot set a reference to a Slot (don't have it), so according to the documentation, we must specify Location and set status as "needs-action".

We also specify requestedPeriod - and we really want to be very specific about it.

But the issue is that Millennium book this appointment to a random free slot to a random Practitioner at this Location  instead of time we requested.

Not only we want Millennium to stick to our proposed requestedPeriod, we want it to also consider Practitioner we provide (not supported now).

We understand this is something you currently don't support, but is there any workaround, or a chance you build support in the near future?

Again double-booking is a very basic functionality every single scheduler has had since beginning of days, and it's up to a particular practice policy to allow it or not.

Please advise.

Thanks,

-Mikhail

[Mikhail Polatov]

Well, after some testing, it appears your backend does support double-booking - we were able to have two Appointments (one booked, one proposed) at the same time-slot at the same Practitioner.

booking into a slot 24477854-21304876-63640599-525

location_id: 21304876 
practitioner_id: 12742614 
patient_id: 12724065 
start: 2021-10-15 21:45:00 UTC 

214607.566403Z IN sent https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Appointment => (POST,X-Request-ID=b425c8889129f3a957a02ef0c226a74eed61ab11d30943e1ec562d73693d52c7)
214608.756693Z IN recv https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Appointment <= (201,X-Request-ID=b425c8889129f3a957a02ef0c226a74eed61ab11d30943e1ec562d73693d52c7)
                                                                                                                                                                                                                                                                                        
Booked, appointment id: 4836013

Then we sent a request to create proposed Appointment for a different patient into the same Location/start time:
                                                                                                                                                                                                                                                                                        
location_id: 21304876
patient_id: 12724070 
start: 2021-10-15 21:45:00 UTC 

215911.915334Z IN sent https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Appointment => (POST,X-Request-ID=7caed8c2dc7c4b3befd0753e6afa4f85732eefcea57deaf15a21a5d7f6a2f71f)
215913.186453Z IN recv https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Appointment <= (201,X-Request-ID=7caed8c2dc7c4b3befd0753e6afa4f85732eefcea57deaf15a21a5d7f6a2f71f)

Your backed did chose the same slot/Practitioner as above:

start: 2021-10-15 21:45:00 UTC
practitioner_id: 12742614

Proposed, appointment_id: 4836016

Here we are, two Appointments (Booked, id: 4836013) and (Proposed, id: 4836016) at the same time slot/Practitioner - accidentally chosen by your backend.

So, what we are looking for, is an ability to specify Practitioner when we PROPOSE an Appointment, and your backend that that into consideration instead of looking for a random free slot.

We would greatly appreciate if this would be considered for short-mid term implementation.

Thank you!
-Mikhail

[Richard Leaf]

Thanks for the clarifications Mikhail - Millennium does support the features that you describe (double/over booking, specifying resources for proposed appointments, etc.), but we just have not exposed them through the FHIR services yet. Our backend services that FHIR consumes also allow the ability to pass in a Practitioner when creating the proposed appointment, so in theory if FHIR opened that up, you would be able to create a proposed appointment using the requestedPeriod that exactly matches the slot times of an existing appointment.  However, workflow wise, that would not show up as an over booked appointment on any views in Millennium and would require a Millennium user to still book the appointment. 

We do have the concept of "standby requests" which I think more align with what you are trying to accomplish with this specific workflow, wherein someone can be booked if an appointment cancels and we want to fill that slot back in, but that type of appointment request is not supported through our FHIR workflows.

[Mikhail Polatov]

Richard,

Standby appointments (with auto-fill after cancelling) is more complex flow and may not perfectly fit, as patients simply don't show up without calling and cancelling (in fact majority of them).

Two appointments may exist till the very end, with one getting marked as no-show.

So,  creating proposed Appointment exactly at the specified Practitioner and requestedPeriod maybe much better approach, even if would require manual approval (as with any other proposed Appointment).

Also it seems you have all bit's and prices for it as well (just propagate down Practitioner and use it when specified).

Any chance you could add this to your roadmap for implementation?

Much appreciated for all your help!

Thank you!

-Mikhail

[Richard Leaf]

Even if creating the proposed appointment with a duration matching an existing appointment as an overbook, it would still not be faceup/visible to anyone looking at a scheduling view in Millennium. The FHIR scheduling approach is very iCal like, but that does not translate well into Millennium as a scheduling view. For example, when I send you a calendar invite for 1:00pm outlook will put it on your calendar as tentative.  It does not work like that in any workflows in Millennium when using Appointment Requests, they live in separate views and the scheduling user/provider would never see the adjacent appointment in their normal views alongside fully booked appointments.

I don't think this is something we'll be able to put on our roadmap at this time.

[Mikhail Polatov]

I see...

Couple of questions:

1. Given all your explanations (thanks again), what's the actual purpose of proposed appointments if they not integrating well with Millennium?

2. Your second idea - standby requests - is that something you're looking to support via FHIR short/mid term?

3. Another approach (related to #2) if you could allow users to create StandBy Slots (with status  busy-tentative) - this is aligned with FHIR/R4. Does that make sense?

Still trying to seek for an option here to fill the gap in scheduling flow.

Thanks,

-Mikhail

[Richard Leaf]

Proposed appointments do integrate into Millennium, they just do it in a way that's not compatible with how FHIR and iCal work :)  Millennium actually has several kinds of appointment requests that drive different workflows, but the integration for FHIR is specific only to a "book" or new appointment workflow.  In Millennium, our book requests (proposed FHIR appointment) are sent to a queue. This is most often the case when, as an example, a practitioner signs an order for a patient and the order has the configuration to trigger a book appointment request. Then someone in the practice or a centralized scheduling would work through the queue and book appointments as the requestedPeriod for the appointment dictates. With FHIR, this now gives the FHIR consumer (either as a patient in an app, or a centralized scheduling system integrated with a CRM system) the ability to find these book appointment requests and complete them through a FHIR workflow rather than using Millennium directly.  The API also allows for the creation of a proposed appointment, giving the FHIR consumer the ability to request a new appointment if there are environments/configurations where a practice may not allow direct booking of appointments.

Since FHIR only has one proposed status for an appointment, we mapped that to the book (new appointment) request in Millennium. In Millennium, the Standby request is associated to the Appointment, and to return those through FHIR would require us to somehow send the FHIR consumer an appointment with the same ID but in two different states.  That would not be compatible with the FHIR API.  Without a significant change/remodel of the FHIR API, I don't see us having Standby requests exposed through FHIR, and is not anything that is on our current roadmap.

We do support making slots busy-tentative in our R4 implementation, but as a way to lock or reserve a slot in part of a booking workflow. This workflow is primarily intended for the types of scheduling interfaces where the consumer identifies a time before the identity of the consumer is known, so the consumer can select the slot, reserve it, and then authenticate/create their account, and complete the scheduling workflow. The busy-tentative status of the slot automatically expires after 15 minutes and is definitely not intended to be a long term appointment reservation tool, which is how I think you are envisioning it.