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:
- 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.
- 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:
- 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.
- 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).
- 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
|