National-COVID-Cohort-Collaborative / Phenotype_Data_Acquisition

The repository for code and documentation produced by the N3C Phenotype and Data Acquisition workstream
60 stars 35 forks source link

Add MANIFEST parameters to R exporter #62

Closed empfff closed 4 years ago

empfff commented 4 years ago

Should move MANIFEST fields to R exporter execution so that sites do not forget to fill it out.

rtmill commented 4 years ago

Related to #57.

This should be quick (the logic exists in the 'reorg' branch). Is this the full list of fields in MANIFEST to parameterize? SITE_ABBREV SITE_NAME CONTACT_NAME CONTACT_EMAIL

empfff commented 4 years ago

I think we need:

SITE_ABBREV, SITE_NAME, CONTACT_NAME, CONTACT_EMAIL, CDM_NAME, (but i think you already have this parameterized) CDM_VERSION, VOCABULARY_VERSION, N3C_PHENOTYPE_YN, N3C_PHENOTYPE_VERSION, DATA_LATENCY_NUM_DAYS (this integer will be used to calculate UPDATE_DATE dynamically) DAYS_BT_SUBMISSIONS (this integer will be used to calculate NEXT_SUBMISSION_DATE dynamically)

rtmill commented 4 years ago

Should we hardcode (or at least have a default value) for the following? They seem static to the particular script used and independent of the local implementation. -CDM_NAME (will always be OMOP in the OMOP scripts, always ACT in ACT scripts, etc) -N3C_PHENOTYPE_YN -N3C_PHENOTYPE_VERSION

By CDM_VERSION, do we mean the CDM version of the source db or the CDM version of the output files? If the former it could be done dynamically (select top 1 cdm_version from @cdmDatabaseSchema.cdm_source), if the latter we could hardcode it to '5.3.1' in the OMOP script

Similarly, VOCABULARY_VERSION can be pulled (select top 1 vocabulary_version from @cdmDatabaseSchema.cdm_source) for OMOP

empfff commented 4 years ago

CDM_NAME is static for the script used, correct.

N3C_PHENOTYPE_YN will be site-specific, however. And N3C_PHENOTYPE_VERSION will change as the phenotype version changes.

CDM_VERSION should be CDM version of the source DB.

If VOCABULARY_VERSION can be pulled, that's great, because that field only applies to OMOP anyway. It will be null always for all of the other models.

Thanks!