OHDSI Home | Forums | Wiki | Github

Measurement table discussion

CDM Builders
#1

We are working with laboratory data and we have a question about the difference of the following columns in the measurement table ( http://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:measurement )

The first column is quite clear

measurement_concept_id    

A foreign key to the standard measurement concept identifier in the Standardized Vocabularies.

But later the table defines another very similar column

measurement_source_concept_id

A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source.

For example, we can consider value 43.7% for ‘Hematocrit (HCT) Whole Blood Test, (CC, SOFTLAB, HCT2)’ The test is in RED terminology and it is local to our institution. It has local code 2153991. This local terminology is not in “Athena”. (“CDM Vocabulary”)

what goes into measurement_source_concept_id? (same code as in column measurement_concept_id)

If the unit is “nothing” (e.g., %), do we leave units blank?

#2

The _source_concept_id fields are used to store unique concept ids for any
source vocabulary, if applicable and available in the ohdsi vocabulary.
The _concept_id field is for the referent standard vocabulary for the
domain. So, in the measurement domain, one referent vocabulary is loinc.
If your source database has data already coded in loinc, then you would
have the same concept_id for both the measurement_concept_id and
measurement_source_concept_id field would contain the same value. If,
however, you only have the string of the lab test that you’ve shared in
this thread, and it does not correspond to a referent vocabulary, then you
should store that free text in the measurement_source_value field, then set
the measurement_source_concept_id = 0 for an unmapped source vocabulary,
then set measurement_concept_id = whatever standard concept in the
measurement domain that you map your free text to. If you don’t yet have
your source values mapped into the standard, you can use the usagi to help
with that.

Note, this is only about the measure itself, not the value. The value
associated with the measurement can either be numeric or standardized into
a conceptid, and stored in the corresponding value_as_ fields.

1 Like
#3

@Vojtech_Huser:

As Patrick said.

% is a unit. The concept_id is 8554.

#4

@Christian_Reich:
Somewhat on tangent, but still a discussion of Measurement table.
CDM allows to leave both value_as_number and value_as_concept_id empty to represent just the fact that the corresponding Measurement was carried out.
We have a use case where the study is interested in the fact that the Measurement was ordered, even if it was never curried out.
Would it be possible to extend CDM to cover this, maybe using measurement_type_concept_id = 44803837 “Service order request”?
Then a record with this measurement_type_concept_id and empty value_as_number and value_as_concept_id will indicate “Measurement {measurement_concept_id} was ordered”. If there is a result for the order, it will be in a separate record for the same measurement_concept_id and one of the 5 measurement_type_concept_ids from vocabulary ‘Meas Type’.

#5

@apeshansky:

Yep, we could do that. I am trying to think whether that requires a Working Group session, or whether we can add the Type Concept. BTW: Type Concepts we just create, we don’t have to use an existing SNOMED Concept for that. So, we could just have “Test ordered through EHR” or something like that. You tell me.

#6

@Christian_Reich: I am a somewhat adherent of Occam’s Razor: “Entities must not be multiplied beyond necessity” :wink:
But if you think it is necessary, I’ll defer to your judgement.

#7

One option to consider within the current structure is modeling the order as a procedure: one orders a procedure (procedure_occurrence) which generates a result (measurement). This generates its own set of issues (most immediately, the relationship between procedure and resultant values is often 1:N), but it fits many data sources, and somehow feels better than calling the request and the result separate measurements.

YA option, if it’s important to stay in the measurement table, might be to model the request as a valueless record with measurement_type_concept_id denoting a request, and then replacing that with a valueful measurement record with measurement_type_concept_id denoting a result, when the result is available. This is analogous to, say, updating a lab test in progress, and once the lab result is available, the request record doesn’t really give you added information (presuming the test wouldn’t have happened if it wasn’t requested).

#8

Well, then you have the shave in the opposite direction: A Concept created for the very simple purpose you need is better than a SNOMED Concept that who knows where it came from, and who knows what’s going to happen to it. :smile:

The problem is 1:N, as you state, but also 0:N - the vast majority of tests do not have an explicit procedure. Phlebotomies are usually encoded. You’d have to artificially create phlebotomy procedures, but that would create it’s own problems (unknown procedure_date, inflation of pretty useless data).

Why would you replace it? Just have it there twice. One valueless when the order happened, and one when the result comes in. And then Alexandre has his pairs.

#9

@Christian_Reich: I stand corrected (or should I say “shaved”? :wink:
So what is the procedure of reserving the concept_id for the “Test ordered through EHR” (I believe the name fits perfectly)?

#10

@apeshansky:

You just did. :smile:

Except we may want to run it through the group.

#11

the order as a procedure: one orders a procedure which generates a result

The problem is 1:N, as you state, but also 0:N - the vast majority of
tests do not have an explicit procedure. Phlebotomies are usually
encoded. You’d have to artificially create phlebotomy procedures, but
that would create it’s own problems (unknown procedure_date, inflation
of pretty useless data).

Sounds datametaphysical. All measurements have a procedure – if they don’t we call it a “fabrication”. :slight_smile: We tend to see the procedures in our data, because we have a window into the ordering workflow (and the compliance folks tend to call a real measurement whose procedure they can’t see either “unbilled” or “fraud”.) But the underlying principle holds: if you have to synthesize a record from a request to obtain a measurement, you might think of that as the procedure itself rather than as the anticipated measurement. TMTOWTDI, of course.

and then replacing that with a valueful measurement record

Why would you replace it? Just have it there twice. One valueless
when the order happened, and one when the result comes in. And then
Alexandre has his pairs.

Well, I’d replace it because there aren’t two measurements, just two states of the same measurement. :grinning: But I agree you’re fine either way, as long as you’re careful about measurement_type_concept_id. And either way you can use fact_relationship to link the two if you need to keep track of what begat what.

#12

@Christian_Reich: What is a timeline for that (getting the actual concept_id value)? We need to submit our data soon.

#13

5001 Test ordered through EHR

You’ll get it in the next release.

#14

Thank you! Starting using it now :wink:

t