There's a DeliveryStatus enum that tracks the state of the ringdown (whether it was sent or received) and the state of the patient (arrived or offloaded) and the unit (returned to service), as well as whether some of those states have been acknowledged by the hospital.
It's potentially confusing to have one value tracking the state of those different objects, and may be cleaner having them separated. For instance, if the acknowledgements are coming from people, they might arrive after the patient or unit has already changed state.
On the server, there's a PatientDelivery model that uses the DeliveryStatus values, and on the client there's a Ringdown model that uses a copy of those same values. So it's already confusing the status of delivering the patient and the status of the ringdown transmission.
There's also some code, like in RingdownCard that doesn't account for the acknowledged versions of the states, and would probably not show the right thing in those cases:
There's a
DeliveryStatus
enum that tracks the state of the ringdown (whether it was sent or received) and the state of the patient (arrived or offloaded) and the unit (returned to service), as well as whether some of those states have been acknowledged by the hospital.It's potentially confusing to have one value tracking the state of those different objects, and may be cleaner having them separated. For instance, if the acknowledgements are coming from people, they might arrive after the patient or unit has already changed state.
On the server, there's a
PatientDelivery
model that uses theDeliveryStatus
values, and on the client there's aRingdown
model that uses a copy of those same values. So it's already confusing the status of delivering the patient and the status of the ringdown transmission.There's also some code, like in
RingdownCard
that doesn't account for the acknowledged versions of the states, and would probably not show the right thing in those cases: