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?
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.
@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â.
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.
@Christian_Reich: I am a somewhat adherent of Occamâs Razor: âEntities must not be multiplied beyond necessityâ
But if you think it is necessary, Iâll defer to your judgement.
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).
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.
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.
@Christian_Reich: I stand corrected (or should I say âshavedâ?
So what is the procedure of reserving the concept_id for the âTest ordered through EHRâ (I believe the name fits perfectly)?
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â. 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. 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.
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.
But I agree youâre fine either way, as long as youâre careful about