Re: Archetype publication question - implications for implementers

[Thomas Beale]

As a reminder, the current draft spec on versioning and lifecycle 
is 
here, and as usual, comments are welcome 
.


- thomas



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

RE: Archetype publication question - implications for implementers

[Heather Leslie]

The versioning rules have been following. This is a use case that is testing 
them, testing our strategy. Excellent.

What does specialisation add to this? We still have a changed MD5, new 
archetype ID, etc... Aargh.

If we specialise, what happens when the next change comes along? Specialise the 
specialisation? Rinse, wash, repeat?

I don't think this solves the broader issue that we need to accept and 
acknowledge - that archetypes WILL change as medicine changes, as our 
understanding changes and when we get things wrong! As a community of 
clinicians and implementers, we do need to develop strategies to minimise the 
flow on effects to implementers but ensure that we are heading towards high 
quality, correct archetypes. It is a tension that we need to balance.

There is no doubt that publication of a v2 would have had maximal impact on all 
implementers. We have successfully avoided that.

This v1 revision does have an impact, but I believe that we have corrected the 
issue while creating minimal change in the archetype. Note that most (maybe 
nearly all) implementers don't use Tilt; so most won't need to do anything to 
their local systems. Paths won't change for querying etc. The query for 
specific units may need to be managed, but it is manageable and negotiable.

It will impact those who want to share Tilt data from different revisions of 
the archetype. But that was always going to be the case when anyone uses 
slightly different revisions of an archetype. The revision needs to be part of 
the info transfer and then the differences will need to be negotiated somehow.

Remember that the archetype revision number and build UID are now in the latest 
archetype metadata downloadable from CKM to facilitate implementers having a 
finer level of control over the versioning.

This may be the first time we discuss how to manage this kind of change in the 
list, but it won't be the last and there will almost certainly be more with a 
lot more impact.

I know it will irritate some when I say that archetyping the actual clinical 
content that clinicians need and use in practice is often more art than 
science, but let me reassure you that we are 'science-ing the hell' out of the 
clinical knowledge governance process as much as we can. It is really complex, 
and the more we understand it, the more we realise how complex this area is.

This is our job. Implementers need strategies to align the mismatches that will 
occur. Publication per se is a very coarse way to manage interoperability and 
will not solve our problems. The alignment needs to be done at a finer level of 
control. This is not a new problem. It is one we are just realising as we 
implement and start to share - we were always going to have to have this 
conversation and solve this problem. It was just a matter of when.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, 19 October 2015 8:46 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Cc: openehr-clini...@lists.openehr.org
Subject: Re: Archetype publication question - implications for implementers


Hence my earlier proposal...
On 19/10/2015 09:18, David Moner wrote:


2015-10-16 3:22 GMT+02:00 Heather Leslie 
<heather.les...@oceaninformatics.com<mailto:heather.les...@oceaninformatics.com>>:

* It means that new implementers can use the corrected v1 revision and 
we don't have to create a v2 for a relatively trivial problem; existing vendor 
implementations can remain unchanged or they can choose to update the units if 
they please. The MD5 changes, but all paths etc are identical. A minimal 
disruption approach, if you like - thanks Heath.

And what happens if a new implementation sends data to an old implementation? 
Since the archetype identifier has not changed the receiver will use its own 
archetype to validate the received data, and if it includes the 'deg' unit it 
will just fail the validation. Breaking revisions are not only about changing 
the archetype structure, but also about generating a different set of possible 
instances.

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

Re: Archetype publication question - implications for implementers

[David Moner]

2015-10-16 3:22 GMT+02:00 Heather Leslie <
heather.les...@oceaninformatics.com>:

> · It means that new implementers can use the corrected v1
> revision and we don’t have to create a v2 for a relatively trivial problem;
> existing vendor implementations can remain unchanged or they can choose to
> update the units if they please. The MD5 changes, but all paths etc are
> identical. A minimal disruption approach, if you like – thanks Heath.
>

And what happens if a new implementation sends data to an old
implementation? Since the archetype identifier has not changed the receiver
will use its own archetype to validate the received data, and if it
includes the 'deg' unit it will just fail the validation. Breaking
revisions are not only about changing the archetype structure, but also
about generating a different set of possible instances.


-- 
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: Archetype publication question - implications for implementers

[Thomas Beale]

Hence my earlier proposal...

On 19/10/2015 09:18, David Moner wrote:



2015-10-16 3:22 GMT+02:00 Heather Leslie 
>:


·It means that new implementers can use the corrected v1 revision
and we don’t have to create a v2 for a relatively trivial problem;
existing vendor implementations can remain unchanged or they can
choose to update the units if they please. The MD5 changes, but
all paths etc are identical. A minimal disruption approach, if you
like – thanks Heath.


And what happens if a new implementation sends data to an old 
implementation? Since the archetype identifier has not changed the 
receiver will use its own archetype to validate the received data, and 
if it includes the 'deg' unit it will just fail the validation. 
Breaking revisions are not only about changing the archetype 
structure, but also about generating a different set of possible 
instances.



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

Re: Archetype publication question - implications for implementers [ long ]

[Thomas Beale]

surely the obvious approach is that the stored field contains the UCUM 
case-sensitive code, and that applications / services use UCUM tables to 
render whatever display form is asked for in a client call? (I realise 
openEHR archetypes are not doing this; they should be...)


there's another problem: in both v2 and CDA, HL7 specified a single 
units field on the assumption that implementers could somehow square 
the circle and have a single units that satisfies human and computer 
readability. This is not possible. Hence the mess we are in.






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

Re: Archetype publication question - implications for implementers

[Ian McNicoll]

Hi David,

That is clearly a revision change1.0->1.1 but is not a breaking change for
data already carried within the system i.e queries for tilt using the
degree symbol will still work.

This is is not inherently any different from the situation where we can add
codes to an internal codelist,  e.g mild/ moderate/severe/ =>
mild/moderate/severe/fatal

This is considered a non-breaking change since existing data is not
invalidated but could cause exactly the same kind of potential mismatch
between systems using different minor revisions of the same archetype.

Revision changes can only guarantee that existing data is unaffected but
cannot ensure that mis-matches occur between disparate systems using
different profiles on the same archetype. This can happen even with
existing archetypes e.g the temperature archetype which allows variations
of unit. In practice we need to use some form of templating or profiling to
resolve these kind of potential variances in real systems and data
exchanges.

The good thing in your scenario is that the recipient system would through
a validation error, alerting the recipient that an unexpected unit was
being sent.

I don't think there is a problem here. We expect similar variance issues to
arise in other circumstances.

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 October 2015 at 11:45, Thomas Beale  wrote:

>
> Hence my earlier proposal...
>
> On 19/10/2015 09:18, David Moner wrote:
>
>
>
> 2015-10-16 3:22 GMT+02:00 Heather Leslie <
> heather.les...@oceaninformatics.com>:
>
>> · It means that new implementers can use the corrected v1
>> revision and we don’t have to create a v2 for a relatively trivial problem;
>> existing vendor implementations can remain unchanged or they can choose to
>> update the units if they please. The MD5 changes, but all paths etc are
>> identical. A minimal disruption approach, if you like – thanks Heath.
>>
>
> And what happens if a new implementation sends data to an old
> implementation? Since the archetype identifier has not changed the receiver
> will use its own archetype to validate the received data, and if it
> includes the 'deg' unit it will just fail the validation. Breaking
> revisions are not only about changing the archetype structure, but also
> about generating a different set of possible instances.
>
>
>
> ___
> openEHR-clinical mailing list
> 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

Re: Archetype publication question - implications for implementers

[Thomas Beale]

I've skimmed the replies on this thread, and I'm inclined to think 
everyone could be right. Problem is, they can't all be right at the same 
time.


So considering the issue from a global deployment perspective I had 
the folllowing idea:


 * in the archetype library, we should stick to proper versioning
   rules, as Diego, David and Sebastian have said, and correct the
   error and issue a new v2 archetype
 o => this way there are no surprises in the archetype library for
   software, or people, by the time we have forgotten about this issue
 o => the paths would stay the same to the various data fields, but
   the units in the tilt table field would be different, and will
   break anything that specifically relies on that
 * but we still may need a way of making adding the correction to the
   v1 version of the BP archetype, for some users, to enable their
   current queries and software based on the 'v1' id to keep working.
   This could be achieved by:
 o creating a specialisation of the v1 archetype that adds a new
   node as Sebastian proposed, or via Heath's proposal
 + => this means that the deployment has to use a new archetype
   id for data production (i.e. in the CDR), but AQL queries
   using the old id should continue to work, assuming the query
   processor correctly finds child archetypes for a given
   archetype id
 o OR enable a modification in the template that has the effect of
   adding the required unit or element
 + => this means that all ids stay the same in data production
   and querying, but the CDR is being told a white lie, in that
   what it thinks is the BP archetype is not exactly what it is
   back in the CKM library

I haven't tried to analyse the details here that far, but the general 
idea is to:


 * a) ensure the archetype library follows the versioning and change
   rules properly
 * b) inject an adjusting fix either as a specialisation, or further
   along in the processing chain - in a template (or even OPT)

thoughts?

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

Re: Archetype publication question - implications for implementers [ long ]

[Thomas Beale]

Eric,

nice summary of issues. If I can take the liberty of pulling out what I 
think are your key issues to worry about + recommendations. I bolded my 
own subset of those ...


On 10/10/2015 10:07, Eric Browne wrote:



*Notes on UCUM*

* UCUM does not supply normative names of units.
* Some of UCUM’s names have been US-ised. E.g. /litre/ has been 
changed to /liter/, /metre/ to /meter/, /deca/ to /deka/.
* *Implementers of UCUM must choose between case insensitive and 
case-sensitive versions*. The two cannot co-exist in the same channel 
of communication without special additional processing.
* Even using UCUM, some units are difficult to represent and agree 
upon e.g. the unit for measuring estimated Glomerular Filtration Rate, 
quite common in healthcare - see http://unitsofmeasure.org/trac/ticket/98


*Notes on openEHR’s implementation of UCUM within the AOM.*

*  The specification is a little vague on adherance to UCUM for 
units, stating that unit strings are to be expressed in UCUM unit 
syntax. This allows for support of units beyond those defined in UCUM.
* The current openEHR BNF for parsing units appears to have some 
errors if it were to be considered UCUM-conforming - e.g. presence of 
‘μ’ symbol; absence of ‘[‘ and ‘]’ symbols.
* openEHR is unclear on which variant(s) of UCUM ( case-sensitive, 
case-insensitive, print ) should be supported or mandated.
The current openEHR BNF for parsing units cannot support 8-bit UCUM 
units such as ‘°’ i.e. degree symbol in values conforming to type 
DV_QUANTITY.


=> conclusion: we should have a PR to correct these issues so that the 
current specifications are at least clear, even if they still may be 
'wrong' in some larger analysis.


Eric, can  you raise a PR here 
, 
with the relevant bullet points from this list? I think we could include 
changes to Release-1.0.3 to make these corrections.




*Tooling implementations for openEHR units*

* Clinical Knowledge Manager - *Many archetypes on the international 
CKM use non-valid UCUM units*.


*Implications for Archetypes, Archetype repositories and Archetype 
Governance

*
* Some unit issues, such as the Blood Pressure tilt angle could be 
“fixed” simply by adding the normative UCUM unit and flagging the 
deprecated unit as such. However, tools would need to be updated to 
allow these new, “fixed” units to be entered where they previously 
could not. Only some of the existing openEHR units could be “fixed” 
this way.
* I think units are somewhat akin to terminology systems like SNOMED. 
There are significant implementation complexities.  The main value in 
standardising units is to ensure safety and quality of data from 
disparate sources. The main additional value in adopting UCUM more 
fully is to support unit conversion.
* Ideally, in order just to support UCUM well, *openEHR 
implementations should support the case-sensitive UCUM value*, the 
print value and the unit definitions, all supplied by UCUM via 
the published XML file. This does not mean that the DV_QUANTITY type 
needs to change, but *it would mean updating existing archetypes to 
replace the current archetype units with the correct UCUM 
case-sensitive one*. Let’s call this the UCUM code. openEHR archetype 
editors would then map these UCUM codes to unit displaynames ( i.e. 
the UCUM print value ).  openEHR applications would also ideally map 
the UCUM code to unit displaynames. i.e. Applications and archetypes 
use UCUM codes internally, but those codes aren’t displayed to humans.
* If there are grounds for changing the Blood Pressure Archetype to 
“fix” the Tile Angle, then those same grounds dictate that many more 
Archetypes be changed.  This *should be undertaken as a major 
versioning exercise*, probably with 6 months warning 
* There will always be tension between national and international 
archetype repositories trying to produce models for an ideal world, 
rather than for implementations that have to operate in the real 
world. My observations of how the openEHR world is evolving is that 
*these archetype repositories do generally, and should try to set a 
gold standard*. _They should push implementations  rather than retard 
them_. The trouble with “fixing” the units of all currently 
published archetypes is that adopting them in order to really make use 
of the normative UCUM units would mean pain for implementers. But for 
what gain?



*Notes on current practice regarding unit usage in  HL7 laboratory 
messages*


I include the following, simply because it tries to illustrate how 
units are currently handled in many typical data sharing environments.
* Legacy, non-openEHR systems using 7-bit databases might use 
predefined table of units something like UCUM - more likely they would 
specify their own unit system - perhaps “deg” for values for "°C” in a 

Re: Archetype publication question - implications for implementers [ long ]

[Grahame Grieve]

hi Eric

Some comments:

* UCUM introduces ambiguity, despite the above claim.
>

please demonstrate examples.


> * UCUM does not provide a single code for each unit - it provides 2
> normative codes, as well as a non-normative display/print rendition and an
> ad-hoc name. For each unit, UCUM defines a case-sensitive version, a
> case-insensitive version, and a version intended for display or printing.
>

the display is not the same as the 2 codes and so your sentence is
misleading. As for the 2 codes, the case-insensitive codes should be
ignored. All the contexts of use I have seen require the use of case
sensitive codes.


> * Some units have no display/print variant defined.
>

you mean name, or printSymbol? examples?

* Some similar units have quite dissimilar UCUM variants. e.g.
>

so?


> * UCUM’s names don’t  follow the 7-bit rule. Some names like *Ampère* and
> *Ångström* use 8-bit character representation.
>

UCUM says that the codes do, not that the names or print symbols do

* UCUM uses [qualifier]s to indicate where a base unit is changed, e.g. *mm* is
> a unit for length property whereas *mm[Hg]* is a unit for pressure
> property. The [] syntax is unnecessary and complicates implementations.
>

The [] is not unnecessary, nor should it complicate anything. It's a code,
and [] is introduced to remove ambiguity. What complications do you think
it introduces?

* UCUM releases are clearly supported and versioned, although differences
> between versions are hard to determine.
>

are you familiar with text diff programs?


> * Further useful information:
> http://motorcycleguy.blogspot.com.au/2009/11/iso-to-ucum-mapping-table.html
>

and here: the most commonly used UCUM codes based on extensive survey of
implementers systems: http://hl7.org/fhir/valueset-ucum-common.html



>
> * Depending on the quantity being sent in a report, the ability to
> computationally deal with the unit is fraught with implementation issues.
> Some parameters such as temperatures or weights that have been modelled as
> such in archetypes can be validated. In many cases there is simply too much
> variability, either in the units that are allowable for a particular field,
> or for the variability in quality of the actual units sent.
>

there's another problem: in both v2 and CDA, HL7 specified a single units
field on the assumption that implementers could somehow square the circle
and have a single units that satisfies human and computer readability. This
is not possible. Hence the mess we are in.

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

RE: Archetype publication question - implications for implementers

[Heather Leslie]

Hi Thomas,

See my email from October 9 regarding how this has been resolved.

There is now an updated v1 Blood Pressure archetype with addition of the 
correct units for Tilt added to the node and a note that the previous units are 
no longer to be used. It has been republished as a non-breaking revision.

· It follows the versioning rules that we have firmly established for 
published archetypes.

· It means that new implementers can use the corrected v1 revision and 
we don't have to create a v2 for a relatively trivial problem; existing vendor 
implementations can remain unchanged or they can choose to update the units if 
they please. The MD5 changes, but all paths etc are identical. A minimal 
disruption approach, if you like - thanks Heath.

We can consider other changes that might require a v2 in the future, at our 
leisure. There is no urgency at this point as the remaining changes that have 
been proposed are more along the lines of updating the archetype towards 'more 
modern' patterns for anatomical location etc. We don't need to rush down this 
path as there will be little to gain, and probably quite a lot of confusion 
generated.

If we identify other breaking issues in the future, a v2 will be considered 
again, including the remaining 'ideal pattern' proposals. But for now, my 
advice is to leave the revised v1 as is.

Through this discussion we have identified is another strategy for governance 
and change management, that I hadn't considered before. A good outcome from my 
POV.

Have I missed anything?

Thanks again for all of your contributions.

Regards

Heather


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 15 October 2015 11:05 PM
To: openehr-clini...@lists.openehr.org; Openehr-Technical 
<openehr-technical@lists.openehr.org>
Subject: Re: Archetype publication question - implications for implementers


I've skimmed the replies on this thread, and I'm inclined to think everyone 
could be right. Problem is, they can't all be right at the same time.

So considering the issue from a global deployment perspective I had the 
folllowing idea:

  *   in the archetype library, we should stick to proper versioning rules, as 
Diego, David and Sebastian have said, and correct the error and issue a new v2 
archetype

 *   => this way there are no surprises in the archetype library for 
software, or people, by the time we have forgotten about this issue
 *   => the paths would stay the same to the various data fields, but the 
units in the tilt table field would be different, and will break anything that 
specifically relies on that

  *   but we still may need a way of making adding the correction to the v1 
version of the BP archetype, for some users, to enable their current queries 
and software based on the 'v1' id to keep working. This could be achieved by:

 *   creating a specialisation of the v1 archetype that adds a new node as 
Sebastian proposed, or via Heath's proposal

*   => this means that the deployment has to use a new archetype id for 
data production (i.e. in the CDR), but AQL queries using the old id should 
continue to work, assuming the query processor correctly finds child archetypes 
for a given archetype id

 *   OR enable a modification in the template that has the effect of adding 
the required unit or element

*   => this means that all ids stay the same in data production and 
querying, but the CDR is being told a white lie, in that what it thinks is the 
BP archetype is not exactly what it is back in the CKM library

I haven't tried to analyse the details here that far, but the general idea is 
to:

  *   a) ensure the archetype library follows the versioning and change rules 
properly
  *   b) inject an adjusting fix either as a specialisation, or further along 
in the processing chain - in a template (or even OPT)

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

Re: Archetype publication question - implications for implementers [ long ]

[Eric Browne]

Hi Heather et al,

Whilst I have followed this thread and agree with many of the observations and 
conclusions reached so far,  I would like to make the following observations, 
which are restricted to the aspect of the “non-UCUM" unit described in 
Heather’s original posting. They have more serious and broader implications 
than this one iconic Blood Pressure Archetype.

Notes on UCUM

According to the UCUM specification at http://unitsofmeasure.org :-

"The Unified Code for Units of Measure provides a single coding system for 
units that is complete, free of all ambiguities, and that assigns to each 
defined unit a concise semantics. In communication it is not only important 
that all communicating parties have the same repertoir of symbols, but also 
that all attach the same meaning to the symbols they exchange. The common 
meaning must be computationally verifiable. The Unified Code for Units of 
Measure assumes a semantics for units based on dimensional analysis.”

* UCUM introduces ambiguity, despite the above claim.
* UCUM is complex and comprehensive. It brings together units from various 
other standards into a single framework. It is designed to support 
computability and communications interoperability, and hence adopts a highest 
common denominator 7-bit represention of unit codes as normative for sharing.
* UCUM does not provide a single code for each unit - it provides 2 normative 
codes, as well as a non-normative display/print rendition and an ad-hoc name. 
For each unit, UCUM defines a case-sensitive version, a case-insensitive 
version, and a version intended for display or printing. 
* Some units have no display/print variant defined.
* UCUM defines every unit in terms of 7 metric base units and does so in a 
coherent and consistent fashion. This can support conforming systems to perform 
conversions from one unit to another.
* UCUM does not supply normative names of units.
* Some similar units have quite dissimilar UCUM variants. e.g. 

°C  Cel  for temperature  print and case-sensitive variants respectively.

°F  [degF]  for temperature  print and case-sensitive variants respectively.

°   deg for plane angle print and case-sensitive variants respectively.

* Some of UCUM’s names have been US-ised. E.g. litre has been changed to liter, 
metre to meter, deca to deka.
* UCUM’s names don’t  follow the 7-bit rule. Some names like Ampère and 
Ångström use 8-bit character representation.
* UCUM uses [qualifier]s to indicate where a base unit is changed, e.g. mm is a 
unit for length property whereas mm[Hg] is a unit for pressure property. The [] 
syntax is unnecessary and complicates implementations.
* UCUM provides no simple guide for use, particularly regarding normative 
components such as c/s, c/i and print.
* UCUM inconsistently defines print representations of some units as normative 
and others as non-normative depending on the table.
* UCUM’s print codes are often 8-bit. UCUM is premised on providing support for 
the highest common denominator across information systems, by constraining its 
normative unit strings to 7-bit values. However, unit print and unit name  will 
not work in 7-bit environments.
* UCUM releases are clearly supported and versioned, although differences 
between versions are hard to determine.
* The contents of all UCUM specification tables are published as a single XML 
file for download.
* Implementers of UCUM must choose between case insensitive and case-sensitive 
versions. The two cannot co-exist in the same channel of communication without 
special additional processing.
* Even using UCUM, some units are difficult to represent and agree upon e.g. 
the unit for measuring estimated Glomerular Filtration Rate, quite common in 
healthcare - see http://unitsofmeasure.org/trac/ticket/98
* Further useful information: 
http://motorcycleguy.blogspot.com.au/2009/11/iso-to-ucum-mapping-table.html

Notes on openEHR’s implementation of UCUM within the AOM.

* openEHR is a standard primarily for building software components for 
electronic health records. openEHR Archetypes are being created and adopted by 
national bodies in many countries as canonical models for supporting 
interoperability of data shared between systems. Whilst these two goals are not 
mutually exclusive, they do present challenges and compromises for openEHR. EHR 
systems do need to care about supporting the entering and representation of 
data to users. 
* openEHR’s implementation of units is a compromise between these to goals that 
imposes minimal implementation overhead.
* openEHR is designed to work in an 8-bit unicode/UTF-8 world. All 
openEHR-based applications are likely to support unicode characters and clearly 
‘°’ would be part of that world. There are interesting examples such as the 
Observation Archetype "Fundoscopic examination of eyes” that constrains Field 
Angle values to “30º", “45º", etc.. as Coded Text.
* The openEHR DataTypes specification defines properties, 

RE: Archetype publication question - implications for implementers

[Bjørn Næss]

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:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Heather 
Leslie
Sent: 2. oktober 2015 06:11
To: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>; For 
openEHR implementation discussions <openehr-implement...@lists.openehr.org>; 
For openEHR technical discussions <openehr-technical@lists.openehr.org>
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.218

Re: Archetype publication question - implications for implementers

[Heath Frankel]

The existing versioning rules allow adding new concepts and opening constraints 
such as allowing additional units. These change the md5 hash but does require a 
version /id change.

This is why Sebastian's suggestion technically works, the existing obsolete 
concept still exists and the new concepts can be added for those that want to 
move to the preferred approach.

However, I am concerned about adding new concepts that are in fact the same as 
an existing just represented differently. This is why I suggested to add new 
units to the existing tilt element (opening the constraint) rather adding a new 
concept for tilt with the new units.

I also suggested adding the new representation for body site as a new concept 
but starting to think this is a bad idea since we are duplicating the concept 
and have two ways in the same archetype to represent the same concept and worse 
the concept has two identifiers.

Having said that I suspect the alternative representation is filling a slot 
with a cluster archetype in a template and hence there is no duplicate concepts 
in the same archetype, there is a new slot and the alternate representation is 
in a template instead. Is this any better? Perhaps marginally.

Regards

Heath

On 8 Oct 2015, at 6:42 pm, "David Moner" 
> wrote:


2015-10-08 1:23 GMT+02:00 Heather Leslie 
>:
It was Sebastian's suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

But that will not be v1 anymore...

At this point, anyone who has worked for a time with the archetypes of CKM 
knows that the readable archetype ID, including the version number, it is not a 
reliable reference to identify the archetypes (this is said somewhere in the 
specifications, but should be more clearly stated for newcomers). The only 
reliable identifier from a technical point of view is the MD5 hash of the 
definition part of the archetype. Any change to the structure will create a 
different MD5. Any (correctly implemented) system that uses it will find that 
it is a new archetype, call it v1, v1+internal revision, v2 or whatever.

As Diego said, the less complicated solution is to just follow the versioning 
rules that already exist.

David

--
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-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype publication question - implications for implementers

[Ian McNicoll]

Hi Heath,

I think the suggested change was from

CLUSTER[at1033] occurrences matches {0..1} matches { -- Location
items cardinality matches {1..*; unordered} matches {
ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of
measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025, -- Right arm
at0026, -- Left arm
at0027, -- Right thigh
.
}
}
}
}
ELEMENT[at1034] occurrences matches {0..1} matches { -- Specific location
value matches {
DV_TEXT matches {*}
}
}
}
}

to

ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of
measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025,  -- Right arm
at0026,  -- Left arm
at0027,  -- Right thigh
. }
}

DV_TEXT matches {*} -- Specific location
}

which is how we would model it now.

As a side-note, ADL2.0 introduces the capacity to formally deprecate an
existing node, which will be very helpful in these sort of situations.

I also favour adding the 'deg' unit to the existing Tilt quantity, as I
think Sebastian suggested, as an alternative (and not making the change
above). That would allow us to add the critical changes in a non-breaking
manner.

Thanks to everyone who has contibuted so far - we still need other
implementer views!!

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 8 October 2015 at 10:23, Heath Frankel <
heath.fran...@oceaninformatics.com> wrote:

> The existing versioning rules allow adding new concepts and opening
> constraints such as allowing additional units. These change the md5 hash
> but does require a version /id change.
>
> This is why Sebastian's suggestion technically works, the existing
> obsolete concept still exists and the new concepts can be added for those
> that want to move to the preferred approach.
>
> However, I am concerned about adding new concepts that are in fact the
> same as an existing just represented differently. This is why I suggested
> to add new units to the existing tilt element (opening the constraint)
> rather adding a new concept for tilt with the new units.
>
> I also suggested adding the new representation for body site as a new
> concept but starting to think this is a bad idea since we are duplicating
> the concept and have two ways in the same archetype to represent the same
> concept and worse the concept has two identifiers.
>
> Having said that I suspect the alternative representation is filling a
> slot with a cluster archetype in a template and hence there is no duplicate
> concepts in the same archetype, there is a new slot and the alternate
> representation is in a template instead. Is this any better? Perhaps
> marginally.
>
> Regards
>
> Heath
>
> On 8 Oct 2015, at 6:42 pm, "David Moner"  wrote:
>
>
> 2015-10-08 1:23 GMT+02:00 Heather Leslie <
> heather.les...@oceaninformatics.com>:
>
>> It was Sebastian’s suggestion about governing at an intra-archetype level
>> that has caught my attention - marking an existing data element as
>> outdated, and adding a new one as a revision solves the issue of having
>> correct vs incorrect units and avoids the necessity of a new version
>> immediately. I suggest we make this modification to the existing v1 and
>> republish as stable (and technically correct).
>
>
> But that will not be v1 anymore...
>
> At this point, anyone who has worked for a time with the archetypes of CKM
> knows that the readable archetype ID, including the version number, it is
> not a reliable reference to identify the archetypes (this is said somewhere
> in the specifications, but should be more clearly stated for newcomers).
> The only reliable identifier from a technical point of view is the MD5 hash
> of the definition part of the archetype. Any change to the structure will
> create a different MD5. Any (correctly implemented) system that uses it
> will find that it is a new archetype, call it v1, v1+internal revision, v2
> or whatever.
>
> As Diego said, the less complicated solution is to just follow the
> versioning rules that already exist.
>
> David
>
> --
> 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-implementers mailing list
> openehr-implement...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> 

RE: Archetype publication question - implications for implementers

[Heather Leslie]

Hi everyone

Thanks for the suggestions and active discussion.

My main issue was with how to proceed with potentially breaking changes to 
correct technical artefacts and seeking strategies to manage the tension 
between pure modelling and implementation.

Your suggestions have been helpful. We have developed some strong rules about 
governance from identification of changes/mods that require either new 
versions, minor revisions and patches. These rules seem to be quite solid and 
have withstood this discussion.

However through the discussion we have identified some ways to include these 
changes in a non-breaking way, and that has been very welcome.

As a result I have just uploaded an updated version that includes all the 
proposed non-breaking changes. According to our governance rules, it is 
classified as a minor revision to our existing v1 and it has been republished.

See http://www.openehr.org/ckm/#showArchetype_1013.1.130

We can now consider at leisure whether we want to proceed with the breaking 
changes, although to a large degree these are not of semantic value and I'm 
inclined now to note them but not proceed with a proposed v2 at this point. We 
can do so at any time in the future, if we want.

Kind regards

Heather


From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Heath Frankel
Sent: Thursday, 8 October 2015 10:28 PM
To: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Cc: For openEHR technical discussions <openehr-technical@lists.openehr.org>; 
For openEHR implementation discussions 
<openehr-implement...@lists.openehr.org>; For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org>
Subject: Re: Archetype publication question - implications for implementers

Thanks Ian for explaining the actual proposal.

I can't see why you can't add the dv_text to the location of measurement 
(opening the constraint). Then it just becomes an implementation choice to 
exclude the specific location inline with the new preferred model.

Regards

Heath

On 8 Oct 2015, at 8:26 pm, "Ian McNicoll" 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:
Hi Heath,

I think the suggested change was from

CLUSTER[at1033] occurrences matches {0..1} matches {
-- Location
items cardinality matches {1..*; unordered} matches {
ELEMENT[at0014] occurrences matches {0..1} matches {
-- Location of measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025,
-- Right arm
at0026,
-- Left arm
at0027,
-- Right thigh
.
}
}
}
}
ELEMENT[at1034] occurrences matches {0..1} matches {
-- Specific location
value matches {
DV_TEXT matches {*}
}
}
}
}

to

ELEMENT[at0014] occurrences matches {0..1} matches {
-- Location of measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025,
-- Right arm
at0026,
-- Left arm
at0027,
-- Right thigh
.
}
}
DV_TEXT 
matches {*} -- Specific location
}

which is how we would model it now.

As a side-note, ADL2.0 introduces the capacity to formally deprecate an 
existing node, which will be very helpful in these sort of situations.

I also favour adding the 'deg' unit to the existing Tilt quantity, as I think 
Sebastian suggested, as an alternative (and not making the change above). That 
would allow us to add the critical changes in a non-breaking manner.

Thanks to everyone who has contibuted so far - we still need other implementer 
views!!

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=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 8 October 2015 at 10:23, Heath Frankel 
<heath.fran...@oceaninformatics.com<mailto:heath.fran...@oceaninformatics.com>> 
wrote:
The existing versioning rules allow adding new concepts and opening constraints 
such as allowing additional units. These change the md5 hash but does require a 
version /id change.

This is why Sebastian's suggestion technically works, the existing obsolete 
concept still exists and the new concepts can be added for those that want to 
move to the preferred approach.

However, I am concerned about adding new concepts that are in fact the same as 
an existing just represented differently. This is why I suggested to add new 
units to the existing tilt element (opening the constraint) rather adding a new 
concept for tilt with the new units.

I also suggested adding the new representation for body site as a new concept 
but starting to think this is a bad idea since we are duplicating the concept 
and have two ways in t

RE: Archetype publication question - implications for implementers

[Heather Leslie]

Hi All,

It has been an interesting conversation. Many thanks for everyone’s input.

However, I think we do have a reasonable potential solution.

It was Sebastian’s suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

The other breaking changes suggested are effectively ‘cosmetic’ in some ways – 
ie a more refined way to record the body site for the measurement that is 
congruent with the pattern that has evolved since the archetype was first 
published. And I suggest that we add this as a draft v2 – ie the way of the 
future.

Both archetypes can then be present in CKM – the published v1 and the newly 
proposed draft v2. Yes, there will be two atcodes related to ‘Tilt’ in the v1 
archetype – one for use, one outdated - but implementers who are using this 
data element will be able to make their own decisions on what to do internally; 
those implementations who don’t use the data element will be unaffected. This 
will minimise disruption to existing implementations, allow new vendors to use 
the correct v1 atocode in new implementations and we can then choose to review 
and publish the v2 at the time of our choosing.

Comments?

In principle, I think CKM has to be seen as the ‘source of truth’ wherever 
possible.

I really like this solution proposed by Sebastian as it offers us a way to 
govern that is finer grained than simply: draft vs published; v1 vs v2. We need 
to be mindful of this and use it as a more ‘delicate’ approach to our knowledge 
governance processes.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Mikael Nyström
Sent: Thursday, 8 October 2015 4:27 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>; 
For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Cc: For openEHR implementation discussions 
<openehr-implement...@lists.openehr.org>
Subject: RE: Archetype publication question - implications for implementers

Hi Ian,

I should probably clarify that the versioning mechanism in SNOMED CT is more 
than a technical thing. The versioning mechanism also includes guidelines about 
how to handle the changes in the receiving system. However, the guidelines are 
distributes in a form that is machine (and human) readable and processable, 
which might at a first look seem just to be a technical thing.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 7 oktober 2015 17:22
To: For openEHR clinical discussions
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: Archetype publication question - implications for implementers

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that the 
Norwegian clinical reviewers were being obscure or unreasonable and causing 
problems, or that tilt is not used in some applications. The review team have 
done exactly what we ask of them - to point out issues and errors and the 
'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change in 
the BP archetype is that the unit of measure for the angle of Tilt is defined a 
degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM unit 
which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the 
track, with perhaps hundreds of thousands of BP records, including a small 
proportion with Tilt measurements using the ° unit already captured, it would 
be interesting to consider whether the cost of correcting this issue was felt 
to be worthwhile or whether we could 'live with' using the older version.

@Mikael - the capacity to re-version and version is now quite capably built 
into openEHR (and we learnt quite a bit from SNOMED CT experience with 
namespacing). This is really not a technical question and it is always assumed 
that new archetypes ,new revisions and new versions (breaking) will always be 
required and supported.

The question for us as modellers is whether we should take any account of the 
potential downsides of forking an archetype on implementers in our publication 
process or whether we should at least ask ourselves whether the overall 
benefits outweigh the potential disadvantages.

As I said, I don't think this is unique to openEHR, it will apply to any 
formalism which has constraints or dependencies which over time need to be 
adjusted.

Ian






Dr Ian McNicoll
mobile +44 (0)775 209 

RE: Archetype publication question - implications for implementers

[Diego Boscá]

I'm curious of how this obsolete flag would be supported in a
implementation agnostic view.
How it is different of having several implementation guides for different
MU levels, an epSOS implementation guide (which changed the CDA reference
model itself), or even better, FHIR resources with same id in different
DSTU? The industry will use what the solution requires. In case of
(clinical driven) archetypes, implementation issues should be the less
important part : just create clinicaly correct models and the industry will
use them as needed.
Personally I think the solution of just versioning is far more direct and
less complicated than every other alternative.
El 8/10/2015 1:28, "Heather Leslie" <heather.les...@oceaninformatics.com>
escribió:

> Hi All,
>
>
>
> It has been an interesting conversation. Many thanks for everyone’s input.
>
>
>
> However, I think we do have a reasonable potential solution.
>
>
>
> It was Sebastian’s suggestion about governing at an intra-archetype level
> that has caught my attention - marking an existing data element as
> outdated, and adding a new one as a revision solves the issue of having
> correct vs incorrect units and avoids the necessity of a new version
> immediately. I suggest we make this modification to the existing v1 and
> republish as stable (and technically correct).
>
>
>
> The other breaking changes suggested are effectively ‘cosmetic’ in some
> ways – ie a more refined way to record the body site for the measurement
> that is congruent with the pattern that has evolved since the archetype was
> first published. And I suggest that we add this as a draft v2 – ie the way
> of the future.
>
>
>
> Both archetypes can then be present in CKM – the published v1 and the
> newly proposed draft v2. Yes, there will be two atcodes related to ‘Tilt’
> in the v1 archetype – one for use, one outdated - but implementers who are
> using this data element will be able to make their own decisions on what to
> do internally; those implementations who don’t use the data element will be
> unaffected. This will minimise disruption to existing implementations,
> allow new vendors to use the correct v1 atocode in new implementations and
> we can then choose to review and publish the v2 at the time of our choosing.
>
>
>
> Comments?
>
>
>
> In principle, I think CKM has to be seen as the ‘source of truth’ wherever
> possible.
>
>
>
> I really like this solution proposed by Sebastian as it offers us a way to
> govern that is finer grained than simply: draft vs published; v1 vs v2. We
> need to be mindful of this and use it as a more ‘delicate’ approach to our
> knowledge governance processes.
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> *From:* openEHR-clinical [mailto:
> openehr-clinical-boun...@lists.openehr.org] *On Behalf Of *Mikael Nyström
> *Sent:* Thursday, 8 October 2015 4:27 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>; For openEHR clinical discussions <
> openehr-clini...@lists.openehr.org>
> *Cc:* For openEHR implementation discussions <
> openehr-implement...@lists.openehr.org>
> *Subject:* RE: Archetype publication question - implications for
> implementers
>
>
>
> Hi Ian,
>
>
>
> I should probably clarify that the versioning mechanism in SNOMED CT is
> more than a technical thing. The versioning mechanism also includes
> guidelines about how to handle the changes in the receiving system.
> However, the guidelines are distributes in a form that is machine (and
> human) readable and processable, which might at a first look seem just to
> be a technical thing.
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
>
>
> *From:* openEHR-technical [
> mailto:openehr-technical-boun...@lists.openehr.org
> <openehr-technical-boun...@lists.openehr.org>] *On Behalf Of *Ian McNicoll
> *Sent:* den 7 oktober 2015 17:22
> *To:* For openEHR clinical discussions
> *Cc:* For openEHR technical discussions; For openEHR implementation
> discussions
> *Subject:* Re: Archetype publication question - implications for
> implementers
>
>
>
> Hi Vebjørn,
>
>
>
> I hope I did not give the impression that I was in any way suggesting that
> the Norwegian clinical reviewers were being obscure or unreasonable and
> causing problems, or that tilt is not used in some applications. The review
> team have done exactly what we ask of them - to point out issues and errors
> and the 'iconic' status of BP does not give it any special privileges :).
>
>
>
> Just so that people understand this issue - the potentially breaking
&g

RE: Archetype publication question - implications for implementers

[Heath Frankel]

Hi Heather,
Although I agree with the idea of obsolete concepts, I wonder if it is 
necessary in this case of Tilt. Why can’t we just add the additional units as 
allowed options leaving the existing degrees symbol but in the element 
description indicate that this is obsolete and the correct units should be used 
instead.

The obsolete concept approach could be used for your body site improvement for 
example.

Regards

Heath

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Heather 
Leslie
Sent: Thursday, 8 October 2015 9:54 AM
To: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>; For 
openEHR technical discussions <openehr-technical@lists.openehr.org>
Cc: For openEHR implementation discussions 
<openehr-implement...@lists.openehr.org>
Subject: RE: Archetype publication question - implications for implementers

Hi All,

It has been an interesting conversation. Many thanks for everyone’s input.

However, I think we do have a reasonable potential solution.

It was Sebastian’s suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

The other breaking changes suggested are effectively ‘cosmetic’ in some ways – 
ie a more refined way to record the body site for the measurement that is 
congruent with the pattern that has evolved since the archetype was first 
published. And I suggest that we add this as a draft v2 – ie the way of the 
future.

Both archetypes can then be present in CKM – the published v1 and the newly 
proposed draft v2. Yes, there will be two atcodes related to ‘Tilt’ in the v1 
archetype – one for use, one outdated - but implementers who are using this 
data element will be able to make their own decisions on what to do internally; 
those implementations who don’t use the data element will be unaffected. This 
will minimise disruption to existing implementations, allow new vendors to use 
the correct v1 atocode in new implementations and we can then choose to review 
and publish the v2 at the time of our choosing.

Comments?

In principle, I think CKM has to be seen as the ‘source of truth’ wherever 
possible.

I really like this solution proposed by Sebastian as it offers us a way to 
govern that is finer grained than simply: draft vs published; v1 vs v2. We need 
to be mindful of this and use it as a more ‘delicate’ approach to our knowledge 
governance processes.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Mikael Nyström
Sent: Thursday, 8 October 2015 4:27 AM
To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>;
 For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org<mailto:openehr-clini...@lists.openehr.org>>
Cc: For openEHR implementation discussions 
<openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>>
Subject: RE: Archetype publication question - implications for implementers

Hi Ian,

I should probably clarify that the versioning mechanism in SNOMED CT is more 
than a technical thing. The versioning mechanism also includes guidelines about 
how to handle the changes in the receiving system. However, the guidelines are 
distributes in a form that is machine (and human) readable and processable, 
which might at a first look seem just to be a technical thing.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 7 oktober 2015 17:22
To: For openEHR clinical discussions
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: Archetype publication question - implications for implementers

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that the 
Norwegian clinical reviewers were being obscure or unreasonable and causing 
problems, or that tilt is not used in some applications. The review team have 
done exactly what we ask of them - to point out issues and errors and the 
'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change in 
the BP archetype is that the unit of measure for the angle of Tilt is defined a 
degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM unit 
which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the 
track, with perhaps hundreds of thousands of BP records, incl

SV: Archetype publication question - implications for implementers

[Mikael Nyström]

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=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...@oceanin

Re: Archetype publication question - implications for implementers

[Ian McNicoll]

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that
the Norwegian clinical reviewers were being obscure or unreasonable and
causing problems, or that tilt is not used in some applications. The review
team have done exactly what we ask of them - to point out issues and errors
and the 'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change
in the BP archetype is that the unit of measure for the angle of Tilt is
defined a degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM
unit which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the
track, with perhaps hundreds of thousands of BP records, including a small
proportion with Tilt measurements using the ° unit already captured, it
would be interesting to consider whether the cost of correcting this issue
was felt to be worthwhile or whether we could 'live with' using the older
version.

@Mikael - the capacity to re-version and version is now quite capably built
into openEHR (and we learnt quite a bit from SNOMED CT experience with
namespacing). This is really not a technical question and it is always
assumed that new archetypes ,new revisions and new versions (breaking) will
always be required and supported.

The question for us as modellers is whether we should take any account of
the potential downsides of forking an archetype on implementers in our
publication process or whether we should at least ask ourselves whether the
overall benefits outweigh the potential disadvantages.

As I said, I don't think this is unique to openEHR, it will apply to any
formalism which has constraints or dependencies which over time need to be
adjusted.

Ian






Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 7 October 2015 at 15:12, Vebjørn Arntzen <varnt...@ous-hf.no> wrote:

> Hi
>
>
>
> I've not been involved in the revision of the Norwegian Blood pressure
> archetype, so I do not posess any ownership of the changes proposed. They
> can be looked upon as minor, but still they have arised after a review. I
> know personally several of the reviewers, and can assure they are very
> competent clinicians. In that perspective, I'm not happy about some of the
> comments below. Like "Who's using Tilt anyway" and suggestions of the
> Norwegian community to create obscure problems.
>
>
>
> 1)  Using Tilt: Oslo university hospital is close to implement DIPS
> Arena with the BP archetype. Fairly soon there will be departements that
> will use Tilt. If Tilt was an element not necessary, why is it there in the
> first place? It might not be important for most users, but I have a
> remembrance of Maximum Data Sets.
>
> 2)  Obscure problems: Why should not the correct unit be available to
> the users?
>
> 3)  Blood pressure as a iconic flag ship: Wouldn't it be great to
> show the world that openEHR is able to update even the "dear baby
> archetype" when it is needed? Even our dearest babies grow up.
>
>
>
> Outside our small community, there are a great skepticism towards how
> openEHR will solve versioning of archetypes. It's important that we will
> not be ruled by impractical thoughts like "not invented here", and "doesn't
> matter for the major part of us".
>
>
>
>
>
> Regards
>
> Vebjørn Arntzen
>
> Enterprise architect, ICT-dept, Oslo universitetssykehus HF
>
> Tlf +47 4143 7589
>
>
>
>
> -
>
> Advarsel: Hvert sekund du lever forkorter livet tilsvarende.
>
> Warning: Every second you live, shortens your life equivalently.
>
>
>
> *Fra:* openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org]
> *På vegne av* Jussara macedo
> *Sendt:* 7. oktober 2015 14:43
> *Til:* For openEHR clinical discussions
> *Kopi:* For openEHR technical discussions; For openEHR implementation
> discussions
> *Emne:* Re: Archetype publication question - implications for implementers
>
>
>
> Dear all,
>
> I agree with Ian that any change at international level  should be market
> driven. From an experience of someone who works with standardization for
> years and who  already led the adoption of  standards in Brazil's extensive
> market, it is worth remembering that standards must reflect a consensus
> among the various stakeholders. Not always the final agreement reflects the
&g

RE: Archetype publication question - implications for implementers

[Mikael Nyström]

Hi Ian,

I should probably clarify that the versioning mechanism in SNOMED CT is more 
than a technical thing. The versioning mechanism also includes guidelines about 
how to handle the changes in the receiving system. However, the guidelines are 
distributes in a form that is machine (and human) readable and processable, 
which might at a first look seem just to be a technical thing.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 7 oktober 2015 17:22
To: For openEHR clinical discussions
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: Archetype publication question - implications for implementers

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that the 
Norwegian clinical reviewers were being obscure or unreasonable and causing 
problems, or that tilt is not used in some applications. The review team have 
done exactly what we ask of them - to point out issues and errors and the 
'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change in 
the BP archetype is that the unit of measure for the angle of Tilt is defined a 
degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM unit 
which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the 
track, with perhaps hundreds of thousands of BP records, including a small 
proportion with Tilt measurements using the ° unit already captured, it would 
be interesting to consider whether the cost of correcting this issue was felt 
to be worthwhile or whether we could 'live with' using the older version.

@Mikael - the capacity to re-version and version is now quite capably built 
into openEHR (and we learnt quite a bit from SNOMED CT experience with 
namespacing). This is really not a technical question and it is always assumed 
that new archetypes ,new revisions and new versions (breaking) will always be 
required and supported.

The question for us as modellers is whether we should take any account of the 
potential downsides of forking an archetype on implementers in our publication 
process or whether we should at least ask ourselves whether the overall 
benefits outweigh the potential disadvantages.

As I said, I don't think this is unique to openEHR, it will apply to any 
formalism which has constraints or dependencies which over time need to be 
adjusted.

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=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 7 October 2015 at 15:12, Vebjørn Arntzen 
<varnt...@ous-hf.no<mailto:varnt...@ous-hf.no>> wrote:
Hi

I've not been involved in the revision of the Norwegian Blood pressure 
archetype, so I do not posess any ownership of the changes proposed. They can 
be looked upon as minor, but still they have arised after a review. I know 
personally several of the reviewers, and can assure they are very competent 
clinicians. In that perspective, I'm not happy about some of the comments 
below. Like "Who's using Tilt anyway" and suggestions of the Norwegian 
community to create obscure problems.


1)  Using Tilt: Oslo university hospital is close to implement DIPS Arena 
with the BP archetype. Fairly soon there will be departements that will use 
Tilt. If Tilt was an element not necessary, why is it there in the first place? 
It might not be important for most users, but I have a remembrance of Maximum 
Data Sets.

2)  Obscure problems: Why should not the correct unit be available to the 
users?

3)  Blood pressure as a iconic flag ship: Wouldn't it be great to show the 
world that openEHR is able to update even the "dear baby archetype" when it is 
needed? Even our dearest babies grow up.

Outside our small community, there are a great skepticism towards how openEHR 
will solve versioning of archetypes. It's important that we will not be ruled 
by impractical thoughts like "not invented here", and "doesn't matter for the 
major part of us".


Regards
Vebjørn Arntzen
Enterprise architect, ICT-dept, Oslo universitetssykehus HF
Tlf +47 4143 7589

-
Advarsel: Hvert sekund du lever forkorter livet tilsvarende.
Warning: Every second you live, shortens your life equivalently.

Fra: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org<mailt

Re: Archetype publication question - implications for implementers

[Diego Boscá]

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

Re: Archetype publication question - implications for implementers

[David Moner]

Hello,

If the archetype introduces incompatible changes with the existing version,
then no discussion it is possible: a new v2 has to be published after the
proper review rounds. Then the question is what happens to v1. Being
purist, v1 should be marked as obsolete (still usable at your own risk) and
v2 be the recommended one for new implementations. It is the simpler and
safest way to act in order to maintain a controlled repository of
archetypes. If implementers have adopted an archetype methodology, they
they have to accept that changes to archetypes will happen.

It is also true that many software projects maintain several branches of
development simultaneously (i.e Tomcat 6, 7 and 8). Is this also applicable
to archetypes? Can we maintain v1 and v2 both as published archetypes?
Certainly we agree on defining such rules of governance. But we should ask
ourselves some questions: Are both versions just alternative
representations of the same clinical model? Should the community prioritize
one over the other? Or maybe they are representing different models that
should be named differently to avoid confusions? Or maybe v1 can become
just a kind of template of v2?

The answer to these questions will depend on each use case, but the
important thing is that we act consistently in all cases.

David


2015-10-02 6:11 GMT+02:00 Heather Leslie <
heather.les...@oceaninformatics.com>:

> 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 

Re: Archetype publication question - implications for implementers

[Sebastian Garde]

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

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