-------- Original Message --------
Subject: Re: [Gnumed-devel] Machine readable models at openEHR
Date: Tue, 03 Jan 2006 20:59:16 +0800
From: Richard Hosking <[EMAIL PROTECTED]>
To: Karsten Hilbert <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Karsten Hilbert wrote:
I think that an implementation of the openEHR RIM(reference information model)
via one of these Python ORMs
would be very interesting,
Agree !
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).
The whole point as I understand it is to try and abstract the business
rules (constraints/archetypes) to an external engine so that the whole
DB schema doesnt have to be changed for new data types. Yes apparently
the archetype engine could ultimately be built into the DB itself, but
would remain separate from the underlying data reference model
Tim's paragraph above is similar to what I am after when
hoping for "informers" which monitor GNUmed and $project and
report potential synergies.
Yes I hope I can be one of these informers (advising only as I am not
skilled enough to *do*) :)
R
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
