After discussion with @jdick, I will amend my previous post with a couple of changes:
- Include
location_waiting_forandprovider_waiting_forwithin queue entries to optionally specify for which provider and/or room the patient is queued. This can be useful in some workflows, can be ignored when not needed, and allows us to build on the existing module. - Replicate additional
encounterattributes within theencounter_statustable as needed to identify to which encounter the status applies (or will apply when the encounter is created). If we had support for draft encounters (the ability to create an encounter row before the actual encounter takes place), we would be adding this status directly to the encounter table. Because we don’t yet support draft encounters and we need to track status before the encounter is completed (and theencounterrow created), we are – for now – creating anencounter_statustable to hold this information. Astatusattribute alone is insufficient to know to which encounter the status belongs, so we will need to duplicate additional attributes fromencounterinto theencounter_statustable to allow us to know to which encounter the status applies. These would include at leastencounter_datetime,encounter_type,patient_id, andvisit_id(note thatvisit_idwill be used to help unambiguously identify the encounter to which the status belongs and is not meant to assign status directly to a visit, which – if needed – we would do introducing eithervisit.statusor, if necessary as a workaround for lack of draft visits, within a newvisit_statustable).