Re: [Gnumed-devel] Gnumed structure and philosophy

[Karsten Hilbert]

Tony,

> Jim's 'request for clarification' have been very useful in the past.
No question on that.

> The corollary of this philosophy is that 
> it is not necessary to determine the exact details of Richard space or 
> Horst space as, given the right tools, we will all be able to create 
> our own space.
In a way, yes.

> Although Gnumed will be an excellent, open-source replacement for the 
> current crop of medical database packages, it will be significantly 
> more than this.
Eventually, in a galaxy far far away.

> Gnumed is a complete environment for designing medical packages.
At least for frontends.

> Its multi-levelled stucture ensues the stability and integrity of the 
> underlying EHR,  while allowing end-users the flexibility to customise 
> both the functionality and the 'look and feel' of the application.
To any extent imaginable does the backend try to allow for
different types of frontends. To a small extent is/are the
existing frontend(s) customizable in themselves.

> The 
> structure also increases the scope of the application by allowing 
> interested 'scriptors' to write their own plug-in modules.
Which today means they need to be able to write in
Python/wxPython.

> Level 1) SQL
>  the basic tables of information are stored in an SQL compliant 
> database. Postgres is the current 'database of choice'.
> Written by - Core team
> Estimated Current Level of completedness  v0.8
v0.5 overall but the parts considered "ready" are at 0.8.

> Level 2) The 'backend' EHR, (table information managed as views)
> The tables are accessed through a  set of views that present the highly 
> normalised tables in a more familiar structure. A set of methods allow 
> safe access to the tables.
I believe you are mixing middleware (eg client/business/) with
backend EHR (nice term !), no ?  We don't currently use too
many stored procedures for actually inserting/updating. But
you might be mixing intentionally for sake of the bigger
picture. So, generally, yes.

>     patientID.setDemographic(firstname=>'Tony')
>     encounterID.setSOAP(assessment=>'Penetrating injury to leg')
>     druglist=patientID.getDrugs(current)
> Written by - Core team in Python
> Estimated Current Level of completedness  v0.6
v0.5 overall but if related to the 0.8 part of "completed" SQL
structure mentioned above it could be considered 0.9 *for that part*

> Level 3) Basic structural functions
> Log-in, error tracking, log,  etc
> Written by - Core team in Python
> Estimated Current Level of completedness  v0.9
ACK

> Level 4) Interface widgets
> GUI elements that where necessary  utilise the Level 2 methods to read 
> and modify the EHR backend
> eg Scroll Wheel, Search boxes, drug selectors, dialog box
Yes. We got some but not particularly many.

> Written (currently) to utilise wxPython, but available to 'Level 5 
> scriptors' as simple commands such as
>      scrollwheel(prescribeDrug)
>      scrollwheel(orderPathology)
>      chart(test=>'hbA1c',startdate=>'10/2/2002',enddate=>'today')
Nice idea to keep around for later. Buds already in
gmMacroPrimitives.py.

> Level 5) Modules
> Modules are plugins elements that are added to a gnumed screen.
> eg Prescription writing module, BMI module, scrapbook module, 
> prescribing module, pastHx display
Yes.

> Modules can be written using 'gnumedscript', which allows the module
Written to the layout manager API, currently.

> Level 6) User Interface
> Endusers can design their own screens by determining which modules they 
> would like to place where.
Currently we only allow them to decide which plugins to load
at all.

> They can also select or design their own 
> 'skins' to change the look of their application.
> Written by all users as part of gnumed application.
> Level of Completeness 0.4
0.4 ? No way.

> Thus gnumed provides the blocks for users to build their own 
> applications to access and modify the underlying EHR. (No doubt this is 
> a significantly more complicated aim than just writing
> an 'approved' application in python, wxPython and SQL).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is our immediate goal.

The scripting aspects will have to wait, IMO.

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