-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solution to replace default Table 1 specs #92
Comments
There are three fields in Table 1 specs:
|
For 1. Covariate ids: Steps: Resolve concept expression: ROhdsiWebapi::getConceptSetConceptIds . But this may return conceptIds from various domains. Given a list of conceptIds, we need details of conceptId from the concept table - so that we can then classify them based on domainId. We need a function, in ROhdsiWebApi, that accepts a list of conceptIds and returns a data frame from conceptTable. This would be POST call using this end-point. |
I disagree with your assessment that "Table 1 specs is currently fixed". I deliberately made it customizable, by replacing the specifications argument when calling the function. The problem is that it takes quite a lot of knowledge to know how to modify the specifications to your liking. Remember, the specifications represent a hand-picked selection of covariates to show. I don't think we need (or can) automate anything here. The biggest challenge is explaining (and / or facilitating) covariate IDs and analysis IDs. Covariate IDs are not the same as concept IDs, although for most analyses we made it so one can easily be derived from the other. Analysis IDs are not clearly documented anywhere, although the standard ones are listed in this hard-to-read CSV file. But we should also support custom covariates, which also will have covariate IDs and analysis IDs. I recommend we instruct people to use a CovariateData object as the starting point for creating their own table 1 specs. The CovariateData object has covariateRef and analyssiRef objects, that detail all the covariates and analyses. We might even create a small editor (say, in Shiny) that, using a CovariateData object as input, allows users to pick analyses and covariates. But to me that seems overkill. A good vignette documenting how to create table 1 specs is probably sufficient. A note of warning: the implementation of FeatureExtraction is about to change drastically with the replacing of ff. |
I will try to write a function to support this important need. Something like
I will post this function on this thread. |
@schuemie here is my untested code. If you think this is a good approach, i will tested it and do a PR?
|
Do you think this function will make it easier to edit the specifications compared to just letting people edit the text file? It is also not clear how you specify covariate IDs (which are not the same as concept IDs) |
Yes. I think it will be very useful by making it easier, but also less error prone (because of the checks, deduplication, domainId matching to anlaysisId) - compared to the external file. Here are my assumptions: AnalysisId: analysisId's are part of the System.file i.e. installed in the package. An advanced user may change analysisId using packageMaintenance . But the analysisId has to be installed and pre-specified prior to calling this function. i.e. This function does not add/delete/manage AnalysisId. CovariateId: Yes, this function supports creation of CovariateIds that are (conceptId * 1000) + analysisId. |
Why not work from an existing CovariateData object, where we have all the covariate IDs and analysis IDs, and can just pick from those? |
I did not study CovariateData object, so i dont know. Does using CovariateData object allow specifiying table 1 label/structure? |
The CovariateData object (the result from getDbCovariateData) has a covariateRef table and an analysisRef table. Together they specify all the covariates and analysis that were generated. If you're hand-picking covariates and analysis to show, that would be the most convenient source. It even includes any custom covariates people may have constructed. No need to try to figure out which analysis is what, and what logic to use to construct covariate IDs |
Table 1 specs is currently fixed. There is no simple solution to replace the standard table 1 specs. This is a needed functionality - as default may not be relevant for all cohorts.
We need a solution to do a simple replace of the default Table1Specs. This solution needs to be documented.
Continued from here OHDSI/CohortDiagnostics#32 (comment)
Solution should be available as a function call for any downstream package that uses Feature Extraction's create table 1 function
The text was updated successfully, but these errors were encountered: