Observation_concept_id should not be conditions, procedures, drugs or devices

[askanter]

Observation_concept_id

CDM or THEMIS convention?

CDM

Table or Field level?

Field

Is this a general convention?

Does this convention apply to the model at large or perhaps applies to multiple fields (i.e. how datetimes are represented)
No

Summary of issues

• What concepts can be linked to the observation table?

Summary of answer

This is a foreign key of the CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains should NOT be included as observations, but go to their corresponding table (Problems/diagnoses/conditions to the Condition_occurance table, procedures to procedure_occurance, etc.

Observation concepts should be standard concepts as usual.

Related links

[- Put any links you have found related to this convention]

Other comments/notes

• Please use this section to add any other relevant notes or comments. (i.e. if links are not working, something is out of date or deprecated)

[askanter]

Note that Christian adds Specimen and Visit to the list of domains not in observation: https://forums.ohdsi.org/t/there-are-not-enough-observation-concept-id-in-the-omop-cdm/8396/4?u=andy_kanter

[MaximMoinat]

Issue # and location

CDM issue #635

Issue summary

observation_concept_id should not be conditions, procedures, drugs, visit, specimen or devices

Convention type

Table

CDM table

observation

CDM field

observation_concept_id

Links to issue discussion

• OHDSI Forums discussion
• CDM Documentation

Provenance of data

General

The ratified convention

Although the general convention is that the domain of the concept should match the domain of the table, the observation table can contain a mix of concept domains. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, Specimen, Visit or Device domains should NOT be included as observations, but go to their corresponding table.

Observation concepts should be standard concepts as usual.

Date of ratification/published

NA

Downstream implications

In Atlas cohort definitions, when selecting the observation table in a criteria, it should be allowed to select a concept_id from any domain.

Link to DQD check

Yes - fkDomain.

Related conventions/further information

To insert: link to general convention of mapping concepts to respective domains.

#Tags
observation, domain, concept

[MaximMoinat]

To the reviewer: this convention is actually an exception to the general convention that concept domain should match table, i.e. "Records with concepts from domain condition, procedure, drug, visit, specimen or device have to go to corresponding tables."
Also note that the original documentation is a bit unclear whether this goes for observation_concept_id or observation_source_concept_id.

[MelaniePhilofsky]

@clairblacketer There is conflicting information in our documentation about which concepts/domains can live in the observation_concept_id field.
What is the use case to store data in observation_concept_id where the standard concept domain_id is not 'Observation'? Our documentation states to exclude most clinical event tables, but the exclusion list leaves us with domains like location, specialty, cost, currency, etc. Why would those be allowed in here? Shouldn't those only go to their table/field?

[clairblacketer]

@MelaniePhilofsky and @MaximMoinat I don't think we need to be prescriptive to the point of listing all the possible domains that could go in the observation table. We should give more context around what the Observation table is used for, reiterate the movement of records based on condition, drug, procedure, measurement, device, specimen, and then describe ways the Observation table is used like 'history of', marital status, tobacco use, etc. I will add this to the CDM docs