Yes, there are two approaches to running CohortDiagnostics: The cohort diagnostics can be embedded in an OHDSI study package, where all the cohort definitions are stored as part of that study package, or the cohort diagnostics can be used as a stand-alone solution, relying on a WebAPI instance to provide the cohort definitions.
For the first option, you can use the example package included in the CohortDiagnostics repo as a starting point. See the README for details how to modify it to your needs.
Is it also true that you could use your own custom cohort table for execution in cohort diagnostics? Ie: let’s say you made your drug_era table your cohort table, where the drug_concept_id in the drug_era table would serve as your cohort_definition_id, and your drug_era_start/end dates would serve as your cohort_start/end dates…in this way you could get a diagnostic report without any cohort construction at all? I think you’d still have to work out building a cohrotSetReference .csv file (but you can easily construct this by querying for the drug_concept name from the vocabulary). I think there’s a way to skip cohort construction as a paramater in the R package…where it assumes you already have a cohort table constructed.
Yes, the main runCohortDiagnostics function assumes the cohorts have already been constructed, but… it still needs the JSON and SQL, for example to figure out the labels for the inclusion rules, or the SQL for instantiating the concept sets.
As a consequence, even though you might trick CohortDiagnostics in executing on cohorts that were created with custom SQL code, several of the diagnostics would fail because the JSON and SQL are not there, or not as expected.