[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Hosking
Subject: [Fwd: Re: [Gnumed-devel] Machine readable models at openEHR]
Date: Tue, 03 Jan 2006 20:59:48 +0800
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)

-------- Original Message --------
Subject:        Re: [Gnumed-devel] Machine readable models at openEHR
Date:   Tue, 03 Jan 2006 20:59:16 +0800
From:   Richard Hosking <address@hidden>
To:     Karsten Hilbert <address@hidden>
References: <address@hidden> <address@hidden>

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*) :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]