lessons from Intermountain Health, and starting work on openEHR 2.x

Erik Sundvall erik.sundvall at liu.se
Thu Sep 6 07:08:51 EDT 2012


On Thu, Sep 6, 2012 at 12:47 AM, Sam Heard
<sam.heard at oceaninformatics.com> wrote:
> I will be pushing the backward compatibility angle very hard indeed - this
> can be a pain for those who want to progress.

Don't push too hard on "backward compatibility" without a clear
definition of what you mean by it and what you want to apply it to. A
fresh re-start (based on implementation experience by openEHR, 13606,
other CIMI actors etc) can make future systems a lot better than if
they have to be constrained by the "wrong" kind of backward
compatibility philosophy (e.g. "add but never remove"-bloatware). :-)

The openEHR RM includes an attribute with RM version in stored
records, so in one way a storage system can be lifelong and
backwards-preserving even if the RM changes, but queries etc will need
to be rewritten to fit several model versions if you have a mix.

What you could focus on is the "_understand_ any issues for current
systems", of course, but make sure that "understand" does not mean
_constrain_ the future options for change and simplification.
Demanding a list of "this old construct could be converted to this new
construct this way" and "this construct is _not_ algorithmically
convertible" is constructive and educating. But forbidding breaking
changes is not constructive, so I hope (and think) that is not what
you meant.

Going from 1.x to 2.x in software usually _does_ include many breaking
changes. If an non-breaking update/refresh is also needed, then a
1.0.3 or 1.4 version of the openEHR specifications could be produced
in parallel - but don't put the wrong constraints on 2.0!

> I personally guarantee there
> will be no official publication of openEHR 2.0 or ADL 1.5 until we
> absolutely understand any issues for current systems.

Can a chairman really personally guarantee any decisions in a
democratic organization? If you are the CEO or owner of a commercial
company you may have some veto rights in that company, but in the
kinds of democratic organisations I am used to, the chairman does not
have a veto right. What kind of organisation do you want openEHR to

> This does not spring
> from a technical concern - rather our community's commitment to life long
> health records. These are after all the asset of the most value in the
> health care enterprise. There are now 60,000 people with openEHR records in
> one Australian repository, some with as many as 2000 compositions.

That system won't break just because new specifications are published.
System upgrades are not mandatory and do not have to be rushed.

If breaking specification changes are not allowed now when there are
relatively few records, archetypes and implementations, how would it
sound later when there are many more archetypes, implementations and
millions of records? Would breaking changes ever be allowed? Better to
break things early than late, if necessary, when aiming for somewhat
global adoption...

Resisting change favors old implementors with existing systems, but
simplifying/strengthening models and thus future implementation (and
maintenance), makes life easier for new actors wanting to enter the
openEHR scene. So there is probably no neutral ground ;-)

What an interesting dilemma to deal with :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

> On 5/09/2012 10:49 AM, Thomas Beale wrote:
>> for those interested, I have been spending this month with Dr Stan Huff's
>> group at Intermountain Health in Salt lake City. I have at least a dozen
>> potential change requests / issues for openEHR. Mostly small, but important
>> in their way. That has come from the evidence of their systems, and our
>> performing a cross-review during this month. The comparison has shown that
>> we (i.e. openEHR and Intermountain) have essentially the same multi-level
>> modelling system, with different details. Plus I have learned a lot in terms
>> of their design philosophy and thinking.
>> Essentially we can think of these as distilled wisdom/lessons from various
>> incarnations of Stan's leading edge 3M/ASN.1 environment over 15 years, up
>> to the most recent, the Qualibria system using 'CDL' (the ADL equivalent).
>> I'll put these into the openEHR Jira SPEC-PR issue tracker for everyone to
>> see over the next couple of weeks, plus on the mailing lists for more
>> general things I have learned here.
>> The new openEHR Spec programme should get up and running in the next few
>> weeks, which will mean that people here who want to nominate for working on
>> the various specs (i.e. working toward openEHR v2.0) should have a think
>> about doing that. The governance details are mostly worked out, so it just
>> needs people.
>> I know some people feel that the specs have not been changing for too long
>> (myself included) but on the other hand, they have stood up amazingly well
>> over the last few years, and we have a huge amount of industry knowledge
>> accumulated, most of which I think is captured on the PR issue tracker, and
>> at least on the mailing lists. Also, we have a pretty decent ADL/AOM 1.5
>> spec, which needs community review. AQL has also been implemented a number
>> of times and heavily used now, and has held up very well. There are things
>> to change there, based on its use in industry.
>> So, soon we can start on getting a new version of openEHR... it will be a
>> great opportunity I think, to include the clinical and technical lessons
>> available to us in the next generation platform. The community here is
>> wide-ranging and has a huge amount of knowledge... time to use it!
>> - thomas

More information about the openEHR-clinical mailing list