Page on custom concept convention (Themis issue 73)

[MaximMoinat]

Resolving OHDSI/Themis#73

Open questions:

• Reusing concept_class from other vocabularies? e.g. 'Clinical Finding' for Conditions, 'Procedure' for Procedures? Or request an 'empty' class? --> we can use the concept class 'Undefined' (which is the concept class of concept_id 0)
• Setting vocabulary_concept_id to 0 --> provisional decision 2023-12-07: this is allowed
• Advice on creating concept_hierarchy. Is this indeed only for standard concepts? If allowed for custom concepts, can custom concepts be descendants/parents of standard concepts?

[AgnesWW]

Here is my humble ETLer perspective:

1. vocabulary_concept_id

I am for: Setting vocabulary_concept_id to 0 and the convenion to put the abbrieviated name of institution as a part of the vocabulary name. (If given custom vocab is rebuilt we can also add version as second part of the name.)
Example: MYINST_PH2_PROVIDER for My Institution second phase of the project provider custom mappings.

I am against: Adding requirement for the institution number as a part of vocabulary_concept_id.
It may generate unnecessary work of assigning institution an OMOP recognized number and keeping up with this system ( guaranteeing uniqness of assigned id-check against vocabulary ids used already etc.) I find it an administrative overkill unless we have some institution ids and coventions readily available in the bigger schema of things. The id would need to be greater than all vocabs ids in Athena.

2. concept_class

Reusing concept class from other vocabs seems OK to me too - we can list the classes and have some 'Undefined' as allowed if the class is difficult to find. I would suggest to add the list of commonly used concept classes as the reference for ETL er in the documentation.

[askanter]

So we are defining custom concepts as never being part of OMOP vocabularies? This assumes that the missing concept is not going to be re-used and only has value to the local institution. The Jackalope concept creates custom concepts that are precoordinated standard concepts. These clearly could be re-used. Do we want to distinguish up front that our definition of "custom" excludes these other use cases for creating concepts?

[MaximMoinat]

To me, custom concepts and standard concepts are mutually exclusive. Adding concepts (as standard OR non-standard) to the OHDSI vocabularies is a separate process.

There are several subtleties of course, which we might want to address or not:

• A method to go from custom concepts to a contribution to the OHDSI vocabularies. Only at this point a concept_id <2B would be assigned and possibly made standard. Always in collaboration with the Vocabulary WG.
• Once your source vocabulary has been added to the OHDSI vocabularies, then of course your mapping strategy will change and you might not have a need for custom concepts anymore.
• Custom concepts will always be more flexible than adding your concepts to the OHDSI vocabularies, as you don't have to go through the vocabularies release process.

[MaximMoinat]

@AgnesWW thanks for your feedback. Agree with all, except for:

I am for: Setting vocabulary_concept_id to 0 and the convention to put the abbreviated name of institution as a part of the vocabulary name. (If given custom vocab is rebuilt we can also add version as second part of the name.)

Adding the institution name is fine, but I don't think we should make this a convention. This should be a decision by the local ETL team. A custom vocabulary might not be just be defined within an institution.

[AgnesWW]

Sure we can leave the naming to the vocabulary owner, they may have some internal convention already from previous work and want to keep it for consistency.

[clairblacketer]

@MaximMoinat I added this page in a separate PR: #651 because I was having trouble rebasing your fork.

[clairblacketer]

https://ohdsi.github.io/CommonDataModel/customConcepts.html