[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Gnumed structure and philosophy

From: Tony Lembke
Subject: [Gnumed-devel] Gnumed structure and philosophy
Date: Thu, 5 Aug 2004 20:03:31 +1000

Sure, in Horst-space. The very same (as in "the same physical
lines of") code is used in Richard space.

Jim's 'request for clarification' have been very useful in the past. So adopting 'Busser mode', may I ask if I have an accurate understanding of the basic gnumed 'space' - its structure, philosophy and goals (for ?gnumed 2.0) The snippet below represents my understanding of the gnumed concept as it has grown from the ideas of Horst, Karsten, Ian and others, and is not (of course) my original thought . (apart from the currently fictional term gnumedscript and fictional examples of code) This outline now may be completely off the track. I welcome corrections / admonishments. 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.

Although Gnumed will be an excellent, open-source replacement for the current crop of medical database packages, it will be significantly more than this.
Gnumed is a complete environment for designing medical packages.
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. The structure also increases the scope of the application by allowing interested 'scriptors' to write their own plug-in modules.

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

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.
    encounterID.setSOAP(assessment=>'Penetrating injury to leg')
Written by - Core team in Python
Estimated Current Level of completedness  v0.6

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

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
Written (currently) to utilise wxPython, but available to 'Level 5 scriptors' as simple commands such as
Written by - Core Group in Python
Level of Completeness 0.7

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 Modules can be written using 'gnumedscript', which allows the module developer to place interface widget elements within a layout and thereby interact with the backend EHR. The fonts/colours etc used by modules are determined by a 'style sheet' or skin and are not hard coded.
eg Module BMI
"input(size=4,name='Height'). \
"input(size=4,name='Weight'). \
                input(type=button,label='Calculate',onClick='calculateBMI()' \
        function calculateBMI{
Modules are wriiten in gnumedscript and can be written by anyone with basic scripting knowledge. Perhaps one day a GUI will make this easier.
Level of completeness
  -  Some modules functional
  -   gnumedscript 0.1

Level 6) User Interface
Endusers can design their own screens by determining which modules they would like to place where . 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

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). It will, however, be unique, more adaptable and scaleable, and allow many more people to come and play with us!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]