[Top][All Lists]

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

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

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

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.


J Busser wrote:

At 7:02 PM +0800 1/1/06, Richard Hosking wrote:

The latest candidate openEHR specifications are at
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.

reply via email to

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