I did some design sessions with teammates here to get their opinion about this problem, they suggested adding ability of creating appointment blocks dynamically. This will avoid having to create future appointment blocks that may never be used. I’m currently working on this, I hope it will solve the problem.
regards
Okay, I’m still not sure I’m crazy about that approach… flagging @ddesimone for his input.
Take care, Mark
In theory, I think booking appointment blocks dynamically makes sense. The ability to do this would be a useful addition to the scheduling module for implementations where they don’t have capacity or inclination to enter in provider blocks.
I would push for this being permissioned separately so only certain users have the ability to book appointments that automatically create provider blocks. (similar to the way “Show Full Time Blocks” works now).
The Manage Appointment Blocks UI would get very cluttered with many, many separate blocks, but maybe this just wouldn’t be used in this case.
Were you planning on doing this in conjunction with the location_availability table you proposed above? I can see why you proposed this, but to me, the utility of this overlaps a lot with what appointment blocks do for you.
If the biggest issue you are trying to solve is set up time, we’ve always known that someone would eventually need to build in the ability to book recurring appointment blocks and perhaps recurring appointments. As a step towards that, I would be ok with just an enhanced UI from which you could do bulk create and bulk delete of blocks, even if they weren’t managed as recurring or linked to each other on the back end.
This could definitely be the subject of a design forum.
Dave
Definitely would be interested in a design forum!
Also, @jecihjoy feel free to share more details of your design here when you are ready.
I generally agree with @ddesimone… I think being able to create appointment blocks dynamically may make sense in certain cases, but if the main issue you are looking to solve to making it easier to configure appointment blocks, I would vote for adding functionality to create reoccurring appointment blocks, rather than creating appointment blocks “on demand”. Would be good to discuss the various use cases more though.
Take care, Mark
Hello
Apologies took sometimes to get to understand the module little bit more
The reason we were opting for the dynamic creation of appnt blocks over recurring ones was
However with dynamic blocks a user will just select the appnt date which is 3 yrs from now from which just one appnt block will be created for this date.
With regards to that, the following is our proposed design
Creating an appointment_resource data model that will be persisting all the data needed to create an appnt block as follows
This is a one to one mapping with location data model. The above gives more detail on the availability of a location/block.
This design assumes the following existing functionality of the module
a) creating an Appointment Block creates a single Time Slot that fills that whole block.
b)Also assumes there is no need to display timeslot to the user since this will clutter the UI, Instead we provide timeslot information such as the number of scheduled patients
With the above design scheduling an appnt workflow would be:
Populate the appntment_resource data model with a resource/block availability data ie start-time and end-time operation time, services offered their (ie appnt types), excluded dates, start-date and end-date range on when the block will be available for scheduling, if weekends should be allowed or not and provider . A resource is subject to updates ie when a provider ships to another block etc
Once the resource details are provided, scheduling an appnt will be as follows: the payload will look like this, some of this value can be retrieved from the user session ie in our case scheduling an appnt is done just before a visit is stopped
“patient”: “b7009090-4015-11e4-8e9b-2939a1809c7e”,
“status”: “SCHEDULED”,
“appointmentType”: “4d85dda4-c437-11e4-a470-82b0ea87e2d8e”,
“location”: “6351fcf4-e311-4a19-90f9-35667d99a8af”,
“date”: “2019-01-01”
The date property is the scheduled date of the appnt. Once the user makes a POST request, the following is handled from the backend:
a) Use of the date and location from payload to check if the timeslot for that location for that date exists ie timeslot.appointmentBlock.location=location && timeslot.startDate = date if it does set it to the appointment object and save (ie existence of a timeslot means existence of a block)
b) If timeslot doesn’t exist, retrieve the appointment_resource data for that location and create appnt block and timeslot sequentially appointmentResource.location=location and date in the range of the resource start-date and end-date (however i’m not really sure if date validation is necessary since we want ability to schedule appointments any day, please advice) After creating appnt block and timeslot dynamically, Retrieve this timeslot, set it to the appointment object then persist the scheduled appnt
Once the timeslot is created in case (b) above, if a user schedules another appointment with same date and location, case (a) will pass and the scheduled appointment will be persisted, this goes on until the timeslot is full and the timeslot full exception will be thrown
The module can also be designed to accommodate use cases where users want to create multi-timeslots per appnt block so that it can work in both cases ie one where it’s one timeslot per appnt block and multi-timeslots per appnt block in which in this case user intervention will be needed to define timeslot duration or timeslot end time and start time. However I think most implementers have adopted one where single Time Slot fills the whole block, so I was hoping we could focus on this first.
Design Improvements
Both appnt block and appnt resource data models are designed to store same kind of data ie block/resource availability which follows one resource per location mapping (I believe in the case of multiple timeslots we don’t need to create dublicate blocks but multiple timeslots whose originality can be linked to a block/resource) ie daily timeslots for block A for January makes more sense than daily timeslots and daily block A for January
With this we could chose to reduce the data models into a single table if need be but as at now i’m making use of both of the tables ie This is if this design of dynamic blocks is accepted.
@mogoodrich @ddesimone above is our proposed solution in handling the appnt blocks issues
I soo much looking forward to hearing your opinion concerning this and even more on how best we can solve the block issues. If this design makes sense i’ll be soo interested in continuing this discussion through a design call too. Also I have a working branch with the above proposed design working, if it will be interesting I could share the link so that you can have a look.
Please consider, Thank you
Until now i’m not exactly sure what are the advantages of recurring blocks over dynamic ones, could you kindly shade some lights?
However the dynamic block design is more into provider-less blocks but i’m sure we can enhance it to cater efficiently for provider-based blocks.
Regards.
@jecihjoy thanks for sharing the full design, this is very helpful!
I will review in the next few days, I am looking forward to moving this forward!
Take care, Mark
I will so much appreciate to hear from you once you look at it. Thank you
@jecihjoy I had more time today than I expected so have had a chance to give a first look at this. Generally, I think I like it, but want to ask a few questions to make sure I understand it properly:
An Oncology scheduler sets up blocks for a set of clinicians that provide Oncology consults:
And then when a patient needs an Oncology consult, the appt system can list the providers/blocks available:
The advantage I was seeing with reoccurring blocks would be if you build reoccurring blocks then the logic/functionality for scheduling appointments (ie the previous screenshot) would still work out-of-the-box. For “dynamic” blocks we’d need to modify the above functionality to take the appointment_resource into account as well… that is, when looking to make an appointment, the system would need to take into account both existing blocks and blocks that could be created. This seemed like it might take some work, but, that being said, I don’t see anything that would prevent it… was that something you were thinking of adding?
Say you have a provider that works from 8am to 11am and 2pm to 6pm Monday to Friday, so you want to create morning and afternoon blocks for that provider, and you want to schedule them out for the next year. Then would you create two appointment resources as follows:
location_id=1
provider_id=1
start_date=2019-04-01
end_date=2020-04-01
start_time=08:00
end_time=11:00
availability_status=? (what is this for?)
include_weekends=0
location_id=1
provider_id=1
start_date=2019-04-01
end_date=2020-04-01
start_time=14:00
end_time=18:00
availability_status=? (what is this for?)
include_weekends=0
Then if someone wants to schedule the patient for April 17, 2019 at 9am, it would know that if it needed to create a new block for that provider on that day for the appointment, the start time would be 8am and the end time would be 11am?
Does this make sense, and was it what you were thinking?
Take care, Mark
Concerning “how to know time frame to use when making dynamic blocks”, your example is correct. The availability_status column is to be removed, I figured it’s function is handled by the voided column.
I also understand your concerns on how is dynamic block creation will entirely affect the UI, in our use case we were only planning on using the appnt module API so I hadn’t studied the module’s UI enough.
However to avoid interfering with the module’s existing workflow functionality, I had created the dynamic block creation feature in independence in such a way that it won’t affect how appointments are being handled currently.
I was hoping that maybe both dynamic and reoccurring blocks designs should be adopted since both makes sense, in this case we would need to do a detailed design to ensure it is possible
Main concerns with the reoccurring blocks
a)Won’t having soo many appnt blocks in the UI clutter the UI?
b)Managing both group of blocks and single blocks the same time, the issue we had earlier
Hoping to get into a conclusive design that suits both the appnt module users who also use the appointment UI module and those who don’t
Regards.
Ah, cool… so you are not planning on using the Appointment Scheduling UI module, but instead building your own UI?
Take care, Mark
yes, we already have a UI right in place since we were doing patients appointments already, the problem is we still using obs table to store the patient appointments. So we want to make use of appnt module API to easen our work of managing appnts and their reports.
This said, are we going to adopt both the reoccurring and dynamic blocks designs or how best can we achieve easening blocks creation for both Appointment Scheduling UI module users and non users?
Regards.
Thanks @jecihjoy, that makes a lot of sense… let’s discuss more on the design call that is being scheduled, but my gut is that it makes sense to implement some form of the dynamic block design you have come up… then, if in the future we allocate some time to improve the scheduling experience for our users, we could consider our initial idea of reoccuring blocks, or see if we can leverage the functionality you have added instead… this is something that has been on our radar, but isn’t in our current workplan.
Also, I’m not quite sure if there’s a way that this would work, but flagging @jdick here as this is an example of a feature that both PIH and AMPATH use but with different UIs… trying to think if there would be any way for a UI convergence here…
Take care, Mark
It would be great to figure out a common UI solution (as well as backend functionality).
@jecihjoy, do you have any screen shots on how we will use the appointment module? I thought we were still in the design phase of this process but you may be moving faster than I had realized.
@mogoodrich, I think that if you are interested in building a new UI for this we would be happy to collaborate on that with you. Two ways to potentially go about this. One, we could just make it a OWA. Or potentially, if your timeline isn’t too urgent, we could experiment with single-spa approach. Also open to other ideas.
JJ
This is really good, we hope the design call will be soon so that we can actualize the dynamic block creation feature so that we as well can start using the module.
Regards
The issues we were facing currently was how we were storing our appointments data which are being stored as obs, so our adoption of the appointment module will help eliminate the issues, however in terms of the UI we were planning to continue using our the exiting UI
However single-spa sounds great
Jacinta, thanks for creating the google doc:
… I was going to say that I was having a hard time keeping track of all these Talk posts and so having a central design doc will be helpful… I will make any additional comments there (as well as reviewing the exisint Pull Request).
@jdick we don’t have any particular time constraints… we are currently using the Appointment Scheduling UI module and although there are future enhancements we want, none of them are on our short-to-midterm roadmap. It’s just that while we are happy to review enhancements to the module, it would be obviously be much more advantageous to us if we could use them… the easiest way for that to be possible would be if they were added to the existing Appointment Scheduling UI module. Beyond that, I’d vote for a separate OWA, because we could potentially switch out our current implementation with the new OWA. Not sure how single spa would help because we won’t be replacing our existing PIH EMR with a single page app any time in the new future, what we really need is a modular component that could integrated into our existing app .
(side note: which is why I’m still a little unclear of how Single Spa would work unless it provided an underlying framework for hotloading different components, which I’m guessing is beyond the scope of Single Spa)
So my vote would be to implement as a standalone OWA, but I won’t lobby too hard for that because while your MVP will certainly have additional features that we would very much like (like dynamic blocks) I suspect it may not have all the existing features from the appointment scheduling UI module we need, and I wouldn’t want you to build something outside of your preferred method and then no one else ever using it… 
Not sure what the answer is, and not trying to be too much of a downer just kind of thinking out loud of the challenges of the collaborating when we are already starting from different base points. Anyway, interested in your thoughts and lets definitely keep the conversation going… and I’ll add my specific thoughts to the design documents.
Take care, Mark
@jdick and @mogoodrich - wouldn’t “making it an OWA” be consistent with “experimenting with Single Spa” and allow for sharing to occur? If we make a fully client side single page app for appointment scheduling, that seems to be the main thing that would enable what you both want. This can be packaged up as an OWA for incorporation into existing distributions (eg. PIH EMR), and it could be added as a SPA alongside other existing SPA distributions (eg. AMRS), who could experiment with Single-spa to see if they can use this to unify them. Maybe I’m over-simplifying?
Mike
My hope is that single-spa is the type of framework that allows us to how-swap front-end modules. We’ll see if that’s the case as we experiment with it.
We weren’t anticipating re-creating the entire ui for the appointment scheduling module at this time.
However, I think we have underspecified what we need the UI to do. Historically, we have not create appointments at all instead. We have a question on the form about the rtc date for the patient which is stored as an obs.
Would be very good for us to understand your needs for the UI. And then work on creating an improved version in angular.
At this point, I suspect that we ought to create a version that takes your needs into account but build around or own needs for a MVP. When it comes closer to the time on your roadmap for working on this, we could work together towards a second version.
Would be curious to see if anyone else in the community is looking for a project. @c.antwi do you know if there is a dev/designer out there looking for something?