Dear All,
it seems the UCUM code for the temperature units in the Body temperature archetype is wrong. It uses the UCUM print symbol, e.g. “°C”, rather than the UCUM code “Cel”.
http://www.openehr.org/ckm/#showArchetype_1013.1.49
Regards,
Daniel
Hi Daniel,
You’re 100% correct. This error is corrected in the branch I uploaded after the Norwegian body temp archetype was published, but this hasn’t been taken into the trunk yet as it contains some other major changes.
As a general observation, an issue with using UCUM units in archetype (which is to my mind the only way to go), is that there’s as far as I know no way to include both the code and the print symbol in the archetype. This imposes a larger implementation burden on the systems who will have to be able to read UCUM codes and show the corresponding symbol instead of the code, which in many cases is not readable to clinicians.
Kind regards,
Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: @arketyper_no
So, right now the DV_QUANTITY.units is a String, perhaps it should be DV_CODED_TEXT?
/Daniel
That’s overkill - just have two fields, human and computable units.
Grahame
In DV_CODED_TEXT there are three mandatory attributes: DV_TEXT.value, DV_CODE_PHRASE.terminology_id, DV_CODE_PHRASE.code_string, i.e. 50 % overkill only 
/Daniel
Hi Daniel,
This is being discussed by the Specs group as part of a different CR around use of ‘dose units’ but would mean a breaking change, so is tricky.
https://openehr.atlassian.net/browse/SPECPR-96
Ian
Hi Grahame,
For the use case raised, I agree, but there other considerations e.g. Dose units and other non-UCUM code use - in the UK there is a desire to use SNOMED terms for dose units.
FHIR has human + code + system for quantity units, I think?
Ian
One option might be simply to do a per FHIR and ‘hardwire’ code + code system, alongside units. This would retain backward compatibility. It would prevent us using DV_TEXT features like mapping but in many respects that might not be a bad thing.
Ian
Yes you’re right. We need to allow snomed units there etc. but we use quantity for more than openehr does, so I thought you might be able to just have ucum. So you might as well copy FHIR then
Grahame
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
It’s not out of the question, although my view was always that the units string should be parsed and then rendered using one of the other columns of UCUM, or even something else. But this does as Silje says, put more work on to implementers, so we probably should consider a CR on the RM to add another field to carry the rendered form.
- thomas
Hi Ian
As far as I know, ‘dose units’ are not scientific units as such; they’re measures of discrete objects (including ‘puffs’ etc), which don’t fit into a clean grammar of scientific units, and trying to do so will just ruin the former.
We do of course need dose units, but we need a better way of modelling them - my view is that they should not be treated as if they were ‘units’ in the usual sense.
The relevant SNOMED codes seem to be these ‘unit of product usage’ codes, which is the correct kind of description.
What is the current problem/issue with modelling ‘dose units’ in archetypes in fact? It looks to me like the current modelling approach (similar to FHIR) represents these elements in a reasonable way.
- thomas
The main problem is that ucum units are not human readable units, and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA.
Hi thomas,
See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on this. Medication dose and quantities need both SI units and otherwise. The current restrictions make the modelling much clunkier than is necessary IMO. I’m not clear why strict adherence to SI is helpful in this context. Surely part of the point of a health orientated ref model is to make life easier and medication dose units are a critical type of quantity in this domain.
Ian
The main problem is that ucum units are not human readable units,
right - my idea 13 years ago was to use the UCUM string as a key into something that generated a human-readable form. For reasons that became clearer since, I think we all agree that we need to embed not just the formal form, but the human-readable form as well. So that’s a fairly anodyne design problem for the Quantity type in everyone’s type system. I think we can solve that in a reasonable way in openEHR.
and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA.
A secondary problem is discrete units like tablet, capsule etc which have no computable form in ucum
I suspect this is the main problem for some people at least these days. Scientifically speaking, anything like ‘tablet’, ‘capsule’, ‘drop’ etc isn’t a ‘unit’ in the science/physics sense; but in English (and most other languages I suspect) we use the same word in a non-science sense to mean ‘discrete amount of anything’, e.g. unit shares, 5mg tablet is the unit of dosing, and so on. This makes people think the problem can be solved within the model / language of scientific units. It can’t in any clean way.
So dose ‘units’ need to be understood as something different from scientific units, and modelled in a different way. They are units of discretisation or quantisation of material, not units of physical properties.
- thomas
And we probably want that the human-readable form can be multilingual as well.
Really? No one has ever brought that to us as an requirement
Grahame
The arbitrary units are something different, but why does that matter at the data type level? If you understand the unit, you can work with it, if you don’t you can’t. Separating them because of … Ontological … Purity: just creates make -work for all the users who otherwise don’t differentiate them
Grahame
If you have a human-readable form for 'º' as "degree" you probably
want that non-english speaking countries can put "grado"
I was reviewing that (good statement of needs). The issue isn't SI units - there are lots of non-SI units in UCUM. The issue is that units of doses are not scientific units, and can't be represented the same way. So we shouldn't expect our models of the latter to work properly for dose units.
Of course I agree that we should make life easier for developers, systems etc, and also that we have not really done so.
The more I think about this issue over the years, I mostly come to the same conclusion: we need a special Quantity type that models exactly what is needed. E.g. something like
class DoseQuantity
unitForm: DvCodedText // type of physical dose entity tablet, capsule, puff etc
unitAmount: DvQuantity // how much is in a `doseForm` unit e.g. 5mg
doseCount: Integer // how many items of `doseForm` to deliver
doseAmount: DvQuantity { // total amount of substance delivered to patient
Result := doseCount * unitAmount
}
end
Note that this does not include the actual substance, e.g. morphine or whatever.
- thomas