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,
OHDSI Home | Forums | Wiki | Github |
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)
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
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.
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.
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