@slubwama Thanks for your fantastic overview of the module on Friday. And @aojwang, @corneliouzbett, and @jwnasambu thanks for your comments on that call.
I’ve taken a bit of time to discuss some initial ideas with @jdick, as well as to review the Patient Queueing User Guide as well as the designs @slubwama came up with on the Wiki and the original design from 2012.
As @jdick’s initial post notes, there are some ties between this and the clinical workflow. Indeed, @slubwama’s demo showed that the way Uganda EMR is leveraging the patient-queueing module is as a way to track not only the patient’s status in a queue, but the patient’s status within a visit (where has the patient been? where is the patient supposed to be next?).
Starting from this and @burke’s remarks above, I think it’s helpful to separate out where the patient is in a workflow from the queue and instead add queues as something that are derived from a more generic mechanism for tracking the patient’s current state (i.e., where is the patient now?).
To that end, I’m proposing we move the patient queueing module towards using something like this data model (note that the data element names are evocative rather than necessarily recommended names for the table fields):
The idea is that each Visit has one or more Visit States which track the current status of the patient and can be updated as the patient moves through different encounters in the visit or independently of the encounter. Certain Visit States might indicate that the patient is waiting for something. In this case, we create a Queue Entry to capture the fact that the patient is waiting for something.
Patient Visit State
||Links to the patient this Visit State tracks
||Links to the visit the Visit State is a part of
||The date and time the patient entered this state
||The date and time the patient exited this state
||A concept capturing what this state is
||An optional comment about the status
||An optional location field storing where the patient currently is (or at least should be)
||An optional field linking to the encounter that first entered this state. This is to allow the
PatientVisitState class to implement the
FormRecordable interface from recent versions of OpenMRS
Patient Queue Entry
||Links to the patient visit state this queue entry derives from
||As @slubwama helpfully showed, its useful to have some identifier for a patient in a queue can be tracked that isn’t otherwise a personal identifier for the patient. Sticking the value here allows us to track it on a per-queue basis or copy it across any number of potential queues
||A concept indicating the patient’s priority in the queue
||A comment on the priority, if any
||This shouldn’t be there; ignore it
||The provider the patient is waiting for, if any
||The location the patient is waiting for, if any
You might notice that in this model the queue itself does not actually exist in the database. This is because queues, at least for these purposes, are ephemeral rather than something durable: the queue is just the query who is waiting for x and the order.
Some sample questions and how to answer them:
- How long has patient x been waiting? This should be simple math determined by the time the patient entered the current state and the current time.
- Who is waiting for y? Assuming y is a location or provider, this should be a matter of querying the active queue entries for the particular resource in question (location or provider)
- Who is next in line for y? This is the main reason for using queues. This should be a matter of the top entry in the active queue sorted according to some rule I’m leaving undefined for the moment.
- Who is waiting for any resource (provider or location, etc.)? This is simply a matter of querying all available active queue entries.
- What is the status of patient x? This should just be a matter of querying the most recent Patient Visit Status.
There are a few pieces of business logic necessary. The first is to ensure that the previous visit state is always ended when the next state is done. Both the start and end dates for states are stored in one row as this makes the logic to determine “active” state cleaner and it makes retrospective analysis easier (how long does the average patient wait for this set of resources?).
The hard part in this model is determining whether or not a given visit state is a queue state and so a queue entry should be created for it.
Finally, let’s talk through an example visit:
A patient, Mona, comes into the clinic. Mona is seen by the registration desk, where she is checked in. Since this isn’t an emergency, Mona is sent to the triage area to await triage. At this point, Mona’s record will have been created and a visit started. Mona enters the “Waiting for triage” state and a queue entry is created to indicate that Mona is waiting for the triage location.
Mona is seen by a nurse at triage. At this point, Mona stops being in the “Waiting for triage” state and enters into the “With triage” state. The previous state is no longer active. The triage nurse takes Mona’s vitals, asks basic screening questions to determine how urgently Mona should be seen. This information is recorded an Mona is sent to wait for Dr. Ruiru. At this point Mona stops being in the “With triage” state and enters the “Waiting for clinician” state. A new queue entry is created to indicate that Mona is waiting for Dr. Ruiru.
Mona is seen by Dr. Ruiru. At this point, Mona stops being in the “Waiting for clinician state” and enters the “With clinician” state. Dr. Ruiru sends Mona to the lab for tests and then to the pharmacy. At this point, Mona enters the “Waiting for lab” state. A new queue entry is created to indicate that Mona is waiting for the lab.
This is just intended as a first pass at this, so thoughts, criticisms, etc. are welcome! Also, if I missed something please let me know!