Subject: Re: Archetype versioning on CKM
Erik,
thanks for the pointer. I like this set of rules. It is not too different
from the current draft identification spec
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/k
nowledge_id_system.pdf , and it would be easy to upgrade
Erik,
thanks for the pointer. I like this set of rules. It is not too
different from the current draft identification spec
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf,
and it would be easy to upgrade it to reflect the SemVer rules more
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
2011/4/28 Thomas Beale thomas.beale at oceaninformatics.com:
On 27/04/2011 10:44, Diego Bosc? wrote:
I still don't see the problem
If we wait until an archetype is published to care about versions then
you will have v2 or v3 archetypes as much, which in my opinion breaks
completely
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/cfbff873/attachment.html
2011/4/28 Heather Leslie heather.leslie at oceaninformatics.com
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
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/143ac7ac/attachment.html
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
On 28/04/2011 13:15, Heather Leslie wrote:
* 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')?
Some current plans for CKM include
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/6287abf1/attachment.html
Hello,
With the latest Demographic archetypes updates on the CKM I think we
have to be careful with archetype versioning. The new archetypes seem
quite different of the ones that were uploaded some time ago. They are
different on structure but the version of the archetype has not been
improved
Hi Diego,
For those who are not aware, Diego is referring to a slew of updates to the
Demographic archetypes, most in response to Review comments to the Name and
Address archetypes.
In many cases there have been significant structural changes and if any of
these archetypes had been published, I
So do you mean that only 23 (everything that is not draft) of the
current 270 archetypes on the CKM are 'safe' to be used? Everything
else could be completely changed in the next revision of the draft :(
2011/4/27 Ian McNicoll Ian.McNicoll at oceaninformatics.com:
Hi Diego,
For those who are
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110427/cf290f9a/attachment.html
I am OK with all that, my only problem is that new iterations should
make new versions if changes are enough (even in draft status). If not
all current projects using archetypes will be just wrong with the
'official' current archetype in CKM
The situation of two incompatible archetypes with the
Hi Diego,
I will be interested in other opinions but I don't think that is really
feasible for first draft archetypes. The only 'official' archetypes in CKM
are those that are published. The remainder will definitely change, some
quite substantially, as a result of clinical review and local
Hi Stefan,
This is very helpful.
As you suggest, it is not easy to reconcile the different speeds and
requirements from all parties The next major upgrade of CKM due pretty soon
will include a much more complete implementation of Release Sets which I
think will help address this issue. In the
2011/4/27 Ian McNicoll Ian.McNicoll at oceaninformatics.com
Would calling first draft archetypes .v0 help to highlight their fragility?
In fact, that is what the specifications say. Our archetype editors should
use 0 when creating a new archetype.
(Knowledge Artefact Identification
I still don't see the problem
If we wait until an archetype is published to care about versions then
you will have v2 or v3 archetypes as much, which in my opinion breaks
completely versioning purpose. What is the problem with having a v27
archetype? Is it less pretty?
2011/4/27 Ian McNicoll
April 2011 7:15 PM
To: For openEHR clinical discussions
Cc: For openEHR technical discussions
Subject: Re: Archetype versioning on CKM
I still don't see the problem
If we wait until an archetype is published to care about versions then
you will have v2 or v3 archetypes as much, which in my
On 27/04/2011 06:28, Diego Bosc? wrote:
I am OK with all that, my only problem is that new iterations should
make new versions if changes are enough (even in draft status). If not
all current projects using archetypes will be just wrong with the
'official' current archetype in CKM
The
On 27/04/2011 10:32, Ian McNicoll wrote:
Hi David,
Thanks for this, though I think these are still draft specifications.
I had some input into that document but with experience I am not sure
the revision rules really work for .v0 archetypes though the .v0 idea
itself is useful. The
22 matches
Mail list logo
