UgandaEMR Bed Management

Continuing the discussion from Queue module as a basis for managing inpatients, specifically:

I spent some time with the esm-ugandaemr-bed-management-app today, getting it installed and exploring it’s features, and my takeaway is that the functionality within it falls into 2 categories:

  1. Bed Administration - these features rely entirely on the bedmanagement module API and REST endpoints, and focus on administering the beds in a ward - managing bed types, managing bed tags, and managing the beds and bed layout in each ward.

  2. Bed Assignment - these features seem somewhat UgandaEMR specific, as they are built around queues as defined within the patientqueueing module, which is not something all implementations will adopt, and not even the same queueing module that exists in the referenceapplication.

I would like to propose that we harvest the Bed Administration functionality into it’s own ESM in an exising or new monorepo in the OpenMRS organization. The custom bed assignment functionality would remain in a Uganda-specific ESM, though we could continue to work together to see where requirements overlap broadly for this aspect as well, that can be a separate discussion.

@slubwama / @dkigen / @ibacher how do you feel about this approach? Would this be something the Uganda team would support?

Also, thoughts on where the bed administration component would be best situated in the OpenMRS ecosystem? Could possibly go in patient-management, or if we think it is useful to have ward-specific esms in their own monorepo, we could potentially create something like “openmrs-esm-ward-management” would would then have this esm and would also be where we could locate some of the other new “inpatient” and/or “outpatient” ward views that we have been designing.

3 Likes

I’m strongly in favour of this approach.

I think patient management probably makes the most sense. I don’t see a lot of point in multiplying the number of monorepos we maintain.

1 Like