You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This "issue" is a placeholder for further discussion on the direction that Atlas/WebAPI should go for providing users with an enhanced ability to create and use custom features within cohort characterization and other study designs.
Current functionality
Within Atlas users can create a custom feature using multiple approaches:
Using CRITERIA - a powerful approach using cohort-building UI forms. Some documentation in the Book of OHDSI but not allot of details
can generate count and averaged data over simple cohort selections or multiple sub-group analyses
Using CUSTOM - SQL created within Atlas using SQL
uses a parameterized SQL with few pre-set parameters
There has to be a valid concept_id for the new feature which can be 0
In either case, counts are aggregated and stored in the cc_results table. Row-level feature results are only stored during execution and then deleted.
Metadata in cc_analysis, fe_analysis, cc_cohort, cohort_characterization
row level data is only stored temporarily and then deleted
This means that carefully Atlas constructed features are not presently accessible within R e.g., using Feature Extraction
Users can also use the R Feature Extractor approach
Produces an R Adromeda object that wraps a sqllite database (on disk) using RSQLite
No use of Atlas unless the custom query SQL is using the cohort or other results tables
Useful for row-level or summary stats
Feature Extraction using Cohort definitions
Easier to write and uses Atlas/WebAPI cohorts and produces row-level or aggregated data
Feature Extraction using Cohort Attributes
Broken : no cohort_attributes exists in the CDM as of >= v5.3
In any case, the output of an Andromeda object could potentially be used to apply functions from other packages (e.g., a risk scoring function) and the results either updated in the Andromeda object or used to create a new object
this implies a potential approach where Atlas/WebAPI is used to create cohorts and then to design a workflow to arrive at final feature object that is then used in other studies
e.g., population estimation or patient-level prediction
Note: there is no way to go from an Andromeda object back into Atlas/WebAPI
for example, to provide additional features for a cohort characterization, incidence rate or cohort pathways
Desired functionality
User friendly integration between Atlas/WebAPI and R methods for creating and using/re-using custom features
Atlas/WebAPI custom features --> R study package
R Feature Extraction custom features --> Atlas/WebAPI analysis and specifications (e.g., Estimation or PLP)
Easier integration of non-OHDSI R packages that make for useful features
e.g., risk scores
Better documentation and vignettes
Book of OHDSI is scant on details for Atlas custom features
the cohort_attribute method is deprecated but still promoted on github
Writing CUSTOM in Atlas requires some skill and could probably be assisted by AI
similarly for the fully custom R Feature Extraction method
Revised architecture for synergy with new changes happing in the community
Use of Strategus
Alternative cohort and study characterization approaches
These are some thoughts to get the conversation going.
The text was updated successfully, but these errors were encountered:
This "issue" is a placeholder for further discussion on the direction that Atlas/WebAPI should go for providing users with an enhanced ability to create and use custom features within cohort characterization and other study designs.
Current functionality
Within Atlas users can create a custom feature using multiple approaches:
Users can also use the R Feature Extractor approach
Entirely custom
No use of Atlas unless the custom query SQL is using the cohort or other results tables
Useful for row-level or summary stats
Feature Extraction using Cohort definitions
Feature Extraction using Cohort Attributes
In any case, the output of an Andromeda object could potentially be used to apply functions from other packages (e.g., a risk scoring function) and the results either updated in the Andromeda object or used to create a new object
Desired functionality
These are some thoughts to get the conversation going.
The text was updated successfully, but these errors were encountered: