Hi! I came to think of this openEHR versioning discussion thread when I read about the Semantic Versioning initiative at http://semver.org/
I think the reasoning there is very appropriate also for openEHR artifacts. The problem for openEHR might be that there are so many seemingly usable archetypes in the openEHR-hosted CKM that are neither modified for a long time nor officially tagged as "published". It is understandable if it's tempting to start using them in real systems already now. After all the alternative is to reinvent the wheel locally and is that really better? Perhaps there should be a time limit on how long artifacts in the CKM can stay at a version below 1.0.0? Perhaps things would become easier if we break the link between an artifact having "published" status (as in being CRB approved) and the fact that an artifact has a version over 1.0.0. That way systems can start using archetypes past 1.0.0 knowing that non-compatible changes will have new major version numbers (irrespective of if they are published or not). Keeping approval "badges" like "ARB published", "NHS approved" or "WHO 2011 Certified" separate from technical version numbers might be a good idea anyway... (Example: the first "ARB published" version of Archetype X might be 2.4.2 and the next time it's awarded an "ARB published" badge again might be when the ARB has time to get around to looking at version 2.8.4 or 7.8.9). Likely, agencies will want to approve sets of artifacts on a regular basis like tagging a number of mutually compatible archetypes and templates as "NHS 2012-Q1 approved". The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1 < 1.0.0beta2 < 1.0.0.) might solve the "draft problem" discussed in this openEHR thread previously. (Provided that beta versions etc. don't get used/abused in live EHR systems.) The Semantic Versioning specification formalism is also machine processable in a nice way. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Thu, Apr 28, 2011 at 13:41, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 28/04/2011 02:07, Heather Leslie wrote: > > Hi everyone, > > I think you are missing some of the further complexity here. There is a > definite need for differentiation between draft and published archetypes for > which a version number alone is not enough. > Currently we are talking only about v1 archetypes and how to manage them, > and to a degree it makes sense. We certainly considered using v0.x for > drafts but it doesn't solve the downstream problems - once a v1 archetype is > published, the non-breaking revisions will become v1.1, 1.2 etc. No problem > But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but > it needs to be clear that it is v2 *draft* initially and not v2 *published* > until we have completed the neccessary collaborative reviews. > > There are two ways to look at this: > > A - 'draft' is only possible at the notional v0 or first version stage; > after initial publication, it can't be used, since the archetype is now 'in > the open' > B - it is possible to go back to 'draft' status when the major version > number is incremented on the basis that a new major version is a new > archetype, and authors need to be able to go back into 'initial development' > mode > > I can see arguments for both. What we need to decide on as a community is > what rule we want here, and to stick to it. If we can decide that, we can > document it and post it in a new draft of the identification specification. > > Diego's problem of knowing what archetype one is actually using is real and > needs to be solved. CKM does track revision numbers, but they are not part > of the version id, and you have to go into the revision history view to see > them. However the above-mentioned identification draft spec indicates a > system of referencing to do this such that an archetype whose id is > currently shown as openEHR-EHR-EVALUATION.diagnosis.v1 would be referenced > from data and / or software (i.e. in any operational context) as > openEHR-EHR-EVALUATION.diagnosis.v1.29.0, or in the future with a namespace > as well, i.e. org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29.0 > > Note that in this system of identification, if the final part of the > revision number is a '0', i.e. the '0' above in '1.29.0', it means that the > archetype is published; if it is anything else it is draft or some other > pre-release state (this corresponds with view B above). Changes in the > lifecycle state of the archetype are assumed to always cause an increment in > final number of the extended version id. > > A fuller idea of referencing archetypes from from data is described in this > spec, exemplified by the following: > > se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12,? -- some Swedish > archetype > org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29,?? -- its parent, > the CKM diagnosis archetype > org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4?????? -- the ultimate > parent, the CKM problem archetype > > here the whole specialisation lineage has been included. The reason for > doing this are a) if the archetype lineage information is not shared between > sender and receiver (maybe the receiver can't see the Swedish CKM) and b) to > enable the receiver to know what archetypes could be used for querying the > data, assuming it was not going to use the most specialised one (e.g. the > data might have been sent from Sweden to Denmark, and the Danish system > doesn't use the Swedish genetic diagnosis archetype, but does use the other > two). > > Note that the version ids above only have 2 parts, because the final part is > always '0' for published archetypes (but it could be included for better > consistency). > > Assuming this kind of system was used, then supporting it requires some > changes in CKM to a) make the full version + revision id visible. > > Note that the 'identifiers' above are just strings. Even in a future where > Oids were used for identifying artefacts, you still need to generate the > above strings, or the equivalent, from meta-data - essentially as composite > keys (in the relational sense) so that comparisons can be made between > artefacts. (Or they might also be obtainable from some Oid-keyed meta-data > repository). In other words, embedding such strings in data isn't making a > statement about how archetypes are identified, it is just one useful means > of referencing archetypes. > > Finally, to be sure that the archetype you have in your environment is > indeed what you think it is, digital signing, or at least hashing, is needed > such that published archetypes are posted with their signatures alongside > for verification by accessing systems. MD5-based hashing is already in use > in some openEHR-based products, but it has not been properly described (an > initial idea is in section 8 of the identification spec doc). > > It seems that there is enough use of archetypes now to finalise many of > these issues, and describe them in a new issue of the identification > specification. We then need to work out an implementation plan, mostly to do > with changes to CKM to support the decisions. > > There are two ways to go about this: > > interested parties review the identification spec, and provide feedback > we work out the details on the technical list + wiki via discussion and then > update the spec. > > Key things that need decisions: > > do we go with starting at v0 or v1 (I still like v0 because it implies 'you > will most likely get burnt by using this archetype in a real system, but > have fun and tell us your experience')? > can we agree on the archetype life-cycle states and the idea that a change > in state always causes an increment in minor revision number? > how should archetypes be referenced from data? > what system of hashing and signing should be used? > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
