gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Tim Churches
Subject: Re: [Gnumed-devel] Machine readable models at openEHR
Date: Mon, 02 Jan 2006 08:42:30 +1100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Karsten Hilbert wrote:
> On Sun, Jan 01, 2006 at 10:06:56AM -0800, Jim Busser wrote:
> 
> 
>>>The latest candidate openEHR specifications are at
>>>http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/index.html
>>><snip>
>>>Should these form the basis of data structures in Gnumed?
> 
> That isn't a useful question IMO.
> 
> A useful question would rather be something like "Should
> these be taken into account for the developement of GNUmed."
> 
> OpenEHR does not simply define data structures. It defines
> entire models (actually, two of them). Hence any software
> being "based on" OpenEHR *is* OpenEHR. It would mean a
> complete rewrite (middleware, backend).

My understanding is that openEHR Archetypes will act as intelligent,
self-validating storage "objects", and thus an openEHR storage engine
will be a lot like an object database. However, widely available openEHR
storage/retreival engines just don't exist yet - there is one open
source one in Java from Sweden I think, but last time I looked it was
incomplete and lacked documentation.

> However, that may be desirable in the future. In fact, if
> any of the standards I know of are to be our future it's
> OpenEHR as far as I am concerned. I have previously said so.

I agree, but until there is an engine to play with, it is hard to tell
how many of the theoretical advantages of the openEHR approach will
carry over to the real world whne used in real information systems. Teh
Australian trials of openEHR in Queensland relate to a shared community
EHR and thus only involve secondary data col;ection, not the initial
data capture or generation (as commonly occurs in GP information
systems), It will be interesting to see how openEHR translates to the
latter domain. I just wish they would bring out an open sourced engine.


>>Potential Pros
>>- a wider set of use cases has likely been factored into the design
> 
> yes
> 
> 
>>- they could assist interoperability
> 
> possibly

It depends how widely openEHR is taken up and what form the social
infrastructure which faciltates the sharing and co-ordination of openEHR
Archetypes takes. A lot more work needs to be done (and not just by the
openEHR people) on the latter, elase it could end up as a big mess of
incompatible Archetypes.

>>- efforts under this framework could be better pooled
> 
> potentially

OK, that's the point I was making pre-emptively above - I must remember:
should always read ahead...

>>Potential Cons
>>- the more expansive, the harder to imagine "whole" implementations
> 
> definitely
> 
> 
>>- have the specs been assembled with a view to being manageable to 
>>implement?
> 
> not really as far as I know them, implementable yes,
> manageable, no, not at our current scale of developers

You'd have to write a storage/retreival engine from scratch. We thought
about this in 2003 for NetEpi, but decided it would be about a
person-year's of work, which we couldn't afford. It is now 2006 and
still no open source openEHR stoage/retreival engine.

>>- hard to code without reasonably fully "digesting, internalizing" 
>>the process that created the specifications?
> 
> yes, hard to code, however, not impossibly hard to digest

The basics are just regular expression wrangling on strings, relating to
each other in fairly sterotypiocal and generalised ways. Perhaps our
estimate of one person-year was too conservative, but a awful lot of
time would need to be put into unit tests and higher-level functional
tests, which means assembling comprehensive suites of test cases, and
that could be very time consuming - the point being that if you write an
engine fro scratch, you have to be sure it works. But doable in Python.
If I won te lottery tomorrow, that is one of the projects I would fund....

>>- could the specs, if written to accommodate the widest possible 
>>audiences and use cases, limit their usability (on account of 
>>compromises) for any one audience, or use case?
> 
> That shouldn't happen, actually.

The idea of Archetypes is that they allow "principled" specialisation,
so a group can start with a more general Archetype and then specilaise
it for their more specific use, and still remain backwardly compatible -
or at least, the compatibility issues should be automatically explicit.

>>How much of the specifications define how data ought to be 
>>*stored/structured*
> 
> hardly any, it gives tools for structuring, but does not
> define how, it does not define how to store pretty much at
> all

Agree. I think teh openEHR approach is just store everything as strings
in a BLOB or just in a file the filesystem. That's teh dumb "back-end"
but all those files/BLOBs need to be addressed via an engine whcih
implements al teh openEHR constraints when working with those
files/strings/BLOBs. Some form of keyed indexing would be needed though
to maintain look-up performance.

>>If, on the whole, the pros would outweigh the cons, some thought 
>>could be given to a migration strategy, maybe to happen after v 0.4? 
> 
> v2.0 or so

Separate project, perhaps GNUmed2 perhaps?

>>Perhaps identifying how the openehr schema could be roadmapped 
>>against what will already have been done would be useful? And would 
>>this only happen if, among the gnumedders, there are individuals who 
>>would do *both* this legwork *and* code? There is a high likelihood 
>>of non-follow-through if the result of the exercise is simply someone 
>>who learns/digests the openehr "way" to just "advise" everyone it 
>>ought to be followed.
> 
> OpenEHR is - AFAICT - an all-or-nothing approach. No
> asymptotic approach from our side being possible.

Agree - hence my suggestion of a separate project if anyone wants to
follow the openEHR route. Could well be worth following.

Tim C




reply via email to

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