Re: [Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning]

[Karsten Hilbert]

See, this is why I like to have Syan around. He's able to
see through the petty technicalities, define what's what in
technical terms -- and then embark on one of the "crazy
developer fringe projects" which are the salt in an open
source project :-)

This is a fairly high-level but technical description of the
GNUmed model. Let's keep that on the Wiki !

Karsten

On Wed, Dec 21, 2005 at 01:56:28PM +0800, Syan Tan wrote:
> Subject: Re: [Fwd: Re: [Gnumed-devel] Vision and implications: Strategic
>       planning]
> X-Mailer: AtMail 4.2
> 
> with respect to "impenetrable" , gnumed is definitely not 
> impenetrable :- it has the following features:
> 
> 
> 
> - single threaded , event driven execution  - using wxWindows framework.
> 
> Someone mention QT, this is also single threaded event driven
> 
>   - event driven means a user event or a system event happens, and this
> causes the program to offer a response
> 
> 
> 
> - it is a object relational mapping , and does disconnected transaction 
> checking
> 
>   - it uses sql as a final backend because relational databases are usually 
> fast,
> 
> easier to program with SQL, (then say network databases ), widely available 
> 
> documentation due to high demand from ease of use.
> 
>   - uses objects as way to group together functions , e.g. F*CRUD with 
> integrity 
> 
> checks.
> 
> (F*CRUD - find, create, update, delete)
> 
> 
>   - objects relate naturally as a Document :  medical records are collections
> organized as one document/file  per patient,
> 
>      - a document can be viewed a single rooted hierarchy of objects, 
>       a tree,  or directed acyclic graph ;  it is possible to serialize one
> document <=> objects pertaining to one patient , into a single serialized 
> text.
> 
>      - the main reason for using SQL is it's easier searchability, and the
>   possibility of fine locking of parts of document for concurrent access to 
> one document.  With respect to concurrency, gnumed uses SQL transaction blocks
> to ensure integrity of foreign keys between parent/child rows, but uses 
> manually programmed Transaction ID checking to check for write-write 
> conflicts,
> and postgres Push model notifications to push TID changes so clients sharing 
> a 
> document  have  a sequentially consistent model of a document. 
> 
> 
> 
> - unlike Mozilla, which must incorporate a lexer, syntax analyzer, and 
> graphical 
> constructor, or sendmail, that reads configuration scripts and have a rules 
> parser,
> gnumed's configuration consists of mainly specifying which graphical widget 
> module
> to load ;
Plus a bunch of yes/no or integer options. They are getting
more these days.

> it relies on it's domains pretty stagnant conceptual evolution - handle 
> scripts, notes, medications, allergies, immunizations, lists of info (past 
> history, 
> social history, family history) , investigation requests, referral letters, 
> import 
> results / electronic discharges , and images of letters / paper results,  and
> you've got the basics covered. Add in a DICOM plugin to view radiology 
> images, 
> a OpenGalen or SNOMED-CT natural language parser/ classifier, and hey  
> presto, you're 
> the vertical app leader.
> 
>   in other words, it would take less than 1/20th the work on apache to get a 
> functional gnumed.

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