OHDSI Home | Forums | Wiki | Github

CPT codes in MEASUREMENT?

Vocabulary Users
#1

I am trying to do an analysis of patients with breast cancer, specifically the results of HER2 and estrogen and progesterone tumor receptor tests. I realize that these results are typically captured in sequencing tests, which are interpreted by a pathologist and (at least at our institution) exist only in free-text notes (in our case sent to the EHR via HL7 from CoPath).

So I was very curious to find that there are what appear to be ORDERS for these tests in measurement, which seems confusing because I was under the impression that measurements are supposed to be results not orders.

For example:

SELECT
concept_id,
concept_name,
vocabulary_id,
domain_id,
concept_code,
COUNT(1) AS cnt_condition,
COUNT(DISTINCT person_id) AS cnt_pts
FROM
concept a
LEFT JOIN
measurement b
ON
a.concept_id = b.measurement_concept_id
WHERE
concept_name LIKE ‘%estrogen%’
GROUP BY
concept_name,
vocabulary_id,
domain_id,
concept_code,
concept_id
HAVING
COUNT(DISTINCT person_id)>0
ORDER BY
COUNT(DISTINCT person_id) DESC;

I am looking at the top two codes at our site, which are CONCEPT_ID’s 2213308 and
4307360. Looking at the first one, the vocabulary_id is CPT4, and when I look at the raw measurement values:

select count(measurement_id) from measurement a where measurement_concept_id = 2213308 and (value_as_number is not null or value_as_concept_id is not null) ;

I get no measurements that have actual values. I was expecting there to be NO measurements using these concepts (because the positive/negative values are coming from free-text) but instead I see lots of them using a concept that seems to be in the wrong domain, none of which have valid actual results.

What gives? Is this a mapping problem we made or is this expected behavior?

TIA!

#2

Expected behavior. MEASURMENT doesn’t just contain results, it can also contain the existence of a measurement without its corresponding result (e.g. just the order). Here’s the CDM MEASUREMENT table description: OMOP CDM v5.4

#3

@blm14 Your use case is similar to what I am doing right now with Sunnybrook Research. We also have a lot of pathology reports in free text format sent to the EHR via HL7 from CoPath.
My understanding is that CPT4 concepts will be mapped to OMOP Cancermodifier standard vocabulary first. In my “proof-the-concept” prototyping experiment, I use USAGI manual queries to map from the source concept instead of the code-to-code automapping. Then I will verify my mapping with the OMOP CDM V.5.4 spec.
My gut feeling tells me that you might have a mapping error. However, I will need to know more details before I can be certain and provide a possible solution. Please feel free to contact me at che@sri.utoronto.ca for more details.

#4

@blm14 I have just confirmed with my manager at Sunnybrook Research today that we are going to have a new project in January 2022, which will involve a lot of CoPath stuff. Are you interested in collaboration with us?

#5

You should also check the measurement.value_source_value field. Since your result data are free text, it might only live in the value_source_value field if they haven’t been mapped to a standard value_as_concept_ids. Or maybe these records are just records of the test being done, as Patrick pointed out.

Which concept do you see? Are these in the value_as_concept_id field?

t