Client design decisions

• there is always exactly one active patient
• there is always exactly one active care provider

• a model / view approach is used
• the model gains access to the backend via a backend middleware
• clinically meaningful classes are preferred where possible
• plugins do not communicate directly, they use message passing

• database connections are read only by default
• all database access is transactioned at the serializable level
• database access happens on demand where possible
• there is no explicit locking of patient data in the backend