gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] forms handling / NetEpi


From: Tim Churches
Subject: Re: [Gnumed-devel] forms handling / NetEpi
Date: Thu, 28 Jun 2007 06:48:10 +1000
User-agent: Thunderbird 1.5.0.12 (Windows/20070509)

Karsten Hilbert wrote:
> On Wed, Jun 27, 2007 at 08:46:15AM +1000, syan tan wrote:
> 
>>>> If we were starting stoday, we would use openEHR
>>>> archetypes or a variation thereof, but we'd need to spend
>>>> 6-12 months building the engine ourselves.
>>> If I had the manpower I'd go that route, too, yes.
>> how would that be faster than storing entity attribute values ?
> The suggested storage architecture for openEHR artifacts is
> medium-granularity blobs quite similar to what NetEpis form
> defs are. It would carry over that advantage (fewer
> subqueries to retrieve relevant chunks) to the form data
> itself.

openEHR archetype definitions are supposed to be stored as blobs, but
the actual data values can be stored in XML or in a database which uses
the RIM as its schema. In that sense, openEHR is just a more elaborate
version of the EAV formulation. The problem is that building a complete
openEHR kernel, and testing it, is not a trivial undertaking, evidenced
by the fact that none of the teams working on openEHR (for many, many
years, some for a decade or more) have done it yet (at least not to teh
stage that they have released such engines for sale or downlaod).

> The real benefit of it, however, would be cleanly modelled
> infrastructure.

Cleanly but complexly. I wonder if openEHR complexity is just as much as
is needed, or a bit too much. Hard to say in the absence of working,
testable implementations.

You should also look at openMRS if you are going down the EAV route,
because that is what they use and it seems to work for them. They have a
nice schema diagram on their web site.

Tim C




reply via email to

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