The versioning rules have been following. This is a use case that is testing them, testing our strategy. Excellent.
What does specialisation add to this? We still have a changed MD5, new archetype ID, etc... Aargh. If we specialise, what happens when the next change comes along? Specialise the specialisation? Rinse, wash, repeat? I don't think this solves the broader issue that we need to accept and acknowledge - that archetypes WILL change as medicine changes, as our understanding changes and when we get things wrong! As a community of clinicians and implementers, we do need to develop strategies to minimise the flow on effects to implementers but ensure that we are heading towards high quality, correct archetypes. It is a tension that we need to balance. There is no doubt that publication of a v2 would have had maximal impact on all implementers. We have successfully avoided that. This v1 revision does have an impact, but I believe that we have corrected the issue while creating minimal change in the archetype. Note that most (maybe nearly all) implementers don't use Tilt; so most won't need to do anything to their local systems. Paths won't change for querying etc. The query for specific units may need to be managed, but it is manageable and negotiable. It will impact those who want to share Tilt data from different revisions of the archetype. But that was always going to be the case when anyone uses slightly different revisions of an archetype. The revision needs to be part of the info transfer and then the differences will need to be negotiated somehow. Remember that the archetype revision number and build UID are now in the latest archetype metadata downloadable from CKM to facilitate implementers having a finer level of control over the versioning. This may be the first time we discuss how to manage this kind of change in the list, but it won't be the last and there will almost certainly be more with a lot more impact. I know it will irritate some when I say that archetyping the actual clinical content that clinicians need and use in practice is often more art than science, but let me reassure you that we are 'science-ing the hell' out of the clinical knowledge governance process as much as we can. It is really complex, and the more we understand it, the more we realise how complex this area is. This is our job. Implementers need strategies to align the mismatches that will occur. Publication per se is a very coarse way to manage interoperability and will not solve our problems. The alignment needs to be done at a finer level of control. This is not a new problem. It is one we are just realising as we implement and start to share - we were always going to have to have this conversation and solve this problem. It was just a matter of when. Regards Heather From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Monday, 19 October 2015 8:46 PM To: For openEHR technical discussions <openehr-techni...@lists.openehr.org> Cc: openehr-clinical@lists.openehr.org Subject: Re: Archetype publication question - implications for implementers Hence my earlier proposal... On 19/10/2015 09:18, David Moner wrote: 2015-10-16 3:22 GMT+02:00 Heather Leslie <heather.les...@oceaninformatics.com<mailto:heather.les...@oceaninformatics.com>>: * It means that new implementers can use the corrected v1 revision and we don't have to create a v2 for a relatively trivial problem; existing vendor implementations can remain unchanged or they can choose to update the units if they please. The MD5 changes, but all paths etc are identical. A minimal disruption approach, if you like - thanks Heath. And what happens if a new implementation sends data to an old implementation? Since the archetype identifier has not changed the receiver will use its own archetype to validate the received data, and if it includes the 'deg' unit it will just fail the validation. Breaking revisions are not only about changing the archetype structure, but also about generating a different set of possible instances.
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
