# Handling Archetype Versions **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2008-06-16 17:32 UTC **Views:** 5 **Replies:** 4 **URL:** https://discourse.openehr.org/t/handling-archetype-versions/14760 --- ## Post #1 by @Tim_Cook2 Hi All, I do not recall who said it or even which openEHR mailing list it appeared on but I would like to get feedback from implementers\. I recently read a comment that seemed to me to be counter to a core philosophy of openEHR\. The comment was regarding how to handle different versions of an archetype and it basically posited that there should be some automated intervention that would migrate data from one archetype version to another\. In my mind, this is a TOTALLY wrong approach\. While it is common practice in the general world of IT we all know that healthcare is different\. Even if there was a mistake in the archetype or the information technology has changed\. Isn't it more important to maintain the integrity of how, where and when the information was recorded? IANAL but it seems that from at least a medico\-legal standpoint, manipulating information, in ANY way, after the fact could have serious consequences and compromise the integrity of the information system\. Your Thoughts? \-\-Tim --- ## Post #2 by @Andrew_Patterson > I do not recall who said it or even which openEHR mailing list it > appeared on but I would like to get feedback from implementers\. > different versions of an archetype and it basically posited that there > should be some automated intervention that would migrate data from one > archetype version to another\. Tim, it was me I think \- I mentioned it on one of the wiki pages I setup\. Mea culpa\! I brought it up in relation to the migration of reference models, not actual archetypes \- but it was just an idle thought, not a firm opinion\. I was making the point that it might be nice if 'minor' changes to reference model schemas could be handled in a way that meant that the data could be upgraded to the new reference model\. This would depend on the canonical form etc or else as you point out, the digital signatures etc would be invalid\. I only mentioned it because if we are envisaging a lifelong record for a person \- and my children\* are writing openEHR 13\.x systems in 50 years time, do we really want to be inflicting upon them the need to still be dealing with reference model 1\.0\.1, 1\.0\.2, 1\.0\.3a etc \(where the only significant difference is a field that was renamed, or an extra field was added?\)\. I am firmly in agreement with you that modifications to existing data is a general no\-no, and would only be done if it was possible to do in a way that kept all the medico\-legal niceties in tact\. But I think the maintenence of future openEHR systems is also a valid 'use' case\. Andrew \* children mentioned in this email are currently fictional --- ## Post #3 by @thomas.beale What we have always said is that with a new version there should be an algorithm published that will transform data from the previous version to the new version\. This algorithm could be used to migrate data \(a once\-off operation\) or it could be used on the fly every time a query operation was executed\. The main requirement is that data from previous versions respond to queries in as correct a way as possible \- that means where queries are dependent on some new feature of a new version of an archetype, e\.g\. a changed field meaning, then the old data can be made to respond properly\. I am not religous at all about transforming data, quite the reverse\. I think we will have to see how openEHR queries pan out, and how many really have dependencies on things changed for reasons of versioning\. \- thomas Tim Cook wrote: --- ## Post #4 by @Greg_Caulton > to respond properly\. I am not religous at all about transforming data, > quite the reverse\. I think we will have to see how openEHR queries pan > out, and how many really have dependencies on things changed for reasons > of versioning\. > > \- thomas > This is an idle thought but it seems to me that if the queries adhere to the structure of the archetype that is less appealing than using an identifier for the data element e\.g\. select \.\.\.\.\.blah blah\.\.\.\.          where obs/data\[at0001\]/events\[at0006\]/data\[at0003\]/item\[at0004\]/value/value > = 140 is nasty to type \(or copy/paste\) and while I understand the purpose of AQL was to be computer generated based upon archetypes, I thought a reason for SQL and XML success was its simplicity and the ability to read and write simple examples \(despite computer generated versions being possible and superior\)\. If an identifier was assigned to that blood pressure surely that would be nicer\.\.\.? e\.g\. select\.\.\.\.\.\. blah blah\.\.\.\.\.        where obs\.bpsystolic >= 140 or even select\.\.\.\.\.\. blah blah\.\.\.\.\.              where obs\.bpsystolic1634 >= 140 With unique identifiers not tied to the structure of the document perhaps revision versions of the archetypes become less important\.\.\. or perhaps not\.\.\. Anyway, I am no expert on such things so as I said it is an idle thought\. Greg --- ## Post #5 by @thomas.beale Greg, The first thing I would say is: beware the attraction of hand\-built or directly readable computer formalisms\. For many examples, including most of SQL, XML, and many other languages, only trivial examples can be built by hand without error, except by computer experts\. So we always build tools to author or look at such things\. Clincally trivial queries can easily be technically complex\. However, we have thought about this identification idea before\. It would necessitate either external terminology support, e\.g\. if new Snomed codes could be created for every path, or else it requires the identifiers to be defined with the archetypes, using more internal codes, where each such code is equated to a long path\. Both approaches preserve linguistic independence, but it is not obvious at this stage whether the former is possible or desrable, or the latter is worth the effort\. The latter is certainly doable, but more analysis is needed\. \- thomas beale Greg Caulton wrote: --- **Canonical:** https://discourse.openehr.org/t/handling-archetype-versions/14760 **Original content:** https://discourse.openehr.org/t/handling-archetype-versions/14760