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

Sam Heard sam.heard at oceaninformatics.com
Thu Sep 6 17:44:19 EDT 2012


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

On 6/09/2012 11:56 PM, Thomas Beale wrote:
>
> 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/20120907/2f7be0dc/attachment.html>


More information about the openEHR-clinical mailing list