OHDSI Home | Forums | Wiki | Github

Proposal to change the definition of measurement domain to avoid ambiguity

Vocabulary Users
#1

Measurement should be only some test or evaluation, for example “WBC count”.
such concepts as (SNOMED_concept_code concept_name)
“372851000000101 Cardiac troponin positive”
“371401000000107 Urine buprenorphine level positive” belongs now to measurement domain. And my suggestion is to change their domain to ‘Condition’,
while measurements itself, ‘105001004 troponin T cardiac measurement’ and ‘407692000 urine buprenorphine level’ remain the ‘Measurement’.
This allows to avoid endless discussions about “Is anemia or preteinuria a condition or measurement?”

so test itselft is Measurement
and some conclusion given like “Cardiac troponin positive” is Condition.

@ericaVoss, @Christian_Reich, all
What do you think?

THEMIS: New Initiative to create definitive conventions for data in the OMOP CDM
#2

I feel though that in these two examples they are still are measurements. Cardiac troponin is a finding of a protein in the blood and the urine buprenorphine is really measuring if they can find the opoid in the urine (potentially testing for abuse?). I think proteinuria is similar to these in that it is a measurement of protein in the urine. However people think of anemia as a condition.

I think in some cases where it is hard to automatically disentangle, what if we create both a MEASUREMENT record and a CONDITION record.

But I’ll let @Christian_Reich chime in. Tagging @clairblacketer as well.

#3

actually that’s why I came up with this proposal:
anemia = low hemoglobin
proteinuria = presence of protein in the urine
Urine buprenorphine level positive = presence of buprenorphine in urine (yes, it says about abuse)
so all these are the same - there are some changes in organism found
and then people start arguing if it is a measurement or a condition based on are those changes are closer to a disease or just to test result.
We can say actually anemia is a disorder and there are a lot of clinical forms and types and so on OR we can say Anemia is a measurement - it’s just a low Hemoglobin level;
but from data analytical view there is no difference between those terms.
Difference is between testing urine buprenorphine level and fact Urine buprenorphine level positive
in first case we populate the value_as_concept_id or value_as_number (depending on the source) with it’s result;
is second case we put the concept only;
This way I want to use this exact difference instead of relatively subjective logic based on clinical meaning

#4

@ericaVoss:

I think what @Dymshyts is proposing here is to move the line a little bit to the right:

Everything is a Condition, unless it is explicitly a Measurement. To be an explicit Measurement, it has to either say so (the words “test” or so in it), have an exact result, or otherwise be clear that this is not an ongoing problem, but a single transaction. If in doubt, it becomes a Conditions.

It makes sense to me. Except that his example “Urine buprenorphine level positive” I’d read as a measurement (has the word level in it). But it is tricky no matter what we do.

Thoughts?

#5

@Christian_Reich & @Dymshyts -

Ahhh - sorry I wasn’t getting it. I get why it is tricky, but I think this plan sounds good. Default condition unless we think it is a test based on the text (e.g. words like “test”).

This probably means on the ETL side we may have to get better about where lab data ends up. If a raw lab record ends up in domain condition you may need to check the output values before you write a row to the condition. For example let’s pretend there was a lab value called “anemia” (which I think we agree above should be listed as a condition) but the result of the lab was “negative” - in this case we don’t want to blindly write a record to the CONDITION_OCCURRENCE table because the result is saying a test was performed but we cannot confirm the diagnosis.

#6

@Christian_Reich ,@Dymshyts ,@ericaVoss:
I suppose the actual number of measurements with the same name as conditions is extremely low.
For example, there are lab. tests for hemoglobin measurement, RBC count etc. And I didn’t meet measurement called “anemia” in my practice. But you are right:all disputable conditions/measurements have to be scrupulously
reviewed before making decision.
As for me such record as “Urine buprenorphine level positive”(condition) should be somehow related to
“urine buprenorphine level” (measurement) with value above reference range(positive). And related condition should occur in “condition_occurrence” table if measurement (with corresponding value) is present. But now this is utopia,isn’t it?

#7

Well, why so complicated?
if it’s a testing procedure - it’s measurement
if it’s a result of measurement - it’s condition like “Urine buprenorphine positive”, it has ancestor “Measurement finding”, so all descendants of “Measurement finding” will be conditions

And then it should be not hard to define those domains using SNOMED internal relationships, for example these findings have relationship =“Has interpretation” and “interprets”

#8

I think in this case both are fine, but I prefer it to be either a condition or a observation. This is because it does not fit the classic measurement paradigm (please correct me if my understanding is wrong).

Measurements: are of four types. Nominal, Ordinal, Interval or Ratio. We measure an attribute and the value is the measurement of that attribute. So in the examples below - one concept id combines both the attribute and its value.

i.e. there is no separation of the entity and its value, no separation of what is being measured and its measure. So it is not a classic measurement.
A classic measurement may be something like an attribute ‘784261000000103 High sensitivity cardiac troponin T measurement’ with a value that is ‘positive’, ‘negative’, or a number like 1.1

Condition: Conditions (or observations) may be

  • is known to be present
  • is known to be not present
  • is not known to be present
    e.g. Cardiac troponin is known to be present, Cardiac troponin is known to be not present, or Cardiac troponin is not known to be present.
    or
    CHF is known to be present, CHF is known to be not present, or CHF is not known to be present.
#9

Just to clearify:
So, you agree that
372851000000101 Cardiac troponin positive
371401000000107 Urine buprenorphine level positive
are the Conditions (or Observation - there is another good question - about Condition vs Observation)

and ‘784261000000103 High sensitivity cardiac troponin T measurement’ is Measurement?

#14

Yes! Agree. Thank you!

#15

Well, the fact that there are vocabularies which pre-coordinate things into a single concept doesn’t make a difference. We can just “de-coordinate” and map the test to a test and the result to a result. That way, “Urine buprenorphine level positive” would become a Measurement with a result.

The question is, do we believe “Urine buprenorphine level positive” was a single transaction to measure the buprenorphine level in the urine, or is this a condition where the patient had high levels of buprenorphine. In a way, only the ETL can know this for sure.

What we are trying to do here, is to make an educated guess for standard codes in HCPCS, CPT-4 etc. whether it is one or the other.

#16

@Christian_Reich,
so should we implement the measurement domain as I said?

#17

FYI
changes discussed here are already implemented

t