Calendar Changes - Project Proposals

During last Saturday’s weekly conference call we discussed adding the ability to schedule an order-able list of patients on the calendar that is not time-based.

Brady mentioned that there has been some interest in the past for a feature like this, particularly by practices that put patients on a list for a given day without scheduling actual times.

The types of practices that might have use for this type of scheduling feature might be:
(1) Urgent care/ER practices
(2) Practices in third world countries that have a more informal method for scheduling
(3) Practices that do home visits (like mine).

I would like to try to do this project as a core project (not a module.). And, I would like to add the feature to the calendar without changing how it works.

During the last week, I have been looking at how the scheduling calendar functions and how it is coded. I have also been brainstorming some ideas of how to implement the scheduling of an order-able list of patients.

Creating A New Provider Category - Patient List
When you click on a time to create a new appointment, you have the option to create two different types of Events – a “patient” event or a “provider” event.

Please note that I will refer to appointments as events since that is how the OpenEMR code refers to appointments. The table used to save appointments is called ‘openemr_postcalendar_events’.

I would create a new category of “provider” event and call it “Patient List”.

This category would have a start time and an end time and all of the other features of other provider event categories.

When this Patient List block is displayed in the calendar, it would be displayed the same way other provider events are displayed. However, inside the block, we would need to display the list of patients scheduled during that block. I don’t think this would be very difficult.

Scheduling Appointments inside the Patient List Appointment Block
When clicking on the patient list scheduling block, there would need to be two different types of popups.
(1) Edit the Patient List Event.
(2) Add/Edit Patients in the Patient List.

The top of the patient list block would have the label “PATIENT LIST”. Clicking on that would open a popup to edit the patient list provider event.

Next to the label “PATIENT LIST” would be a plus icon. Clicking on that would open a popup to add a patient event just like clicking on a time to schedule a patient in a time slot. However, the popup would be slightly different. There would be no provider tab and no date/time entry. There would be an additional input box for order number.

Clicking on a patient name in the list (if there are any) would open a popup to edit the patient event.

Database Storage for the Patient List Appointment Block
All of the appointments for patients scheduled in the patient list block would be stored in the same table that all other appointments are stored in – ‘openemr_postcalendar_events’.

Two new columns in the table ‘openemr_postcalendar_events’ would be created:
(1) pc_patient_list_item (type = boolean)
(2) pc_patient_list_order_no

The columns for start time and duration for the patients in the patient list would match the start time and duration for the patient list block that they are in.

Calendar Code Upgrade
The current scheduling calendar in openemr is outdated, does not display well, and needs new modern features, such as drag and drop to change appointment time and duration.

It is based on an open source project that no longer exists, is no longer updated, and is not coded in a way that is easy to read and modify:
PostCalendar - PostNuke Events Calendar Module

There is an open source calendar project that is modernized, has a better UI, displays well, is coded well, and is still actively maintained/updated. It was even discussed in the forums five years ago:

In their website, click on demo, then login to see their calendar scheduler.

Its basic design and structure is almost identical to the calendar in OpenEMR. However, it is just more modernized with additional features and design tweaks.

If you look at it superficially, it even looks like it could be a fork from the PostNuke Events Calendar Module (but it is not and the coding is very different).

I know this calendar upgrade/replacement would be a major endevour, but I don’t think it would be too big or too difficult.

I would like to hear everyone’s thoughts about my proposals.

Thank you,
David Eschelbacher

1 Like

Recommend leaving calendar untouched since its core purpose is scheduling with focus on capacity constraints. The application does need enhancements in some of the scenarios mentioned above.

First In First Out practices like ER, Urgent Care should be using Flow feature exclusively without need for calendar/appointment records. This also applies to practices that schedule appointments but also accept walk-ins. As a good data practice, a walk-in visit should have no appointment record because patient did not make one.

All other cases proposed to be handled by patient lists are really patient related planned items with a target date and need for reminders. CDR engine already provides infrastructure for such information. Only development needed will be to allow (or more specifically not delete when recalculating) manual entries. There will be some additional work to improve user interface and reporting.


After further look at the EasyAppointments code, there are a lot of things that it does that is not relevant to the calendar and the code that does the database calls is very very different from the way that openemr does it. Therefore, I don’t think it is worth trying to replace the current calendar with EasyAppointments.

However, I will probably try to implement some of the EasyAppointments features, and examine the EasyAppointments code to use as a framework for adding those features.

In Regards to MDSupport’s Comments:
My personal case scenario would fall under the “All other cases proposed” category.

How do you access/use “patient lists”?
What menu function do you use to get to it?

@psoas If guessing, you probably have two scenarios

  1. hard plan to see a patient on a specific date (and in some cases at specific time)
  2. Promise/Soft plan to a patient within an interval, e.g. follow up in 6 weeks

Calendar as a scheduling and capacity management tool will handle first. Until your plans are firmed, you can enter appointments for a range like full day, morning hours etc. Then prior day or throughout the day you can plan the order and change the appt time if you wish to get ordered list.

Second scenario (we broadly call it followup) is a hole in emr functionality leaving each practice to come up with random ways to meet this real life requirement. Followups are plans with a date (+ time) to be firmed into an appointment and continue to be open item until an encounter record is created in case of missed appointments. CDR has all that code. But it is unnecessarily complex code coupled with horrible user interface which meets MU requirements but renders it useless for average practice. We ended up implementing CDR categories+action combinations that are stored in standard rule_patient_data table but processed by our workflow engine rather than standard CDR. This was the development effort referred in prior response.

In standard code your Patient list is accessed using the well camouflaged menu path Administration->Patients->Patient Reminders.