OHDSI Home | Forums | Wiki | Github

Duplicate standard concepts for value_as_concept_id in OMOP Vocab

Vocabulary Users
#1

To guide users to one (and only one) way to code data, this duplicate concept
http://athena.ohdsi.org/search-terms/terms/45884084

should be made non-standard.

It is a duplicate of this concept http://athena.ohdsi.org/search-terms/terms/9191

(see covid19 elt guidance post elsewhere on the forum)

Same duplication appears for Negative http://athena.ohdsi.org/search-terms/terms/9189

(or if we like the relationships LOINC has for LA codes, then remove the duplication the other way round (making the SNOMED term non-standard).
(this is a problem with LOINC SNOMED sub-optimal coordination; well, the values should be in license free GPS subset of SNOMED and than LOINC can freely use them in copyleft manner)

Who is working with UK Biobank?
Mapping Microbiology Susceptibility into OMOP CDM4 Observations
Where does blood type go?
#2

We’ve been thinking about mappings between LOINC parts and SNOMED attributes, but LOINC Answers were kind of out of the scope.

But I am agree, this catching of all the permutations of the same values is really annoying. Unfortunately, this fix will not resolve the other type of variability (please see below). So the reality is that in every other study we need to look into the data anyway.

BTW, does every ETL implies a standard practice to remap (through the concept_relationship) the non-Standard concepts that lies in the “value” area?

ID CODE NAME CLASS CONCEPT VALIDITY DOMAIN VOCAB
45884084 LA6576-8 Positive Answer Standard Valid Meas Value LOINC
45879438 LA9633-4 Present Answer Standard Valid Meas Value LOINC
4183448 43261007 Abnormal presence of Qualifier Value Standard Valid Meas Value SNOMED
4128650 260411009 Presence findings Qualifier Value Standard Valid Meas Value SNOMED
4126674 260350009 ++++ Qualifier Value Standard Valid Meas Value SNOMED
4125547 260349009 +++ Qualifier Value Standard Valid Meas Value SNOMED
45877985 LA11882-0 Detected Answer Standard Valid Meas Value LOINC
45877737 LA21225-0 Yes, positive Answer Standard Valid Meas Value LOINC
45881864 LA4677-6 Positive / Elevated Answer Standard Valid Meas Value LOINC
'Presumptive' Codes for Results
#3

We can help the network a lot by making one of the terms non-standard. We need to reach a decision at some point. CDM group seems to be focused on producing table overviews - so not sure if we can bring it up at their next meeting.

#4

I think it would help a lot to stick to our axiom of non-duplication (for standard terms) for this problem. Would CDM workgroup consider discussing this or how Vocab changes are voted upon officially.

For SNOMED CT Expo, I wrote this analysis on a related topic of value_as_concept_id. (now accepted to the conference). It is available in the readme (and at the link) here: https://github.com/vojtechhuser/project/tree/master/lab/linkage

#5

Here is the proposal on how this can be implemented within a new ‘Has Standard answer’ relationship.

1 Like
#6

OK. The proposal is a good first step. From the PPT file, I am not able to decipher all the info but having a relationship that somehow restricts the permissible values would be good.

E.g., result negative could not be answer for Blood type (only A, B, AB, and 0 would be)

#7

Here is an example of poor data quality (plausibility)
blood group+rh factor should have only values like A+,A-,AB+,AB-,etc…
Only those would be linked as ‘has-standard-answer’

In reality, we see a mess.
Including: normal, just negative or just A

The mantra is: quantitative lab tests have some plausible ranges, qualitative lab tests have some plausible values. The rest is flagged as “less plausible/desired” and if there is too much of less plausible data - DQD or Heel lets the research know !.

Snippet of 2020 Aug results from DQD Lab Thresholds study - described
here OHDSI Informatics Study: DQD Lab Thresholds

Data

image
image1433×456 32.7 KB

t