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 foundation. Heath 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>
