Uploaded image for project: 'OpenMRS Core'
  1. OpenMRS Core
  2. TRUNK-3662

Project: Patient Queues by service


    • Complexity:


      This issue was discussed on the dev list June 7-8, 2012

      This proposal is ruthlessly stolen from Martha Vida's comments on a registration module. The idea is to maintain queues of patients waiting for particular services. The queues would be defined in metadata and their state changes would be triggered by Ben's events. There would also be some queue management functions like viewing, manual removal, manual entry. There would also be some statistics kept, such as maximum and minimum time in queue, maximum number in queue. There would be a queue taglib for displaying a queue. Normally, the queue entries would be patients, but hopefully could be other things (like lab specimens).

      Wesley Brown:
      I have been working on a module that might fit this need which I call the Persistent List Manager (repo on github). The goal is support very basic workflow-like process by allowing modules to create arbitrary lists of items that are persisted somewhere (usually a database), have some type of data structure-like ordering (queue, priority-queue, stack, etc), and allow those lists to be accessed by other modules. Rather than serializing and storing the actual object (which is likely already done elsewhere) these lists just store a string item key and let the calling code load the actual object. The usage for these lists is described in the repository README file. While this module doesn't currently support the statistics that Roger mentions, adding this type of tracking would be fairly trivial.

      This module is not complete (I did it mostly as a means to learn about creating OpenMRS modules) but if this would be useful to others I can try and get an initial version finished quickly.

      Tobin Greensweig:

      This is a high priority module for us as well and one we hope to put resources behind developing starting this summer (or maybe September) if nobody beats us to the punch. Roger your ideas are really outstanding. As we move forward we'd really like to have a design forum to make sure that what we build will be as generic as possible and useful for many.

      In the meantime, I hacked together a temporary fix using a free php to-do-list called mytinydo (http://www.mytinytodo.net/) placed onto the home screen inside of an iframe using Role Based Homepage module. It's worked REALLY well as a stop gap and offers a lot in terms of prototype. I've been meaning to make a special youtube screencast to share it, but in the meantime everything is shown pretty well in this "receptionist training video." Feel free to watch the whole thing to get a sense of our implementation but the stuff with the patient que starts around minute 6.

      TLV Refugee Clinic Receptionist Training Video: http://www.youtube.com/watch?v=Mxrl6y7rl-s

      For those interested here's a Physician Training Video: http://www.youtube.com/watch?v=yI47Otr2200

      Look forward to any and all feedback!

      Bob Joliffe:
      I'm sure nobody minds the ruthless reuse of ideas. I am positive that if HISP India don't have to maintain their own patient_queue module they will be happy for it.

      Though I find myself increasingly drawn to the idea of just making use of a commodity message queue service (apache activemq) for managing queues of things in a hospital like setting. As you say there can be many things besides patient appointments which need to be queued, tagged and managed eg. lab tests, pharmacy orders, billing slips etc.
      Having a flexible messaging architecture to draw upon can solve a lot of the problems of tying these modules together.

      Of course one can (and we have) implement simple queueing functionality as an openmrs module. But I really do wonder what world of possibility opens up by making use of something like activemq.
      Anybody else thought upon these lines?

        Gliffy Diagrams

          Balsamiq Wireframes





                  • Assignee:
                    r.friedman Roger Friedman
                  • Votes:
                    1 Vote for this issue
                    7 Start watching this issue


                    • Created: