OHDSI Home | Forums | Wiki | Github

Overhauling Measurement Types

CDM Builders
#1

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: Are surveys measurements or observations?, 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.
#2

I agree that 2 tables - MEASUREMENT and OBSERVATION present a classification problem.
Perhaps we will merge them in v6. (who knows)

Note that OBSERVATION has an additional qualifier column which many people may like. ( something like “coded value 2”)

As some guidance for v5 implementers - I would include on the CDM spec site as many examples of exemplary MEASUREMENTS as possible. (even some examples for the type_concept_id column)

#3

Do you mean: these fields in the observation table- I don’t see anything “like coded value 2”
qualifier_concept_id
qualifier_source_value

And then the Measurment table has:
value_source_value;

The source value associated with the structured value stored as numeric or concept.
This field can be used in instances where the source data are transformed to procedure the structured value

#4

I recall the suggestion from the discussion about surveys proposing that the classification depend on reliability of the test. That leaves a lot of grey area for me, especially when I’m considering clinical reliability rather than technical reliability of the assay. What I’ve been thinking more recently is that best distinction may be on the characteristics of the result: MEASUREMENT fits well for things that have discrete values, units, and normal ranges; OBSERVATION fits well for things that are more Boolean or qualitative. That doesn’t eliminate grey areas, but at least it’ll let us use each table to its greatest advantage.

I agree with the value of examples. My worry is that using the Potter principle we’re going to end up with different analyses “expecting” a given datum in different places, depending on what it looked like to the person writing the coder.

#5

@Vojtech_Huser: We just split the Observation and the Measurement! :slight_smile: The latter contains well curated quantitative or qualitative results from a defined measurement. Surveys really aren’t measurements. You need some kind of explicit appliance. Of course, to measure the pulse that appliance would be a watch (iPhone these days), and then you could say a survey needs a pen, but I think we can make that distinction.

The qualifier column “which many people may like” - what do you want to do with that? It should really only qualify the observation, like in a severity. We haven’t seen much use case for that, and if we continue not seeing it the danger will be that we will kick it right out again.

I agree with the examples for clarity. However, you don’t need it for ETL. The vocabulary tells you what domain a certain Concept is and where to put it. If you want to query it and don’t know in which of the CDM data tables, again, go to the CONCEPT table and look up the domain.

@bailey: Not sure where you had that discussion, but I may have missed it. I think the distinction is neither reliability, nor quantitativeness, but explicit method, usually involving a specialized tool, device or appliance. Anything you would call a test. But yes, there are shades of gray.

#6

@cgreich: Mostly trying to synthesize a few different discussions. The problem with the definition as you articulate it is that surveys are almost by definition obtained using an explicit method or specialized tool, so would quality as measurements. Ditto for composite scores like APACHE.

#7

@ningyifan, @rkboyce, @wstephens: Take a look here. I need you all to come to the same page before I start the surgery and re-declare things.

#8

@Christian_Reich

I’m fine with the split between Observation and Measurement as it represents a differentiation between quality, trustworthiness and use of specialized equipment and techniques. Perhaps the names are getting in the way? I think of Measurement as “assay”/“analysis” and Observation as “examination”/“response”.

It also seems that units can provide some guidance here. I could reasonably expect the observation of gross values (kg/cm/Likert/dates), but not fine values (mmol/L, mmHG, # cells per HPF).

Following this approach, patient provenance measurements seems odd…

Examples:

  • Weight / height: lbs/kg/in/cm: Observations
  • Medical history: Patient provided: Observations
  • Survey response: Patient provided: Observations
  • Dietary recall: Patient provided: Observations
  • Bone Density: Obtained from imaging inside of body using specialized equipment: Measurement
  • Ejection fraction: Obtained from imaging inside of body using specialized equipment: Measurement
  • Urine appearance: Obtained from specimen, evaluated by clinical staff: Measurement
  • Hematocrit: Obtained from specimen using specialized equipment, mm/dL: Measurement
  • BP: Obtained using specialized equipment, mmHG: Measurement
  • Heart Rate: Obtained using specialized equipment: Measurement
  • Blood sugar from lab specimen: Obtained from specimen, performed by clinical staff, mmol/L: Measurement
  • Blood sugar from patient monitor: Obtained from specimen, performed and reported by patient, mmol/L: ???

My main issue with processing Survey/History data into observation has been conceptually mapping questions and responses. This is mainly because the CRFs were not developed with thought of the available biomedical terminologies. There are many questions that can almost be mapped, but were written in negated form (“I have never has heart problems: T/F”. “Birth Weight Unknown: T/F”). Also, the Observation table ends up containing condition, procedure… that cannot be mapped to a term in the Observation class.

Bill

#9

@wstephens I mostly agree with your examples, with the exception of weight/height - no different from BP, for instance, and I’d argue was a Measurement.

I think the quality/trustworthiness criterion is something of a red herring, and would argue to stay away from it in the spec, in large part because I think it’ll create variations in ETL across different instances that will inhibit standardizing analytics. (I trust my spun crits, so I call it a Measurement; you don’t, so you call it an Observation.) I understand that to some extent the concept domain addresses this, though I think there’ll be drift as people propose new tests for inclusion.

In terms of the data model, the range attributes are really what distinguishes the two tables, so I follow your thinking about “assays” vs “examinations”.

#10

Gents: Don’t get too upset what people call it. We will decide here, and than it becomes the commandment the Lord hands to the prophet. The domain_id will tell everybody what we (Lord, prophet) think it is. :smile:

But we need a set of rules we like, we can put down in the description, and then use for domain assignments.

@wstephens: I agree with @bailey on the weight/height thing. Of course, you can slowly drift further to the right: Pulse (still measurement? No instrument but your iPhone), reflexes (needs a hammer, but subjective “measurement”), auskultation, Karnofsky? So, no matter where you draw the line, there will be wishy washy cases straddling it.

#11

Yes, height and weight can be in either according to the conceptual mappings. I’ll place EMR values into measures, Patient-reported into Observations.

Yes, many gray areas here…

#12

@Christian_Reich, @bailey, @wstephens and All,

For our part, we are working with an assessment instrument called the Minimum Data Set that is interesting to represent in the CDM for the following reasons:

  • It is a nurse assessment done periodically and so in principal contains observations - so would not fit in any measurement types I saw listed above.

  • Patient conditions from the patient charts are listed as ICD codes that can go into the condition table

  • The assessments contain both validated psychometric scales such BIMS (cognitive status) and PHQ-9 (depressive symptoms) which result in something like measurements (quantitative scores) but that also can be interpreted as conditions based on expert guidelines (e.g., depression if PHQ-9 score > X)

  • LOINC (and standard vocab) has codes for all of the questions such as 40757755 = “Cognitive skills for daily decision making in last 7 days MDSv3”.

  • LOINC has answer codes for the questions that are not yet in the standard vocab (hence our discussion! Are surveys measurements or observations?)

Wrt to the question about placing survey items in measurements. Based on our limited experience, we might propose that values from any psychometric scale be treated as observations, regardless of the value types.

This is how we do it now - our working interpretation is that all MDS data except the conditions be coded as observations using the concept ids for LOINC question codes and answers (once in). Business rules in our ETL are then applied to translate the subset of observations from validated psychometric scales that can be interpreted as conditions. For example, major depression if found by PHQ-9 because, in general, this treated clinically as lasting condition from which a patient could have remission.

-Rich and Yifan

#13

Rich,

This is almost the same solution that I arrived at for CRF data, except that I placed conditions into Observation because they were actually patient reported condition history items (HX, Family HX) rather than actual provider identified problems or EMR diagnoses.

Placing the LOINC concept mappings into Observation for these CRF-type questions means that we’re breaking the domain specification on the Concept entry. However, I think placing these (ex: 3045933) into Observation is the correct move.

Looking further into my example shows that the items I mapped were actually part of the LOINC Patient Health Questionairre
3045933, “Trouble falling or staying asleep, or sleeping too much in last 2 weeks Reported PHQ-9”

Looking into Concept, I see that all LOINC Measurement concepts are mapped to the “LOINC” concept class rather than the class that LOINC defines.
According to OMOP, this is Concept Class = “LOINC”
According to LOINC, this is Class / Type = “SURVEY.PHQ/Survey”

I wonder if we could update the LOINC concept mapping to redirect these survey concepts to Observation?

Bill

#14

@rkboyce: Am I understanding rightly that you’d like all psycometric scales to be in Observation, but are agnostic about physiometric scales? I’m happy to agree to disagree on psychometric scales, but might push back more on moving physiometric scales to Observation because they’re scales – still trying to wrap my head around the boundaries. :smile:

@wstephens: One thing that keeps hanging me up about this approach (goes to Observation based on how reliable we think it is) is I can’t see how we avoid having to comb through LOINC item by item and decide how to allocate them. But that may just be an artifact of my biases.

#15

@wstephens

Bill!!! Hey! No sinning. No deviation from the right path here! :smile: Instead, let’s fix the domain assignments if you can agree on the right one.

Already fixed. I can show you if you want in dev.

We can, and I already have it in the concept_stage.

Let me know. The best would be if there was a clear heuristic, and not a manual step in these.

#16

@Christian_Reich

I did what I had to do for this project. Splitting the CRF data between 3 tables (condition, observation and measurement) seemed like a more difficult approach for the end users who needed to query data. I really needed a structure that allowed me to store patient reported survey structured data (Form, Question, Response) with concept mappings, but it doesn’t exist.

Perhaps I just like breaking rules :wink:

This project (using CDM v5 and Achilles) is wrapping up and being presented next week. I’ll wait to update to the new Vocab in a future sprint at this point.

Bill

#17

I have been following this because we have some questionnaire data that we will be putting in.

One might be able to narrow things down like so:
If it has units, it is a measurement (labs, pulse, walking speed, etc.)
If it is reported from a lab without units, it is a measurement (e.g., urine color)
If it is patient reported, it is observation (e.g., survey responses)
If it is a patient assessment based on physician perception or measurement it is an observation (e.g., reflexes, functional status)
If it is something else, it is an observation (e.g., survey weights, comorbidity score, etc.)

#18

@mark_danese I’ve been closing on a sort-of similar hierarchy, since it seems like the units/range are one distinguishing mark of the Measurement table. The parts that seem hardest to me (and this is where @wstephens and I might diverge) are the scales that reflect some quantitiative assessment by a person. (I’ve been using GCS and APACHE as my motivating examples; they don’t really .) I put less weight on who reported it, but am willing to be the minority voice. I’m not sure whether it says I have unusually high confidence in my patients or unusually low confidence in my colleagues. :smile:

Some of the drift may also be that we started in a different place from @wstephens: we’ve been using the CDM to integrate a bunch of patient registry data, and have been routing concepts to Condition_occurrence, Drug_exposure, etc. rather than routing it all to Observation. To some extent, the type concepts help out (for example ‘hx of’ in Observations vs ‘patient-reported’ in Condition_occurrence). But I like the idea of thinking more about ways to represent a question/value set without having to hack the vocabulary.

#19

That is correct. I currently have no opinion on physiometric scales because we are not working with any of that data yet.

observation_type_concept_id for HCUP-NIS ETL
#20

I like very much what @bailey had suggested:

But I like the idea of thinking more about ways to represent a question/value set without having to hack the vocabulary

I think we should start a new forum topic that would go after exactly this.

I think CDM is a great tool for not only running common analyses but there is some early use to use it to communicate routine care data + research eCRF data.

We should think about clear research scenario. Something like - my warehouse also has data from 3 clinical trial studies. eCRFs data - they are “like observations” but they are special in a way.
At NIH clinical center, we use CDISC ODM way of thinking about eCRF.
Patient is assigned to a trial that has an NCT identifier.
Within a trial - there are eCRFs. eCRFs have sections, and sections contain questions and questions may have (or even share) a value-set. We currently have that as “special tables” outside CDM tables. But maybe there is more of us with interest in eCRF and our special tables may be “similar”.

t