We are adding some vitals into the measurements table and without those two concepts it is impossible to add a unit to them as UCUM does not provide even BMP. Can they be made standard? or please point out where/how should be put any Pressure or Heart Rate measurements in the CDM.
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?
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â.
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.
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.
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.
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?
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!