2015-10-08 1:23 GMT+02:00 Heather Leslie < heather.les...@oceaninformatics.com>:
> It was Sebastian’s suggestion about governing at an intra-archetype level > that has caught my attention - marking an existing data element as > outdated, and adding a new one as a revision solves the issue of having > correct vs incorrect units and avoids the necessity of a new version > immediately. I suggest we make this modification to the existing v1 and > republish as stable (and technically correct). But that will not be v1 anymore... At this point, anyone who has worked for a time with the archetypes of CKM knows that the readable archetype ID, including the version number, it is not a reliable reference to identify the archetypes (this is said somewhere in the specifications, but should be more clearly stated for newcomers). The only reliable identifier from a technical point of view is the MD5 hash of the definition part of the archetype. Any change to the structure will create a different MD5. Any (correctly implemented) system that uses it will find that it is a new archetype, call it v1, v1+internal revision, v2 or whatever. As Diego said, the less complicated solution is to just follow the versioning rules that already exist. David -- David Moner Cano Grupo de Informática Biomédica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Politécnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta Valencia – 46022 (España)
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
