lessons from Intermountain Health, and starting work on openEHR 2.x
erik.sundvall at liu.se
Thu Sep 13 03:48:09 EDT 2012
On 12/09/2012 17:43, Heath Frankel wrote:
> 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
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
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:
(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
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. :-)
> 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
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical