OHDSI Home | Forums | Wiki | Github

4203722 (Patient encounter procedure) is broad for mapping

Vocabulary Users
#1

Hi I am trying to map some of the observation concepts to standard concepts. These concepts are all mapped to this 4203722: Patient encounter procedure, which seems really broad.

My source concepts are gender specific, such as:

Mammogram:

  1. 45542403: Encounter for screening mammogram for malignant neoplasm of breast
  2. 1576008: Encounter for screening for malignant neoplasm of breast
  3. 45566396: Encounter for other screening for malignant neoplasm of breast

PSA test:

  1. 35225072: Encounter for screening for malignant neoplasm of prostate

Pap test:

  1. 45600305: Encounter for screening for malignant neoplasm of vagina
  2. 35225071: Encounter for screening for malignant neoplasm of cervix

However those encounters are all mapped to this gender-neutral concept 4203722. Is it possible to map those concepts to more specific standard concept?

#2

Hi @xj2193

Did you check the “Maps to value” links?
The thing is many of these ICDs (not all of them thought which is another problem) are mapped to a broad Encounter procedure and the actual procedure is mapped to the value_as_concept_id field.
The reason for that is uncertainty about whether the procedure was actually performed or only the visit happened while the procedure is still a matter of decision that would trigger a false positive record.
We never really dived deep enough into the problem, therefore the consistency in ICD/other source vocabularies mappings may vary.
So it’s another construction site that requires attention.

#3

Ouch! So, the patient encounter part of the concept goes to the OBSERVATION.observation_concept_id field and the type of patient encounter goes to the MEASUREMENT.value_as_concept_id field. And for those records which go to the Measurement table, they will have MEASUREMENT.measurement_concept_id = 0.

Since the examples @xj2193 gives are not results, I don’t think this mapping is correct. Using concept_id = 45542403 as an example, it maps to = 4203722 in the Observation table and maps to value = 4147961 in the Measurement table. Per the CDM v5.4 definition of the MEASUREMENT.value_as_concept_id field “If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the ‘Meas Value’ domain”.

Do we have a rule about domain designation for the ‘maps to value’ concepts? Whenever a non-standard concept_id maps to > 1, with one relationship = ‘Maps to’ and the other relationship = ‘Maps to value’, we really should try very hard to have it map to one row in the CDM. It’s very hard to post-coordinate concepts, especially ones which are mapped to two different tables and fields. Maybe we need an “Obs value” domain_id? Per the OBSERVATION.value_as_concept_id description, “It is possible that some records destined for the Observation table have two clinical ideas represented in one source code”, this solution would align the meaning of the concept with the definition of the field. But, I will argue a screening mammogram and almost all other screenings are procedures because they have a “diagnostic purpose” and they can and sometimes are measurements because they encompass “systematic and standardized examination or testing of a Person or Person’s sample”. And “other screening” could be imaging or biopsy. I don’t envy the OHDSI Vocabulary team’s job. These vague terms are quite complex!

#4

Why that? “Maps to” and the domain of the target concept define where the “Maps to value” goes.
And since the value_as_concept_id field exists in both tables, there’s no contradiction.

It has nothing to do with this situation. It’s nether a Measurement nor a categorical result.
It would follow the Observation conventions, the same we use for the “History of” values.

It’s more a question of why we still have a Standard concept of the encounter as opposed to actually creating the visits out of these records. But in CPT/HCPCS many didn’t like the idea.

Probably because of

They go to the same table where the concept_id goes. They should not be interpreted separately.

No need, since the value_as_concept_id in the Observation table is not that strict and can fit everything.
We don’t even follow the rule for the MEASUREMENT.value_as_concept_id and said we need to change the convention.

It’s not a question of whether they are or not. Could fit any Domain. The question is if we’re certain enough to create the independent event out of them, or if we should still “hide” them in the value field.
The current answer was no.

#5

The problem is when an analyst is creating a concept set or using a cohort. If the domain_id of the standard concept = “Measurement”, then people will be looking in Measurement.measurement_concept_id for the data.

It makes sense from an ETL point of view, but it also needs to make sense from a concept set - cohort creation point of view.

#6

This is what I’m saying. The example above is in the Observation Domain, so there is no need to look up the measurement table. “Maps to value” could target various things like Meas Value, Geography, or Measurement Domain concepts, but they all don’t define the landing table.

This is the same as what we claimed to be a convention for a history of events here. The value could be everything, but the event itself always sits on the Observation table.

t