During today’s Platform Team call, we iterated on the model and decided to simplify the queue service to focus on its primary goals:
- Created, update, and delete queues
- Add & remove entries from queues
- Efficiently answer questions like “what was the average time spent in this queue over the past week? And what was the average number of patients in that queue over the past month?”
The queue entries can be managed in with a queue_entry table like this:
We’d include a queue table for metadata (name, description, etc.) and likely one or more tables like queue_stats to help manage queue statistics efficiently.
The triggers to add or remove entries from a queue could be myriad and come from a variety of domains (e.g., registration, encounter state, observation value, modules for specific workflows, etc.).
For the initial use case of encounter-based queues (triage, lab, clinic, etc.), we can create and track encounter state by introducing an encounter_status table with status (Concept) and encounter_id to optionally link to an encounter. Eventually, when we have support for draft encounters in the Platform, this status field could be merged into the encounter table.
For now, the implementation of triggers to add/remove entries could be included in the service queue module or provided by other modules. As common patterns evolve (encounter-driven triggers, observation-driven triggers, etc.), the service queue module could provide configurable support for these out of the box.
@corneliouzbett & @ibacher are going to spike on adapting the service queue module this direction and we’ll aim to iterate on code going forward.
Updated 2022-01-14: included some additional attributes based on this comment