Child pages
  • Queueing, Especially Patient Queues
Skip to end of metadata
Go to start of metadata


This project seeks to build on existing work to design and incorporate a queueing facility for OpenMRS, with particular emphasis on Patient Queues. See TRUNK-3662 The queues would be priority queues, accessible through the API and forms. There would be a queue display portlet that could be included on any webpage. There would be a queue management page for defining and manipulating queues. Queues would keep statistics on the passage of objects through them, which would be summarized and saved for analysis.

Blame Us

Darius Jazayeri
Roger Friedman


Design a queue object, its methods and API.
Design a Queueable interface that permits an object to be queues by the feature.
Design a queue management page.
Design means to persist a queue definition and a history of its operations.

Feature Descriptions

Queueing Model E-R Diagram

Implementation Issues

  • No labels


  1. I think this could be really useful but I question why it should be focused on any specific entity type and why the queues would be limited to priority queues (or any type of queue).  As I mentioned in the linked ticket, an abstract way to store lists of items, irrespective of ordering or item type, would work as a patient queue as well as a much broader feature set as well.

    1. I don't disagree with that. But at the same time, "list of any type of entity that can be stored in any way, and can be ordered in any way" is incredibly broad, and feels (perhaps) over-generalized.

      I would hope that we can lay out concrete requirements around a queue-of-patients use case, and we can look at a design that handles the broader list-of-anything idea. Hopefully the latter satisfies the former without getting unnecessarily confusing.

      1. Darius,

        I think we are just looking at this from different perspectives.  We had a very similar use case to the one that you described TRUNK-3662 but decided that this is a specialization of a more general gap in the OpenMRS functionality.  As such, we decided to create a more general purpose design that will also work as a patient queue.

        We already have a module which handles the core functionality needed by a patient queue and I think it would be a good starting point for this project, at the very least.  The repository is up on github here:  I'd be willing to discuss if/how this might fit into this project if there is any interest to do so.

  2. I have added the queueing model diagram above.

    I want to explain why I am so psyched about using a queueing model and maintaining service statistics. (1) I am very tired of seeing hospitals/clinics filled with waiting people who may even be living on the grounds waiting for service after having travelled for days. I think hospital management and staff needs to be more patient-oriented in designing processes. (2) Having real-time information about how many people are waiting for what for how long for what services allows management to reallocate staff dynamically to meet needs. (3) I am interested in being able to have evidence of what size and type-mix of staff is necessary to provide good service. Hospitals/clinics can use this information to support appropriate budgets.

    Having worked with simulations, I can attest that having these statistics can be very persuasive. To see how the absence of a staff person for half an afternoon affects patient waiting time and number of patients seen is impressive. The system is very non-linear and hard to understand. Also, these statistics can be "played back" in an animation and the staff/management can actually see the big picture.