Hmmm, seems to me that you are introducing a new term AND omitting a
term that is in use. While not clarifying the previous terms which Tom
did quite well.
I believe that Tom very well defined a version change as a change that
substantially modified a previous version in such a manner as to render
it incompatible with previous versions.
A Revision (which you omitted) is a change that may further constrain or
otherwise modify an archetype but does not render the expressed
information unusable.
This is also the same information that can be found in the relevant
documents. But I see no reference to 'Package' as far as archetypes are
concerned.
Package implies a grouping of some type. An archetype is (AFAIK)
considered to be the expression of a single clinical concept.
I 'm afraid I agree with Tim on this one. The difference between
'breaking' Version changes and non-breaking Revisions is clearly
documented in the specification. The reason for confusion and non-use
within the NHS is simply that the current tools do not support
Revisions. Now that the Template Model has been produced, I would hope
that we can properly support Revisions in both Archetype Editor and
Template Designer.
I appreciate that at first, Version / Revision is confusing because of
the similarity in English, but I think it is too late now to change
these terms, which at least have clear technical definitions. I was
interested to see Thomas's comment that a future version of the parser
will offer guidance on whether an altered archetype needs to be
re-versioned.
BTW What would be the equivalents in Dutch for Revision and Version?
[openEHR-EHR-COMPOSITION.encounter.v1*] (or perhaps more correctly
[openEHR-EHR-COMPOSITION.encounter.v1.*], where the dot means any
character
not the version delimiter) and [openEHR-EHR-COMPOSITION.encounter.v\d+]
are
different. The first allows all revisions of .v1 (e.g. v1.1, v1.2, ..)
Close, but not quite!
[openEHR-EHR-COMPOSITION.encounter.v1.*] allows all revisions of .v1, .v10,
.v11, ... .v100, .v101, etc.
To allow all revisions of .v1, we would need this:
[openEHR-EHR-COMPOSITION.encounter.v1\..*]
But what about .v1draft? This regex wouldn't catch it. Does this matter? Or
is that old "draft" convention going to be phased out?
The v1draft convention is already deprecated. The BNF for AQL doesn't
support it deliberately, to ensure only non-draft archetypes are used when
committing/retrieving data.
Heath
From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Peter Gummer
Sent: Thursday, 5 June 2008 11:14 AM
To: For openEHR technical discussions
Subject: Re: openEHR Querying specifications
Heath Frankel wrote:
> [openEHR-EHR-COMPOSITION.encounter.v1*] (or perhaps more correctly
> [openEHR-EHR-COMPOSITION.encounter.v1.*], where the dot means any
> character
> not the version delimiter) and [openEHR-EHR-COMPOSITION.encounter.v\d+]
> are
> different. The first allows all revisions of .v1 (e.g. v1.1, v1.2, ..)
Close, but not quite!
[openEHR-EHR-COMPOSITION.encounter.v1.*] allows all revisions of .v1,
.v10,
.v11, ... .v100, .v101, etc.
To allow all revisions of .v1, we would need this:
[openEHR-EHR-COMPOSITION.encounter.v1\..*]
But what about .v1draft? This regex wouldn't catch it. Does this matter?
If for example the change between the first and second version is a change
in a position value set from “sitting”, “standing” and “other” to “sitting”,
“standing”, “lying” and “other”. If then a query is written for the first
version of the archetype searching for all cases where the position is “not
sitting” and “not standing” the query will search for the position “other”
and return a correct answer.
If we implement Rong’s suggestion the query will work also with the second
version of the archetype, but it will return another answer than the
intended, namely the cases where the position is “not sitting” and “not
standing” and “not lying” instead of the intended “not sitting” and “not
standing”.
Micke, what if you keep the original search criteria “not sitting” and “not
standing” instead of searching “others”, will you get expected result with
both versions?
Yes, that works, and that is the proper way to do it. My example was an example of how people quite often do without realizing the consequences. They think that if something works in a specific version it will work in the subsequent versions. I think I have seen these kinds of problems too often in other areas in medical informatics (like the not elsewhere classified-problem in ICD) and I therefore think that people will do things without realizing the consequences also when they query archetypes.