OHDSI Home | Forums | Wiki | Github

Overhauling Measurement Types

CDM Builders
#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”.

#21

Do we have any consensus where to store height / weight / BMI / blood pressure in CDM?
(Is it Measurement ? or Observaiton?)

#22

Hi all,
I have a quick question. I’m trying to convert from national emergency department data to CDM. Are GCS (glasgow coma scale) and AVPU scale observation? or measurement?

#23

Looking at my v5 Concept table, I see:

glasgow coma scale mapped to 3 possible domains:

  • Condition: using SNOMED and a specific score value defined in the Concept name “4008896 Glasgow coma scale, 4”
  • Observation: using SNOMED Staging/scales as concept “4296538”
  • Measurement: using LOINC as concept “3032652”

AVPU (alert voice pain unresponsive):

  • Observation: using SNOMED Observable Entity as concept: 44808540
  • Observation: using SNOMED Staging /Scales as concept: 40493498
1 Like
#24

We updated the vocabulary and now SNOMED Staging/scales belong to measurement domain.
So “4296538” (glasgow coma scale) and 40493498 (AVPU - alert voice pain unresponsive scale) belong to measurement domain.

1 Like
#25

I am working with height data. There is not a concept_id for “inches” in the Unit domain. Should concept_id = 4121360 be moved from the Observation domain to the Unit domain? It is a standard SNOMED code with concept_class_id = Qualifier Value.

#26

It’s concept_id=9930.

#27

And, btw: If we need a unit UCUM has a procedure to make any one we want. So, no need to “move” anything.

#28

9330

1 Like
#29

@wstephens Thank you for reply!, @Dymshyts It sounds great! I will use these concept. :grin:

t