This just reminded me to put a few points down as well before I forget them.
I think openEHR is doing 3 different things, which make it hard to
understand for some organisations:
* /a standards function/: developing, publishing and maintaining
specifications
* /a knowledge engineering function/: facilitating the building of
archetypes, via a community of clinical and health informatics
professionals
o NB: similarly to IHTSDO / SNOMED CT, this could be looked on
as a kind of standards function, since the idea is to get
everyone to use the archetypes
* /an (open source) software development function/: building OS
tools, components, systems that implement the specifications and
consumer the archetypes
The first function has historically been performed by Standards
Development Orgs (SDOs) like CEN, HL7, ASTM, ISO etc; the second by WHO,
WONCA, and now IHTSDO; the third has historically been done by all kinds
of groups and companies. In Health, some SDOs, notably IHTSDO, and HL7
realised they needed tools to make their standards work, so they have
built some software as well.
It may be that the 3 functions of openEHR need to be more separated -
into distinct orgs? Or perhaps into better delineated (and separately
governed?) part of openEHR?
On the general future direction: I think meritocracy is a fine concept.
However, democracy / consensus on design is not - it doesn't work. My
contention is that there is no escape from the analysis and design
functions of software engineering, and these are necessarily limited to
1 or 2 people at a time. Fred Brooks has written a whole book
<http://www.amazon.co.uk/Design-Essays-Computer-Scientist/dp/0201362988/ref=sr_1_1?ie=UTF8&qid=1296663690&sr=8-1>on
this, on which I commented in my blog
<http://wolandscat.net/2010/12/19/design-in-ehealth/>. The real question
is not one of meritocracy, it is of how to practically design and build
specifications and software, in a world where the individuals are all
over the place. You can vote on what priorities should be, and you can
vote on a design that someone has produced, but you can't produce the
design by voting. You can produce very poor specifications by voting,
aka 'design by committee', and the results in e-health are there for all
to see. We should not go that way.
I don't think this is very hard to achieve: a few face-to-face meetings
of relevant project groups would do it, and help people to get to know
each other as well.
Nevertheless, as long as a sensible approach to engineering and
maintaining things is adopted, I do think a more Apache-like community
would be good, at least for the software part of openEHR - i.e. let's
just get moving and build some nice software. However - doing so means
maintaining and continuing to develop the standards that everyone agrees
to, and this is where we need some governance. Currently the standards
in e-health are in a desperate mess, and the customers (governments and
vendors) do not seem to know what to do. In my mind, there is no
escaping the need for a new kind of organisation to create 'standards'
in e-health - an org that runs on a largely open source community and
tools mentality, which however does not fall for the design by committee
trap. More on this in my blog
<http://wolandscat.net/2009/10/18/the-crisis-in-e-health-standards-iii-solutions/>.
Another observation: I had some involvement of the open source health
software community over the last 10 years, and although some nice tools
have been built, they don't interoperate. Open source doesn't help
interoperability generally - that takes a further, special effort.
Secondly, because health IT is so specific, the ability to attract
distant developers to a new tool is very low - too much context and
specific knowledge is generally required. Maybe this could change with
better communications, but with the sector so fragmented, I think it
will still be a challenge.
I think the main issue with openEHR is that if it has value, then those
who get the value need to put some resources toward it. I think it has
achieved quite a lot so far:
* a pretty decent health information reference model, including data
types, EHR, EHR Extract, and demographics
* a pretty clean formalism for expressing content models: Archetype
Definition Language and Object Model
* a formalism for portable querying based on the archetype formalism
(AQL, a-path)
* a growing library of archetypes
* tools which which are not far off enabling full cycle development,
i.e. archetype development => templates => operational template =>
downstream conversions, including message schemas, code APIs,
document schemas etc
* emerging service models
A lot has been learned from implementation over the last couple of
years, and the Jira trackers show a number of small but important change
requests waiting to be done. These represent real maturity: such change
requests are things that nobody could have guessed at the outset. So
openEHR today provides a practical platform for health computing both on
the tooling side and the EHR systems and messaging side. If this is seen
as valuable, or can be turned into practical value, then the only
problem is one of organising the community to support the ongoing work.
Solving the three-headed Hydra problem may be the start.
- thomas beale
On 02/02/2011 15:30, Erik Sundvall wrote:
> On Tue, Dec 21, 2010 at 17:44, Tony Shannon<tony.shannon at nhs.net> wrote:
>> Please see the announcement below for your attention.
>> Your views on the future direction of openEHR are especially important
>> at this time.
>> Please feedback any/all views to this list to generate the discussion we
>> need.
> Hi Tony!
>
> Thanks for inviting comments in an open way. Organisational issues
> have been touched upon earlier (see previous discussions on the
> technical list). I believe some of us would like to know what will
> happen to the feedback this time. Some previous discussion responses
> (and partly an interest in implementation rather than organisation)
> have made me keep a version of this message in draft for several weeks
> instead of finishing and sending it. My hope is that this message
> helps more than it hurts.
>
> Previously parts of a board announcement said...
>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/460c9e09/attachment.html>
