On Tue, Jan 03, 2006 at 01:20:32PM +1100, Tim Churches wrote: > SQLobject - see http://www.sqlobject.org/ Last I looked I found sqlobject to simplistic to do anything even slightly advanced (meaning leveraging advanced database functionality). Will review SQL alchemy.
> I think that an implementation of the openEHR RIM > (reference information model) via one of these Python ORMs > would be very interesting, Agree ! > But as Ian Haywood said that David Guest said: it ain't > that hard. I share the sneaking suspicion that the openEHR > guys are deeply involved in figuring out optimal techniques > for Olympic hurdling before they are even able to walk. Hehe, couldn't have said it any better. However, that's their *approach* conceptually: Understand it, then walk. And of all the projects in that direction I always have a good feeling about OpenEHR. > There may be a place for GNUmed2 to implement an > openEHR-for-dummies engine that actually works. Definitely ! > At its heart, after you strip away the jargon, openEHR is not > really very revolutionary - its just a well-thought out > elaboration of what many have been doing for a long time - > it brings formal order to EAV and other generalised RIMs. EAV, that's one of the things that makes me cringe. What good is using an RDBMS if all you are storing is EAV ? Numbers without meaning are useless in most cases. Data without meaning is basically nothing but numbers. That seems to suggest that some meaning should be attached to numbers at the lowest practical level - with more meaning potentially added at higher layers. That's why I have a strong dislike for dumping clinical data into a big pile of dog p**p which doesn't make any sense without an elaborate, intricate and hence fragile external framework (such as application level implementations of OpenEHR RIMs). Hence I try to attach *some* meaning to our data at the database level. If a GNUmed1 database is lost, the clinical data is lost, of course. If the database is not lost, the data is of at least *some* use, regardless of whether I have access to a GNUmed client. If an OpenEHR blob is not accessed by the appropriate frontend it probably does not make sense - lest it internally is some very well structured human readable text - in which case it would beg the question why not enforce that structure at the database level (which question may have good answers that I am not aware of currently). Tim's paragraph above is similar to what I am after when hoping for "informers" which monitor GNUmed and $project and report potential synergies. 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
