openEHR and HL7 – some thoughts on the current discontents from Chair of openEHR

I returned from a week of sailing to discover flames leaping from
the openEHR list server in the machine room opposite my office! I’m with
many recent correspondents on the lists in welcoming the positive side
of the debate whilst regretting some of the evidence of raw feelings in
play. I’m sure many are wondering or reflecting on what this is all
about. From my perspective, there’s no need for a lot of new words
about openEHR and HL7, per se, but a great need to keep hearts and minds
in good shape for clarifying, understanding and learning from one
another. openEHR is a truly open community; anyone can take its
published outputs and do what they want with them; but their integrity
and that of the community, brand, and methodology of openEHR must be
protected and maintained, we believe. Please keep in mind the words that
all sign up to when joining openEHR and its lists and downloading its
materials.

That said, I know that good things can happen where extreme difference
of view and even animosity is in play. I learned that from seeing a lot
of the action, as a very junior committee member, in the early days of
Amnesty International in the mid 60’s. The offices of the then tiny, but
already strikingly influential, organisation were raided by the secret
police of various countries. But these events felt as nothing compared
with the fights among the visionaries within the movement who were
determined in quite different ways on their view of how the quest for
freedom of expression under the UN Charter, on which all were united,
should be framed and pursued!

‘Never helps hone’ is an anagram of the letters in openEHR and HL Seven!
In my experience, an imposed drive for unity never helps hone good and
enduring answers to problems; finding common mission can and does but we
mustn’t forget that there is strength in diversity and that monopolistic
tendency may serve some interests but, equally, carry with it the
potential for weakening or corrupting others. I’m writing here as
someone a bit removed from the heat of the crucible of EHR
implementation and standardisation, who, nonetheless, sees and hears,
from colleagues and students on the front line, many inner details of
what is playing out. From the policy to the practice of health care
modernisation and in the creation of new health care information
infrastructure, in many countries, the debate ongoing through
the openEHR lists is becoming a central concern. That’s a good thing; a
very good thing. For too long the issues have been delegated or
relegated unduly far from the clinical domain and into the domains of
engineering and organisation. Unfulfilled aspiration for health IT has
created a poker game of ever increasing stakes of ambition, resource and
emotion, drawing in an ever wider range of stakeholders, to the top
policy levels. Just look at the Commonwealth Fund web site in the States
or view on the web the recent Public Accounts Committee hearing on CfH,
in the UK.

I’ve been around the debate a long time and have learned that the three
things that matter, as I’ve said before, are implementation,
implementation and implementation! The problem with standardising, top
down, before doing, is that one tends never to have time to do, and
learn well through doing. The problem with doing, bottom up, before
learning how to standardise, is that one tends to spend a lot too much
time and money, creating eventual ultimate havoc of incompatible legacy.
This complexity can only be reduced to tractable levels through starting
again, while problems of integration remain elusive. I see the waste and
despair that creates in the healthcare workforce. It’s a Catch 22; I can
chart five reinventions of a national programme for IT, within the NHS,
in my career.

At its heart, all of this is a debate about emerging discipline, notably
in medicine and computer science and at their interface. It’s hard
because that discipline has been sorely lacking on all sides and in
their intersections. No one’s fault, really, but shameful, all the same,
that through diverse confusions and confabulations, the protection of
the multi-billions that are now spent on not serving well the
information needs of healthcare, end up with money mainly directed,
largely unwittingly, and not in any sense by stupid people, in ways that
have still failed to reach or be allowed near the heart of the matter.
That is where considerations of quality, information and governance
intersect in providing health services that people trust and value. In
such circumstances, there are problems best approached through
simplifying and withdrawing resource; Fred Brooks and his concept of the
mythical man-month is salutary.

openEHR has never yet had external financial support; we, our research
teams, colleagues and parent organisations have done it ourselves. Of
course, it has been largely ignored on high, for as long as possible,
because bottom-up and top-down motivated initiative is bound to
encounter an uncomfortable collision layer in the real world. That
collision is occurring right in the middle of changing patient care. I
have very disappointing records of how the ideas motivating openEHR were
introduced to numerous important people over recent years, illustrating
how weak the critical appraisal of health IT principles still is, in
clinical, management and technical terms.

There seems to be an implication in some of the recent contributions to
the lists that openEHR is somehow now rocking the boat. In terms of its
economic weight, that really feels like criticising someone moving a
deck chair on the Titanic for its demise. Incidentally, according to a
recent paper, it was probably weak rivets and not the iceberg that
caused the disaster. Having just been sailing, forgive me for
introducing a navigational Catch 22. It’s sometimes not a good idea and
in no one’s interest to rock the boat because it may capsize; but you
sometimes have to rock the boat to learn how to build boats safely and
sail them. openEHR and HL7 are contrasting voyages of discovery and
exercises in simultaneous boat, crew and community building, in the open
water. They’re building new kinds of boats and learning how to sail them
at the same time; that needs a certain kind of foolhardy spirit, to be
sure, but innovation was ever thus. In health informatics, there are
some emerging principles about boats, teams, weather and seaworthiness,
but not enough is known yet to be confident about laws covering what is
and isn’t allowed to be a system (boat) and how they should be
regulated; what and where the Plimsoll line might be, for example.

We’re in a situation, nonetheless where many people, who have to get
across the sea, are being persuaded to get into some pretty unseaworthy
boats. That’s an observation about the inner workings of systems and
software, which I’ve observed, for thirty years. It’s not a purist
argument as some pretty ropey early stage software has achieved some
pretty amazing impacts. But it is a comment about mission, method and
maturation of sustainable infrastructure. I could give some old and some
distressingly current examples of unseaworthy systems and projects, but
don’t want to be too provocative.

As the board of directors of the Foundation, we’ve tried always to
keep openEHR itself free from being typecast by things like datatypes,
information models and engineering systems, important though these
undoubtedly are. Let us forget any idea that there are right and wrong
answers to these issues. But let us remember that there are good and bad
approaches and retain an independent sense of what is good enough or not
good enough, in context. Otherwise there will be neither sustained
progress nor proper regulation and governance, and its health care that
will be the worse.

My perspective comes from earlier days as a physicist. Many of the
models that have been at the heart of the evolving discipline of physics
are in some senses both right and wrong. They help in some ways, they
don’t in others. They’re none the worse for that.

A rigorous grip on the scope of the modelled domain and the measurements
and behaviours addressed within it are essential for any modelling
exercise of worth. When I was first studying physics, the vibrational
spectra of nuclei were well predicted by analogy with a spherical drop
of liquid and its vibrations. When you fired protons at a large nucleus
and observed fission and the emission of a whole host of new particles,
you were nowhere near modelling these starting from the analogy of a
spherical drop model. Getting there by further pursuing that analogy and
formula was not a good way forward. The problems of modelling the
nucleus as a many-body problem in quantum mechanics have taken decades
longer than the simple task in classical mechanics of calculating
vibrational properties of a liquid drop. But each model had its domain
and utility. Scientifically, physics didn’t move forward by combining
them into a single omni-domain model, just as the idea of painting a
canvas by mixing all yellows and blues and thus replacing with greens
also loses something. Quantum mechanics and much much more powerful
computers evolved to fulfil the modelling needs of interest and
relevance to contemporary experimental physics.

Since the idea of openEHR first came to us, we’ve tried always to keep
clinical and health care needs and realities at the heart of its
mission, in practical ways. It’s hard to do. What medicine is, how it
works and how one would know what constitutes good medicine are
challenges identified since the times of Florence Nightingale and still
at the heart of practising and managing health care. Innovation can
damage and threaten stability; conservatism and vested interest can
impede useful advance; that’s true everywhere. If you read the biography
of Stanley Prusiner, Nobel Laureate in Medicine for his work on prion
disease, you will see a story of a man blocked at various stages of his
career for his challenge to biological genetics orthodoxy; just as
Copernicus and Galileo challenged the orthodoxies of the church of their
day. Blocked tenure led onto Nobel Prize with stupefying rapidity! All
scientific innovation grows in Conan Doyle’s country of the blind where
the one-eyed man is king. Let’s try and suppress judgmentalism and treat
the journey as an experimental one, guided by implementation experience.
But let us be honest and free in our appraisals, confident that they
will in turn be appraised in a good and fair light.

openEHR as a community has received and has sought noone’s money other
than from those who work directly at its heart. Its rise within the
international agenda is indicative of something. I’m sure we’ll stick at
it, working with everyone, guided by our own perspectives, methods and
ways of doing things. There is a log jam in health IT. A memorable paper
claims that sorting out health care data is an $80billion per annum
problem for the US economy. In some sense, we believe that it needs to
be transformed to a problem perhaps an order of magnitude less than that
in monetary terms. It’s hard to make a business case for saving so much
money when those effectively spending and consuming it are persuaded or
in cahoots that more and more rather than less and less spending of our
societies’ money is needed to deal with the problem. Maybe that is
flames from me, now!

David Ingram, Chair of the openEHR Foundation
September 21st, 2006

Hi,

First I have a few explanations, than a few questions.

I hope Rong and Thomas will read further, because they can possibly
answer my questions.
But others can have interesting opinions, and I alos hope that they will
read this, and maybe try to answer my questions

As I can see in the code, there is already a lot of work done on the way
to 1.0 version. But I have no exact todo list, that is why I cannot
really judge that.

Were can I discover what parts of the kernel are not yet 1.0, where can
I expect problems, and which parts are more or less stable?

The 1.0.1 update on RM is done. The update on AOM and parser will soon be finished. The Java kernel will be divided into RM, AOM, parser, serializer, builder etc to make it easiser to maintain and test these components.

The stability I look for is most important on the “edges (interfaces)”
where it communicates on other code.

  • So, is it possible for me to write a stable persistent layer, or are
    there important changes to expect which causes my work to be done for
    nothing?

The persistence layer should be based on RM classes, so if the RM is stable (which is the case now) you should be able to build a stable persistence layer.

  • How about the ADL-parser, are there important problems, which makes it
    difficult/impossible to use important archetypes?

The parser is rather up-to-date (thanks to Mattias work on the editor :slight_smile:

  • How about the code-interfaces, the class-interfaces, are there
    important changes to expect?

What is your advise to me, should I start with your trunk-kernel and
keep it up to date with code changes, do you think that is possible?

We are going to announce some new branch very soon.

Cheers,
Rong

Bert Verhees wrote:

The problem also is, that we cannot wait another year, since we have
come this far.

Release 1.0.1 is nearly done, and the deliverables are all online now (see the home page). Three more changes are expected to be made that we didn’t foresee:

  • we propose to add an optional attribute to DvOrdered called something like “rangeQualifier” that can take values like values like “HHH”, “HH”, …“L”, “LL”, “LLL”. This is not because we think it is a nice idea, it is because implementers (in Australia as it turns out) working with HL7v2 messages coming from labs have discovered that this kind of flag is often supplied on individual lab values, and openEHR cannot throw it away. I have not yet written up the CR for this, but will alert everyone when I have, and of course you should comment. But the proposal will be designed to make no difference to existing openEHR data or software.
  • http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/144/pcng_issue_view - Ratio type. We thought we would leave this to the next release originally, but since we have taken longer to get 1.0.1 done than expected (due to the huge amount of feedback), we think it should be included. The justification is that it provides a model of certain pathology values that currently cannot be correct captured using the existing types.
  • We may have to make DvCount.magnitude a Real rather than an Integer, to allow for countable but partial amounts, like 1 1/2 tablets etc. We have not yet written a CR for this.
    These 3 changes as you can see are all in the Quantity package, and deal with relatively obscure problems not dealt with by the current model; in other words we see them as corrections. We could pretend that the problems don’t exist, and say that openEHR 1.0.1 is more stable, but that wouldn’t be the right approach in my view. The problems such as the above are not correctly addressed in HL7 or CEN or other models, but the need is clearly there in the data.

However, other than these changes, that is it for 1.0.1.

I have enough knowledge of the internals to build my own persistent
layer, I have to maintain an archetype-editor, maybe have to build a new
one (I heard about problems about the dotnet-technology and saving files
on Mac)

Why are you maintaining an archetype editor? There are two already being maintained. The Java one will work on the Mac, if that is the platform you want…

I have some choices, but are there really choices? I cannot judge that.
That is why I am writing this.

It is no option to follow the latest version, because that is a moving
target.

Not sure why you say that - do you mean the latest Release of openEHR? What is in Release 1.0.1 is given precisely on this page http://svn.openehr.org/specification/TRUNK/history.htm plus the 3 things mentioned above. The release will be declared in a couple of weeks. So, it’s not moving really, it’s very stable.

I also want to do as less work as possible

--------------------------------------
My questions
---------------------------------------
---------------------------------------
Eiffel
---------------------------------------
This is described much more promising.
[http://svn.openehr.org/ref_impl_eiffel/TRUNK/project_page.htm](http://svn.openehr.org/ref_impl_eiffel/TRUNK/project_page.htm)

It states ADL is up to 1.4, the ref model is more less conformant to the
1.0.1 version.

this is true, but less of the necessary functions are implemented (e.g. quite a few set functions).

Because it is written in Eifel, and it has produced dotnet-versions, I
come to following assumptions.

It is possible to create dotnet libraries from the code, maybe these are
already published but have to be rebuild because of license-issues in
commercial environments.

we haven’t published a .Net DLL of this because it is not complete, but it is easy enough to do

because the complete kernel and parser are in it, they can directly be
used in an dotnet application, and the only thing I have to do is
implement and write a persistence layer.

The kernel is not yet complete, although if we can get paid to do it, we would elevate its priority.

I don't expect to be ready in a few weeks, but in a few months,
certainly yes.

yes, it could well be done by then anyway. The Eiffel kernel could be deployed in dotNet, or on any unix machine in a C/C++ environment. It could also be used with Java, but this is harder, because Java only offers the arcane JNI method to talk to C-based code (but I have done it before with the ADL parser, and it works).

The Java group are doing a good job on getting the Java code up to date (it is on a branch); this also requires more work. But I would not see this as a moving target in the sense that you don’t know what it is supposed to do (it is supposed to implement 1.0.1, which is fully described, as above); it might be a bit of a moving target in terms of work still going on, but this is (as ever) limited by funding and resource options.

My guess is the main decision is to know what your deployment platform and technology preference is.

  • thomas

Thanks, Thomas, for your answer, and excuse me for my late reply (busy,
busy).

I understand that 1.0.1 is not really finished. I will look up the
changes when it is ready.

Release 1.0.1 is nearly done, and the deliverables are all online now
(see the home page). Three more changes are expected to be made that
we didn't foresee:

Do you advise me to implement version 1.0?

This question is not specific for a special implementation. (Java or Eiffel)

thanks
Bert

Bert Verhees wrote:

Thanks, Thomas, for your answer, and excuse me for my late reply (busy,
busy).

I understand that 1.0.1 is not really finished. I will look up the
changes when it is ready.

Release 1.0.1 is nearly done, and the deliverables are all online now
(see the home page). Three more changes are expected to be made that
we didn't foresee:
    

Do you advise me to implement version 1.0?
  

definitely 1.0.1 - 1.0.1 is 1.0 with the problems fixed. The UML and XML
are already online.

- thomas