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
<https://openehr.atlassian.net/issues/?jql=project%20%3D%20SPECPR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC>,
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
system in a metric country or “deg” for values in “°F” in a system in
the US. In many systems the units are often implicit and not stored
with each value.
* In Australia, *diagnostic testing laboratories almost all send test
result reports in HL7 v2 messages*. Many of these use atomic fields
for each observation. HL7 v2 uses an explicit field for transmitting a
unit description. The Australian Standards specify ISO+ values to be
used to name these units in messages. ....
* Both of the above shortcomings lead to implementers wanting
archetypes with little or no unit constraint on many fields. More
often than not this is a *result of lack of compliance infrastructure*.
* In the real world of extensive data sharing, highest common
denominator ( or often *lowest common denominator ) trumps standards
and quality, and even safety*.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
