UCUM code in body temperature archetype

Technical (archive)
21

Dear All,

There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat DO NOT use valid UCUM codes for units in various DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have some ‘invalid' UCUM unit.

I spent some time trying to explain the reason for, and ramifications arising from this issue in a previous post. That post arose from Heather Leslie’s concerns about potential major changes to the coveted blood pressure archetype - see https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09185.html.

In that post I stated "Even basic archetypes like Body Temperature define units which are not UCUM-conformant. I consider this to be a more serious issue than the tilt angle of a person whose blood pressure is being recorded."

At that time Thomas suggested I raise a Problem Report, but so far I have failed to do so.

There are also the related PRs:

https://openehr.atlassian.net/browse/SPECPR-13
https://openehr.atlassian.net/browse/SPECPR-96

regards,
eric

Eric Browne
eric.browne@montagesystems.com.au
ph 0414 925 845
skype: eric_browne

22

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.browne@montagesystems.com.au
ph 0414 925 845
skype: eric_browne

23

I knew someone would say that;-) But it’s not for some principle of ontological purity. It’s for the most basic practical reasons. Consider a quantity / units library designed based on a rigorous model of units, like UCUM (which is a very good and rigorous piece of work), and also other basic principles in science e.g.

  1. there are only 9 primitive physical properties;
  2. all other physical properties can be obtained by combining the 9 primitive ones, e.g. pressure = mass/area; area = length^2;
  3. various mathematical properties hold for true amounts (these can be described formally)
  4. etc

These things don’t hold for ‘dose units’, because they are not the same kind of thing. They can’t be modelled or computed in the same way.

So there are two choices:

  • hack a clean model / library of scientific units to force it to deal with non-units; these creates dirty code and bugs, and lots of if/then exception conditions
  • write a new clean model of the new kind of units, and integrate it with the basic scientific units model.

I am only interested in one thing here: clarity for coders and data, which translates to error-reduction, better quality data and more maintainable code in the long run.

The final result may not be particularly differentiated on the screen, or even consciously understood by end users, but they are miles away from the models and code inside the systems we build.

  • thomas
24

very interesting, seems like a few archetypes need to be changed

25

That's the "o" in "numero", as in Nº, not degree (which is °).

  https://en.wikipedia.org/wiki/Numero_sign

Karsten

26

You are right, but not my main point :wink:

27

When we register a coded value, we store the terminology and the code. The display or rubric of it can be used for example to communicate data to a system that may not have access to the complete terminology, so that a human user can understand it. This behavior should not be different for units. We should not store the readable form of the unit everywhere.

Apart from that, I think that trying to avoid unscientific units should be, as far as possible, a requirement the modeling activities. FYI:

Spoons lead to inaccurate medicine doses for kids (http://www.nhs.uk/news/2014/07July/Pages/Spoons-lead-to-inaccurate-medicine-doses-for-kids.aspx)

28

Yes, unfortunately. I have even implemented a Validation Check named VUI for this in CKM after these discussion, so that this is not forgotten, because I too think it is important to get this right...
This check is available for each archetype (or for all archetypes from Reports/Validation Report when logged in).
I think the validation errors are usually fixed when the archetype is updated the next time.

Regards
Sebastian

29

You are right, but not my main point :wink:

Actually, it sort of is. It shows that the same symbol can
mean different things to different people :slight_smile:

Karsten

30

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

31

They usually are, though the units file in the Archetype Editor has had (still has?) a lot of errors in it, which means the correct units had to be edited into the ADL by hand. I made a better version of the units file for the AE a while ago, but there were some issues with it that I'm not sure if have been solved or if it's made its way into a release.

Regards,
Silje

32

I believe that anything between brackets can be considered a correct UCUM

33

Eric,

One thing I had better do is re-instate my UCUM string checker in the ADL Workbench...

thanks for the timely warning.

- thomas

34

Hi Silje,

Yes, it was at the end of October that I was trying to get it to work. A DataGrid in AE was throwing exceptions, complaining about duplicates because the property_id and text fields have to form a unique key. I did manage to find and remove one pair of duplicates from the file that you provided but even after that it was still complaining. I never got to the bottom of what was causing it.

Looking at GitHub, nothing resembling your corrections appears to have made it there yet:

  https://github.com/openEHR/arch_ed-dotnet/commits/master/ArchetypeEditor/PropertyUnits

I would suggest that the best way to proceed would be to add the fixes again, but proceed slowly, testing your file in AE after every few changes. Keep a backup copy after each successful test. Then, if AE complains about a small set of changes, it will be easy to identify what has caused it.

Peter

35

Unfortunately Silje, not quite correct. The eye deceiveth.

The construct [H20] is not valid UCUM. In none of the CKM archetypes did I find the correct UCUM code [H2O]. A zero has been substituted for the letter ‘O’.
An easy mistake for a human to make. H20 even mistakenly appears 4 times in Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.

The same is likely to occur in the case of Litre, with ‘l’ (lowercase L) vs ‘1’ (numeral one) vs ‘I’ (capital letter eye), depending on typefaces used. That’s why many health safety organisations favour ‘L’ for Litre over the lowercase variant. UCUM unfortunately allows either as case sensitive variants ( which strictly means that this particular unit is not case sensitive in the case sensitive case) :frowning:

Also, despite ‘U’ being a valid UCUM unit, it is probably incorrectly used in the CKM archetypes. The correct UCUM unit code for international unit should be “[iU]” or “[IU]” - another case of case variants for supposedly case-sensitive units. ‘U’ is the UCUM code for catalytic activity. Same applies for ‘U/l’, which may be valid UCUM syntactically, but unlikely to be correct semantically in the liver function test archetype.

Also mmho is correct UCUM. A mho is a unit of electrical conductance ( It comes from Ohm, the unit for resistance, spelt backwards. Ohm starts with a capital letter since named after a human, whereas mho does not). mho as been deprecated as an SI unit and renamed to siemens, but is retained and valid in UCUM. mmho was found in openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl

regards,
eric

36

Hah, thanks for that correction, I completely missed the ‘0’ instead of ‘O’ and the ‘mho’. J

‘U’ is certainly wrong if used for international units, as you say, but for the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring catalytic activity, so U/L should be correct. Not sure where ‘U’ by itself is used.

Regards,
Silje

37

Hi Silje,

‘U’ is used in the lab_test-blood_glucose archetype.

I also think that 10*12/l, 10*6/l, 10*6/mm3, 10*9/l are all valid UCUM codes. In fact UCUM’s table 26 Example Unit Terms by Term lists 10*6/mm3 as legal with a preferred alternative of /pL . It also lists the following alternatives:-

10*3/L = /mL
10*6/L = /uL
10*9/L = /nL

with all 6 codes being valid.

regards,
eric

38

Ah yes, that's definitely not right. There are actually two blood glucose archetypes, and the other one has 'IU' (which should be [iU]).

Probably all of the current OBSERVATION.lab_test* and OBSERVATION.pathology_test* archetypes should be deprecated and (some of them) redone as either cluster extensions or specialisations of the newer OBSERVATION.laboratory_test archetype.

I think it would be very useful if you would be willing to proof read my Archetype Editor units file if we can ever get it into a form that the AE will accept. :slight_smile:

Regards,
Silje

39

Hi Peter,

I think I did manage to identify and fix that particular problem locally but was stumped by this wider issue of whether how/if we display code / human version or both.

https://openehr.atlassian.net/browse/AEPR-44?focusedCommentId=14127&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14127

Ian

40

Hi