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

Thomas Beale thomas.beale at oceaninformatics.com
Thu Sep 6 10:35:01 EDT 2012


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:
      o impact of the changes on *existing software*, including tools
        and re-usable libraries
      o impact of the changes on existing *archetypes and templates*
      o impact of these changes on *existing data*, and if appropriate,
        migration / transformation algorithms for the data to convert to
        the new form
      o 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 at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20120906/4fbbf322/attachment.html>


More information about the openEHR-clinical mailing list