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
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
För Ian McNicoll
Skickat: den 7 oktober 2015 13:27
Till: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Kopia: For openEHR technical discussions <openehr-technical@lists.openehr.org>;
For openEHR implementation discussions <openehr-implement...@lists.openehr.org>
Ämne: Re: Archetype publication question - implications for implementers
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
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll
[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 2 October 2015 at 12:46, Sebastian Garde
<sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>>
wrote:
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
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<tel:%2B61%20418%20966%20670> skype: heatherleslie
twitter: @omowizard
_______________________________________________
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org<mailto:openehr-clini...@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-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org<mailto: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
________________________________
[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-clinical mailing list
openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
