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. Vennlig hilsen Bjørn Næss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010> From: openEHR-implementers [mailto:[email protected]] On Behalf Of Heather Leslie Sent: 2. oktober 2015 06:11 To: For openEHR clinical discussions <[email protected]>; For openEHR implementation discussions <[email protected]>; For openEHR technical discussions <[email protected]> Subject: Archetype publication question - implications for implementers 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
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
