Re: Re: [Gnumed-devel] Machine readable models at openEHR

[Karsten Hilbert]

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