OHDSI Home | Forums | Wiki | Github

Spec Disease Status vs Meas Value

CDM Builders
,
#1

This yet another post follows on the recent discussion on SNOMED overhaul taking place in the Vocabulary WG last Tuesday, slides, recording and meeting notes available in Teams.

One of the proposals was to change the domain of 3 concepts as we are missing them in the Meas Value domain:

image
image2036×1138 255 KB

On the call, we asked the community if they may need these concepts in the Spec Disease Status as well. It appears that they do in the Specimen table, which led us to the tentative decision to have these 3 concepts in both Meas Value and Spec Disease Status domain.

Now, @Andy_Kanter brought up a question of having one set of concepts and relaxing CDM conventions to allow to use concepts from domains other than ‘Meas Value’ in MEASUREMENT.value_as_concept_id field. Since this is the topic involves CDM and Themis conventions, we felt we need to include a broader community in this discussion. As usual, tagging our CDM gurus @clairblacketer, @MPhilofsky and @Christian_Reich.

SNOMED Overhaul Discussion
#2

Don’t we need more concepts for value_as_concept_id?

  • Detected
  • Not detected
  • Equivocal
  • Expressed
  • Overexpressed

And more.

#3

I agree. And @Dymshyts agrees here. And I know this topic was somewhere else with a bunch of folks wanting to remove the domain restriction, but I can’t find it.

1 Like
#4

Wait. We don’t reduce the list. We just add 4 more (to 42k) that were highjacked by another Domain.

Agree. But let’s not do it for the whole bunch of Domains. Let’s define the use cases where we do allow the use of other Domains as the values.

At the same time, we were talking a lot about Standardizing the ‘Meas Value’ domain itself by defining the subset of permissible values (like dozens or thousands) and mapping over the rest of them.

#5

Bad idea. When we post-coordinate, we should have a convention what goes into the variable (Measurement concept) and what goes into the value. Otherwise we can have both:

  • Blood culture positive for – gram negative bacteria
  • Gram negative bacteria found in – blood culture

If we allowed this, ATLAS cohorts will die.

Measurements should be fully pre-coordinated and the value should only be the result. In this case it would be:

  • Negative bacteria in blood culture – Positive

LOINC does it that way (mostly). SNOMED of course is all over the place. We need to clean up. Urgh.

#6

Same thing again. Ok for modeling, bad bad bad for the use cases. Constructing cohorts based on these will be the usual code chasing we are trying to avoid in OMOP.

I would postulate the following: If a standard concept cannot have a single domain it is not sufficiently defined. It’s wishy washy.

#7

I think we need to better define the Specimen table. Currently, the definitions states: The specimen domain contains the records identifying biological samples from a person. Standard concept fields include data for what the sample is: blood, liver biopsy, catheter tip, slide, etc. And where the sample came from: Lobe of liver, duodenal structure, etc. There is a disease_status_concept_id which lacks a definition or recommended concepts. When looking in Athena I find only 3 standard concepts as found in Anna’s post. I would argue disease status is the result of a Measurement. It doesn’t fit the definition of the Specimen table. Should this field be in this domain? I think it belongs in Measurement. The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample.

#8

No question about it. Problem is: Very few people are using it, so the priority has always fallen all the way to the bottom of the well.

And yes, the Specimen Status concepts sound like Measurement Value concepts. Still, their definition makes them different, which means, they should have their own domain, rather than used for both.

t