Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im Auftrag von Thomas Beale Gesendet: Donnerstag, 25. Januar 2018 17:34 An: openehr-technical@lists.openehr.org 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 openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org