One further addition: if you were not using CKM, you would use a normal version mechanism like Subversion, Mercurial etc, and track changes just as for a software file. The 'version id' in an archetype (perhaps badly named in hindsight) is not for tracking all changes done by authors, but for distinguishing certain kinds of change made to an archetype. It should only be incremented when a 'breaking change' is made (one that makes the archetype incompatible with existing data created with the previous version of the archetype) - effectively creating a new archetype.
- thomas beale On 22/03/2011 17:35, Sebastian Garde wrote: > Hi Annette, > > In addition to John's response, please keep in mind that not every > change to an archetype will require a new version of an archetype. > > Many changes are just compatible revisions which do not require a new > version at all. > Also as long as an archetype isn't published and in use somewhere, > there would be no point in increasing the version number even if it is > a breaking (incompatible) change. > > The Clinical Knowledge Manager would warn you if you upload an > archetype that > a) has been published and > b) where the modified archetype is incompatible to the current latest > archetype in CKM. > > In this case, CKM would suggest to > a) (possibly) deprecate the v1 archetype > b) increase the version of the revised archetype to v2 > > In the archetype revision history you can always compare two revisions > of an archetype to see the changes and the compatibility of two revisions > > To document changes to each and every revision of an archetype - > instead of frequently increasing the version number - the > revision_history of the archetype could be used (although this is > rarely done at the moment I believe) > > Regards > Sebastian* > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110322/add8291d/attachment.html>
