Awesome! These can be classified into UCUM, non-UCUM and just plain wrong:
UCUM:
1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg,
kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, ml/d, ml/ml, ml/s,
ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmol/l, pg, pmol/l, s,
Non-UCUM:
/d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, , IU,
cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp), °, °C,
°F, µmol/
Just plain wrong:
gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this comes
from?)
Not 100% sure:
{Volume/Volume}
So quite a few units in archetypes are actually UCUM-compatible, but there are
plenty which aren't, and some which are wrong and can be badly misinterpreted.
Oh, and UCUM does allow non-units to be represented using curly braces, like
{puff} or {tablet} as symbols for the default unit '1'.
Regards,
Silje
-----Original Message-----
From: openEHR-technical [mailto:[email protected]] On
Behalf Of Eric Browne
Sent: Wednesday, May 18, 2016 2:03 PM
To: For openEHR technical discussions <[email protected]>
Subject: Re: UCUM code in body temperature archetype
I just did a bulk download of 133 Observation archetypes from ckm.openehr.org
and extracted the following list of units:-
/d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units,
Hz, Hz/s, IU, U, U/l, [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl,
fl oz, ft, gm, gm/d, gm/l, gm/wk, h, in, in2, kHz, kPa, kg, kg/m2, l, l/min,
l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, mg/dl, mg/l, millisec, min, ml, ml/d,
ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmho, mmol/l,
oz(avdp), pg, pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/
I did this with a script and have not manually validated this list visually in
the ADL.
regards,
eric
Eric Browne
[email protected]
ph 0414 925 845
skype: eric_browne
> On 18 May 2016, at 8:35 pm, Thomas Beale <[email protected]> wrote:
>
> Hi Daniel,
> the reason it is a String is because we have always treated UCUM units as
> parseable strings. E.g.
> kg.m^-2
>
> and
>
> kg/m^2
> are parseable according to UCUM's grammar into an expression that has a
> single meaning, and can also be equated to e.g. 'kPa' (which is itself
> parseable and so on).
> - thomas
> On 18/05/2016 10:05, Daniel Karlsson wrote:
>> So, right now the DV_QUANTITY.units is a String, perhaps it should be
>> DV_CODED_TEXT?
>>
>> /Daniel
>
> _______________________________________________
> openEHR-technical mailing list
> [email protected]
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
