OHDSI Home | Forums | Wiki | Github

Utilization of UCUM for N3C

Vocabulary Users
#1

Hello Vocab:
I have been looking into utilization of UCUM to indicate units within N3C. I read many of the entries here on the forum, looked at Athena, and the OMOP specification. As such I was aware that UCUM was being used, not cached / downloaded and there were some maps for Medications in Athena. it was not until this am when I located this resource:

https://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:ucum

That my many questions about implementing UCUM on OMOP were answered. However, I do have a couple of unanswered questions based on my UCUM Odyssey…

  1. Do or how do other OMOP implementations store conversion(s) from source data to an set of implementation-specific canonical UoMs?
  2. What (if any) bearing do the CIEL maps to UCUM have for the N3C implementation? Is this related at all to my question (1) above?
  3. How do OMOP implementations resolve the curly braces? Is this done on a per implementation basis?

Many thanks in advance for your assistance!

Davera Gabriel

#2

Mostly background info (not answering your questions)

Let me say that I think a lot of OMOP sites do not have notion of “target units” and don’t do any conversion at ETL time . They leave the problem until analysis time.

Only recently AoU and N3C started doing it.

AoU crucial knowledge base for this is here https://github.com/all-of-us/curation/blob/develop/data_steward/resource_files/_unit_mapping.csv

It would be nice to unite the work of N3C and AoU on units harminization into one public resource. E.g., a github repo within OHDSI organization. It could even live here https://github.com/OHDSI/CommonDataModel/blob/master/CodeExcerpts/CodeExcerpts_README.md

#3

Ad Q1:
With exception of unit_source_concept_id there are “source value columns” in the OMOP CDM today to store the original values.

And the missing field has been filed as change request. see link below

For example - assuming your measurement_concept_id has not changed during “unit harmonization”
if you convered x pounds into y kilograms for weight
x goes into value_source_value
pounds go into unit_source_value (no ???concept_id counterpart here (see above))
y goes to value_as_number
concept for kg goes to unit_concept_id

(italic font shows the original values files, and 2 lines below is the “harmonized part”

https://ohdsi.github.io/CommonDataModel/cdm531.html#measurement

image
image1074×625 18.4 KB

#4

Hi @DaveraG,

  1. Colorado does not convert their units of measurement, we store the data in OMOP ‘as is’.
  2. I haven’t ever looked at the CIEL maps. What and where are those?
  3. Our source data for Units doesn’t contain curly brackets. It comes across as free text strings: cm, mcg, mg/dl

*edit: @DaveraG This post would be better suited in the Implementers category where you will probably get more replies since this is about the implementation of Measurement data and not a question about the Vocabulary :slight_smile:

#5

@Vojtech_Huser,

re:

Granted we don’t convert our source data, but the above is not how we would implement. The *_source_value informs the *_concept_id. And pounds isn’t equal to kilograms. IF we were to implement this in Colorado, without there being guidance from the community, I would put the original value and units into the value_source_value field and the converted data into value_as_number, unit_source_value and unit_concept_id. Logic: the original source data is left intact in the value_source_value field and the converted data is stored where the unit_source_value is the english representation of the unit_concpet_id.

Example: Person weight = 110 lbs
value_as_number = ‘50’
unit_source_value = ‘kilograms’
unit_concept_id = 9529
value_source_value = ‘110 lbs’

#6

Hi Everyone,

We are actively pursuing a research effort to harmonize units and measurement concepts at Columbia as well. I look forward to collaborating on this.

Best,
Matt

t