I am happy to add them, but you don’t need them. The unit is really 1/min (concept_id=8541). The numerator can be breaths, beats, Juan Bandas, potatoes, whatever. It’s not a physical unit, but an integer count. But to make people happy UCUM allows those pseudo units in curly brackets ({breath}, {beats}, {RBC}, {eos} etc.
@Christian_Reich, Can you dig into this example a bit deeper? We’re doing an ETL for lab values and we’re going to encounter this too.
Is it the case that the conceptID of the measurement will infer the numerator unit the measurement is measuring? Example: Brachial pulse rate (4226234) of a unit of 1/min is that beats or breaths (and apologies if this is an obvious example, I’m not familiar with what a Brachial pulse rate is measuring), but my point is, is there enough info looking at the measurement concept to know the type of thing we’re measuring. In your statement above, what represents the numerator that allows you to distinguish potatoes per minute vs. Reichs per minute?
-Chris
I will write something into the UCUM description. I realize it is under-documented.
But in brief: Currently, we don’t have a set of units that are allowed for each Measurement. Brachial pulse rate (the pulse rate measured on your wrist) should only accept “/s” (concept_id=44777659, the canonical SI unit for rate, concept_class_id=‘Canonical Unit’), plus any unit that could be derived from that unit ("/min", “{Reichs}/min”, “{Reichs}/min{of the luckiest hour in a day}”. UCUM is not a fixed standard, but more of a grammar. So, you can invent any unit you want. But whatever non-unit you put in curly braces it will just be disregarded when being processed.
Problem with that approach is:
- We don’t have that conversion table from canonical , however there is a good starting point here, and the rest would proabably be easy to add.
- We don’t have the table linking Measurements to Units. LOINC did that, but we haven’t incorporated it, and SNOMED Measurements are not covered at all.
Thanks, @Christian_Reich, I think the UCM approach is definitely problematic, i’d hate to parse curly braces to understand what the unit of measure is!
But, that didn’t quite answer my question, so maybe I can put it a different way:
If I have a measure of the average speed someone ran a mile, and I record 2.3 as the value, and use the concept 8541 (1/min), how would I know the numerator unit? Is it 2.3 miles / min 2.3 meters / minute 2.3 yards / minute? Etc Etc, my original question was how do you know what the numerator unit is? I’m not sure I actually agree that 1/min is an actual ‘unit’, because your left with ‘yes, but 1 what per minute?’.
You “hate” parsing. Is that so? 
It’d be the analytic who’d have to do that, if you want to do proper processing of units. But to plug UCUM here a little: It’s the only system that is consistent and flexible, so we can add any unit we want and stay interoperable and preserve the ability to do generic conversions automatically.
But to your question: The unit “/min” has only “pieces”, “items”, “counts” or anthing integer in the numerator. Anything you can count and is not one of the base units or it’s derived combinations.
Your runner: the unit would be min/mile or s/m. Meter, yard or mile is a base unit, so it cannot be replaced by “1”.
Makes sense?
Yes, I understand what you’re saying, so let’s now circle around back to Juan’s original statement about missing concepts for ‘beats/min’ and ‘breaths/min’. It sounds like you are saying that in the case of my runner, you’d need the units in the concept because it’s a base unit ([mile][feet][meter]) per some unit of time. But in Juan’s case, it’s not a ‘base unit’ so you’re saying that the 1/[minute] is enough. So is that to say you can infer that they are counting ‘breaths’ or ‘beats’ based on the particular measurement concept ID of the row?
Correct. That’s how it works. Obviously, I can add the beats and breaths per minute to make it easy on us, but the /min is sufficient.
You have to know what’s in the measurement row, and you have to understand how the UCUM system works. So, what you have to do is this:
- Try finding the unit as is: Write down your overall composite unit (here: beats/min). Look it up just like that.
- Try finding the stripped UCUM version: Find each unit in the list of base units. If you find it, leave it. If not, take it out. (here: /min). Look it up in the vocabulary.
- Try finding the canonical version: If you want to consider using a canonical unit including the conversion convert the base units into canonical base units (here: /s). Look it up in the vocabulary.
- Complain if you cannot find anything or if the canonical is too much hassle.
I’ll put that into the description shortly.
What would a SQL query look like doing all of the above where I wanted to find people with a measurement of > 3 breaths/sec? And let’s assume a ConceptId 12345 = ‘Breath Rate’, Domain = ‘Measurement’
I agree that more documentation is needed. However, having the researcher derive the true unit based on context, in my opinion defeats the purpose of even having a unit at all. Why not even remove the unit concept_id field then? if people are inferring stuff
Since the SNOMED unit concepts are in the vocabulary and while not being standard, they will remain there, why not just actually use (read: make standard) the ones missing from UCUM? I understand the user can define new ones, but there are no mechanisms in the vocabulary to be able to standardize them. Maybe create a ‘Custom Unit’ concept and let them all be defined using that concept?
I am not opposed to either, but if this is the requirement, all assumptions/standards have to be rigorously documented for people doing ETL work.
select * from measurement where measurement_concept_id=12345 and value_as_number>3.
If you want to make sure its per minute, add
and unit_concept_id in (select concept_id from concept where concept_code like '%/min'
Juan. It’s not that big of a deal. Take the unit, remove anything that is in curly braces, and voila, you got the unit. Because pulse and breathing is always per minute.
Let me say it again: We can add those breaths and beats no problem. But logically, they are no units. They are integer counts of discrete entities. This is the world of physics, and nothing we can do about it.
There is no such a thing as a “Standard UCUM”. All units, as long as you follow the UCUM syntax, are standard.
It’s up to us. Submit it to the CDM Working Group list, and we make it the standard. Or we just do it.
Of course there is. We decide we want them, and I put them in. Simple.
Thanks, @Christian_Reich, that clears it up, tho I probably wouldn’t use ‘like’ operators in my own query, but i’d find the concepts that have the specific unit that I’m looking for, but regardless, that’s what I wanted to know.
Thanks!
-Chris
Yeah, plus the query isn’t quite correct (as I realized yesterday while jogging). It should check for “/min” at the end and either nothing, “1” or “{%}” before the slash. But you got the idea.
Friends:
Come to think of it: We might create a set of relationship that does the UCUM “conversion”. It doesn’t really do a conversion, but it will connect all equivalent units to a “standard” (the simplest without curly braces) one. Would that help?
1 Like
I think this would greatly help!
This makes it a bit clearer. But I think more examples would make it nicer.
Like the ones for BPM and such. Thanks for writing this up!
Hate to revive an ancient conversation, but @Christian_Reich, are you aware of any efforts (from Regenstreif or anywhere else) to map LOINC standard units to UCUM?
Not sure I understand. LOINC standard units? I am not aware of such a thing. There are units in Answer concepts, but usually in combination (concept_id 45876379 concept_code ‘LA13891-9’ “More than 1000 mg”).
We got a list that allegedly came from Regenstreif of LOINC codes with the “standard unit” for each - e.g.
10561-9 mmol/L
We need to get it into UCUM format and I was hoping there might be a way to do this using CONCEPT_RELATIONSHIP. Something along the lines of:
select c1.concept_name, c1.concept_code, c2.concept_name, c2.concept_code
from concept c1
join concept_relationship cr on cr.concept_id_1 = c1.concept_id and c1.vocabulary_id = ‘LOINC’
join concept c2 on c2.concept_id = cr.concept_id_2 and c2.vocabulary_id = ‘UCUM’
so that we don’t have to manually convert each unit type into UCUM. We get a lot of labs in from various sources and they don’t always have the “right” unit, so if we get everything in UCUM it would be easy to convert it all in so that we can make apples-to-apples comparisons between seminal carnitine values from Quest vs seminal carnitine values from some other lab that gives the value in ng/mL instead of mmol/L. No worries - just thought you might know. Thanks!
Here is what I know. Since I had AMIA poster on it 3 months ago.
There is an article in JAMIA here https://academic.oup.com/jamia/article/25/5/614/4093028
There is reponse to it from LOINC team : here
LOINC standard has a column that says “example units”. They are not normative. Best if we could get the LOINC team to formally comment.
Data driven concensus on units is here: GitHub - OHDSI/OhdsiStudies: OHDSI study packages are posted here (folder ThemisConcepts) (see file …-ABC.csv) (or other forum posts)