Hi Thomas, See my email from October 9 regarding how this has been resolved.
There is now an updated v1 Blood Pressure archetype with addition of the correct units for Tilt added to the node and a note that the previous units are no longer to be used. It has been republished as a non-breaking revision. · It follows the versioning rules that we have firmly established for published archetypes. · 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. We can consider other changes that might require a v2 in the future, at our leisure. There is no urgency at this point as the remaining changes that have been proposed are more along the lines of updating the archetype towards 'more modern' patterns for anatomical location etc. We don't need to rush down this path as there will be little to gain, and probably quite a lot of confusion generated. If we identify other breaking issues in the future, a v2 will be considered again, including the remaining 'ideal pattern' proposals. But for now, my advice is to leave the revised v1 as is. Through this discussion we have identified is another strategy for governance and change management, that I hadn't considered before. A good outcome from my POV. Have I missed anything? Thanks again for all of your contributions. Regards Heather From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 15 October 2015 11:05 PM To: openehr-clinical@lists.openehr.org; Openehr-Technical <openehr-techni...@lists.openehr.org> Subject: Re: Archetype publication question - implications for implementers I've skimmed the replies on this thread, and I'm inclined to think everyone could be right. Problem is, they can't all be right at the same time. So.... considering the issue from a global deployment perspective I had the folllowing idea: * in the archetype library, we should stick to proper versioning rules, as Diego, David and Sebastian have said, and correct the error and issue a new v2 archetype * => this way there are no surprises in the archetype library for software, or people, by the time we have forgotten about this issue * => the paths would stay the same to the various data fields, but the units in the tilt table field would be different, and will break anything that specifically relies on that * but we still may need a way of making adding the correction to the v1 version of the BP archetype, for some users, to enable their current queries and software based on the 'v1' id to keep working. This could be achieved by: * creating a specialisation of the v1 archetype that adds a new node as Sebastian proposed, or via Heath's proposal * => this means that the deployment has to use a new archetype id for data production (i.e. in the CDR), but AQL queries using the old id should continue to work, assuming the query processor correctly finds child archetypes for a given archetype id * OR enable a modification in the template that has the effect of adding the required unit or element * => this means that all ids stay the same in data production and querying, but the CDR is being told a white lie, in that what it thinks is the BP archetype is not exactly what it is back in the CKM library I haven't tried to analyse the details here that far, but the general idea is to: * a) ensure the archetype library follows the versioning and change rules properly * b) inject an adjusting fix either as a specialisation, or further along in the processing chain - in a template (or even OPT....) thoughts? - thomas
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
