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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
