P2 - Discussion Request: Integration of Vocabulary tables into the AccessDM

[brendagutman]

Downgraded from P1, because there are short-term, work around solutions that can be implemented prior to finalizing these decisions

Background:
Various AccessDM columns expect coded values that are formatted in an expected manner. {vocabulary curie}:{code identifier} LNC:LA34185-1. The AccessDM requires a combination of vocabulary curie and code because 'codes' are not unique across vocabularies. I'll call the combination of vocab curies and codes, curie-codes.

Example vocabularies, codes, and names(code_names).

Purpose:
AccessDM users will want to be able to join curie-codes within the Access data tables with their associated metadata,

Proposal:

1. The curie-code metadata should be available to users, and be apart of the AccessDM. The metadata tables will be referred to internally as vocabulary tables and will consist of multiple tables including: concept, concept_relationship, etc.
2. A future version of the CommonAccessDM will include these tables.

• The tables will be represented in LinkML in a GH repo separate from the CommonAccessDM
• If the current CommonAccessDM has tables that are related to vocabulary metadata these will be removed. e.g. the concept table

4. The vocabulary tables will be similar to the OMOP vocabulary tables with minor modifications/leniencies. These modifications will need to be worked out and documented.
   a. OMOP concept translates to code in our model.
   b. OMOP has column definitions that identify column requirements such as enumerations. We will have something similar, but modify them to more closely follow our needs.
5. Release schedule: Ad hoc releases in the short-term until we get stable modeling. The long term strategy can also be ad hoc with a planned data review to visualize differences between the ontology versions. Upgrade when necessary.

How will the proposed change affect the harmonization pipeline?

• The same rules that apply to Access Model changes will apply here as well. Releases, documentation, etc
• The vocabulary data can be imported into a designated schema via the import pkg.
• study-specific harmonizers will not have any extra work related to these tables. These tables will not require any harmonization but may be used for validation and analysis.

See this GH Issue for more information. - vocab tables - pipeline use
See this GH Issue as well. - data storage

[chris-s-friedman]

sounds good to me

[torstees]

@brendagutman regarding #4, those may no longer be true. Robert made a pass at the model back in June that largely updated names to be more consistent with OMOP.