The existing versioning rules allow adding new concepts and opening constraints such as allowing additional units. These change the md5 hash but does require a version /id change.
This is why Sebastian's suggestion technically works, the existing obsolete concept still exists and the new concepts can be added for those that want to move to the preferred approach. However, I am concerned about adding new concepts that are in fact the same as an existing just represented differently. This is why I suggested to add new units to the existing tilt element (opening the constraint) rather adding a new concept for tilt with the new units. I also suggested adding the new representation for body site as a new concept but starting to think this is a bad idea since we are duplicating the concept and have two ways in the same archetype to represent the same concept and worse the concept has two identifiers. Having said that I suspect the alternative representation is filling a slot with a cluster archetype in a template and hence there is no duplicate concepts in the same archetype, there is a new slot and the alternate representation is in a template instead. Is this any better? Perhaps marginally. Regards Heath On 8 Oct 2015, at 6:42 pm, "David Moner" <dam...@gmail.com<mailto:dam...@gmail.com>> wrote: 2015-10-08 1:23 GMT+02:00 Heather Leslie <heather.les...@oceaninformatics.com<mailto: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-implementers mailing list openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
