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

  • never place screen objects explicitly… let it all be taken care of (calculated) by wxPython sizers.
Topic revision: 20 Jan 2013, JamesBusser
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark