[Gnumed-devel] gnumed-mini

[Karsten Hilbert]

> We've been spending the better part of the last 4 years to
> do the following so welcome back to Ground Zero:
> 
> > So I started to rewrite the system, this time I wanted to do it properly, 
> > and 
> > using a non-proprietary backend schema.
> ...
> > I want to clean that up and document it properly before I bother people 
> > with 
> > it.
> 
> > In principle, the architecture looks like that:
> > 
> > a) every database concept (like "a patient", "a doctor", "an address" etc.) 
> > is 
> > wrapped into a gmdbXXX class with standardized high level accessor methods. 
> > They all inherit common traits from a gmdbObject ancestor including a very 
> > simple and crude caching mechanism.  There should be no SQL queries at all 
> > in 
> > the GUI code
> Hm, this sounds suspiciously like gnumed/client/business/*.py
> 
> I have to admit I haven't yet been able to see through the
> caching mechanism. I am sure keen on learning whether it
> provides benefits over what we use in GNUmed.
> 
> > b) every possibly self-contained functionality (e.g. "prescribing", 
> > "appointment booking") exists as an independent module which can be run 
> > either standalone or as a plugin within the gnumed framework
> While nice and having been tried I have found it to be hard
> to maintain. Likely our GNUmed code isn't clean enough yet.
> Once you get to a certain complexity of functionality there
> are assumptions in the code that are met by the framework
> which isn't available when running standalone ...
> 
> > c) all such independent modules ( regardless whether gui or not) 
> > communicate 
> > with each other exclusively via the central messaging hub (dispatcher)
> Likely we have taken a few corners here that prevent us from
> running plugins standalone.
> 
> > d) as a rule, GUI components are designed with wxGlade. The generated GUI 
> > code 
> > is never modified manually, but a wxXXX module inherits from the generated 
> > wxglXXX module.
> How does this allow for creating widgets from non-wx-Core
> GUI classes ? Say I wrote a dedicated progress note
> notebook, how can I use it in wxGlade ?
> 
> > f) Not only for simplicity, but also for speed reason, the backend schema 
> > is 
> > not always normalized.
> Does it properly support clinical encounters and episodes
> of care ?
> 
> > At times, where it would yield a substantial 
> > performance gain, foreign keys *may* be the data itself
> "would" or "does" as in "tested" ? I doubt it'll make much of
> a difference in most cases. Or so the PostgreSQL people
> attest to.
> 
> > g) the backend schema is versioned. Modules check what backend version they 
> > need. The backend is updatable incrementally - after the first full version 
> > number, only "update" schema sql snippets will be generated, allowing 
> > update 
> > of a running system without anybody having to log out first
> Same as GNUmed.
> 
> > h) installation should be running "gnumed.sh" and "python setup.py install" 
> > and nothing else, no hoops to jump through for the end user. This requires 
> > an 
> > administrator running gnumed.sh as somebody who has the right of creating 
> > new 
> > postgres databases and users
> Yup, that is doable with GNUmed as it exists now. Do you
> intend to store program bitmaps (icons) in the database
> generated from python encoded inline data ? Or else how do
> you intend to make "python setup.py install" install bitmaps,
> docs etc in a client system ?
> 
> Trust me, been there, done that.
> 
> Karsten

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346