@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.
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
@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”.
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. 
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.
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…
@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
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
@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.
@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.
Bill!!! Hey! No sinning. No deviation from the right path here! 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.
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 
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
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.)
@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.
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.
That is correct. I currently have no opinion on physiometric scales because we are not working with any of that data yet.
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”.
Do we have any consensus where to store height / weight / BMI / blood pressure in CDM?
(Is it Measurement ? or Observaiton?)
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?
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
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
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.
It’s concept_id=9930.