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