[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Machine readable models at openEHR
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] Machine readable models at openEHR |
Date: |
Sun, 1 Jan 2006 10:06:56 -0800 |
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/publishing/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] Machine readable models at openEHR, Richard Hosking, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR,
J Busser <=
- Re: [Gnumed-devel] Machine readable models at openEHR, Karsten Hilbert, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Tim Churches, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, J Busser, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Tim Churches, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Tim Churches, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Karsten Hilbert, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Karsten Hilbert, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Karsten Hilbert, 2006/01/01
- Re: [Gnumed-devel] Machine readable models at openEHR, Karsten Hilbert, 2006/01/03
Re: [Gnumed-devel] Machine readable models at openEHR, Richard Hosking, 2006/01/02