OHDSI Home | Forums | Wiki | Github

UCUM code for Celsius doesn't match UCUM specs

The UCUM code for “degree Celsius” is “[degC]” on Athena. According to HL7/FHIR, the code should be “Cel”. https://hl7.org/fhir/us/core/2017Jan/ValueSet-us-core-ucum.html

@janetzahner:

Yeah, the Celsius is fishy. It really is Kelvin plus a fixed number (the difference in K between the absolute zero and the tempature of freezing water). So, it should be something like K[Celsius] or so. But it isn’t. Now we are stuck with either bad notation.

What’s the consequence of leaving it the way it is and you have to map over? The consequence of changing it for the Standardized Vocabs is probably not that much: We’d have to deprecate the existing one, create a new one and link between the old and the new. Not sure how it would work on existing ETL code, and even how many people have Celsiuis to begin with. You probably get that from measuring body temperature. For US databases, you mostly get Fahrenheit back. In future, when we start fixing the unit mess, we will have to map and convert to Celsius anyway.

@Christian_Reich:

Thanks for your response. Our body temperatures are recorded by end users in Celsius, and then the EHR converts the measurement to Fahrenheit. We convert back to Celsius in our OMOP model because that’s what investigators are used to seeing. If the vocabulary entry stays the way it is, we just add a simple case statement to our ETL code to represent these as “Cel” instead of “[degC]”.

@janetzahner:

Sounds good. I wouldn’t use the concept_code for displaying anything. The concept_name says “degree Celsius”. Should be expressive enough.

This is an error. I filed an issue with vocab Celsius in UCUM is wrong · Issue #173 · OHDSI/Vocabulary-v5.0 · GitHub

indeed

As I said: We can fix it, meaning, deprecating the degC and creating a new Cel. And mapping one over to the other. No big deal. But again: This is the concept_code. For OMOP CDM purposes what matters is concept_id=8653.

So, want us to?

Yes, I agree with @Vojtech_Huser that this is an error and should be corrected. The solution outlined by @Christian_Reich sounds reasonable.

t