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:openehr-technical-boun...@lists.openehr.org] On Behalf Of Eric Browne Sent: Wednesday, May 18, 2016 2:03 PM To: For openEHR technical discussions <openehr-technical@lists.openehr.org> 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 eric.bro...@montagesystems.com.au ph 0414 925 845 skype: eric_browne > On 18 May 2016, at 8:35 pm, Thomas Beale <thomas.be...@openehr.org> 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 > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org