| OHDSI Home | Forums | Wiki | Github |
These CPT codes belong to the domain of measurement
So they should be in the measurement table
But, there is no appropriate measurement_type_concept_id, if the provenance of the data is from claims. The only concept_id’s available to populate measurement_type_concept_id are
Do we need a new measurement type concept id – ‘Measurement reported in a claim’?
How about “Medical claim Measurement order”.
Sounds right.
This may be more of a THEMIS request than germane to this topic, but we’re developing a mixed semantics problem in measurement. There’re the first class citizens, whose semantics are, “Here is the measurement for something.” Then there are the second class citizens, whose semantics are, “I asked somebody to measure something. I don’t have the actual measurement, but I wanted to let you know.”
The second class citizens create a handful of problems. Most importantly, they don’t have the result, which is what we often want 
(and the table is structured around). Second, there’re granularity mismatches (e.g. panel vs component), though that’s sort of theoretical. Third, there’s ambiguity about whether a particular thing is a procedure (we took some blood), a measurement (that blood was used to measure some stuff), and an observation (we measured some stuff from that blood, but we think the result is more observation-y than measurement-y.), though domain_id helps if you’re starting from a concept_code.
I don’t have a ready one-size-fits-all solution, but for analytic purposes it’d be nice to have a home for measurements we have, not just procedures that promise to measure something. I’m of course biased by the frequency with which I get questions of the form “have an abnormal X” rather than “looked at X”, which under my suggestion would require looking in both measurement and procedure_occurrence (or some new diagnostic_occurrence or somesuch).
I’m wrangling with this as well - when a culture panel is documented - its both a procedure_occurrence and set of observations? measurements? depending if you have the laboratory returned values available.
I’m leaning towards - if results are numeric or enumerated - use measurement to register the result. If text - found a particular bacteria present - use observation. Both would register a procedure_occurrence.
Advice from others would be helpful.
@mkwong That particular use case is tough. FWIW, the solution we arrived at in PEDSnet was to have a culture/isolate record in measurement that has a normal/abnormal result (we kept in in measurement because there’s a normal range as well as an observed value), and a separate measurement_organism table to catalog the isolates.
I haven’t gotten my act together to propose anything to the CDM group, but here’s the table as it currently exists (apologies for the image; can’t figure out how to get a Markdown table into this reply):
Hi Charles,
IMHO, this ‘Measurement’ problem is yet another compelling case for an industrial-strength Semantic Services Framework that would:
Be founded on the premise that we’d have to support an evolving n:n (as in many-to-many) relationship ‘of everything’ – whether we know of any such relationship today or not, as one ought to assume that new discovery somewhere in the healthcare / life sciences / transnational research / Precision Medicine would change it
Provide a dynamic, continuously adaptable multi-dimensional semantic model served up by graph DB technology
Rely on a technology enabled (rather than manual) version and configuration management services
I’ve eluded to this problem space and potential approaches in the OHDSI thread on “Recent changes in SNOMED CT relationships?” Recent changes in SNOMED CT relationships? and LinkedIn post “A call-to-action for disruptive Semantic Services Framework” at https://www.linkedin.com/groups/161594/161594-6354017692604780549
Thoughts?..
Friends:
Not sure I follow where the problems are:
Ok, but that’s a problem of the data. If there is no result then those fields are empty. If you want the result you query for the ones that aren’t empty. Why is this a problem of the model?
True if you are trying to combine the orders with the results.
That is a problem for which we have no generic, but only a pragmatic solution right now. Because there is a continuum between diagnostic procedures that have some kind of a result (like a biopsy) to a lab test, where the “procedure” is venipuncture. There is a project going on between LOINC and SNOMED to connect these, so at least nothing will fall through the cracks anymore. But we are still waiting.
If it has a quantifiable result it is a Measurement.
Should be a Measurement.
Those texts should be conceptualized. We have Concepts for all those test results (positive, negative, inconclusive, etc.). Measurement Concepts should not go anywhere else but into the Measurement table, otherwise you kill the interoperability of the OMOP CDM.
Hang on. The Procedure in the OMOP CDM are activities on the patient. Essentially, where it “hurts a little”. Lab procedures are not Procedures. They can lead to Measurements, though. Putting something under the microscope and counting cells or cultures is not. So, for the purpose of this discussion, only the phlebotomy is the procedure. Now, we could put a procedure “Venipuncture” each time we got a blood test done, but usually that is of so little value that it amounts to waste of database space.
Why can’t you put both into Measurement? Why do you need the extra table?
That is a problem!!! 
What are you proposing, @Ron? Do you want to make a proposal or POC? Do you have a use case that would directly benefit?
@bailey, I agree @Christian_Reich - ideas to change the core convention of OMOP/OHDSI (in this case the definition of a domain, and what concept of a vocabulary belongs to what domain) should be discussed at the CDM/Vocabulary WG.
The intent of this discussion thread was to seek guidance on implementation of these codes in OMOP CDM, with the premise that the mapping conventions are accurate.
Should we proceed with adding a new type-concept-id
@aostropolets - Could you create a measurement type concept id for app generated and manually entered from a paper form? I created an issue for the vocab wg. If not let me know which I should use for the MOCA measurement data. Thank you.
yes. 
