Patient Appointment Scheduling - Integration with other forms

Development
, ,
Tags: #<Tag:0x00007f8280f46050> #<Tag:0x00007f8280f45f88> #<Tag:0x00007f8280f45ec0>
#1

I would like to find out how to integrate appointment scheduling into our existing flows across multiple encounter types and data entry forms as we provide support for point of service within UgandaEMR

  1. Currently we use the Return Visit Date concept Id 5096 to capture when the patients are to come back for the next visit

  2. I would like to see a calendar of total number of patients visiting each day and what encounter type they are visiting for

  3. Can I manage the load - give a warning for new entries when the load for that date is reached (how can I define the rules)

  4. Being public health facilities, and free services, the visits are not tied to time or to providers despite being able to predict that 80% of the providers will be the same (maybe it can be an option)

  5. Optional: Add the ability to reschedule an appointment to a new date … (still trying to figure out how this one will work out) but its possible

Design Forum 2018-06-25: Patient Appointment Scheduling
Propose a Design Forum Topic
#2

@ssmusoke, thanks for the discussion. We are tackling similar questions. We use the appointment scheduling module in some clinics but also simply use a “Next Visit Date” concept within encounters of various types in other implementations, and we are trying to determine the best-of-breed approach of where one vs. the other is correct and how the two are best used. @ddesimone and @mogoodrich would be good to get involved in the discussion.

#3

Just had a thought, if the current appointment scheduling UI is using REST resources then maybe in addition to the default REST resource from the database tables, we can add the ability to also pull those from the Next Visit Date concept.

#4

@ssmusoke if you’re not otherwise using the appointment scheduling module, then I would not suggest involving it in the solution to your issue. Because its data model doesn’t align, it’s not really going to help.

You could build a simple widget that shows the number of scheduled visits by day (based on obs for concept 5096). This could be accessible from the homepage (or wherever).

Then, on your form where you ask for next visit date you could have a link that opens the daily-load widget for 1 month away, in a separate tab.

(If you are really fancy you could create an HTML Form Entry widget specifically for “next visit date” which would provide an even better calendar popup.)

#5

@darius being lazy (in the large), I considered adding just a widget however it does not cater for the rest of the requirements. Also the approach we are using for UgandaEMR is no custom code, it should just be configuration - the workflows and all belong within Ref App/OpenMRS Core

In your knowledge is there anything similar in Bhamni that we can leverage?

#6

I think you’re being a bit too dogmatic about this – it’s not the case that the reference application is going to be exactly right for any country…

If I were doing this I would probably create a new module called simplisticappointments or returnvisitdate which handles exactly this use case. It’s probably a common use case, so maybe you could get others to collaborate on it, e.g. PIH might presumably be interested based on Mike’s comments above. I would make sure to keep this module as small as possible, and not let it creep into somehow becoming a real appointment scheduling system.

The alternative is that you could try to define as much as possible as reusable widgets, which are appropriate to build in the coreapps module:

  • (2) calendar showing counts of obs for concepts with datatype=date
    • it’s a bit more of a stretch to have this widget also do grouping by encounter type, but okay, I guess
  • (3) if you’re using HTML Form Entry to actually record the obs, then maybe add support for some kind of js-driven REST call that displays a warning if the load is too high. (This means coding that logic into the form itself.)
  • (5) You’d need to decide how to actually handle this, e.g. do you need to void the old obs? or just say that only the latest-recorded obs for this concept is value (maybe by encounter type).
#7

Just a principle as it forces us to think out of the box and focus on building more generic functionality.

Thank you @darius this makes sense, @mseaton what do you think? This way we can isolate the widgets, dashboards in a single location. I can kickstart by writing out a needs document.

#8

I am now playing devils advocate, what would stop “simple appointments” from being part of the appointment scheduling & appointment scheduling ui modules? They are already included in Ref App and other distributions

Just like HTML Form Entry has StandardUI and Simple UI flows…

#9

@ssmusoke, @ddesimone, @mogoodrich , it would be useful to set up some design time to talk this through, where we could review the current appointmentscheduling capabilities and data model, and look at how this dovetails with the needs you describe. Mark, Dave, and I have debated and discussed changes to appointmentscheduling in the past around some of these same issues. Personally, I’d like to see us remove some of the built-in assumptions in appointment scheduling to make it more flexible.

Mike

#10

Yes, definitely interested in discussing this. Our stakeholders for some of our current projects are asking for some (but not all) of this functionality in booking appointments and we will need to make a decision on how to proceed with this sooner, rather than later.

#11

@ddesimone @mseaton I am bringing this back up on the table, as we have received multiple requests for it again. Have you done any work around this? Is this scheduled anywhere in your short-to-medium term activities?

#12

@ssmusoke - We have not done any work around this and even though we still have needs here, with our other priorities, we probably will not get to this anytime soon (though sometimes priorities change, of course).

We can definitely get on a call and discuss the needs we’ve heard from our stakeholders though.