O3: Queue Workflows from station to station

, , ,

Thanks to dedication from @DonaldKibet & @CynthiaKamau, we are getting close to finishing the O3 Service Queues feature.


In current form, the new O3 Queues feature only focuses on one specific area/department at a time. What we need is, an easy way to transition patients between departments/areas in larger facilities. Writing about this here before our discussion on this in tomorrow’s Design call.


We can’t just magically make this happen in O3 - we will need 1-2 groups to come forward to make this happen. (The current O3 Service Queues feature has been happening thanks to very hands-on collaboration btwn Ampath, Palladium, and Brown.)


Users in a given area should be able to see all the patients waiting for their care, with most urgent at the top and those waiting longest at the top, so that patients can be seen in a timely manner. This means Users need a UX that helps them (1) SEE this patient queue, and (2) SEND a patient to their next “station” so the next team member doesn’t overlook any patient.

Imagine This Scenario

You show up with your sick child at a large health centre. There are many possible departments, staff, rooms, and stations. Fortunately, you can just go to the first place: Reception. From there you might need to go to Billing to pay a visit fee, or go directly to the Triage area. From there you might be directed to the General Outpatient Clinic waiting room, or to the Pharmacy for a quick medicine dose to reduce your child’s fever while you wait, or to a Specialized Department like Oncology, or even to the Emergency Department for serious treatment. Some areas have even further rooms - e.g. a Specialized Department might also have separate waiting queues to see a Doctor vs a Dentist vs maybe the Chemo section of the Oncology Clinic. (Real examples courtesy of UgandaEMR team.)


How does the EMR handle this scenario? How does each team know - without counting patients in the hallway - the number of people waiting for care in their specific area? How do the staff know who to see next? This is exactly the situation that @pauladams and I saw recently at a paediatric hospital in Kenya, and it’s also the reality at many UgandaEMR sites. And in fact, the UgandaEMR team walked us through the work they have already done to handle this use case (thank you @slubwama and @solemabrothers) - many UgandaEMR production sites are using their “Provider Queues” feature (GIF below).

Current state in UgandaEMR for reference:

When I search for a patient to check them in, the Check-In action modal includes a way to send the patient to the “Next Service Point”: UgandaEMR Service Queue Example

What We Need in O3

  1. “Check-in and Go”: A fast way for the point-of-entry (the clerical or reception desk) to send patients to the next area at the same time as checking them in - so this can all be done in one quick workflow (the user doesn’t have to think about doing “2 tasks” because it should feel like part of the same check-in task)

  2. “Send To”: A fast way for users to move patients to a new queue/area, so that it’s obvious to other users exactly how many patients are waiting in their area, and who is either the highest priority or has been waiting the longest, so that patients get seen safely and fairly.

  3. Queue start & end times. Departments need to track their own wait times. You can’t just tell a site “your patients are waiting 3 hours too long” - internal teams need to know where in the site the bottlenecks are happening, so that improvements can be made in the right area. So for example, we want to know the client’s total wait time, but also, how long she spent in Triage, with the Clinician, with the Dentist, etc. How: We should be able to log a timestamp when the next “Send to” action happens.

  4. “Next Patient”: A fast way for users to switch to the next patient in the list, without having to click much around the EMR to switch from 1 patient to the next patient in line.

Good news: We already have a design for this, thanks to foresight from @cduffy. The user can open a list of interest (e.g. “ART Clinic”, or “Chemo Area”, or “LTFU”, etc), and use this to guide who to see next. (We need to update this design to show priority level and waiting time).

Pt Chart side panel/workspace DL2_PatientChart-listOpen

So: Does this resonate for others?

CC @slubwama @ddesimone @tanderson @aojwang @lousa @rubailly @ssmusoke @reagan @mksrom (& please CC others you think may be interested)


@mmwanje come take a look at this

1 Like

We discussed this briefly in the O3 Design Call back in June. @cduffy reminded us of these already designed screens (i.e. Needs (2) and (4) are already designed for):

“Status” is more or less “Queue" in this feature

Queue list in Workspace (notice it’s been updated to show priorities :smiley: )


I have updated the “Service Queues” label in Zeplin to make sure both of these are included. Next, @slubwama and I will discuss here about how to proceed with a V2 of queues that includes the multi-department needs mentioned in the original post above.

CC @abhinab & @n0man as this may be of interest to Bahmni-Lite as well.

@grace thanks for these. @solemabrothers @eachillah @zacbutko @dkibet & @cynthia are Some of the designs I was thinking about and they are well elicitated here.


OK based on discussion with @slubwama & @burke & @cduffy on Monday’s design call: so scope/next steps needed for V2 of Service Queues, with the ability to “send patient to next queue”:

  1. Way to pick a patient in a queue/list-view and either “Send them to X area next” or “End visit”

  2. Way to see/switch between the different queues (eg “I want to see the Dentist queue” or “I want to see the HIV Triage queue”) → We can start by using the “View” UI: image

  3. Way to define with metadata what the queue options are @corneliouzbett or @ibacher: Do you know, does the current Queue module have any particular way of representing a given queue in metadata? Eg If we made a set of standard Queue names with Concepts, could we reference those concepts somewhere through the Queue module to pull in those options? (eg HIV Clinic, HIV Triage, HIV Clinician, Oncology Triage, Oncology Clinician, XRay Dept, etc…)

1 Like

Every queue is a Queue object. The queues for a given setup would need to be created probably adding a domain to Initializer for this is the way to go.


Thank you @ibacher!

Does this mean you agree with the architecture idea? I can propose this domain addition to Iniz more formally in a dedicated post if that helps.

And, do you know; what might be the dev lift to set up a new domain in Iniz?

@slubwama would someone from your team be able to help work on iniz to add this Queues domain support?

Definitely, there is a need for an interface that can help a facility create a queue. This could be done in the SPA or legacy UI to avoid too much dependency on other UI modules from 2.x reference application

Do we have a requirement that end-users create their own queues? An Initializer domain is much less of a lift development-wise and we’d have to create some form of metadata to allow us to identify, e.g., what concept should qualify as a potentially valid queue.

“New domain in Iniz” is way too variable to give a general answer to, but for this specific case, to create a queue, it should be fairly trivial to implement (queues only have a name, description, location, and concept; of these, only the name and concept are required).

In a distributed setting such as UgandaEMR where each health care center (Hospital, Clinic…) may have its own clinical rooms, multiple labs, and dispensing areas that a default domain Iniz may not be able to fulfill or even metadata base created queues of distribution can not satisfy. In that case, a system administrator at a given hospital, or clinic… may create queues that enable them know it better.

How about an intermediate compromise, just to down-scope version 2 for now: What if we used the concept dictionary?

So: in V2, we could hard-code a Convenience Set concept to be referenced, like a “Queues at our Location” concept. Then admins could add set members to that parent concept as their “UI” for adding Queue names/options.


Could this work in the interim @slubwama? Do the admin personas have some familiarity with creating concepts? Or perhaps this is low-effort enough that a site could request IP support to add these options?

Maybe that’s too hacky an idea…LMK.

Discussed today in O3 Squad call. Perhaps we could use this concept-based/set-members-based idea for initial iteration; however, there is a lingering concern: we need to assign Queues to Locations. Locations do not have associated concepts so can’t just do this as concept set-members.

In general:

  • Don’t want users in a facility to define metadata! Risk of creating ++ complexity
  • Concern that queue is an object, not a concept. Might use a concept for the name.

Scratching my head thinking about how we can address the location concern…

It would be nice if each Queue also had a priorities and statuses property that pointed to concept sets. This would allow the choices for priorities & statuses to be configurable at the level of a queue (i.e., not all queues would be forced to share the same list of statuses) and add the benefit of having priorities & statuses localized (since they would be concepts).

@grace – while we could use concepts to configure parts of a queue (e.g., priorities & statuses), I don’t think we want to use the dictionary to define which queues exist, since there are other details required to configure for a queue (service & location) and likely more to come over time (priorities, statuses, access permissions, etc.).

The original intention was not to require queues to use the same set of priorities or statuses, but I had also thought that the application consuming the queue would be responsible for determining the valid set of priorities and statuses for that queue—which might be a convenience set, hard-coded or anything else. This doesn’t mix well with having user-configurable queues, though, so I suppose it would make sense to add that as a property for queues.

Update for those following this:

Last week @slubwama & @aojwang presented current challenges and ideas for V2 of Service Queue Design, and shared a helpful requirements/summary document.

@slubwama as promised on our design call today, I’ve gone through and attempted to parse-out the frontend features. Do you like this prioritization table? If so, could you help me by going through and adding your view of the priorities - since you know much better than I do exactly which features are highest priority for your users :slight_smile: Service Queue Design Document - Google Docs

Hopefully organizing things like this will also help @cduffy with prioritizing his design help for you too :slight_smile:

1 Like