Stream: implementers
Topic: CodeSystem for UCUM?
Paul Lynch (Jun 03 2019 at 21:11):
Does a CodeSystem resource for UCUM (https://unitsofmeasure.org) exist somewhere? I am curious to see what happens for a code system that cannot be fully enumerated.
nicola (RIO/SS) (Jun 03 2019 at 22:00):
Probably UCUM is not code system at all. We discussed with @Grahame Grieve a long time ago FHIR UCUM service :)
nicola (RIO/SS) (Jun 03 2019 at 22:01):
There are already operations for it - $cannonize, $translate :)
Peter Jordan (Jun 03 2019 at 22:04):
http://hl7.org/fhir/ucum.html - note the ValueSet for common UCUM codes.
Rob Hausam (Jun 03 2019 at 22:05):
It is a compositional code system, with an expression syntax and a potentially infinite set of codes (see here).
Rob Hausam (Jun 03 2019 at 22:07):
@nicola (RIO/SS) What is "$cannonize" supposed to represent?
nicola (RIO/SS) (Jun 03 2019 at 22:12):
translate to SI :)
Grahame Grieve (Jun 04 2019 at 00:46):
there is no code system resource. Server implementations can only exist in code. But that doesn't matter to a client - it's just another code system to them
Paul Lynch (Jun 04 2019 at 20:39):
UCUM defines a number of properties for its units (in ucum-essence.xml) including a short definition, and isMetric flag, and a "class". It would be useful to be able to access that information in FHIR, and the logical place would be in a CodeSystem resource. The problem is that is not fully enumerable, but perhaps that could be solved setting CodeSystem.content to "fragment"?
Lloyd McKenzie (Jun 04 2019 at 20:45):
You could also get it using $lookup
Brian Postlethwaite (Jun 04 2019 at 20:47):
I don't know that it's a fragment, as it contains the know ucum codes. However the extended properties aren't all there. But should be accessible through lookup. Just no extensions
Rob Hausam (Jun 04 2019 at 20:56):
I don't see any reason that we can't or shouldn't create a CodeSystem resource to describe the UCUM code system and its properties. As was mentioned, you could optionally also include a fragment of the content (i.e. the "known" set of UCUM codes) - but we don't do that for SNOMED CT, LOINC, etc. and for a number of other external code systems, and it may not be necessary/useful for us to do that in this case.
Paul Lynch (Jun 04 2019 at 21:11):
@Lloyd McKenzie How would I know what the names of the properties are that I could request via $lookup, without a CodeSystem resource to look at?
Lloyd McKenzie (Jun 04 2019 at 21:54):
We certainly should have a no- content CodeSystem instance.
Peter Jordan (Jun 04 2019 at 23:37):
...which would allow us to reference the CodeSystem properties in a TerminologyCapabilities resource.
Brian Postlethwaite (Jun 05 2019 at 00:51):
I always thought that existed, due to the existence of the common ucum valueset with its expansion
http://hl7.org/fhir/valueset-ucum-common.html
But I guess not :smile:
Grahame Grieve (Jun 05 2019 at 10:03):
we can define a complete code system for UCUM - just like we could with other code systems. But it has compositional = true, indicating that there's more to say....
Brian Reinhold (Jun 05 2019 at 12:48):
Speaking of UCUM, can anyone tell me what the UCUM code is for dimensionless? Is it {unitless} 1? Note the space.
nicola (RIO/SS) (Jun 05 2019 at 16:01):
Still not sure that UCUM is semantically CodeSystem (base units of UCUM is a CodeSystem) , because of internal translations, generative nature, algebras etc - it's a Units System - something special :).
Lloyd McKenzie (Jun 05 2019 at 17:47):
It has defined codes. They have meanings. Therefore it's a code system. Generative nature/post-coordination capability isn't a barrier to it being a CodeSystem. It's just an ugly one to fully represent.
Grahame Grieve (Jun 07 2019 at 04:27):
@Brian Reinhold yes
Paul Lynch (Jun 07 2019 at 20:05):
Speaking of UCUM, can anyone tell me what the UCUM code is for dimensionless? Is it
{unitless} 1? Note the space.
@Brian Reinhold & @Grahame Grieve The UCUM specification says, "White space is not recognized in a a unit term and should generally not occur. UCUM implementations may flag whitespace as an error rather than ignore it. Whitespace is not used as a separator of otherwise ambiguous parts of a unit term. "
I did not reply earlier because I was not sure what to suggest. There are many possible dimensionless UCUM units. "{unitless}" by itself is fine. Incidentally, we have an on-line validator at https://ucum.nlm.nih.gov/ucum-lhc/demo.html. That one says "{unitless} 1" is not valid, as does as a validation API written by Jozef Aerts: https://ucum.nlm.nih.gov/ucum-service/v1/isValidUCUM/%7Bunitless%7D%201. Of course, both of those could be wrong, which I why I am citing the spec above.
Last updated: Apr 12 2022 at 19:14 UTC
