We currently use the module to support the below patient flow:
One is waiting for a service i.e. triage if they are added to a triage queue
When a provider picks a patient from a queue, the status changes from waiting for triage to calling. We have an interface where this is visualized and can be projected on a screen
If the called patient is available/present, he/she is served by the provider else they are marked to be a ‘no show’ and pushed back to the same queue but with a ‘no show’ flag
The process ends with a patient transferred to the next service point or exited from the queue i.e. checked out
These are actually all questions we didn’t want to provide hard answers to, with the idea that they’d be answered by whatever application is consuming the queue. The queue structure by itself is intended to cover both one queue per facility or one queue per service or even one queue per room, depending on how specific an implementation or application wants to be. That said, both service and location were intended to be optional rather than required fields.
That was the intention.
That wasn’t the intention with the design, i.e., the original intention was that patients only have an active queue entry when they are actually waiting, but I think queues have sort of morphed into what I originally intended the PatientVisitState to be.
Thanks @corneliouzbett , @aojwang , and @ibacher for these insights, it is very helpful. From what I gather, it sounds like this is being used very successfully in Uganda, Kenya and maybe elsewhere, so I am very interested to learn more about those experiences.
What I’m trying to uncover is the degree to which the current module will meet our needs at PIH around hospital flow, triage, check-in, and queuing, and patient census, both related to outpatient and inpatient care.
I do have some additional feedback / suggestions for specific parts of the module, but I’ll save those for later. One thing I will say is that it is a bit difficult to follow changes, or to weigh in on designs, without having a JIRA project to watch and reference. Would this be something we could try to adopt?
There is one point @ibacher made that I’d like to follow-up on:
I went back and re-read your proposal around PatientVisitState and PatientQueueEntry@ibacher , and found that it very closely matches a design that I had also been working up. I think it’s worth building on this and seeing where it leads, whether to an evolution of the queue module or other alternative/complementary modules.
Related to your proposal, I’m also interested in thinking through how we model “services” and “space”.
What is a “Service”? Is this best just modeled as a Concept? What is it’s relationship to Location?
Is it proper to model beds, rooms, wards, units, departments as Locations (in a hierarchy)?
If so, could bed management be fully supported by “PatientVisitState” or an object that references it?
I’d be interested in discussion on an upcoming TAC. @grace / @burke
All fair questions and something we should probably work-through. Here’s some preliminary thoughts:
A “Service” is intended to be flexible; we want to cover both the case where the user is waiting for, say “Radiology” or “Room 12” or “Dr. Chakrabarty”. It’s named “Service” because this is a concept in the appointments module (i.e., you can schedule an appointment with a service), but represented as a concept because we didn’t want to pre-specify the specificity of “service”.
There’s no specific, defined relationship between a “service” and a “location”, but the previous iteration of queues had been tied to locations and we wanted to make an easy path for this.
Initially, I thought this was the case, but I’ve somewhat changed my mind. More specifically, it may be appropriate to use “location” for the more “fixed” parts of things (“wards”, “units”, and “departments”) are likely to not change in any important way in the middle of operations, but below that level, things get dicey. Obviously, rooms as physical locations might be representable as a location, however, they have a lot in common with beds and I don’t think beds are well-managed by locations.
Specifically, when managing beds in a clinical setting, we need a fair bit of flexibility to handle a number of things:
Though a clinic might have X number of beds, they can only utilise beds that they have appropriate staffing for, thus we need a way of indicating (in real-time) which beds are in use, available, and unavailable.
In some circumstances, a clinic might have temporary beds added, e.g., in an emergency situation, sometimes cots and other things are repurposed as “beds”. These should be trackable in the system.
Beds can be moved between different locations and this should be tracked (that is, the number of beds per room, for instance, might be variable).
Similar to adding and removing beds, certain rooms might be in use, available, or unavailable, depending on needs, staffing levels, etc.
All of this implies that to properly implement a bed management system, we need something that is added to and updated by users during normal system operations. And this suggests to me that locations are maybe not the best suited for this, since we don’t normally have locations being created, marked as available or unavailable live. There’s no technical reason that we couldn’t, it just makes sense to ask whether we want those sorts of things to be tracked in the location table or a separate table for that. And, because of the required flexibility, I’m leaning towards having a separate domain for this, maybe with a hierarchy like:
Location → Room / Clinical Sub-division* → Bed
With the latter two being handled by separate domain object(s).
* Clinical Sub-Division is intended to capture that there might be other arrangements for how beds are organised logically, if not physically. Specifically, I’m thinking about systems that use a concept of “pods” that have an assigned team of nurses to cover a subset of beds / rooms in a larger organisation like a unit or department.
We definitely need some way of tracking which bed a patient is in for IPD and ED at least, and I think having a way of tracking the history is important. So I think we’re going to wind up with some domain object to track that.
Right. Recognizing that this idea of “service” is starting to independently proliferate, I’m wondering if we want to define a shared standard that these independent modules (and future core features) can utilize. It seems that we can either say that “service” is just a Concept, and the way to share the idea of services between modules is linking Concepts and possibly sets of Concepts. Or if there is a need to create a formal HealthCareService domain object similar to this in FHIR, etc. Probably the most straightforward path is to use Concept in the short term for this, and then provide a path where this can be linked (or migrated) to a HealthCareService by concept in the future?
This is a fair point, and something that would be good to discuss. The best argument to use Locations is that there is so much built up to support Locations already. We have hierarchies of Locations (unit → ward → bed), we have attributes of Locations (bed number, bed type, in_service), we have tags of Locations (Pod A), etc. And most of our clinical data can reference a location, whether in core or in a module.
Schedule another call next week to continue discussion (@slubwama going to digest some of the design for queue module and bring concerns to next calll)
@mseaton and @minimalist continuing to work together to align PIH & Palladium
@mseaton, @minimalist, and @slubwama, could you chat and agree on a time for a next call sometime next week that works for all three of you?