Hi everyone Thanks for the suggestions and active discussion.
My main issue was with how to proceed with potentially breaking changes to correct technical artefacts and seeking strategies to manage the tension between pure modelling and implementation. Your suggestions have been helpful. We have developed some strong rules about governance from identification of changes/mods that require either new versions, minor revisions and patches. These rules seem to be quite solid and have withstood this discussion. However through the discussion we have identified some ways to include these changes in a non-breaking way, and that has been very welcome. As a result I have just uploaded an updated version that includes all the proposed non-breaking changes. According to our governance rules, it is classified as a minor revision to our existing v1 and it has been republished. See http://www.openehr.org/ckm/#showArchetype_1013.1.130 We can now consider at leisure whether we want to proceed with the breaking changes, although to a large degree these are not of semantic value and I'm inclined now to note them but not proceed with a proposed v2 at this point. We can do so at any time in the future, if we want. Kind regards Heather From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Heath Frankel Sent: Thursday, 8 October 2015 10:28 PM To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org> Cc: For openEHR technical discussions <openehr-techni...@lists.openehr.org>; For openEHR implementation discussions <openehr-implement...@lists.openehr.org>; For openEHR clinical discussions <openehr-clinical@lists.openehr.org> Subject: Re: Archetype publication question - implications for implementers Thanks Ian for explaining the actual proposal. I can't see why you can't add the dv_text to the location of measurement (opening the constraint). Then it just becomes an implementation choice to exclude the specific location inline with the new preferred model. Regards Heath On 8 Oct 2015, at 8:26 pm, "Ian McNicoll" <i...@freshehr.com<mailto:i...@freshehr.com>> wrote: Hi Heath, I think the suggested change was from CLUSTER[at1033] occurrences matches {0..1} matches { -- Location items cardinality matches {1..*; unordered} matches { ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of measurement value matches { DV_CODED_TEXT matches { defining_code matches { [local:: at0025, -- Right arm at0026, -- Left arm at0027, -- Right thigh ..... } } } } ELEMENT[at1034] occurrences matches {0..1} matches { -- Specific location value matches { DV_TEXT matches {*} } } } } to ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of measurement value matches { DV_CODED_TEXT matches { defining_code matches { [local:: at0025, -- Right arm at0026, -- Left arm at0027, -- Right thigh ..... } } DV_TEXT matches {*} -- Specific location } which is how we would model it now. As a side-note, ADL2.0 introduces the capacity to formally deprecate an existing node, which will be very helpful in these sort of situations. I also favour adding the 'deg' unit to the existing Tilt quantity, as I think Sebastian suggested, as an alternative (and not making the change above). That would allow us to add the critical changes in a non-breaking manner. Thanks to everyone who has contibuted so far - we still need other implementer views!! Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 8 October 2015 at 10:23, Heath Frankel <heath.fran...@oceaninformatics.com<mailto:heath.fran...@oceaninformatics.com>> wrote: 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-techni...@lists.openehr.org<mailto:openehr-techni...@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
