Clear documentation on conventions for Custom Concepts

[StijnDupulthys]

It is currently difficult to find clear documentation for a convention on how to use custom concepts (e.g. for internal use), as I mentioned on the OHDSI forum. Two example cases for which we couldn't find a convention:

Example case 1:

• We have drug_source_concept_id's, as ATC codes
• We mapped our drugs to the closest fitting Standard concepts (so mostly RxNorm (Extension))
• We have some trial drugs (in oncology) that we gave custom concept id's, where do we put them, since their ATC code concept id is already in the drug_source_concept_id? We obviously don't want to lose the more granular information for internal use.

Example case 2:

• We have custom condition_type_concept_id's for diagnoses derived from the automatic protocol of ECG machines and from screening apps/wearables (fyi, they also get condition_status_concept_id = "Preliminary diagnosis")
• There is no condition_type_source_concept_id, so should we add extra columns?

(Our original, wrong, interpretation: we used our custom concepts as local 'Standard' codes, used them in the _concept_id columns and put normal (< 2Bilj) ids as their parents in the concept_relationship table; we thought this was the entire goal of the >2Bilj rule)

[askanter]

This seems related to the discussion on post-coordination or interface terminology that has come up in several WGs (HS, ONC), etc. These examples could inform those discussions...

[MaximMoinat]

An unofficial set of conventions around customisation was presented by Melanie here: https://www.ohdsi.org/2021-global-symposium-showcase-18/

A few general guidelines based on that poster:

• Custom concepts are always 'non-standard' (concept.standard_concept = NULL).
• Custom concepts can only be used in the _source_concept_id fields
  • Columns like _type_concept_id do not have a equivalent source concept field. So we cannot use custom concepts for these.
• Don't repurpose/change standard OMOP concepts. Preferably add custom concepts only to separate (source) vocabularies.
• It is encouraged to use custom concepts to create vocabulary mappings to standard concepts. See this poster titled "Mapping Custom Source Codes to Standard Concepts: A Comparison of Two Approaches"
• Do remember that custom concepts are not available for network queries.

[MelaniePhilofsky]

Themis discussed on 8/17/23, we have two separate issues:

1. ETL use for source codes; Local, source values being mapped to standard concept_ids; Usagi still uses STCM;
2. Broader use of local vocabularies, potential integration into the OHDSI supported Vocabs, potential hierarchies, used by sub-groups

Themis can and should give guidance on #1. The Vocab group and broader community will give guidance on #2.

[MaximMoinat]

Themis WG discussion 2023-10-06

General rules for creating custom concepts:

• Custom concepts are always 'non-standard' (concept.standard_concept = NULL).
• Custom concepts can only be used in the _source_concept_id fields (e.g. condition_source_concept_id)
  • If field _source_concept_id does not exist, add custom column to your table (adding _source_concept_id fields in standard CDM is a separate discussion for the CDM WG)
• Don't repurpose/change standard OMOP concepts.
• Always add custom concepts to a new vocabulary
• Advise on how to populate the fields for Concept table
• Advise on how to populate the fields for Vocabulary table
• There is a separate process for adding new (source) vocabularies to the global OMOP vocabularies.

This can be documented on a new 'Conventions' page on the CommonDataModel Github.ui page.

This should also contain a reflection on when to create custom ( >2 billion) concepts and insert into Concept and Concept Relationship tables versus when to use the STCM. With pros and cons of both methods. Including advise on creating bi-directional relationships in concept_relationship table.