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

Bert Verhees bert.verhees at rosa.nl
Wed Sep 12 04:27:16 EDT 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20120912/1e48bf24/attachment.html>


More information about the openEHR-clinical mailing list