Backend Support for Service Delivery Queues / Workflows

[ibacher (Ian Bacher)]

@slubwama

location_from (previous_location). this offers a traceable movement of patients where one can easily draw the pattern of how patients move across the clinic.

So previous location is captured in the model, but it’s part of the encounter_status_history in the above diagram.

@slubwama

1.queue_rooms (sub-locations) are very important. At times patients are sent to rooms without specifying which provider, since providers could easily switch rooms without their specific name tags to the door.

queue_rooms, i.e., where the patient currently is (if I’ve got this right) could be modelled as the location attached to the current encounter_status_history record.

@slubwama

vist_number (queue_number). In local clinics where more than 100 patients are attended to in a day, these help to keep order in the clinic. At times paper cards can be issued to patients in reference to which number they hold in the queue and then later called by their queue numbers aloud. This improves the privacy of patients also

As I think we discussed previously, these could be converted into, e.g., a visit-specific attribute (since they’re data about a visit). That way, the visit_number only needs to live in one place (unless there’s a need for a visit_number per queue?).

@slubwama

Also, take into note that a queue may not necessarily be tied to an encounter since there are some services that could utilize other data models such as orders without necessarily being attached to a specific encounter.

Could you give me an example of this? I’d think that when the order gets created it’s generally attached to some sort of encounter right?