OHDSI Home | Forums | Wiki | Github

About domain restrictions of MEASUREMENT.value_as_concept_id

(I am not sure if this belongs to Implementers or Vocabulary Users. Since I am an ETL implementer, this seems more natural…)

https://ohdsi.github.io/CommonDataModel/cdm531.html#measurement says this about value_as_concept_id column:

If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the ‘Meas Value’ domain.

and also

This is also the destination for the ‘Maps to value’ relationship.

What should I do with a source concept “Y90.0 Blood alcohol level of less than 20 mg/100 ml” from ICD10 vocabulary (concept_id=45590669)?
CONCEPT_RELATIONSHIP row with relationship_id == “Maps to” says this is a SNOMED vocabulary concept in Measurement domain: “167009006 Blood ethanol measurement” so this clearly goes into MEASUREMENT table.

CONCEPT_RELATIONSHIP row with relationship_id == “Maps to value” states the ICD10 code maps as value to SNOMED concept “442082004 Measurement finding within reference range” (Concept_id=40481826) but the domain is “Condition”.
Can I use this Concept_id=40481826 as MEASUREMENT.value_as_concept_id even though it is in Condition domain and not “Meas value”?

Hi @prikala,
Nice finding.

Ideally, this concept should be represented as whole MEASUREMENT table row:
Measurement_concept_id = Blood ethanol measurement
value_as_number = 20,
unit_concept_id = milligram per milliliter
operator_concept_id = <.

We want to add the “Wide mapping table” to store relationships between a source concept and different attributes (to Event_concept_id, unit, operator and number in this case).

Not sure, when it will be agreed by the community and takes an actual place.
So, you can create some look-up table and use it during your conversion to get the result above.
Note, the concepts like
Y90.2 Blood alcohol level of 40-59 mg/100 ml
will end up in two rows, one with >=40, another with <=59

And if you don’t want to be bothered with the additional logic, just break the rule of Meas Value restriction for now.
And once we release the “Wide mapping table”, you can fix that.

Hi @Dymshyts,
I found a set of SNOMED concepts that might be affected by the same domain restriction. Lab results for virus detection can be reported as Positive/Negative or Reactive/Non-reactive, but for some reason the SNOMED concepts have different domains assigned:

Meas Value domain:

Observation domain:

Since there is no value_as_source_concept_id column, it seems that the only formally correct way is to use 0 for Reactive and similar codes.

Does Reactive is the same as Positive and Non-reactive is the same as negative?

I’m not a clinician, so this should be confirmed by someone who is. My impression is that in most cases the meaning is the same. I’ve seen some particular examples (e.g. HIV testing) when Reactive might be considered as a preliminary result that should be confirmed by a different test. So I’d keep the data as close to the source terms as possible, leaving determination of Positive vs Reactive relationship to the analytics part.

From the domain assignment perspective, these SNOMED concepts are the same, like LOINC concepts Positive and Reactive.


And Here they literallty say
“Synonym(s): Positive Test Result”
And in your article @jliddil1 the same is probably meant - you never know when the positive result is false-positive, otherwise there wouldn’t be such a case.
So, @andrey you just map Reactive and Non-reactive and get the right domains.

Not really, the full meaning of a concept is derived from its hierarchy, look (the link doesn’t work properly, so to see the hierarcy you need to put the concept_code or concept_name in a search window),

it is some characteristics of a pathogenesis, not a lab test result.

1 Like

@Dymshyts I see, thank you for the explanation. I’ve checked the Positive and Negative SNOMED concepts, they’re certainly different and in line with the lab result context. If the SNOMED Reactive appears in the context of the viral test result, it can be mapped to one of the SNOMED Presence findings, e.g. Present.

@Dymshyts Now I have to implement a similar ETL, and found that the example from the CDM specification also violates the Meas Value domain restriction:

the ‘Maps to’ relationship directs to 4046263 ‘Enzyme measurement’ as well as a ‘Maps to value’ record to 4135493 ‘Abnormal’.

The 4135493 concept Abnormal belongs to the Spec Disease Status domain. In line with your previous recommendation, I’m going to use this concept.

The parent concept 4174761 Normality findings has 9 children concepts, some of them are of Meas Value domain, others are of Spec Disease Status domain. Should all of them be of Meas Value domain? If yes, could you please update the vocabularies?

Thank you.

Yes, looks like domains of Normality findings descendant concepts should be fixed, I’ll create a ticket and when we work on the next SNOMED update we can fix it.

where did you take this quote from? I don’t see it in this thread?

@Dymshyts That quote was from the CDM specification v5.3. Other versions (v5.4 and v6.0) have the same example in the ETL Conventions section.

1 Like