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