Was @bailey's post in https://github.com/OHDSI/CommonDataModel/issues/5
@bailey commented 5 days ago
I'm struggling a bit to understand the uses for measurement_type_concept_id as opposed to measurement_concept_id. Thinking abstractly, the two categories of measurements we're currently recording that are different from vital signs are anthropometrics (heights, weights, etc.) and Z scores for physical measurements, but I'm not sure whether they'd benefit from separate measurement_type_concept_ids. @cgreich, do you have any insight from the use cases that drove the original four values?
@Christian_Reich commented 4 days ago
Well, usually the types are used to understand the provenance of the data. For example, whether drug information is from prescription orders or filling at the pharmacy. They are not supposed to be a type or classification. That is done in the Concept world: There, the concept_class_id field and the classification Concepts connected through the CONCEPT_ANCESTOR table will do that job for you.
Currently, we have the following Measurement Types:
- Patient reported value
- Pathology finding
- Lab result (should probably better called "Clinical laboratory generated" or so)
- Vital sign (should probably better called "Established through physical examination" or so)
Sounds to me like your height and weight are "Vital sign" types. The Z scores are calculated. Do you think it makes sense to create a "Calculated value" type?
@bailey commented 23 hours ago
@Christian_Reich : Thanks for the clarifications. With name changes, the anthropometrics should fall under the existing physical exam findings category nicely. I do think that a derived value/calculated value/what-color-is-your-bikeshed value makes sense. A few other categories to consider:
What's the limit of lab result? A serum Na is clearly in. A creatinine clearance is probably in -- it's derived but the lab does the derivation. An ejection fraction (imaging study)? A bone density? Is the defining principle for a lab result that the analyte must have been separated from the patient? I'm hearing the ghost of Potter Stewart here.
If the critical element of Lab result is that it's separate from the patient, is there a unifying type for testing that doesn't (imaging, ECG, EEG, EPS, etc.)?
I'm not quite sure how to think about cognitive instruments (typically surveys) that produce quantitative scores. If one captures item-level responses, those seem to fit best as Observations, but something like an APACHE score is arguably "a structured value (numerical or categorical) obtained through systematic examination of a person". Best to consider as just another type of derived value?
@Christian_Reich commented 20 hours ago
@bailey (and the Potter Stewart ghost reading this over your shoulder):
Yes, we tried a definition as you are quoting at the end. All of your examples including the ejection fraction, ECG, EEG would be covered. Surveys we already discussed here: http://forums.ohdsi.org/t/are-surveys-measurements-or-observations/186, and folks deemed them observations.
But you are right, there are quite a few concepts that fall between categories, and we will have to do the Potter Steward thing, look at them and know what they are. I have no other solution.
@bailey commented 18 hours ago
So ordered. My short-term requirement is an ETL spec for network sites, so let me try this as a concrete proposal:
- We rename "Vital Sign" to "Physical examination finding", and we'll use that for the heights and weights.
- We add a new category "Derived value", and we'll use that for Z scores and the like.
- When we get to stuff like APACHE or PGH-7, we'll use "Derived value" as well, and figure out then whether the raw elements are "Patient reported value"s in Measurement or are surveys in Observations.
- I'm still stuck for the noninvasive stuff (and yes, anyone who's ever had an EMG or the like is free to quibble about whether it's noninvasive). "Imaging" seems too narrow, but the SNOMED approach ("Procedures") too broad.