On 13/09/2012 03:48, Erik Sundvall wrote: > Hi! > > On 12/09/2012 17:43, Heath Frankel wrote: > > 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. > > Yes, what about using that approach (deprecation scheme etc) for a > "stable" or "production grade" series of versions - v 1.0.3, v 1.1 and > so on... > ...and at the same time start working on an "experimental" 2.x series.
yep, this is just a question of agreeing what release id goes with what changes, in the Specification Programme. > > This is how it is often done in big open source projects (with a lot > bigger user base than openEHR has). Critical systems, in > production use, seldom jump over to the new 2.x series while it is > young, they wait for it to mature. BUT they have been able to follow > and comment on the 2.x development all along the way so that they can > be prepared without constraining the options by insisting on full > backwards compatibility. The 1.x branch could also slowly make changes > to prepare for a simplified future transition to 2.x including adding > transformation tools. > > If we want 13606, CIMI and openEHR modelling to merge somewhere in > 2.x, the we can not express too much protectionism from openEHRs side. > (I think I have heard people complaining about HL7 protectionism on > these lists...) Truly good changes (simplifications, increased > archetyping flexibility etc) should not be stopped by > protectionism, but of course things should be well tested in > implementation before new specifications are finalized. It would be > great if e.g most of the future ISO 13606 version could be a true > subset of openEHR instead of the current confusing situation. I think the key will be to decide what openEHR 2.x is actually for. From my point of view, it's primary goal is to actually work for implementing real systems, as it does now. That means that all proposed changes have to be carefully analysed for consequences in software - not just in existing systems (i.e. what will break) but any system or implementation. I.e. do the specs lead to good quality software and data? Which requires implementability, reduction of errors etc etc. So although we do want to get a harmonised standard with 13606 and others, the primary goal needs to remain 'what works', not what looks pretty in a UML diagram or whatever else. openEHR needs to be a standard for the real world. We have already posted some possible simplifications which should improve things without reducing software implementability and power. > > In the openEHR 1.x to 2.x case perhaps we will understand each other > better if we discuss concrete examples rather than expressing > unspecified fears from both "sides", I'll start one below. Feel free > to add other examples (a concrete example of proposed data type > changes for example). > > When you look at > http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model, > do > you then think that the discussed changes at e.g. ENTRY and > ITEM_STRUCTURE level will reduce bloat and misunderstandings, at the > same time as it increases flexibility and understanding? Would that be > truly good for openEHR archetyping and implementation? these are key questions, but I want to see us stay on the 'implementability' mission as a key driver as well. Some of the above proposals are very nice (I really like the one I wrote ;-) > > Ian, an experienced archetype developer, has been asking for this > increased flexibility, see: > http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974. > > (I think Sam also mentioned similar thoughts on the lists earlier.) I > had guessed that those proposed changes are big and breaking enough to > go for 2.x rather than a "soft deprecation" 1.x series, what is the > opinion of those of you that have big systems running? Do they fit in > a 1.x series upgrade path? I don't think that analysis has been done yet; there are two kinds of implementation concern: * impact on existing systems and data - a concern of current vendors & data healthcare owners - i.e. concerns 'starting from where we are now' * consequences for new software - i.e. if we were starting again; this is the point of view of new vendors and adopters > > I thought anything that breaks paths would likely be considered a > "big" change. (In the example above, the transition path including > automated data conversion is pretty clear though.) It is probably > better to break these paths in an experimental 2.x series now rather > than waiting five+ years and try to squeeze it in to 1.8 or something. :-) changes that break paths in existing archetypes should be avoided where those archetypes have already been deployed. But... if we make changes that break existing archetypes that have never been deployed in clinical context, we can deal with that - that is just model conversion. Right now, we don't know how many that is. > > > HL7 [...] look what happened when they offered a major upgrade. [...] > > The big issue was the effort for vendors to transition existing systems > > I think that might be a somewhat unfair comparison: > 1. The proposed openEHR 2.0 changes I have seen so far are not > deviating from the basic design principles and design patterns in > openEHR. The basic approach does _NOT_ change the same way as HL7 did > between v2 and v3. right - we are essentially talking about incremental changes, not a change of paradigm (we already did the change of paradigm on v1 of openEHR ;-) > 2. The number of vendors using openEHR now is _a lot_ smaller than the > ones that used HL7 v2 > 3. The number of vendors we want to join the openEHR approach in the > future is _a lot bigger_ than the ones that have existing > openEHR-based production systems. both true, so there is room to move. There are however already implemented openEHR systems in some hundreds of hospitals & clinics around the world, so there is a question mainly about the data and deployed archetypes in those places. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120914/562b93d3/attachment.html>
