Re: poor version management in archetype editor
Thanks Thomas, for taking action on this I come back to this later, too busy, right now. Bert Thomas Beale schreef: > Bert Verhees wrote: >> A part of version-management is version-numbering. >> >> One should be able to distinguish major versions and minor updates. >> >> A major version would, for example, be another concept to achieve the >> same medical purpose, for example (not real life) add some more ways >> to take bloodpressure, f.e. a new tool/way to do this. >> Minor versions would be, for example, removal of small-errors typo's >> etc. >> For the minor versions I would recommend to use an extern version >> tool like SVN >> For the major-versions, I would like to propose new features to >> archetype-editors, and a change of the version-part of the >> ArchetypeID. >> But a change of a path-ID, even if it is repairing a typo, would be a >> major-version, because it possibly effects the retrieval of data in >> the OpenEhr-system (by AQL). >> > The current proposal is as follows (will be available in a document > soon for comment):* > * > > * personally I believe that the current archetype id, e.g. > openEHR-EHR-OBSERVATION.bp_measurement.v1 can be considered an > 'ontological' id, because it locates the concept of the > archetype in a concept space. Different 'versions' are by > definition (in openEHR) incompatible - although normally very > close. I.e. openEHR-EHR-OBSERVATION.bp_measurement.v2 would be a > close relative of openEHR-EHR-OBSERVATION.bp_measurement.v1 but > with some incompatibility, meaning that the two archetypes could > not be used directly on data created by the other. Note: > o current tools don't respect this properly, and these > archetype version ids have wrongly been used to represent > revisions of any kind. This is a shortcoming in the tools, > and new versions of the tools will correct this. > o not everyone agrees with this notion of the 'ontological > id'. Some alternatives: > + that only the part before the final .vN is the > 'ontological id'. (My problem with this is that > openEHR-EHR-OBSERVATION.bp_measurement.v1 and > openEHR-EHR-OBSERVATION.bp_measurement.v2 are > slightly different concepts and can't be used with > the same data - the ontological space here in my > view is defined by the data structures that conform > to each point in the space.) > + another point of view says that we should include > the 'publisher' id, because two publishers can > create competing ideas of 'blood pressure > measurement', so we should allow something like > uk.nhs::openEHR-EHR-OBSERVATION.bp_measurement.v1 > and > ca.chi::openEHR-EHR-OBSERVATION.bp_measurement.v1. I > disagree with this because I think that the concept > space should be regulated - which means that names > should not be assigned twice. This implies a global > archetype id management system. But we are already > doing this with Snomed codes - there aren't > competing copies of Snomed in existence - why not do > the same with archetypes? > * After the major version (.vN), there is a concept of 'revision'. > In openEHR this has currently been defined to be: > o any change that does not render the later revisions of the > archetype incapable of processing data create by the > earlier ones. This makes sense - there will be a lot of > data around from earlier revisions. We are close to a > formal definition of what changes are possible for a new > revision. Essentially, the rule is that later revisions > can have wider constraints, e.g. change an optionality of > 1..1 to 0..1, which means that the later archetype (the > 0..1 revision) can handle data from the earlier one (the > 1..1 - mandatory one) . The same logic applies for other > constraints including value ranges. > o revisions can't harm the integrity of queries against > data; so as Bert says they can't change archetype paths, > but it doesn't mean they can't add new ones. > * At the finest level, there is a 'build' number, which is any > change at all within a given revision. The proposal is that > 'builds' are only internal to the archetype authoring space e.g. > the Clinical Knowledge Manager > (http://www.openEHR.org/knowledge) or a similar tool. Published > archetypes always have build number = 0. > * Separately from this, we have the idea of 'specialisation' in > archetypes, which creates distinct identifiers, but here, unlike > revisions, the allowed changes are narrower, because the idea is > that a more general archetype (i.e. a parent) should work with > data created by the child. We currently have a completely formal > definition of this relationship (see ADL /AOM 1.5 drafts on the > wiki). > o however there remains the question of what the proper way > for a specialised archetype to refer to a parent is -i.e. > with or without revision, publisher and so on. In other > words, how do we reliably know exactly which archetype is > being identified as the parent. My personal feeling is > that here as well we need a controlled universal semantic > space - i.e. only one idea of 'bp_measurement', not a > segregated space based on separate publishers - with the > latter situation, we don't know what any archetype really > does, since no-one would be forced to name their > archetypes properly. > > Apart from this, account has to be taken of different publishers and > authors, different language translations, and how to version manage > the artefacts, as well as manage releases. We also need a general > model of archetypes from the point of authoring, via 'publishers' to > use in real systems, in what I would call the 'operational working > set' of archetypes and templates within a live system. > > I am in the process of editing such a proposal - it already has ideas > from quite a few people, and as soon as it is readable, I will post it > for wider review. Getting this right will require some thinking from > all of the community. > > - thomas beale > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical