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

Heath Frankel heath.frankel at oceaninformatics.com
Wed Sep 12 19:43:25 EDT 2012

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
On 12/09/2012 5:57 PM, "Bert Verhees" <bert.verhees at rosa.nl> wrote:

>  On 06-09-12 23:44, Sam Heard wrote:
> 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
>  I want to add following which I stumbled over, accidentally:
>  The information model doesn't change in openEHR - it is designed to be
> stable for a very long time (actually certain additions can be safely
> made).
> - thomas
> http://lists.openehr.org/pipermail/openehr-implementers_lists.openehr.org/2008-August/000436.html
> 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
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20120913/b1c986d9/attachment.html>

More information about the openEHR-clinical mailing list