OHDSI Home | Forums | Wiki | Github

Measurement entity - which vocabulary to consider

Hello,
For measurement entity there are multiple vocabularies for measurement code and unit data like snomed,loinc. Which vocabulary should be considered as OMOP github page does not mention any specific vocabulary for measurement.

thanks,

I will only reply to the unit aspect

For unit data - use UCUM.
See ThemisConcepts folder in https://github.com/OHDSI/OhdsiStudies
(this links to a user repo).

See units is this rather complex file below
(only look at column unit_concept_id to keep your life simple)
(another simple column is n = number of sites using this lab-unit pair)

here https://github.com/vojtechhuser/ThemisConcepts/blob/55451169e1e4bd0f70a0044dcfccb351def018e4/extras/results2019/S7-preferred_units-ABC.csv

Hi !

For measurement, does anyone have more info on the choice between SNOMED and LOINC?

Thanks

Can you make your question more specific? If you are talking about unit_concept_id, you need to use concepts where domain_id = ā€˜Unitā€™ and standard_concept=ā€˜Sā€™. I do not see where there is a choice between SNOMED and LOINC.

Hi Don,

I plan to map peroperative measurements, collected by the monitor or respiratory system : heart rate, arterial pressure, oxygen, tidal volume.

For heat rate, I have items in LOINC and SNOMED :
Heart rate in SNOMED valid and standard
Heart rate in LOINC valid and standard
Except the vocabulary, the difference is on the concept class id : Observable Entity for SNOMED item, Clinical Observation for LOINC item

For expiratory tidal volume, I found :
Expiratory tidal volume in SNOMED valid and standard
Expiratory tidal volume in LOINC valid but non standard
Another expiratory tidal volume in LOINC valid but classification

For oxygen saturation, i have :
oxygen saturation measurement in SNOMED valid, standard but a procedure
oxygen saturation in LOINC valid, standard, and clinical observation

I thought LOINC was appropriate for measurements, should I give priority to SNOMED ? Moreover, should I be consistent in the choice of the terminology ? I guess I canā€™t choose LOINC for one measurement and SNOMED for another.

A last question, to document a measurement_concept_id in MEASUREMENT table, has the concept to be a clinical observation ?

Thank you

Certainly more specific :slightly_smiling_face:

You want these elements stored in the measurement table. Then the important attributes are 1) the concept domain, ā€˜Measurementā€™ and 2) standard concept equals ā€˜Sā€™. The concept class or vocabulary ID is not that important.

I thought LOINC was appropriate for measurements, should I give priority to SNOMED? There is no priority. For heart rate pick either the LOINC or SNOMED. (Possible caveat is that some LOINC codes imply what the units should be, if your units are different and there is a SNOMED alternative use SNOMED.)

Moreover, should I be consistent in the choice of the terminology? No, by your example above it is not possible to be consistent, have everything in the Measurement table and not violate the OHDSI rule that the measurement concept id be in the Measurement domain and be a standard concept.

I guess I canā€™t choose LOINC for one measurement and SNOMED for another. But you can. Think of it from the view of a researcher wanting to get heart rates from a network of ETLā€™ed data sources. The researcher will not know if the ETL preferred LOINC or SNOMED concepts. The researcher needs to account for all the possible standard Observation concepts that indicate heart rate.

A last question, to document a measurement_concept_id in MEASUREMENT table, has the concept to be a clinical observation? One last time, since repetition is key to remembering, the measurement concept id should be a standard concept in the Observation domain (concept class and vocabulary are not considered).

Finally, wait a day or two to see if someone corrects my answers. People may not be quick to answer a question, but they are sure to make a correction when something is wrong.

1 Like

SNOMED is a richer model with relationships. If we ever want to reach nirvana with one terminology, it would be SNOMED.

Some support snomed is both the answer and the question. (easier to maintain relationships and knowledge). Others say loinc is the question, snomed is the answer. Their business model is different !

The so called ā€˜SNOMED-LOINC agreementā€™ (who knows if still in effect) focuses on lab terms. Your examples are clinical terms.

1 Like

Hi @DTorok and @Vojtech_Huser,

Thank you very much for your answers ! It seems to be clear now !

Hi,

Iā€™m sorry to warm up this month-old discussion. Unlike @AntoineLamer Iā€™m not quite sure I understand the implications of this. My interpretation of standardized concepts has been, that regardless of the source concept there is a singular standardized concept_id, that represents the same fact.

Given the example ā€œheart rateā€ I imagined that there would be a single concept that represented the physical concept of a heart beating at a certain rate. I understand that there might be more detailed concepts such as ā€œheart rate by monitorā€, ā€œheart rate radialā€, ā€œheart rate at carotidā€ each having their own standard concept. What is not clear to me: how does having LOINC and SNOMED ā€œheart rateā€ both being valid and standard not violate a common data model with standardized vocabulary?

I seem to have issues comprehending the standardization and Iā€™d appreciate it if someone could point me in the right direction.

Best,
Daniel

So we have axioms that we try to achieve. (single standard concept for each ā€˜thingā€™). And in diagnoses, we OHDSI Vocab is good at sticking to this vision/axiom.
Same for drug ingredients - doing well there.

But in some domains, we fail the vision and axioms. And heart rate is one of them. For such concept, the ā€œcrowd voteā€ (ConceptPrevalence study for example) (which concepts gets used more by sites) can sometimes help.

Thank you so much for your response @Vojtech_Huser!

What keeps us from truly standardizing this concept? What prevents us from un-standardizing all but one concept_id, thus making the other one the true standard? It might break things but given a new vocabulary version couldnā€™t we do that?

Thank you,
Daniel

I think itā€™s just a matter of reporting the issue in the vocabulary github repository and call out where you think a standard concept is duplicated. These hints help the vocabulary team refine their vocabulary process, so you should try to report those problems that you find, so that they know itā€™s a problem that has a real use-case impact.

Hi @Chris_Knoll,

thank you for the suggestion. I was wondering whether Iā€™m just having a difficult time to understand the vocabulary or if this is a real issue. It appears the latter one is the case and I will therefore take the step you suggested and report it to the team.

Thank you all,
Daniel

EDIT: If you have any more input please continue this discussion over here: https://github.com/OHDSI/Vocabulary-v5.0/issues/344

t