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

Sam Heard sam.heard at oceaninformatics.com
Thu Sep 6 17:55:08 EDT 2012


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



On 6/09/2012 8:38 PM, Erik Sundvall wrote:
> Hi!
>
> 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
> 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 ;-)
>
> 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
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>





More information about the openEHR-clinical mailing list