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

[Karsten Hilbert]

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).

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.

> Potential Pros
> - a wider set of use cases has likely been factored into the design
yes

> - they could assist interoperability
possibly

> - efforts under this framework could be better pooled
potentially

> 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

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

> - 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.

> 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

> 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

> 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.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346