[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning
From: |
Karsten Hilbert |
Subject: |
Re: [Fwd: Re: [Gnumed-devel] Vision and implications: Strategic planning] |
Date: |
Wed, 21 Dec 2005 10:56:20 +0100 |
User-agent: |
Mutt/1.5.11 |
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