# UCUM dependence - governance? **Category:** [General Discussion](https://discourse.openehr.org/c/general-discussion/132) **Created:** 2025-01-10 14:15 UTC **Views:** 265 **Replies:** 40 **URL:** https://discourse.openehr.org/t/ucum-dependence-governance/6153 --- ## Post #1 by @siljelb Hi all! 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](https://github.com/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? --- ## Post #2 by @yampeku 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 --- ## Post #3 by @siljelb 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? --- ## Post #4 by @yampeku 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 :smiley: (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) --- ## Post #5 by @siljelb I'm not sure I'm explaining myself well enough, but the problem is when the required base units (or blocks) don't exist in UCUM. --- ## Post #6 by @siljelb [quote="yampeku, post:4, topic:6153"] (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) [/quote] Would be great if you reported them! :smile: --- ## Post #7 by @ian.mcnicoll Is this something we might raise as part of the JIC engagement and the FHIR community - it's a universal issue? --- ## Post #8 by @yampeku [quote="siljelb, post:6, topic:6153"] Would be great if you reported them! :smile: [/quote] have to think a way of not spamming everyone when creating all the needed archetype CRs. In any case, they are mostly related to new bindings --- ## Post #9 by @yampeku [quote="siljelb, post:5, topic:6153, full:true"] I’m not sure I’m explaining myself well enough, but the problem is when the required base units (or blocks) don’t exist in UCUM. [/quote] This does happen, when you enter brackets territory (e.g. {tablets}) modeller guess is as good as anyone --- ## Post #10 by @Seref 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. --- ## Post #11 by @grahamegrieve 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 --- ## Post #12 by @ian.mcnicoll Thanks Grahame, 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. --- ## Post #13 by @grahamegrieve 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 --- ## Post #14 by @ian.mcnicoll 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. --- ## Post #15 by @ian.mcnicoll and even if your currency request is rejected, at least you know that an alternative is required. Perhaps that inevitably means a secondary need to govern UCUM extended units for healthcare needs. --- ## Post #16 by @siljelb [quote="grahamegrieve, post:11, topic:6153"] What base unit is missing? Likely it’s not a physical unit at all… it’s pretty thorough. [/quote] 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](https://github.com/ucum-org/ucum/issues/152#issuecomment-2582842017) 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](https://github.com/openEHR/specifications-TERM/blob/master/computable/XML/PropertyUnitData.xml) 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. PS! To be able to progress the audiology modelling, I've created a set of ... labels? ... on the base `dB[SPL]` unit and [submitted them to the openEHR units file](https://github.com/openEHR/specifications-TERM/pull/20). --- ## Post #17 by @siljelb [quote="Seref, post:10, topic:6153"] Issues remaining from 2008 do not sound promising, though I’m well aware I’m writing this from a glass house… [/quote] FWIW our oldest open issues are from [2015 (CKM change request)](https://ckm.openehr.org/ckm/archetypes/1013.1.121/changerequests/1013.36.4) and [2009 (SPEC problem report)](https://openehr.atlassian.net/browse/SPECPR-8). I suspect this may be when the CKM got the change request functionality, and when Jira was adopted by the SEC. --- ## Post #18 by @grahamegrieve > I’m increasingly uncomfortable about using curly brackets as a modifier to be able to move forward with required unit representations yes, that technique doesn't go that far > To my mind there’s not much choice atm, as we don’t have tools that allow rules-based post-coordination of units what tools do you need? There's open source UCUM code for lots of platforms (I wrote some of them) --- ## Post #19 by @siljelb [quote="grahamegrieve, post:18, topic:6153"] what tools do you need? [/quote] 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. --- ## Post #20 by @SteveHarris (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. --- ## Post #21 by @ian.mcnicoll Thanks Steve, I'd hesitate to come up with something to replace UCUm, for good or bad it is well established and does a pretty good job. It has a 'no-derivative' licence but is otherwise liberal, though I'd prefer a standard OSS licence to be applied e.g. CC-BY-ND. In any case the real issue seems to be with the extensible part of UCUM, not the core unit,s so perhaps the work can be framed as not trying to disturb core UCUM but in acting as a clearing house for new unit requests - a very small number perhaps being passed through to Regenstrief, others being managed as an explicit extension for those requests which are deemedot be suitable for the UCUM approach, or being rejected in favour of e,g. a different terminology. A good example might be to encourage use of SNOMEd to capture medication forms like tablet, as long as we can persuade SNOMED to release these as free sets. Whatever we do it has to be very agile - Git- type PRs not ISO-type timescales. But I think definitely something for JIC to look at --- ## Post #22 by @siljelb [quote="SteveHarris, post:20, topic:6153"] 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 … [/quote] This is interesting! Am I understanding you correctly that this is about things like tablets, heartbeats or mitoses? [quote="SteveHarris, post:20, topic:6153"] Happy to help think this through in more detail if there are other like-minded obsessives. [/quote] :raising_hand_woman: :nerd_face: [quote="ian.mcnicoll, post:21, topic:6153"] Whatever we do it has to be very agile - Git- type PRs not ISO-type timescales. [/quote] 1000 times this! --- ## Post #23 by @SteveHarris I completely agree with not replacing - like I said the only thing we considered was anointing a version as that approved for use in England and committing to review that periodically. But the idea of an expert shop who could be (in a sense) first line support for UCUM is attractive, if someone doesn't get there first then it might be we could offer that kind of service. Doing it through ISO properly would be quite complicated but there is precedent - if Regenstreif were to come to SC32/WG2 looking to anoint an ISO UCUM version, or a core part of UCUM, then I'm sure they would be welcome. We already anoint versions of DOLCE and BFO so government organisations can mandate them in contracts. --- ## Post #24 by @yampeku [quote="siljelb, post:22, topic:6153"] This is interesting! Am I understanding you correctly that this is about things like tablets, heartbeats or mitoses? [/quote] any valid snomed unit should be under this concept https://browser.ihtsdotools.org/?perspective=full&conceptId1=767524001&edition=MAIN/2025-01-01&release=&languages=en --- ## Post #25 by @siljelb [quote="yampeku, post:24, topic:6153"] any valid snomed unit should be under this concept [SNOMED International Browser](https://browser.ihtsdotools.org/?perspective=full&conceptId1=767524001&edition=MAIN/2025-01-01&release=&languages=en) [/quote] I'm struggling to envision how anything from SNOMED but "countables" (and even then I'm only finding the children of [`732935002 |Unit of presentation (unit of presentation)`|](https://browser.ihtsdotools.org/?perspective=full&conceptId1=732935002&edition=MAIN&release=&languages=en) which look applicable to me) would be applied to UCUM. Maybe you could enlighten me? :sweat_smile: --- ## Post #26 by @ian.mcnicoll Actually the UCUM Github site does feel like they are trying ot be more responsive and agile. https://github.com/ucum-org I'm certainly not in favour of replacing UCUM with SNOMED, even if that were legally possible. But SNOMED 'Units of presentation' feels like a more sensible approach than using UCUM for 'tablets'. --- ## Post #27 by @grahamegrieve We've said that too, and put that in the spec, but there's no formula - 1 tablet/day. So the idea of a ucum extension is of interest --- ## Post #28 by @yampeku timing representation in medication is also a mess of their own --- ## Post #29 by @grahamegrieve Here's a contribution: https://www.healthintersections.com.au/2025/01/14/extending-ucum.html --- ## Post #30 by @siljelb Thanks Grahame for this excellent write-up of the problem and possible solution. I like the idea of using `@` (or maybe `#`, in Unicode called "number sign"?) to signify a countable. But would the extension then also contain a vocabulary of valid countables, to avoid the "tablets/tabs" issue you mention? --- ## Post #31 by @ian.mcnicoll Nice work. My only issue is that IMO, medication timing is a really bad example of what we might want to handle in a UCUM Extension, only because the syntax required is way, way more complex than "2 {{tablet}}/day". Perhaps seperate thread but the original Medication dose/timing model was designed as a syntax. We found that expressed as a structural model had more acceptance but the syntax does exist.... ``` Worked Example 1: “1-2 tabs 4-6hourly for 7 days, maximum 8 tabs daily” Dose Instruction Dose Direction: Dose Pattern: Dose Amount: “1-2 tabs” Dose Timing: “up to 4-6 hourly, as required” Dose Direction Duration: “for 7 days” Maximum Dose: “maximum 8 tabs in 24 hours” Equivalent Parsable Dose Syntax: “1-2 ^h4\h6 prn:7d [8 h24]" ``` --- ## Post #32 by @grahamegrieve @siljelb yes, it would define the terminology that could be used, definitely @ian.mcnicoll I totally agree about medication dosage, and I wasn't intending to suggest it would scale up to that. But it would be part of it, I think --- ## Post #33 by @ian.mcnicoll I think the problem is that once you start down the road of combining dose **and** timing you will get quickly into a tangle. '1 {{tablet}} 'is fine , though I'd still prefer something like SNOMED CT '1 {{tablet}} / day ' is tempting but IMO a mistake unless we really 'do not try', at least for community/outpatient medications, excluding complex inpatient meds. That was the original scope of the Scottish work. --- ## Post #34 by @yampeku Timing is also available in SNOMED, probably could be preferable too In general << 272103003 | Time patterns (qualifier value) | but for the use case in particular probably the important ones are in << 307430002 | Regular frequency (qualifier value) | ![imagen|670x500](upload://uvmfAvGT1GiuwlCJyPRBoWGxv9Z.png) --- ## Post #35 by @grahamegrieve [quote="ian.mcnicoll, post:33, topic:6153"] I’d still prefer something like SNOMED CT [/quote] Well, if we did this, then it would be a very good to map the codes in the UCUM extension to SCT --- ## Post #36 by @ian.mcnicoll Agree but on a case-by-case basis. It's strong for things like 'Units of presentation' but not universal IMO. I'd rather don't get us back to SNOMED being seen as the only way to do terminology. I guess the extension effort might encompass several different types of outcome. 1. This really needs a core UCUM update, we will pass this on to them, and add it to the extension until it is formally included. 2. This is a common constraint on existing units that is worth standardising, or a sensible use of arbitrary units (some of which might be SNOED coded) 3. This is really out of scope for the Extension - sorry , no, this is better done with a structural model e.g. the FHIR / openEHR timings structures --- ## Post #37 by @siljelb The complexities of medication dosage/timing is a side issue to this topic, and I suggest we don't get into the details about it here. There's a reason why we have four archetypes working in conjunction just to cover all the weirdness of dosage/timing. Specifically about the units part though: [quote="ian.mcnicoll, post:33, topic:6153"] '1 {{tablet}} / day ’ is tempting but IMO a mistake unless we really ‘do not try’, at least for community/outpatient medications, excluding complex inpatient meds. That was the original scope of the Scottish work. [/quote] IMO "tablet/day" or similar can be a reasonable unit for medication dosage/timing **if** you're representing it as a frequency, or to specify a maximum dosage. It's a variation of the "1/[time unit]" of the 'Frequency' element [here](https://ckm.openehr.org/ckm/archetypes/1013.1.2245). It doesn't however work for specifying the dosage at a point in time. [quote="ian.mcnicoll, post:33, topic:6153"] '1 {{tablet}} 'is fine , though I’d still prefer something like SNOMED CT [/quote] Conversely, just "tablet" works if it's used to specify the dosage at a particular point in time, but not for a frequency type data point. [quote="yampeku, post:34, topic:6153"] Timing is also available in SNOMED, probably could be preferable too In general << 272103003 | Time patterns (qualifier value) | but for the use case in particular probably the important ones are in << 307430002 | Regular frequency (qualifier value) | [/quote] IMHO trying to terminologise this is madness, and will end up with a combinatorial explosion covering only part of the requirements. --- ## Post #38 by @ian.mcnicoll TBH I think that is really, really bad use of SCT. Madness!! --- ## Post #39 by @yampeku no need to cover all the possible combinations, as always snomed precordinates the common ones and lets you postcoordinate the rest as needed --- ## Post #40 by @SteveHarris If you're going to introduce modelling into SCT with post coordination, it is absolutely essential that the model has complete coverage of the domain. Otherwise you're never going to be able to reliably extend it with an information model - and this is one of those places where the information model and the terminology model would need to be lock-step. This looks like a domain where it is possible at least. --- ## Post #41 by @siljelb Timely XKCD: ![image|323x355](upload://iq2pkHBG67gnx71wHVsVMme9z7L.png) [xkcd: Uncanceled Units](https://xkcd.com/3038/) --- **Canonical:** https://discourse.openehr.org/t/ucum-dependence-governance/6153 **Original content:** https://discourse.openehr.org/t/ucum-dependence-governance/6153