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

[Tim Churches]

Richard Hosking <address@hidden> wrote:
> OpenEHR/GEHR etc have been around for 15 years or so - they have always 
> seemed to tread a fine line between commercial and open source. Ocean 
> Informatics has a commercial company structure and links to *very* 
> commercial bodies - I understand one the directors has been on the board 
> of HCN for example. Clearly this strategy has been successful in that 
> they have been able to get  sponsorship to continue their work. They 
> have made the main deliverables open so I think they have a legitimate 
> claim to being "open".
> Their work seems very well documented and has a solid research basis. I 
> think a good data model is probably necessary for properly designed 
> software. The Gnumedders have thought about this issue in a more 
> informal way.
> It is not clear whether OpenEHR will become a standard, but it does seem 
> to have more penetration than any other model. Unfortunately they have 
> used C#, Eiffel, and Java for their work. They apparently have a DB 
> backend in C# which *may* be open sourced, but this is vapourware at 
> present.
> It should be possible to convert the OpenEHR reference model/archetype 
> combination to SQL - I will attempt to do this by hand for a simple 
> archetype as a start.

Richard,

Before you start doing SQL by hand, have a look at some Python ORMs - may I 
recommend SQLalchemy - see http://www.sqlalchemy.org/ and SQLobject - see 
http://www.sqlobject.org/ - the former is more advanced but also more complex 
than the latter. Neither are perfect but they may give you some ideas about 
better ways to interface to relational database back-ends.

I think that an implementation of the openEHR RIM (reference information model) 
via one of these Python ORMs would be very interesting, although the hard bit 
is building an openEHR constraints engine on top of the RIM implementation, so 
that an ADL can be used to automatically marshall a bunch of data into an 
archetype data model. 

But as Ian Haywood said that David Guest said: it ain't that hard. I share the 
sneaking suspicion that the openEHR guys are deeply involved in figuring out 
optimal techniques for Olympic hurdling before they are even able to walk. 
There may be a place for GNUmed2 to implement an openEHR-for-dummies engine 
that actually works. At its heart, after you strip away the jargon, openEHR is 
not really very revolutionary - its just a well-thought out elaboration of what 
many have been doing for a long time - it brings formal order to EAV and other 
generalised RIMs. But it is possible to think too much. Consider, for example, 
the case of Schopenhauer...

Tim C

> J Busser wrote:
> 
> > At 7:02 PM +0800 1/1/06, Richard Hosking wrote:
> >
> >> The latest candidate openEHR specifications are at
> >> 
> http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publi
> shing/index.html 
> >>
> >> <snip>
> >> Should these form the basis of data structures in Gnumed?
> >
> >
> > I don't know the answer but maybe some thoughts can help.
> >
> > Much of the impact of any data structure will be on the coders (though 
> 
> > it will also impact users in areas of data interchange, and the amount 
> 
> > of work getting interfaces to the backends rewritten to take advantage 
> 
> > e.g. of clinical decision support).
> >
> > Recently Karsten replied to related questions, indicating a preference 
> 
> > for monitors and/or devil's advocates to indicate why a standards 
> > body/group designs something a certain way, and why that rationale (if 
> 
> > there is one) deserves adoption/adherence. It implied some further 
> > understanding we may need to reach about how/why to "adopt" anything 
> > like the above:
> >
> > Potential Pros
> > - a wider set of use cases has likely been factored into the design
> > - they could assist interoperability (regardless of whether 
> > "intrinsically better")
> > - efforts under this framework could be better pooled
> >
> > Potential Cons
> > - the more expansive, the harder to imagine "whole" implementations
> > - have the specs been assembled with a view to being manageable to 
> > implement?
> > - hard to code without reasonably fully "digesting, internalizing" the 
> 
> > process that created the specifications?
> > - 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?
> >
> > How much of the specifications define how data ought to be 
> > *stored/structured*, or is that only an issue to the extent that it 
> > could simplify *exchange* according to their specs?
> >
> > 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? 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.
> >
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel