Archetype publication question - implications for implementers

[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, 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

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Michael.Lawley]

This is indeed the intent: the language has been design to cater exactly for 
this extension.  I can't say that there's any international content about to 
come out with this addition numeric modelling, but Australia has been 
publishing this kind of content in the Australian Medicines Terminology (AMT) 
since July 2014 (one release per month).

Michael

Sent from my iPhone

On 1 Oct 2015, at 6:43 PM, David Moner 
mailto:dam...@gmail.com>> wrote:

Hello,

At this point I think that is the only option. I want to believe that the 
SNOMED CT Expression Constraint Language has been designed with a future 
evolution of SNOMED CT in mind, where concepts will be enriched with numerical 
values. For example, SNOMED CT now contains a set of Virtual Medical Products 
(VMP) such as "[374649006] Amoxicillin 400mg/5mL suspension (product)" with two 
relationships:
- Has active ingredient →  Amoxicillin
- Has dose form →  Oral suspension
If these relationships are enriched with the medication strength, then the VMP 
concepts would be better defined and could be queried using the numerical 
options of the constraint language.


2015-09-30 9:20 GMT+02:00 Thomas Beale 
mailto:thomas.be...@oceaninformatics.com>>:
On 30/09/2015 07:51, michael.law...@csiro.au 
wrote:
Imagine instead the example was using the corresponding AMT concepts (since 
snomed pure doesn't have any concrete domain modelling -- I.e. numeric values).

Then the focus concept would be the AMT amoxycillin Medicinal Product concept 
2141501136100 and the constraint matches would be MPUUs and TPUUs with 
capsule form and between 500 and 800 mg of amoxycillin as an active ingredient


ok - so the query would be applied to instances in a drug database (each 
instance there is a drug descriptor)?

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[David Moner]

Hello,

At this point I think that is the only option. I want to believe that the
SNOMED CT Expression Constraint Language has been designed with a future
evolution of SNOMED CT in mind, where concepts will be enriched with
numerical values. For example, SNOMED CT now contains a set of Virtual
Medical Products (VMP) such as "[374649006] Amoxicillin 400mg/5mL
suspension (product)" with two relationships:
- Has active ingredient →  Amoxicillin
- Has dose form →  Oral suspension
If these relationships are enriched with the medication strength, then the
VMP concepts would be better defined and could be queried using the
numerical options of the constraint language.


2015-09-30 9:20 GMT+02:00 Thomas Beale :

> On 30/09/2015 07:51, michael.law...@csiro.au wrote:
>
> Imagine instead the example was using the corresponding AMT concepts
> (since snomed pure doesn't have any concrete domain modelling -- I.e.
> numeric values).
>
> Then the focus concept would be the AMT amoxycillin Medicinal Product
> concept 2141501136100 and the constraint matches would be MPUUs and
> TPUUs with capsule form and between 500 and 800 mg of amoxycillin as an
> active ingredient
>
>
> ok - so the query would be applied to instances in a drug database (each
> instance there is a drug descriptor)?
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED CT constraint syntax - for querying instances or terminology?

[Bert Verhees]

I am following this discussion with great interest, just wanted you and 
Michael to know, just in case you would want to stop it or have it 
private, which I would regret.


Bert

On 30-09-15 09:20, Thomas Beale wrote:
ok - so the query would be applied to instances in a drug database 
(each instance there is a drug descriptor)?



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org