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
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.
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)| which look applicable to me) would be applied to UCUM. Maybe you could enlighten me?
Actually the UCUM Github site does feel like they are trying ot be more responsive and agile.
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’.
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?
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]"
@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
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.
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) |
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.
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.
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)
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
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:
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. It doesn’t however work for specifying the dosage at a point in time.
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.
IMHO trying to terminologise this is madness, and will end up with a combinatorial explosion covering only part of the requirements.
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.
