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
On 02.10.2015 11:36, Diego Boscá wrote:
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
El 2/10/2015 11:20, "Sebastian Garde"
<sebastian.ga...@oceaninformatics.com
<mailto:sebastian.ga...@oceaninformatics.com>> escribió:
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.
On 02.10.2015 06:11, Heather Leslie wrote:
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*
oArchetype data is updated to include correct UCUM units
oArchetype data is updated to include more ‘modern’ modelling
patterns that are being used increasingly in more recent archetypes
oNew 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
oFurther 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*
oFurther content review will possibly introduce further changes –
maybe breaking, maybe not.
oExisting 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.
oThe 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.
oTwo versions of the archetype will be in circulation, and
implementers will need to manage the interoperability issues that
will arise.
oNorway 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:
oMaking Measurement Location a choice of coded text and text – at0014
oRemoval 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 <tel:%2B61%20418%20966%20670> skype:
heatherleslie twitter: @omowizard
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics
Skype: gardeseb
------------------------------------------------------------------------
Avast logo <https://www.avast.com/antivirus>
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
www.avast.com <https://www.avast.com/antivirus>
_______________________________________________
openEHR-technical mailing list
openehr-techni...@lists.openehr.org
<mailto:openehr-techni...@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics
Skype: gardeseb
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
