# Archetype publication question - implications for implementers **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2015-10-02 03:55 UTC **Views:** 2 **Replies:** 53 **URL:** https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799 --- ## Post #1 by @heather.leslie Hi everyone, I’m seeking some community input around a conundrum that has arisen regarding archetype governance, or more specifically if we should offer a new version of an archetype that included breaking changes/corrections according to the openEHR specifications but which are not critical in terms of clinical safety – a bit of a grey zone, if you like. If clinical safety were implicated, the decision would be easy. The Blood Pressure archetype was published in 2009 and I believe is in fairly wide use in systems at this point. Currently published version [here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.130), and which has had only ‘trivial’, non-breaking changes, including addition of translations, etc since publication. Recently the Norwegian community translated the archetype and then undertook a local review of the archetype. They have suggested some modifications to the archetype which include updating some of the data elements around identifying the body location of the BP measurement to be in keeping with more recent archetype patterns that we have been using, plus identified that the representation of degrees of Tilt was not using the UCUM units, plus a few minor additions. The result is that their new candidate archetype ([here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.2189)) which includes these changes is regarded as a Major revision under our current CKM versioning rules and if republished warrants becoming a version 2. That is all perfectly OK from an academic governance point of view. There is no doubt that the archetype is a more accurate and enhanced iteration but the practical implications of republishing as a v2 are not trivial to implementers. So I seek your advice on whether we should proceed with further content review with the intent of re-publishing as a new v2 archetype: · **Pros** o Archetype data is updated to include correct UCUM units o Archetype data is updated to include more ‘modern’ modelling patterns that are being used increasingly in more recent archetypes o New implementers will be able to use the most up-to-date version of the archetype, rather than using an archetype that has been identified as having flaws. Otherwise new implementers will continue to implement a known, flawed archetype into their new systems · **Cons** o Existing implementers will need to decide whether it is worthwhile to update to v2. The alternative is to stay with the v1 published archetype as is and consider updating at some future time. o The update of the UCUM unit and body location pattern does not have major safety implications or significantly impact the modelling quality, yet will have internal implications in existing clinical systems. o Two versions of the archetype will be in circulation, and implementers will need to manage the interoperability issues that will arise. o Norway will likely use the new archetype as their national standard, diverging from the openEHR CKM content, which is not desired by either party. A portion of the diff is attached, which demonstrates the major breaking changes. There are many other changes that only refer to translations and are non-breaking in the rest of the diff This is the first time we have had to update a published archetype and it certainly won’t be the last. If there were breaking changes that needed to be made for clinical safety reasons or similar critical reasons I would have no hesitation in proceeding to v2. If there were non-breaking changes we would manage the progression with additional minor revisions or patches – not a problem. This one has breaking changes but no clinical safety issues, so a bit of a grey zone because of the possible implementation implications. I have no doubt that many implementers are already grappling with these issues if they have implemented draft archetypes, so perhaps you all have established systems and approaches for this. I have had some advice suggesting we should leave the archetype as is, rather than ‘rock the implementation boat’ for little semantic value, yet I’m not sure that it is our role to be paternalistic. My own inclinations are that we should govern the archetypes from a pure point of view, updating and creating new versions if we have to, and allowing CKM to provide the transparency that will support implementers to make informed choices. So: Option 1: Do nothing. The current flawed archetype will be the only one available on the openEHR CKM Option 2: Promote the new candidate archetype to the public trunk as a potential new iteration – so available for viewing and download, but with no official status, effectively in limbo until a further review round is carried out and it is republished. Option 3: Promote the new candidate archetype to the public trunk, run formal content reviews on it and plan to re-publish as v2 Please, your thoughts? Regards Heather **Dr Heather Leslie** MBBS FRACGP FACHI **Consulting Lead**, [Ocean Informatics](http://www.oceaninformatics.com/) **Clinical Programme Lead,** [openEHR Foundation](http://www.openehr.org/) p: +61 418 966 670 skype: heatherleslie twitter: @omowizard [details="(attachments)"] ![2015 10 BP major diff.jpg|850x989](upload://A6u3xGT6q0jMY88U6qurVhwD93.jpeg) [/details] --- ## Post #2 by @heather.leslie Hi everyone, I’m seeking community input around a conundrum that has arisen regarding archetype governance or, more specifically, if we should offer a new version of an archetype that included breaking changes/corrections according to the openEHR specifications but which are not critical in terms of clinical safety – a bit of a grey zone, if you like. If clinical safety were implicated, the decision would be easy. The Blood Pressure archetype was published in 2009 and I believe is in fairly wide use in systems at this point. Currently published version [here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.130), and which has had only ‘trivial’, non-breaking changes, including addition of translations, etc since publication. Recently the Norwegian community translated the archetype and then undertook a local review of the archetype. They have suggested some modifications to the archetype which include updating some of the data elements around identifying the body location of the BP measurement to be in keeping with more recent archetype patterns that we have been using, plus identified that the representation of degrees of Tilt was not using the UCUM units, plus a few minor additions. The result is that their new candidate archetype ([here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.2189)) which includes these changes is regarded as a Major revision under our current CKM versioning rules and if republished warrants becoming a version 2. That is all perfectly OK from an academic governance point of view. There is no doubt that the archetype is a more accurate and enhanced iteration but the practical implications of republishing as a v2 are not trivial to implementers. So I seek your advice on whether we should proceed with further content review with the intent of re-publishing as a new v2 archetype: · **Pros** o Archetype data is updated to include correct UCUM units o Archetype data is updated to include more ‘modern’ modelling patterns that are being used increasingly in more recent archetypes o New implementers will be able to use the most up-to-date version of the archetype, rather than using an archetype that has been identified as having flaws. Otherwise new implementers will continue to implement a known, flawed archetype into their new systems o Further content review will expose the archetype to a broader range of clinicians and their input will potentially further enhance, or at least endorse the current, quality. · **Cons** o Further content review will possibly introduce further changes – maybe breaking, maybe not. o Existing implementers will need to decide whether it is worthwhile to update to v2. The alternative is to stay with the v1 published archetype as is and consider updating at some future time. o The update of the UCUM unit and body location pattern does not have major safety implications or significantly impact the modelling quality, yet will have internal implications in existing clinical systems. o Two versions of the archetype will be in circulation, and implementers will need to manage the interoperability issues that will arise. o Norway will likely use the new archetype as their national standard, diverging from the openEHR CKM content, which is not desired by either party. A portion of the diff is attached, which demonstrates the major breaking changes. There are many other changes that only refer to translations and are non-breaking in the rest of the diff Major changes are: · Changing ‘Tilt’ units – ‘°’ to ‘deg’ – at1005 – this is the critical and breaking correction that has triggered considering these additional changes: o Making Measurement Location a choice of coded text and text – at0014 o Removal the redundant ‘Location’ cluster heading This is the first time we have had to update a published archetype and it certainly won’t be the last. If there were breaking changes that needed to be made for clinical safety reasons or similar critical reasons I would have no hesitation in proceeding to v2. If there were non-breaking changes we would manage the progression with additional minor revisions or patches – not a problem. This one has breaking changes but no clinical safety issues, so a bit of a grey zone because of the possible implementation implications. I have no doubt that many implementers are already grappling with these issues if they have implemented draft archetypes, so perhaps you all have established systems and approaches for this. I have had some advice suggesting we should leave the archetype as is, rather than ‘rock the implementation boat’ for little semantic value, yet I’m not sure that it is our role to be paternalistic. My own inclinations are that we should govern the archetypes from a pure point of view, updating and creating new versions if we have to, and allowing CKM to provide the transparency that will support implementers to make informed choices. So: **Option 1**: Do nothing. The current flawed archetype will be the only one available on the openEHR CKM **Option 2**: Promote the new candidate archetype to the public trunk as a potential new iteration – so available for viewing and download, but with no official status, effectively in limbo until a further review round is carried out and it is republished. **Option 3**: Promote the new candidate archetype to the public trunk, run formal content reviews on it and plan to re-publish as v2 Please, your thoughts? Regards Heather **Dr Heather Leslie** MBBS FRACGP FACHI **Consulting Lead**, [Ocean Informatics](http://www.oceaninformatics.com/) **Clinical Programme Lead,** [openEHR Foundation](http://www.openehr.org/) p: +61 418 966 670 skype: heatherleslie twitter: @omowizard --- ## Post #3 by @system Hi Heather, Instead of removing the incorrect UCUM unit and the old modelling patterns completely, would it be possible to mark these bits as 'deprecated' in some [informal] way in the ontology? This way you could make the desired changes and republish as a minor revision of version 1. For a version 2 archetype, the bits marked as deprecated would be removed (this v2 archetype could be provided as a draft now or later). Cheers Sebastian P.S.: Arguably, a more formal way of deprecating bits and pieces in an archetype, will become quite useful in the future. --- ## Post #4 by @yampeku Personally I don't see the reason to not just update the version. If the archetype contains breaking changes it is a v2. I would enforce this even for drafts, as I have stated before. I have also seen lately changes in archetype ids. I would expect that the old archetype with the old id was kept with a deprecated lifecycle status. Regards Hi everyone, I’m seeking some community input around a conundrum that has arisen regarding archetype governance, or more specifically if we should offer a new version of an archetype that included breaking changes/corrections according to the openEHR specifications but which are not critical in terms of clinical safety – a bit of a grey zone, if you like. If clinical safety were implicated, the decision would be easy. The Blood Pressure archetype was published in 2009 and I believe is in fairly wide use in systems at this point. Currently published version [here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.130), and which has had only ‘trivial’, non-breaking changes, including addition of translations, etc since publication. Recently the Norwegian community translated the archetype and then undertook a local review of the archetype. They have suggested some modifications to the archetype which include updating some of the data elements around identifying the body location of the BP measurement to be in keeping with more recent archetype patterns that we have been using, plus identified that the representation of degrees of Tilt was not using the UCUM units, plus a few minor additions. The result is that their new candidate archetype ([here](http://ckm.openehr.org/ckm/#showArchetype_1013.1.2189)) which includes these changes is regarded as a Major revision under our current CKM versioning rules and if republished warrants becoming a version 2. That is all perfectly OK from an academic governance point of view. There is no doubt that the archetype is a more accurate and enhanced iteration but the practical implications of republishing as a v2 are not trivial to implementers. So I seek your advice on whether we should proceed with further content review with the intent of re-publishing as a new v2 archetype: · **Pros** o Archetype data is updated to include correct UCUM units o Archetype data is updated to include more ‘modern’ modelling patterns that are being used increasingly in more recent archetypes o New implementers will be able to use the most up-to-date version of the archetype, rather than using an archetype that has been identified as having flaws. Otherwise new implementers will continue to implement a known, flawed archetype into their new systems · **Cons** o Existing implementers will need to decide whether it is worthwhile to update to v2. The alternative is to stay with the v1 published archetype as is and consider updating at some future time. o The update of the UCUM unit and body location pattern does not have major safety implications or significantly impact the modelling quality, yet will have internal implications in existing clinical systems. o Two versions of the archetype will be in circulation, and implementers will need to manage the interoperability issues that will arise. o Norway will likely use the new archetype as their national standard, diverging from the openEHR CKM content, which is not desired by either party. A portion of the diff is attached, which demonstrates the major breaking changes. There are many other changes that only refer to translations and are non-breaking in the rest of the diff This is the first time we have had to update a published archetype and it certainly won’t be the last. If there were breaking changes that needed to be made for clinical safety reasons or similar critical reasons I would have no hesitation in proceeding to v2. If there were non-breaking changes we would manage the progression with additional minor revisions or patches – not a problem. This one has breaking changes but no clinical safety issues, so a bit of a grey zone because of the possible implementation implications. I have no doubt that many implementers are already grappling with these issues if they have implemented draft archetypes, so perhaps you all have established systems and approaches for this. I have had some advice suggesting we should leave the archetype as is, rather than ‘rock the implementation boat’ for little semantic value, yet I’m not sure that it is our role to be paternalistic. My own inclinations are that we should govern the archetypes from a pure point of view, updating and creating new versions if we have to, and allowing CKM to provide the transparency that will support implementers to make informed choices. So: Option 1: Do nothing. The current flawed archetype will be the only one available on the openEHR CKM Option 2: Promote the new candidate archetype to the public trunk as a potential new iteration – so available for viewing and download, but with no official status, effectively in limbo until a further review round is carried out and it is republished. Option 3: Promote the new candidate archetype to the public trunk, run formal content reviews on it and plan to re-publish as v2 Please, your thoughts? Regards Heather **Dr Heather Leslie** MBBS FRACGP FACHI **Consulting Lead**, [Ocean Informatics](http://www.oceaninformatics.com/) **Clinical Programme Lead,** [openEHR Foundation](http://www.openehr.org/) p: +61 418 966 670 skype: heatherleslie twitter: @omowizard --- ## Post #5 by @yampeku Would they be alternatives of the data type or just new elements at the same level? I see problems with both: if you create an alternative on data types probably you won't be able to add bindings to it, and if made a another element then you don't have an easy way of telling what corrects (you could even have corrections of corrections of corrections... Which one would you link to?). Probably even assertions should be included in order to avoid the inclusion of the deprecated and the corrected one in the same instance. IMHO is much easier to just upgrade the version --- ## Post #6 by @system Hello, If the archetype introduces incompatible changes with the existing version, then no discussion it is possible: a new v2 has to be published after the proper review rounds. Then the question is what happens to v1. Being purist, v1 should be marked as obsolete (still usable at your own risk) and v2 be the recommended one for new implementations. It is the simpler and safest way to act in order to maintain a controlled repository of archetypes. If implementers have adopted an archetype methodology, they they have to accept that changes to archetypes will happen. It is also true that many software projects maintain several branches of development simultaneously (i.e Tomcat 6, 7 and 8). Is this also applicable to archetypes? Can we maintain v1 and v2 both as published archetypes? Certainly we agree on defining such rules of governance. But we should ask ourselves some questions: Are both versions just alternative representations of the same clinical model? Should the community prioritize one over the other? Or maybe they are representing different models that should be named differently to avoid confusions? Or maybe v1 can become just a kind of template of v2? The answer to these questions will depend on each use case, but the important thing is that we act consistently in all cases. David --- ## Post #7 by @system My opinion is that when a new archetype-version is incompatible with the previous, it should not have the same name. In case of compatibility it is save to use wildcards for versions in slots, in case of incompatibility, this can cause problems in queries Bert --- ## Post #8 by @thomas.beale we can - that's the reason for having the major version included the 'interface id' of the archetype - all vN of the same root archetype can co-exist. - thomas --- ## Post #9 by @system Hi Heather, I would go for option 3: ' Option 3: Promote the new candidate archetype to the public trunk, run formal content reviews on it and plan to re-publish as v2' This way 'old' implementations can keep referencing V1 and new implementations can start using V2 or stick to V1 depending on their needs. I think that even the evolution of both versions should be a possibility in the future (although avoided if not completely necessary). Regards, Luis --- ## Post #10 by @system I was specifically pointing to the relationship between version numbers and lifecycle state\. Of course we can have several versions published at the same time\. And nowhere in the Archetype Identification specification \( http://openehr.org/releases/AM/latest/docs/Identification/Identification.html) implies that a new published version automatically makes a previous version obsolete\. The question was if that kind of rule should exist or if users will naturally tend to adopt always the newest version if there are several available\. In my opinion that should not be a fixed rule \(in some cases both versions could coexist as published\), but the community should try to avoid that situation and always push for the latest version\. --- ## Post #11 by @system From a governance point of view, I believe it is clear that the v2 route is the cleanest option here. And in a general way I also agree with your concerns, Diego! I think that my suggestion of deprecating old and adding the new elements, can only make sense if we can model the new elements in a v1 archetype in a way that the data paths don't need to change when later migrating to a forthcoming v2 archetype. From an implementers point of view I am not so sure I'd be so happy if I need to take the archetype to the next major version just because of this. Therefore, I also agree with Heather and share the concerns that creating a v2 in this case is a bit over the top. Not sure if anybody is even using Tilt or the location from this archetype's protocol in the first place? If you are able to add the new things (or at least the unit change) to the v1 archetype and start the work on publishing a "clean" v2 archetype at the same time, this would allow implementers to upgrade in their own time, while being able to enable the use of correct units and 'modern' modelling patterns in the existing v1 archetype. I think it is reasonable to add another unit to an archetype without having to up its major version (and provide some guidance that this is the 'better' unit to use). Changing the modelling pattern for the location and adding this a complete alternative may be asking to much from a minor revision of an archetype. Maybe this is also a good exercise for anybody using this archetype on how best to upgrade from one major version to the next...but my preference I think is to, yes start with a v2 archetype, but also add the correct unit to the v1 archetype and republish as a minor revision. Sebastian --- ## Post #12 by @system Hi all, This is IMO, a very important issue for the openEHR community and many thanks to Heather for providing such a clear exposition of the issues and choices, faced by any community building products and tools based on open-source distribution and governance principles. As such, I do not think these challenges are unique to openEHR. It is particularly important for vendors and implementers, who as well as trying build great systems are also building an ecosystem, one of whose strengths and sales-points is the ability to use 'shared components' out-of-the-box. openEHR is well -engineered to support controlled change to new versions of artefacts and there is no question that we will regularly have to make such changes, even breaking changes as new clinical safety issues or new requirements emerge. One can perhaps see this as 'market-driven' change - suppliers will say - "we need a new data point", or "the V1 archetype is no longer fit-for-purpose, we accept the need for a V2 and will manage the upgrade process". The example Heather has given around the Blood pressure archetype is a good example of what we might call 'modeller-driven/best practice change'. Some perfectly reasonable issues have been detected in the V1 BP archetype, and 'best modelling practice/ best semantics' would suggest that we create a V2. However, I doubt if there is any real demand for this from the vendor community .. very few will be using the Tilt element which contains the error and the other issue is more about modelling style- what is there at the moment works ok. So, in reality, I suspect there are very few drivers to push implementers to use V2, and we will end up (for now) with a 'best-practice' V2 and a V1 that continues to be used by the vast majority of implementations. One can argue that this is how the system is supposed to work .. put the variations out there and let the market decide, but new entrants to that market, and existing vendors working in multiple national markets will find that they are being asked to develop against both V1 and V2. Again, no-one disputes that this will happen for perfectly good reasons where V2 solves some real problems for implementers but I am anxious that we do not create unnecessary market confusion, purely to fix some rather obscure, if real problems. Heather quite reasonably asks the question 'Is it the role of the international modelling team to take such issues into consideration, or should the CKM efforts be purely driven by quality and technical correctness'. I think it is very important that we get feedback from Industry on this. Please give us your input. Ian --- ## Post #13 by @system Dear all, I agree with Ian that any change at international level should be market driven. From an experience of someone who works with standardization for years and who already led the adoption of standards in Brazil's extensive market, it is worth remembering that standards must reflect a consensus among the various stakeholders. Not always the final agreement reflects the most purist academic point, on the contrary they reflect a sum of needs and more pragmatic issues. It is the old saying: perfect is enemy of good. From that experience, I must say there is always has someone challenging the standard adopted, by always, saying that this or that attribute is missing or could be represented differently. I always reply, that if we pursue perfection it wll be a never ending discussion and we will never adopt anyhting. Changes must have a value to aggregate to every user to be done. openEHR is still taking baby steps in several countries and we, the adoption"s supporters,, use precisely the archetype "blood pressure" as a flagship demonstration of green archetypes worldwide, it is iconic . A change to v2 now, in my opinion gives a confusing message from us for those who are starting to adopt openEHR. IMO is strongly reccomended that Norway adopts BP v2 as the national archetype first(I wonder if it is consensus within that country). Later the community can evaluate their experience and change it with more evidence and support of the international community of users. Regards --- ## Post #14 by @system Hi I've not been involved in the revision of the Norwegian Blood pressure archetype, so I do not posess any ownership of the changes proposed. They can be looked upon as minor, but still they have arised after a review. I know personally several of the reviewers, and can assure they are very competent clinicians. In that perspective, I'm not happy about some of the comments below. Like "Who's using Tilt anyway" and suggestions of the Norwegian community to create obscure problems. 1) Using Tilt: Oslo university hospital is close to implement DIPS Arena with the BP archetype. Fairly soon there will be departements that will use Tilt. If Tilt was an element not necessary, why is it there in the first place? It might not be important for most users, but I have a remembrance of Maximum Data Sets. 2) Obscure problems: Why should not the correct unit be available to the users? 3) Blood pressure as a iconic flag ship: Wouldn't it be great to show the world that openEHR is able to update even the "dear baby archetype" when it is needed? Even our dearest babies grow up. Outside our small community, there are a great skepticism towards how openEHR will solve versioning of archetypes. It's important that we will not be ruled by impractical thoughts like "not invented here", and "doesn't matter for the major part of us". Regards Vebjørn Arntzen Enterprise architect, ICT-dept, Oslo universitetssykehus HF Tlf +47 4143 7589 --- ## Post #15 by @mikael Hi all, As long as someone in the world performs medical research, our knowledge about medicine will increase and change. This imply that changes in our information models and ontologies due to new knowledge (and pervious errors) are something constant and something every implementer needs to plan for. I therefore think that openEHR needs to make it as easy as possible for the implementers to implement updates to the archetypes in their systems, but also communicate that archetypes will change regularly and that is something the implementers need to live with. To give some perspective, I can mention that during the first releases of SNOMED CT, the mechanism for versioning in the release format was quite simple and probably not enough helpful for the implementers to manage the regular updates. Quite large resources were therefore spent on creating a new release format, which is more helpful for implementers when handling updates in SNOMED CT, and switch from the old release format (called Release Format 1) to the new release format (called Release Format 2). The SNOMED CT license also require all implementers to regularly update to new versions of SNOMED CT. Regards Mikael --- ## Post #16 by @system Hi Vebjørn, I hope I did not give the impression that I was in any way suggesting that the Norwegian clinical reviewers were being obscure or unreasonable and causing problems, or that tilt is not used in some applications. The review team have done exactly what we ask of them - to point out issues and errors and the 'iconic' status of BP does not give it any special privileges :). Just so that people understand this issue - the potentially breaking change in the BP archetype is that the unit of measure for the angle of Tilt is defined a degree symbol = ° which is the printable version of the UCUM unit and not the official UCUM unit which is = DEG or deg. If the Oslo University Arena implementation was perhaps 10 years down the track, with perhaps hundreds of thousands of BP records, including a small proportion with Tilt measurements using the ° unit already captured, it would be interesting to consider whether the cost of correcting this issue was felt to be worthwhile or whether we could 'live with' using the older version. @Mikael - the capacity to re-version and version is now quite capably built into openEHR (and we learnt quite a bit from SNOMED CT experience with namespacing). This is really not a technical question and it is always assumed that new archetypes ,new revisions and new versions (breaking) will always be required and supported. The question for us as modellers is whether we should take any account of the potential downsides of forking an archetype on implementers in our publication process or whether we should at least ask ourselves whether the overall benefits outweigh the potential disadvantages. As I said, I don't think this is unique to openEHR, it will apply to any formalism which has constraints or dependencies which over time need to be adjusted. Ian --- ## Post #17 by @mikael Hi Ian, I should probably clarify that the versioning mechanism in SNOMED CT is more than a technical thing. The versioning mechanism also includes guidelines about how to handle the changes in the receiving system. However, the guidelines are distributes in a form that is machine (and human) readable and processable, which might at a first look seem just to be a technical thing. Regards Mikael --- ## Post #18 by @heather.leslie Hi All, It has been an interesting conversation. Many thanks for everyone’s input. However, I think we do have a reasonable potential solution. 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). The other breaking changes suggested are effectively ‘cosmetic’ in some ways – ie a more refined way to record the body site for the measurement that is congruent with the pattern that has evolved since the archetype was first published. And I suggest that we add this as a draft v2 – ie the way of the future. Both archetypes can then be present in CKM – the published v1 and the newly proposed draft v2. Yes, there will be two atcodes related to ‘Tilt’ in the v1 archetype – one for use, one outdated - but implementers who are using this data element will be able to make their own decisions on what to do internally; those implementations who don’t use the data element will be unaffected. This will minimise disruption to existing implementations, allow new vendors to use the correct v1 atocode in new implementations and we can then choose to review and publish the v2 at the time of our choosing. Comments? In principle, I think CKM has to be seen as the ‘source of truth’ wherever possible. I really like this solution proposed by Sebastian as it offers us a way to govern that is finer grained than simply: draft vs published; v1 vs v2. We need to be mindful of this and use it as a more ‘delicate’ approach to our knowledge governance processes. Regards Heather --- ## Post #19 by @Heath_Frankel3 Hi Heather, Although I agree with the idea of obsolete concepts, I wonder if it is necessary in this case of Tilt. Why can’t we just add the additional units as allowed options leaving the existing degrees symbol but in the element description indicate that this is obsolete and the correct units should be used instead. The obsolete concept approach could be used for your body site improvement for example. Regards Heath --- ## Post #20 by @yampeku I'm curious of how this obsolete flag would be supported in a implementation agnostic view. How it is different of having several implementation guides for different MU levels, an epSOS implementation guide (which changed the CDA reference model itself), or even better, FHIR resources with same id in different DSTU? The industry will use what the solution requires. In case of (clinical driven) archetypes, implementation issues should be the less important part : just create clinicaly correct models and the industry will use them as needed. Personally I think the solution of just versioning is far more direct and less complicated than every other alternative. --- ## Post #21 by @Sam Hi All Taking this part of the change, I do not see any reason not to add a unit (really symbol change only) and mark the old one as deprecated. The data is unchanged and there is no risk to processing whatsoever. The location change is a little more complicated and seems to be due to moving a DV_TEXT up a level in the archetype - is that the gist of it? The data appears to be the same. I have read the DIFF but am not sure about the actual motivations here. Cheers, Sam Dr Sam Heard openEHR Board of Governors Liaison with Management Board --- ## Post #22 by @system 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 --- ## Post #23 by @Heath_Frankel3 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 --- ## Post #24 by @system Hi, Ian - and everyone else Yes, I agree on the principle for modellers to evaluate the changes related to potentional downsides. And that's what happening now. Good. Still, after reading some of the comments, I felt to state that it has to be the clinical need that should have the priority, despite how painful it will be to version up the archetype. If there is a clinical need - for someone - and it's weighty enough, then it must lead to a new version (or another approach - which others are discussing now). My point were not related to the actual discussion of the BP archetype. Vebjørn --- ## Post #25 by @system 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 --- ## Post #26 by @Heath_Frankel3 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 --- ## Post #27 by @yampeku But then what do we do with current implemented adl 1.4 archetypes? --- ## Post #28 by @heather.leslie David, The changes I’m proposing to the v1 archetype are non-breaking, so it will remain a v1 revision and as the changes are not related to content, can be republished. The changes that are proposed and breaking will be folded into a draft for v2, which will be visible as a potential future version. Heather --- ## Post #29 by @heather.leslie Hi Ian, These ADL changes don’t represent the non-breaking changes suggested, but do represent one option proposed for consideration in a v2, if we decided it warranted trying to update it to our current modelling pattern for Body site – it is effectively removing a redundant CLUSTER heading that adds no value. Thanks Heather --- ## Post #30 by @heather.leslie 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 --- ## Post #31 by @system Hi A breaking change should always be new major version. Then the problem is that changing version number introduces a huge cost. The cost is of course to the implementers – and by this I mean vendors, health care providers, national registries, integrations and so on. The whole ecosystem is influenced by such a change. Which makes it necessary to do a) not eagerly push major changes and b) when needed major changes should not influence earlier entries. In this concrete change of Archetype there is two major changes: 1) Introduce UCUM as UNIT I think we should just add a new unit – the UCUM and make the older deprecated. But keep both of them. This makes it possible to migrate slowly to the new schema for unit. In this case it is important to verify that the magnitude 90 is the same for each of the unit. And it is the only two units used. This makes it somehow safe to compare the magnitude without checking the unit. 2) Migrate from CLUSTER for Location to a choice between DvCodedText and DvText This changes is on one side a change in pattern and on the other side a reduction in functionality. I guess the pattern change is introduced to handle uncertainty in two flavours. 1. The list of local codes will never be complete – let us introduce the choice to also use free text 2. The list of local codes is not precise enough – let us introduce the choice to explain the element with free text This uncertainty will always be present when using coded text to describe a phenomena. It will never be precise enough and cover all use-cases. Given this – what is the criteria to introduce choice between text and coded text? Is this a normal case for this kind of elements? To simplify : Colours: a) RED, b) BLUE, c) GREEN d)Other. RED, BLUE and GREEEN cover the 80% use-case. Other covers the rest. We have several options to model this: a) Expand the list of colours and add new colours as new requirements appear b) Introduce a supporting element to specify colour if other is selected c) Leave colours as Text field with the possibility to a. Add list of items in Template (limited or not limited to list) b. Add list of coded items in Template c. Bind element to Terminology in Template Why is pattern a) chosen as the best way to model this kind of features? The reduction in functionality in the Archetype is because the user now is restricted to 0..1 coded text or text. Before could user choose between 0..1 coded text and an additional text so describe details of the location. I guess this is an wanted reduction in functionality and the intention may be to make entries more precise. In my, technical, opinion: The changes introduced on this specific archetype should be applied in in such a way that no breaking changes are introduced. Just add UCUM and leave the CLUSTER as is and use the specific location to add specific details. Propose the changes as a possible new major version (v2-ALPHA….) and collect more changes before forcing a new major version. --- ## Post #32 by @Eric_Browne Hi Heather et al, Whilst I have followed this thread and agree with many of the observations and conclusions reached so far, I would like to make the following observations, which are restricted to the aspect of the “non-UCUM" unit described in Heather’s original posting. They have more serious and broader implications than this one iconic Blood Pressure Archetype. **Notes on UCUM** According to the UCUM specification at [http://unitsofmeasure.o](http://unitsofmeasure.o)rg :- "The Unified Code for Units of Measure provides a single coding system for units that is complete, free of all ambiguities, and that assigns to each defined unit a concise semantics. In communication it is not only important that all communicating parties have the same repertoir of symbols, but also that all attach the same meaning to the symbols they exchange. The common meaning must be computationally verifiable. The Unified Code for Units of Measure assumes a semantics for units based on dimensional analysis.” * UCUM introduces ambiguity, despite the above claim. * UCUM is complex and comprehensive. It brings together units from various other standards into a single framework. It is designed to support computability and communications interoperability, and hence adopts a highest common denominator 7-bit represention of unit codes as normative for sharing. * UCUM does not provide a single code for each unit - it provides 2 normative codes, as well as a non-normative display/print rendition and an ad-hoc name. For each unit, UCUM defines a case-sensitive version, a case-insensitive version, and a version intended for display or printing. * Some units have no display/print variant defined. * UCUM defines every unit in terms of 7 metric base units and does so in a coherent and consistent fashion. This can support conforming systems to perform conversions from one unit to another. * UCUM does not supply normative names of units. * Some similar units have quite dissimilar UCUM variants. e.g. *°C Cel* for temperature print and case-sensitive variants respectively. *°F [degF]* for temperature print and case-sensitive variants respectively. *° deg* for plane angle print and case-sensitive variants respectively. * Some of UCUM’s names have been US-ised. E.g. *litre* has been changed to *liter*, *metre* to *meter*, *deca* to *deka*. * UCUM’s names don’t follow the 7-bit rule. Some names like *Ampère* and *Ångström* use 8-bit character representation. * UCUM uses [qualifier]s to indicate where a base unit is changed, e.g. *mm* is a unit for length property whereas *mm[Hg]* is a unit for pressure property. The [] syntax is unnecessary and complicates implementations. * UCUM provides no simple guide for use, particularly regarding normative components such as c/s, c/i and print. * UCUM inconsistently defines print representations of some units as normative and others as non-normative depending on the table. * UCUM’s print codes are often 8-bit. UCUM is premised on providing support for the highest common denominator across information systems, by constraining its normative unit strings to 7-bit values. However, unit print and unit name will not work in 7-bit environments. * UCUM releases are clearly supported and versioned, although differences between versions are hard to determine. * The contents of all UCUM specification tables are published as a single XML file for download. * Implementers of UCUM must choose between case insensitive and case-sensitive versions. The two cannot co-exist in the same channel of communication without special additional processing. * Even using UCUM, some units are difficult to represent and agree upon e.g. the unit for measuring estimated Glomerular Filtration Rate, quite common in healthcare - see http://unitsofmeasure.org/trac/ticket/98 * Further useful information: http://motorcycleguy.blogspot.com.au/2009/11/iso-to-ucum-mapping-table.html **Notes on openEHR’s implementation of UCUM within the AOM.** * openEHR is a standard primarily for building software components for electronic health records. openEHR Archetypes are being created and adopted by national bodies in many countries as canonical models for supporting interoperability of data shared between systems. Whilst these two goals are not mutually exclusive, they do present challenges and compromises for openEHR. EHR systems do need to care about supporting the entering and representation of data to users. * openEHR’s implementation of units is a compromise between these to goals that imposes minimal implementation overhead. * openEHR is designed to work in an 8-bit unicode/UTF-8 world. All openEHR-based applications are likely to support unicode characters and clearly ‘°’ would be part of that world. There are interesting examples such as the Observation Archetype "Fundoscopic examination of eyes” that constrains Field Angle values to “30º", “45º", etc.. as Coded Text. * The openEHR DataTypes specification defines properties, including units for DV_QUANTITY types. The specification is a little vague on adherance to UCUM for units, stating that unit strings are to be expressed in UCUM unit syntax. This allows for support of units beyond those defined in UCUM. * The current openEHR BNF for parsing units appears to have some errors if it were to be considered UCUM-conforming - e.g. presence of ‘μ’ symbol; absence of ‘[‘ and ‘]’ symbols. * openEHR is unclear on which variant(s) of UCUM ( case-sensitive, case-insensitive, print ) should be supported or mandated. The current openEHR BNF for parsing units cannot support 8-bit UCUM units such as ‘°’ i.e. degree symbol in values conforming to type DV_QUANTITY. **Tooling implementations for openEHR units** ( I have only looked briefly at these ) * ADL Workbench - appears to have support for UCUM beyond the openEHR spec. - e.g. all 7 electronically published fields can be stored within the Workbench. Units appear to be fully parsed against the UCUM spec. * Ocean Archetype Editor - constrains creation of archetyped units to the set defined in a units and properties XML file distributed with the AE. This set does not match the UCUM units. Current implementation allows only ‘°’ for degree symbol. Recent versions support UCUM ‘overrides’ for each unit. Where UCUM values have been explictly entered, they have been entered inconsistently - some are case-sensitive, some are case-insensitive. Processing of UCUM overides does not appear to have been implemented yet. See [http://lists.openehr.org/pipermail/openehr-](http://lists.openehr.org/pipermail/openehr-)clinical_lists.openehr.org/2014-February/003102.html . * Clinical Knowledge Manager - Many archetypes on the international CKM use non-valid UCUM units. I have not examined archetype processing, but assume from the archetypes in the international repository that existing archetypes are not validated against UCUM. Even basic archetypes like Body Temperature define units which are not UCUM-conformant. I consider this to be a more serious issue than the tilt angle of a person whose blood pressure is being recorded. **Implications for Archetypes, Archetype repositories and Archetype Governance** * The CKM Body Temperature archetype constrains values of quantities to have units of “°C” or “°F”. Most archetype tools I suspect, display the value of the units from the ADL verbatim. WYSISYG. This works well in the user interface world. “°C” and“°F” are both valid UCUM print rendition of units (they just happen to be invalid for sharing). Most EHR applications probably behave similarly - units would be displayed directly as stored in data sources. * Given openEHR proclaims to support UCUM as the standard for units in DV_QUANTITY, it would seem sensible to constrain to UCUM values in ADL. Most tools don’t do this currently. Most archetypes have invalid values for UCUM. Most tools don’t support both display/print as well as case-sensitive normative UCUM values. * Some unit issues, such as the Blood Pressure tilt angle could be “fixed” simply by adding the normative UCUM unit and flagging the deprecated unit as such. However, tools would need to be updated to allow these new, “fixed” units to be entered where they previously could not. Only some of the existing openEHR units could be “fixed” this way. * I think units are somewhat akin to terminology systems like SNOMED. There are significant implementation complexities. The main value in standardising units is to ensure safety and quality of data from disparate sources. The main additional value in adopting UCUM more fully is to support unit conversion. * Ideally, in order just to support UCUM well, openEHR implementations should support the case-sensitive UCUM value, the print value and the unit definitions, all supplied by UCUM via the published XML file. This does not mean that the DV_QUANTITY type needs to change, but it would mean updating existing archetypes to replace the current archetype units with the correct UCUM case-sensitive one. Let’s call this the UCUM code. openEHR archetype editors would then map these UCUM codes to unit displaynames ( i.e. the UCUM print value ). openEHR applications would also ideally map the UCUM code to unit displaynames. i.e. Applications and archetypes use UCUM codes internally, but those codes aren’t displayed to humans. * If there are grounds for changing the Blood Pressure Archetype to “fix” the Tile Angle, then those same grounds dictate that many more Archetypes be changed. This should be undertaken as a major versioning exercise, probably with 6 months warning and with as many ducks lined up before the new archetypes are published. Many deployments will need to change. Testing of those deployments will need to be undertaken. Consideration will need to be given to how to support existing data in live applications. * There will always be tension between national and international archetype repositories trying to produce models for an ideal world, rather than for implementations that have to operate in the real world. My observations of how the openEHR world is evolving is that these archetype repositories do generally, and should try to set a gold standard. They should push implementations rather than retard them. That model, in turn, puts a pressure on the repositories to be of high quality, comprehensive, current. That, in turn implies publishing new versions. Implementations don’t have to adopt the new versions. But the new versions need to offer real benefits. The trouble with “fixing” the units of all currently published archetypes is that adopting them in order to really make use of the normative UCUM units would mean pain for implementers. But for what gain? **Notes on current practice regarding unit usage in HL7 laboratory messages** I include the following, simply because it tries to illustrate how units are currently handled in many typical data sharing environments. * Legacy, non-openEHR systems using 7-bit databases might use predefined table of units something like UCUM - more likely they would specify their own unit system - perhaps “deg” for values for "°C” in a system in a metric country or “deg” for values in “°F” in a system in the US. In many systems the units are often implicit and not stored with each value. * In Australia, diagnostic testing laboratories almost all send test result reports in HL7 v2 messages. Many of these use atomic fields for each observation. HL7 v2 uses an explicit field for transmitting a unit description. The Australian Standards specify ISO+ values to be used to name these units in messages. In practice, messages comply to various levels with these ISO standards. I think the use of these codes is similar in the US, New Zealand and a number of other countries, although I am less familiar with these. * Depending on the quantity being sent in a report, the ability to computationally deal with the unit is fraught with implementation issues. Some parameters such as temperatures or weights that have been modelled as such in archetypes can be validated. In many cases there is simply too much variability, either in the units that are allowable for a particular field, or for the variability in quality of the actual units sent. * Both of the above shortcomings lead to implementers wanting archetypes with little or no unit constraint on many fields. More often than not this is a result of lack of compliance infrastructure. * In the real world of extensive data sharing, highest common denominator ( or often lowest common denominator ) trumps standards and quality, and even safety. regards, eric Eric Browne [eric.browne@montagesystems.com.au](mailto:eric.browne@montagesystems.com.au) ph 0414 925 845 skype: eric_browne --- ## Post #33 by @system 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 --- ## Post #34 by @system Eric, nice summary of issues. If I can take the liberty of pulling out what I think are your key issues to worry about + recommendations. I bolded my own subset of those ... => conclusion: we should have a PR to correct these issues so that the current specifications are at least clear, even if they still may be 'wrong' in some larger analysis. Eric, can you , with the relevant bullet points from this list? I think we could include changes to Release-1.0.3 to make these corrections. --- ## Post #35 by @grahamegrieve hi Eric --- ## Post #36 by @heather.leslie 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 --- ## Post #37 by @system 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\. --- ## Post #38 by @system surely the obvious approach is that the stored field contains the UCUM case\-sensitive code, and that applications / services use UCUM tables to render whatever display form is asked for in a client call? \(I realise openEHR archetypes are not doing this; they should be\.\.\.\) --- ## Post #39 by @system Hence my earlier proposal... --- ## Post #40 by @system Hi David, That is clearly a revision change1.0->1.1 but is not a breaking change for data already carried within the system i.e queries for tilt using the degree symbol will still work. This is is not inherently any different from the situation where we can add codes to an internal codelist, e.g mild/ moderate/severe/ => mild/moderate/severe/fatal This is considered a non-breaking change since existing data is not invalidated but could cause exactly the same kind of potential mismatch between systems using different minor revisions of the same archetype. Revision changes can only guarantee that existing data is unaffected but cannot ensure that mis-matches occur between disparate systems using different profiles on the same archetype. This can happen even with existing archetypes e.g the temperature archetype which allows variations of unit. In practice we need to use some form of templating or profiling to resolve these kind of potential variances in real systems and data exchanges. The good thing in your scenario is that the recipient system would through a validation error, alerting the recipient that an unexpected unit was being sent. I don't think there is a problem here. We expect similar variance issues to arise in other circumstances. Ian --- ## Post #41 by @heather.leslie 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 --- ## Post #42 by @system Dear ckm lovers, My preference is for your option 3. We have to make updates. Nobody is forced to change anything. Best regards Gunnar --- ## Post #43 by @system the normal situation if these were software artefacts would be that you would recompile them all, and anything else that become invalid due to the changes in some changed archetype would then have to be changed as well; anything that still validates remains fine\. This specifically works based on the 'specialise' statement in an archetype that normally refers only to the interface ID, i\.e\. an id that includes only the major version\. This of course relies on the ADL2 differential representation of archetypes, and the ADL2 identification and referencing rules\. \- thomas --- ## Post #44 by @system Hi All I am in favour of a process that allows gentle change. The degree change (DEG) is minor and the choice of units would not have any implications for safety as they are alternatives and the numerical value would not change. I would suggest that this change is made to both archetypes (V1 and V2 draft). I would suggest that the more considerable change be made to both archetypes as well but as an alternative, marking the location value as obsolete. You might ask all archetype users how many have any data that uses the location cluster? When and what are the implications? I would then suggest that we have a major review of the version 2 draft and ensure it is fit for purpose in high intensity environments like ICU and anaesthesia. Are there any state variables that might be worth introducing for cardiac purposes? Is there standardisation of 24hr BP monitoring? And put out a version 2 archetype that has a long life. The implications in systems of versioning archetypes are unknown at present but it is clearly a fundamental step. If we go through the process and no data is actually needing to be updated, then we have responded to a theoretical problem. If we go to version 2 of a very common archetype we are introducing complexity, increasing the likelihood of error and it will mean that all BP queries have to find and work with 2 different archetypes (when perhaps all data is the same!). According to the specs we will issue a transformation script (at least open source it) that updates all existing data to avoid different interpretations. We need to use this as an opportunity for empirical learning around a step that we have planned for a long time ago. Just my thoughts. Cheers, Sam --- ## Post #45 by @yampeku Not sure that having two archetypes really complicates the systems. I'm pretty sure that systems are already using more than two archetypes. If they are versions of the same archetype is not different than supporting different archetypes. If your system has dependencies on how a given archetype is defined, it is probably breaking the dual model principle IMHO --- ## Post #46 by @Oystein_Nytro I am reviewing the rise and development of domain specific OO models\. There are many\.\.\. Just a question of maintenance of OpenEHR: Versioning is fine\. Forking is already happening \(cfr\. ISO\-standardized units or not\)\. Every fork is a bad thing \- it requires double work, fosters arguments, diverted objectives \- from a standardization point of view Every fork is a good thing, because it increases effort spent, robustness, death\-rate, and thus evolution\. OpenEHR is challenged on many fronts, since it has few constraints from other SE ecosystems: OpenEHR has "home\-grown" tools, modelling languages, archetype repositories, implementations etc\. They are all likely to fragment, both independently and with complex dependencies\. And the effort will not be shared with anyone outside the OpenEHR sphere\. How to tackle future needs of consolidation, deprecation, pruning and \- possible refactoring? Maintenance has been the bane of many FLOSS software initiatives, as well as OO domain models\. Would anyone care to comment on how OpenEHR should keep tools, models and implementations fresh, sparkling, consistent and usable? Please correct me if the question is wrong: In that case, what are the right questions about OpenEHR future viability? Best regards, \-\-\- Øystein Nytrø --- ## Post #47 by @system HI Øystein, OpenEHR is a specification, although there is some sourcecode, regard that as an extra service, developed by some contributors, a lot from Ocean Informatics, but also others\. But OpenEHR should be regarded as a specification, and there are more and more implementations coming worldwide\. I believe there is somewhere a business\-page, with companies, and I know a few companies to with commercial success\. In the Netherlands is Code24, and most international mentioned is ThinkEHR, but there are more, mostly small companies\. I think it is a viable specification with great power regarding future use of information systems in healthcare\. If you have more specific questions, please ask, the lists are very responsive\. Best regards Bert Verhees --- ## Post #48 by @system As a reminder, the current [draft spec on versioning and lifecycle ](http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html)is here, and as usual, [comments are welcome](https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECPR%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC). - thomas --- ## Post #49 by @Oystein_Nytro I regarded OpenEHR as a specification language \(environment\)\. Not a specification by itself? Ok, I´ll try to be more specific, using Bert Verhees' terminology of OpenEHR as a specification: What are the governance processes and procedures related to: versioning, forking, refactoring etc for: \* "specifications" \(\- no I do not belive that there will be only one, final, specification\.\.\. :\-\) \* tools used to design and validate the "specification" \* implementations based on a distinct "specification" And since OpenEHR as "specification" was mentioned, \- is it possible to control consistency of additions and changes? Maybe inconsistency is impossible\. I may be asking for much, but governance procedures or test/validation framework seem to be a decisive factor in ensuring a longevity of domain models\. Best regards, \-\-\- Øystein Nytrø --- ## Post #50 by @system Hi Øystein, There seems to be a misunderstanding: OpenEHR is a specification of a reference model and archetypes, etc, it is not software, but there is some software to download\. I was trying to be helpful, but it turns out that I was confusing instead\. I am sorry for that\. In the OpenEHR specification, there is versioning specified, this is versioning of data\-entries\. I think now you are referring to that, so I explain that part\. If I am wrong again, please rephrase your question\. Thanks According tho theOpenEHR specification, entered data are for ever to keep, they cannot be changed, overwritten or deleted\. They are saved with references to audit\-records \(describing who entered the data, when they are entered, why ,etc\) All this is saved for ever\. But in the case when there is an error in entered data, it is possible to enter changed data \. Those changed data, however, do not overwrite the erroneous data, but create a new version of the same data\-entry\. Together with new audit\-data,\. So that both, the data\-entry with the error, and the changed data are saved, but the changed data have the latest version\-number, and are the one the system normally refers to\. How this is happening from technical point of view, is, according to my last reading of the specs, not specified\. The software\-architecture must take care that previous versions, together with according audit data, can be retrieved\. There are more ways to do this\. I hope I explained it clear Excuse again for being confusing\. Best regards Bert Verhees --- ## Post #51 by @system There is certainly forking going on; how much we don't really know. Most needed local changes can be taken care of by specialisation and templating, which are conformant changes; I assume that this is in fact how much 'forking' changes are done - so this isn't really forking in the technical sense of 'creating an incompatible variant of something'. I can't prove this - but if people doing clinical modelling could help report the actual nature of their changes we would have a better idea. How will openEHR keep the tools going? I think it will be by: - being agile - using places like Github to build and maintain them as public projects with live issue trackers - making sure the tools solve real problems - which means communicating with users - getting resources - if the openEHR tools solve certain problems better than some other approach, then resources will be put on to them, e.g. by companies and health authorities. There is evidence of this for the last few years, although more would be better. I like your point about consolidation, deprecation, pruning, refactoring etc - I think that's spot-on. The we we can specifically do this is - to ensure that the underlying formalisms, languages and models 'are lean and mean' - not bloated with unneeded complexity, and - continual review A blackbird stays shiny by continually preening the feathers. We need to do the same ;-) Recent positive signs: - I published a set of Antlr4 grammars on Github just over a week ago, and already people I don't know have helped solve [a number of problems](https://github.com/openEHR/adl-antlr/issues) and provided excellent feedback. - The openEHR/adl-designer project is also starting to receive [issue reports](https://github.com/openEHR/adl-designer/issues?utf8=%E2%9C%93&q=) and solve bugs. - Release-1.0.3 of the Reference Model is [close to being finished](https://openehr.atlassian.net/projects/SPECRM/versions/10860) - the archetype [industry sprint is very active](https://openehr.atlassian.net/wiki/display/healthmod/Proposed+archetypes+for+%27Industry+Sprint%27+Publication) - more industry members have joined (will be announced soon) - thomas --- ## Post #52 by @system governance procedures for the specifications are described pretty clearly [here](http://www.openehr.org/programs/specification/). The Specifications Editorial Committee is [here](http://www.openehr.org/programs/specification/editorialcommittee). We are likely to get more people onto this over time. The documenting and tracking of specifications changes over time is on Jira - see this [overview page](https://openehr.atlassian.net/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all), and look at the SPECXX and SPECPR projects. Validation of specifications is done by some level of implementation prior to the specification being issued. For example with the [AOM / ADL specifications](http://www.openehr.org/programs/specification/releases/currentbaseline#ADL2), this is always at least done in the [ADL Workbench, and usually a lot of other tools](http://www.openehr.org/downloads/modellingtools). We are working on a consolidated project plan for all tools, that will become visible on Jira. For specific open implementations that you see on [Github](https://github.com/openEHR), or [openEHRgen](https://code.google.com/p/open-ehr-gen-framework/), we are using typical open source meritocratic kinds of processes (undoubtedly these should be managed better). For vendor implementations, the processes are up to those companies, but we do know that the ones that have production openEHR systems running adhere pretty well to he specifications, because various data interchange tests have been done in the past. Much more on conformance needs to be done of course, and [this is recognised](https://openehr.atlassian.net/wiki/display/oecom/openEHR+2014+Roadmap+-+Product+and+Market). We can always do better, and critique and involvement from current and potential users is always the key. - thomas --- ## Post #53 by @system Hi Øystein! What worries me a bit more regarding forking is on the archetype level where some local and national projects have not always understood the point of contributing changes back and trying to stay aligned to global development. You can find a discussion regarding this for example in my thesis, [http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702](http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702) section 4.3 and specifically section 4.3.1 "Technical debt in archetype management" --- ## Post #54 by @system Hi Ølstein, Great questions and good answers. I agree with Erik, forking of the specification is not problematic as long as the forks do not purport to be openEHR i.e a trademarking issue. This is is purely so that people know exactly what they are working with. Similarly it would actually to have been beneficial to have more forking and innovation in the software/tooling space. Just because this is a small market, it is preferable for people to contribute back to the core resources but this has been difficult because the current tools have not made this so attractive. I am hopeful that the newly announced java/ javascript tools will provide a more solid basis for collaboration and helpful forking. So again I am comfortable that we are going in the right direction. > Theoretically I agree with Erik about the clinical modelling space being one area where it has been difficult to get a coherent approach, and it might appear that there is a large amount of pointless forking by companies and national standards organisations. I agree that at one level this is frustrating but at another, I think it just reflects the state of maturity of the 'market' and that national bodies, in particular like to feel ownership and need to build local trust - even the most 'well-behaved' national body, in Norway, has felt the need to go local to some extent - @Silje's view here would be interesting. I am increasingly of the view that it is the community of vendors and implementors who will force rationalisation in this space. It is very much in their interest not to have to develop their applications against n versions of Medication etc. We are not quite there yet but as the publication process of the Industry sprint rolls on, I think we will find that systems increasingly use the international archetypes internally and regard local national variants as definitional, using specialisation, local clusters to bridge the gaps. It has not been easy to get to this point but increasingly I am confident that we are getting sufficient momentum in the international space to keep the vendors onside. National programs will take much longer, and whatever we do there will be forking, for both good and bad reasons. That is for me, what makes archetypes interesting - it brings the power of the 'open source market' to the solution of wrangling commonality out of a complex, and at time chaotic problem space. It was always going to be ugly but bit-by-bit, I see commonality emerging. Ian --- **Canonical:** https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799 **Original content:** https://discourse.openehr.org/t/archetype-publication-question-implications-for-implementers/13799