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

Technical (archive)
1

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

2

Hi Thomas, great news! and looking forward to help on the specs.

3

Hi

Great to hear about the progress with Stan Huff and his team Thomas. It has taken a lot of dipping in the water before we have got a real chance to have an indepth collaborative approach to developing openEHR 2.0. I believe this should process should include a few people from CIMI and 13606 who are actually running systems and know what is involved. I hope those that fit the bill will approach Thomas to participate in the next generation of openEHR.

I will be pushing the backward compatibility angle very hard indeed - this can be a pain for those who want to progress. 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. 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.

Cheers, Sam

4

Op 6-9-2012 0:47, Sam Heard schreef:

I will be pushing the backward compatibility angle very hard indeed - this can be a pain for those who want to progress. 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. This does not spring from a technical concern - rather our community's commitment to life long health records.

Thanks Sam,

For my point of view, I really appreciate this!

regards
Bert Verhees

5

Hi!

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). :slight_smile:

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
be?

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 :wink:

What an interesting dilemma to deal with :slight_smile:

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

6

Personally I think the best way to look at this is as follows:

  • specifications will evolve, and they may include breaking changes. As a community we should stick to the usual rules (semver.org) whereby we identify releases containing breaking changes with a new major version

  • all releases should be published with the list of changes with respect to the previous release (‘release notes’) and a system impact statement as follows:

  • impact of the changes on existing software, including tools and re-usable libraries

  • impact of the changes on existing archetypes and templates

  • impact of these changes on existing data, and if appropriate, migration / transformation algorithms for the data to convert to the new form

  • impact of the changes on existing queries, and how they should be upgraded if appropriate

Of course we will try our best to minimise such changes. But none of us here are perfect, so we will never totally succeed at that. For the last two items, there would preferably be software tools / scripts etc available to do the work. Overall, the above should ensure existing systems can be made to interoperate with newer systems. Obviously since in openEHR we are somewhat obsessive about reference model stability, we can hope that the impacts will not be great, and in fact will be very acceptable in comparison to most changes in comparable published standards or industry products.

The implication is always there that someone starting an implementation from scratch later on will build a better system. That’s life, and it’s how the world makes progress. Someone with an older system might have the annoyance of correcting existing queries or whatever, but on the other hand, they will always be ahead in database optimisation, application framework building and other matters. That’s life.

I don’t believe we can legislate on what organisations actually choose to do with the specifications - in the end it will be up to them. Our job is to make sure adopters can make informed decisions. Our real goal is to show how using the output of openEHR can actually lead to better health outcomes for society.

  • thomas
7

Personally I think the best way to look at this is as follows:

  • specifications will evolve, and they may include breaking changes. As a community we should stick to the usual rules (semver.org) whereby we identify releases containing breaking changes with a new major version

  • all releases should be published with the list of changes with respect to the previous release (‘release notes’) and a system impact statement as follows:

  • impact of the changes on existing software, including tools and re-usable libraries

  • impact of the changes on existing archetypes and templates

  • impact of these changes on existing data, and if appropriate, migration / transformation algorithms for the data to convert to the new form

  • impact of the changes on existing queries, and how they should be upgraded if appropriate

Of course we will try our best to minimise such changes. But none of us here are perfect, so we will never totally succeed at that. For the last two items, there would preferably be software tools / scripts etc available to do the work. Overall, the above should ensure existing systems can be made to interoperate with newer systems. Obviously since in openEHR we are somewhat obsessive about reference model stability, we can hope that the impacts will not be great, and in fact will be very acceptable in comparison to most changes in comparable published standards or industry products.

The implication is always there that someone starting an implementation from scratch later on will build a better system. That’s life, and it’s how the world makes progress. Someone with an older system might have the annoyance of correcting existing queries or whatever, but on the other hand, they will always be ahead in database optimisation, application framework building and other matters. That’s life.

I don’t believe we can legislate on what organisations actually choose to do with the specifications - in the end it will be up to them. Our job is to make sure adopters can make informed decisions. Our real goal is to show how using the output of openEHR can actually lead to better health outcomes for society.

  • thomas
_______________________________________________
openEHR-technical mailing list
[openEHR-technical@lists.openehr.org](mailto:openEHR-technical@lists.openehr.org)
[http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org](http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org)
8

Hi Tom

I absolutely agree with your summary. Technically I think making use of obsolescence is the appropriate way to go in software. No competent vendor will put out an operating system, compiler or software that breaks existing tools without doing the work for them.

The point I am making is that there are now health records out there so we need to be absolutely clear that existing health records will work with changes. If we want to use upgrade scripts these need to be handled between releases so that the old and new work at the same time for a while and ensure we have planned obsolescence over a period of software cycles (say 3-5 years).

Cheers, Sam

9

Thanks Erik

We, the openEHR community, have an approach that is just now becoming highly relevant as people genuinely want to share health records. The projects are multimillion dollar and have learned a great deal about the realities of supporting clinical care.

Technically I want you and Thomas to push as hard as you can for good solutions but I am just ensuring that the clinical and national concerns of our users are met as well. We can have openEHR v3 that is technically magnificent but offers nothing to the people doing the work.

Your point about gradual evolution with a version 2 goal state is the way we need to go, with careful transition. I want openEHR to be successful as you do, but realise the tension for rapid technical development and careful management of the key asset in health care (a person's electronic health record) has to be always at the fore. The split in RM and archetypes arose out of this tension - otherwise you would always do what others do and flatten the model to work with current technology.

Lets keep the debate going as we evolve the solutions. I made a loud retort to make sure the clinical voice is heard.

Cheers, Sam

10

yep. That’s called release management :wink: - thomas

11

I want to add following which I stumbled over, accidentally: I must also say that the stability of the RM is one of my most important selling-arguments. Please regard this in your future thinking about RM-development. Thanks Bert

12

Hi all,
I agree we need to try achieve Sam’s desire for backward compatibility in release 2. This is no longer an academic exercise. By the end of the year we will have systems running with the potential of 4 million health records growing at 25000 compositions a day. To migrate this volume of data will require significant planning, testing and processing, I have gone through this already when we went from release 1.0 through to release 1.0.2.
I don’t want to cripple progress nor do we want software bloat, but we needs some guiding principles to ensure we don’t scare off our converts before the get started.
HL7 have been doing the for 30 years with pretty good success, and look what happened when they offered a major upgrade. It was just about it being a bad design, too complex etc, in fact it is closer to what we have than HL7 v2. The big issue was the effort for vendors to transition existing systems. Yes this is an extreme case but my point is more about how V2 succeeded for 30 years and continues.
We need a depreciation scheme that allows us to say that something is no longer recommended for use in a particular release and removed in a subsequent release. This gives implementations time to migrate to the new recommendation. It also means we can get some experience with what the new recommendation is before we remove the deprecated approach.
Please be careful about backward compatibility of our RM, its core to our foundation.
Heath

13

One key approach that we can use for adding breaking fixes to classes is to actually add a new class. For example, a new version of ARCHETYPE_SLOT is needed in the AOM. The way I would propose to do this is not to ‘fix’ the existing ARCHETYPE_SLOT, but to add a new class ARCHETYPE_SLOT2 or SEMANTIC_SLOT or whatever, and enhance existing compilers to handle the new one, and to know how convert between both. This is just an example - there are probably similar instances of breaking changes in the RM. Many change requests I am aware of would not break existing data. The main ones we need to be careful with are structural changes to Entry classes and to the Participations model. We need of course to analyse all the proposed changes carefully, but by now we have a reasonable number of implementers, and they will need to be present on the new specifications editorial committee to help assess impact of any given change. So… we just need to do good engineering thinking on this. - thomas

14

Hi!

We need a depreciation scheme that allows us to say that something
is no longer recommended for use in a particular release and removed
in a subsequent release. This gives implementations time to migrate to
the new recommendation. It also means we can get some experience
with what the new recommendation is before we remove the deprecated
approach.

Yes, what about using that approach (deprecation scheme etc) for a “stable” or “production grade” series of versions - v 1.0.3, v 1.1 and so on…
…and at the same time start working on an “experimental” 2.x series.

This is how it is often done in big open source projects (with a lot bigger user base than openEHR has). Critical systems, in production use, seldom jump over to the new 2.x series while it is young, they wait for it to mature. BUT they have been able to follow and comment on the 2.x development all along the way so that they can be prepared without constraining the options by insisting on full backwards compatibility. The 1.x branch could also slowly make changes to prepare for a simplified future transition to 2.x including adding transformation tools.

If we want 13606, CIMI and openEHR modelling to merge somewhere in 2.x, the we can not express too much protectionism from openEHRs side. (I think I have heard people complaining about HL7 protectionism on these lists…) Truly good changes (simplifications, increased archetyping flexibility etc) should not be stopped by protectionism, but of course things should be well tested in implementation before new specifications are finalized. It would be great if e.g most of the future ISO 13606 version could be a true subset of openEHR instead of the current confusing situation.

In the openEHR 1.x to 2.x case perhaps we will understand each other better if we discuss concrete examples rather than expressing unspecified fears from both “sides”, I’ll start one below. Feel free to add other examples (a concrete example of proposed data type changes for example).

When you look at http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals±+lower+information+model, do you then think that the discussed changes at e.g. ENTRY and ITEM_STRUCTURE level will reduce bloat and misunderstandings, at the same time as it increases flexibility and understanding? Would that be truly good for openEHR archetyping and implementation?

Ian, an experienced archetype developer, has been asking for this increased flexibility, see: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals±+lower+information+model?focusedCommentId=32210974#comment-32210974. (I think Sam also mentioned similar thoughts on the lists earlier.) I had guessed that those proposed changes are big and breaking enough to go for 2.x rather than a “soft deprecation” 1.x series, what is the opinion of those of you that have big systems running? Do they fit in a 1.x series upgrade path?

I thought anything that breaks paths would likely be considered a “big” change. (In the example above, the transition path including automated data conversion is pretty clear though.) It is probably better to break these paths in an experimental 2.x series now rather than waiting five+ years and try to squeeze it in to 1.8 or something. :slight_smile:

HL7 […] look what happened when they offered a major upgrade. […]
The big issue was the effort for vendors to transition existing systems

I think that might be a somewhat unfair comparison:

  1. The proposed openEHR 2.0 changes I have seen so far are not deviating from the basic design principles and design patterns in openEHR. The basic approach does NOT change the same way as HL7 did between v2 and v3.
  2. The number of vendors using openEHR now is a lot smaller than the ones that used HL7 v2
  3. The number of vendors we want to join the openEHR approach in the future is a lot bigger than the ones that have existing openEHR-based production systems.

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

15

Hi,

2012/9/13 Erik Sundvall <erik.sundvall@liu.se>

It would be great if e.g most of the future ISO 13606 version could be a true subset of openEHR instead of the current confusing situation.

This is something I discussed with Thomas some time ago, it would be one of the best harmonisation solutions, but probably with a slightly different interpretation. Since 13606 has more generic classes (eg. the generic ENTRY can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 13606 being a subset of openEHR I think that openEHR should be a specialized model of 13606. Obviously this would require a deep analysis and changes of the models, but that could be the idea.

16

yep, this is just a question of agreeing what release id goes with what changes, in the Specification Programme. I think the key will be to decide what openEHR 2.x is actually for. From my point of view, it’s primary goal is to actually work for implementing real systems, as it does now. That means that all proposed changes have to be carefully analysed for consequences in software - not just in existing systems (i.e. what will break) but any system or implementation. I.e. do the specs lead to good quality software and data? Which requires implementability, reduction of errors etc etc. So although we do want to get a harmonised standard with 13606 and others, the primary goal needs to remain ‘what works’, not what looks pretty in a UML diagram or whatever else. openEHR needs to be a standard for the real world. We have already posted some possible simplifications which should improve things without reducing software implementability and power. these are key questions, but I want to see us stay on the ‘implementability’ mission as a key driver as well. Some of the above proposals are very nice (I really like the one I wrote :wink: I don’t think that analysis has been done yet; there are two kinds of implementation concern: changes that break paths in existing archetypes should be avoided where those archetypes have already been deployed. But… if we make changes that break existing archetypes that have never been deployed in clinical context, we can deal with that - that is just model conversion. Right now, we don’t know how many that is. right - we are essentially talking about incremental changes, not a change of paradigm (we already did the change of paradigm on v1 of openEHR :wink: both true, so there is room to move. There are however already implemented openEHR systems in some hundreds of hospitals & clinics around the world, so there is a question mainly about the data and deployed archetypes in those places. - thomas

17

yep. I have a few more ideas on this not yet posted, to try and reduce gaps. Will do so in the next week or so. - thomas

18

I don’t care about the linguistics of subset / specialisation etc, I just care about getting one model… - thomas

19

although - it will probably come out to have multiple entry points. The 13606 model is about what makes sense in EHR Extract messages. We built and implemented a more recent version of that, using lessons from 13606 - the openEHR EHR Extract. There are undoubtedly a lot of lessons from 13606 Extract use out there (there must be because nearly everyone implements the standard by changing, so that says something!). However, other parts of openEHR are concerned with the logical semantics of in situ EHRs, not just messages travelling between systems. So I think there could be a common core, an EHR part and an EHR Extract part. Having one standard for that would be hugely useful for industry. - thomas

20

I just care about getting one model…

In the case of 13606 one good model that describes a generic interface for EHR communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M: +31 620347088
E: gerard.freriks@EN13606.org

W: http:www.en13606.org