Von: openEHR-technical [mailto:[email protected]] Im
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 17:34
An: [email protected]
Betreff: Re: AW: Quantities of arbitrary units in openEHR
On 25/01/2018 16:28, Bert Verhees wrote:
On 25-01-18 11:03, Sebastian Garde wrote:
Hi Silje,
I think this may 'just' be a modelling tooling issue, openEHR itself supports
this ok.
Speaking for CKM, if you upload an archetype with this to CKM, it should
validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb'u]{whatever} or similar is (very slightly) incorrect in my
understanding:
1. Use the completely vertical ' not ' or similar (at least that is my
understanding).
2. openEHR uses (implicitly I think, but it may be hidden somewhere in the
spec), the case-sensitive version of UCUM - therefore the U needs to be upper
case, see e.g. http://unitsofmeasure.org/ucum.html#para-45
As far as I know, Sebastian, OpenEhr does not use UCUM
it certainly specifies
it<https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class>.
If there are tools and implementations that don't respect this, they are
non-compliant and will get found out ;)
[SG] The first reference
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class
is more an "inspiration": "Units were inspired by the Unified Code for Units
of Measure (UCUM)<http://unitsofmeasure.org/ucum.html>, developed by Gunther
Schadow and Clement J. McDonald of The Regenstrief Institute."
The 2nd reference is clearer: "Stringified units, expressed in UCUM unit
syntax, e.g. "kg/m2", "mm[Hg]", "ms-1", "km/h"."
This is where I think that not only it is stated that openEHR uses UCUM (and
not some part or "inspiration" of it), but also implies that the case sensitive
version of it is used (which in my view is important to know at least for some
of the units). I still think it would be good to explicitly say that the
case-sensitive version is used?
The unit strings in the terminology are to help archetype tooling, but I would
say that all tools and systems in the future should be using a 'UCUM service'
that does not yet exist, but knows about all unit strings, properties and so
on. This is something we could easily specify and implement, if there is not
already one in existence.
[SG] Agree - such a UCUM service may also be able to give a print version,
e.g. °C instead of CEL or °F instead of [degF]
Sebastian
The unit strings in the terminology are to help archetype tooling, but I would
say that all tools and systems in the future should be using a 'UCUM service'
that does not yet exist, but knows about all unit strings, properties and so
on. This is something we could easily specify and implement, if there is not
already one in existence.
but it uses many unit-strings which also are defined in UCUM, but has these
strings for OpenEhr-use listed in an own terminology-list. This list needs to
be maintained separately by the OpenEHR community. There is no validation
defined directly to the UCUM-services. If it would, not only use the
stringified units of UCUM, but also would incorporate UCUM-defined
functionality, it would also have, for example, conversion routines from UCUM,
which are usable for software defined in the UCUM essence-file.
right, that's the sort of thing we need. I have not researched this for a few
years, so if anyone knows of a service and/or service definition / API we can
use and standardise on, please post some information.
- thomas
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture
blog<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
