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
From: Sebastian Garde
Sent: Friday, 2 October 2015 10:19 AM
To: For openEHR clinical discussions, For openEHR implementation discussions,
For openEHR technical discussions
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, 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) 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
Clinical Programme Lead, openEHR Foundation
p: +61 418 966 670 skype: heatherleslie twitter: @omowizard
_______________________________________________
openEHR-clinical mailing list
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
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
www.avast.com
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
