We, as well as most of the healthcare standardisation world, are heavily dependent on UCUM to be able to express units of measure in a machine readable way. I think most people would agree this is the best way to go, and that of the available alternatives for this purpose UCUM is the best available. It’s really good for most of the units we use every day.
However, I’ve recently had to look into how to represent some pretty obscure units which weren’t really part of UCUM at all, and I found the UCUM github org/repo: ucum-org/ucum
Now, I know we as the openEHR community have some issues with our backlogs of proposals and change requests both for the specs and clinical models, but UCUM has unresolved issues which originally were submitted in 2008(!).
So, does anyone know how UCUM is being governed? Is it actually resourced? Does this open up the openEHR community and other healthcare standards orgs for risks which we have no way of influencing?
Main problem UCUM has is also their strength: you can derive units from valid units and be valid (and also create your own as long as you follow the syntax). So in the long run I don’t think we can manage to maintain an UCUM workable copy ourselves (which is basically what we are doing with all PRs) and just accept that UCUM is not really a vocabulary in the end. I would personally remove the limitations of only being able to include"valid UCUM codes" across all tooling, as no such thing really exists. To put it in modern openEHR terminology, current list could be keep as informative, but not as required ;D
Oh, I certainly agree we shouldn’t be keeping an authoritative list of the allowed UCUM codes. For historical reasons we are, but to my mind ideally we should only be using UCUM as a set of rules in modelling software.
What I’m worried about though is when the UCUM doesn’t have a particular base unit at all. Do we then create our own using UCUM’s rules? And everyone else are doing the same? Do we then end up with extension madness where nobody can understand each other?
It is really messy in the end, but as long you are creating your units from already existing blocks it should be fine. Another thing worth mentioning is that UCUM is case sensitive, but most systems really don’t care.
In general I think we are doing an incredible work in the archetypes just by the fact of selecting which units are allowed in a given observation. This is openEHR becoming again the de facto source of truth in healthcare
(that being said, in the OMOP mapping effort I’ve found some UCUM units in the openEHR archetypes that can be improved, and I’m pretty sure the error is in the ucum xml file)
It sounds like it. I think @siljelb is correct in saying that the problem she is pointing at is not addressed yet, at least not that I can see
There is a missing base unit in UCUM she needs. Now what? Without an agreed addition to UCUM, we’d end up breaking interop. As she asks: do we take it to UCUM? Issues remaining from 2008 do not sound promising, though I’m well aware I’m writing this from a glass house…
I cannot help suggest an openEHR managed extension to base units when necessary, but I have no clue what that would map to in our specs conceptually. I played with the archetype designer and it says “current units are from ucum” or something in those lines when selecting units, and it actually attempts to use 122 (from openehr support terminology) as the term mapping code for property when all units are for expressing length. Then I added kilogram and the openehr terminology reference were removed, correctly.
So that’s the basis of my suggestion to consider introducing some small (famous last adjectives) terminology to indicate “these units come from UCUM with an extended base”. Would that work @siljelb ?
Now that my duties as a bull in the china shop are complete, I can go get some tea.
What base unit is missing? Likely it’s not a physical unit at all… it’s pretty thorough.
On the subject of governance, Regenstrief still maintains UCUM, but changes are extremely slow for a variety of reasons.
accept that UCUM is not really a vocabulary in the end. I would personally remove the limitations of only being able to include"valid UCUM codes" across all tooling, as no such thing really exists
It is a vocabulary, just one with a grammar. And you shouldn’t be able to break the UCUM rules - it should have to be valid always. But there are things that are customarily called ‘units’ that are out of scope for UCUM: arbitrary ones like ‘tablets’ or ‘dollars’, so you need to have a way to allow other kinds of units
I guess there will always be questions about what is a ‘core unit’, or otherwise, in UCUM, but there should IMO be some authoritative and quick response from whoever makes those decisions so that the change can be accepted or quickly rejected.
My question above is whether this is something for the JIC group to consider, and perhaps help jointly resource if that would help.
I see little benefit in openEHR/ FHIR or anyone else navigating this world alone. UCUM is a key international standardisation resource. I’m certainly not suggesting that Regenstrief cede control, but if they need help to manage demand for new units, I think that should be offered.
The openEHR quantity datatype does allow dor alternative code systems, so this is not a practical blocker but we do need an authoritative view, so that any workarounds are done for good reason i.e out of scope of core UCUM.
I think it’s a good idea to raise it through JIC. Because I agree a timely response is appropriate, and it’s not timely now. You’ll not that one of the outstanding tasks is a request from me to add currencies to UCUM, since we very often find composite units with currencies in them
Thanks. And important to frame that not as criticism, but as ‘can we help’. All of us appreciate the extent to which most standardization effort has historically been badly resourced, and left to keen volunteers.
You’re right, not a physical unit per se. In audiology, loads of different variations of dB are used. The main one is the “normal” dB[SPL] (sound pressure level) which is in UCUM, but none of the variations are. I’ve added the full set (that I know of) to a github request originally from 2018 asking for some of them.
In the last couple of years we’ve slowly built on the list of base and pre-coordinated units that was originally created for Archetype Designer back in the day, but which has been governed as part of the openEHR TERM specification for a while. Some of these are perfectly fine, but I’m increasingly uncomfortable about using curly brackets as a modifier to be able to move forward with required unit representations (have a look at the end of the file to see what I mean).
Then there’s the question of whether we should be maintaining this sort of list at all. To my mind there’s not much choice atm, as we don’t have tools that allow rules-based post-coordination of units. I don’t think the average Archetype Designer user can be expected to come up with for example {mitoses}/795.10-2.mm2 on their own.
FWIW our oldest open issues are from 2015 (CKM change request) and 2009 (SPEC problem report). I suspect this may be when the CKM got the change request functionality, and when Jira was adopted by the SEC.
I’m not sure of the full extent. But something which allowed a modeller without extensive UCUM experience to generate uV2/Hz from µV²/Hz using only the prefixes, base units and syntax, would be a good start. The logic of UCUM is fairly intuitive at this level, even if the syntax isn’t.
Then, getting to {mitoses}/1185.10-2.mm2 from putting in mitoses/11.85 mm² would be the next level. At this level, nothing about UCUM is intuitive and the user would need a lot more help.
PS! I suspect a lof of the units currently not covered will be arbitrary, and a more robust way of handling them would be very useful.
(just generally to the thread) I don’t there’s not much satisfaction with the governance of UCUM in the terminology and modelling specialists in NHS England, but while the need to do something about it is widely recognised, I’m not holding my breath about something actually happening in the short/medium term - we have too much stuff to do and too few people to do it.
And if we did, the best we could do is create a lightweight layer of governance to put proper foundations under existing content - if stuff isn’t going in that needs to, its pretty difficult to fix that without forking the terminology.
I was in another life a physical scientist with interest in metrology, so UoM is a bit of a hobby horse of mine. I’ve helped sort out bits of ISO/IEC 11179-3 so it is on a firm conceptual footing and can manage a suitable (externally defined) units of measure ontology. If we have some experts who are willing to put in the effort, we might be able to foster something at JTC1/SC32 for representation of SI and derived units, which could then be extended to health care by ISO/TC215. But you don’t look to ISO for rapid governance!! I also note something like this seems to have been tried before with ISO 80000:2009 and that was withdrawn.
A thing that immediately strikes me is even if you’ve sorted out the core compositional bit, you have a fundamental issue with counts - how do you fix the terminology for the things you’re counting? Snomed CT isn’t open so you wouldn’t want to base it on that …
Happy to help think this through in more detail if there are other like-minded obsessives.
