Hospital
description:
in a hospital humans treat and care for other humans with the help of all sorts of equipment: beds, tomography, analysers, dispensers, but also doors, elevators, food trolleys; sticking to well-defined processes and documenting all steps taken is of paramount importance, which is a purely local concern that must be meticulously addressed — computers can remove errors and effort, but they must always work or patients die; an additional concern is data privacy, patient data must always be encrypted such that only authorised personnel has access
techniques:
DDD, event sourcing, edge computing, peer-to-peer, distributed event log
types of data:
process actions are generated by all participants where they occur (e.g. “bed raised”, “door opened”), belong to the hospital and are needed for auditing purposes; patient data are created by machines or doctors and needed in subsequent processes, but must be controlled by the patient or their custodian
expected connectivity:
only local connectivity needed for parties working together, passing data along with patients and processes, possibly stored on physical tokens
stay responsive:
the local process must always be working, non-local failures are not tolerable (reduce resilience), which is achieved by keeping needed process data on the local device and allowing read/write interaction at all times, then synchronising with other devices whenever possible
local communication:
communication is necessary only between participants of a process, e.g. nurse, bed, door, and patient; these are close to each other which allows direct communication links to be used; when needed to communicate over longer distances, like summoning a doctor, events are relayed from one participant to the next (can be optimised by installing wifi)
accept uncertainty:
uncertainty is a well-established principle at a hospital, as long as local record-keeping is reliable; this is why a patient may be accompanied by a memory token to ensure that all data pertaining to this person is always locally available
assert autonomy:
the key to staying responsive on local devices is to allow local decisions based on incomplete but understandable knowledge: stick to well-documented data formats when publishing events, prefer sending events over sending state to allow other devices to derive the state they need
handle dynamics:
the basic principle is to outfit each participant with a computing device that is capable of handling the locally needed processes, this way the system is inherently scalable to any number of participants — provided communication infrastructure that can handle the volume of all processes within a given region (e.g. one ward)
tailor consistency:
almost all decisions taken in a hospital are local so consensus is rarely necessary: allocation of limited resources like a tomography scanner is handled by forming a physical queue in front of it