roadmap.RmdThe picard package was developed following observation
of the 2023 SOS Challenge
which aimed at improving and communicating the process of developing
effective OHDSI studies. While following the 2023 SOS Challenge, we
noticed there were several bits of documentation that were vital for an
OHDSI study. Study leads needed to provide ample information to their
nodes via the ohdsi studies github to run the study. We noticed that
several of these tasks had repeating patterns, that we felt could be
automated. We also noticed how heterogenous the structure of an OHDSI
study could be when looking at the ohdsi-studies github
repository. While some guidance
was provided, repositories did not seem to cohere to any specific
development process.
Based on our study development experience, we also felt strongly
about having strong organization in order for a study to be effective.
Code and study materials need to be effectively communicated and easily
accessible for study members to understand and appreciate the complexity
of developing a timely and effective study. Basic organizational
methods, made it easier to track mistakes and fix cohort definitions as
studies improve via scientific collaboration. These experiences and our
observations of the SOS challenge lead to the development of the
picard package. The picard package attempts to
provide a development workflow for OHDSI studies by automating
repeatable tasks and providing consistent organization to make study
repositories effective sources of guidance for communicating the science
behind a study and executing the software to generate evidence. The
picard package is heavily inspired by the usethis package that
is used to assist in the development workflow of novel R packages and
projects alike. Similar to the development of an R package, there are
several steps and pieces of documentation needed in an OHDSI study to
effectively run the study across the OHDSI network. We felt that the
OHDSI community could benefit from a bit of software the provided
assistance towards the development of a study. These studies could be
privately ran studies within institutions or multi-stakeholder OHDSI
network studies. In this document we provide a roadmap for existing
development and future features we wish to add to the
picard package.
The picard package is a workflow tool that assists in
the development of OHDSI studies. This would host a series of functions
intended to assist in both the development (tools for the study host)
and execution (tools for the study node) of studies. picard
intends to streamline OHDSI studies to conform to a known structure and
standard making it easier to communicate, execute and develop
studies.
Over the past year, there has been significant development on strategus a tool that
helps coordinate and execute HADES modules. Strategus has a significant
impact on OHDSI studies since it has modularized a OHDSI study
execution. It is vital that picard is developed in a way
that enhances the strategus experience. We intend to provide functions
that aim to support the strategus paradigm for OHDSI studies. Alignment
between these packages we believe will improve the user experience for
study developers and study nodes alike. An area of potential development
would be functions to support the development of strategus modules.
make{File})
The first suite of functions is intended to auto-start pre-rendered
files that are needed for an OHDSI study. The picard
package stores multiple templates that are written with whisker used for logicless
templating. The whisker function places a {{{ Mustache }}} in the file
that is rendered with specified inputs. These inputs are largely filled
out by the _study.yml file which serves as a meta data
object for the OHDSI study. This construction is equivalent to that of
the usethis package, however the files are oriented
specifically for OHDSI studies. Below is a list of files currently
covered by templates in picard.
Some templates we would like to add include:
Cohort definitions are essential to an OHDSI study because it is how
we enumerate populations used for statistical methods or simple
summaries. The cohort definition in an OHDSI study is stored as a json
file. Strong organization and communication of the cohort definitions is
an important aspect when developing a study. picard aims to
provide support for keeping track of cohort definitions.
picard provides functionality to handle these
different ways of adding cohort definitionspicard provides a function that adds a new
folder for cohort definitions, makeCohortFolder. The
cohortsToCreate folder comes initialized with a folder
01_target used to store the target cohort definition. Users can
add other types of cohorts such as comparator, outcome,
negative_control, strata, covariates. It is up to the user to provide
naming for different types of cohorts. For each new folder an integer is
added to the front of the file to provide order.CohortDetails.md file that provides a simple
explanation of the cohort and track changes to the definition over time.
It is important to depict how cohort definitions have evolved over the
course of the study when developing within a study team.picard
provides a function called cohortManifest which looks into
the cohort folder and lists all the cohorts used in the study. This
tibble can be manipulated in all sorts of ways that are beneficial to
the development of the study.A future feature we intend to add to the picard package
are functions that works similarly to pkgdown in building a website for
R packages. An OHDSI study page would be very useful in communicating
how to contribute, run and document the study.
Future features that would suit the picard package are
functions that help work with the OHDSI study on github or bitbucket.
Ideas for assistant functions include:
Functionality that helps transfer results to study host. The OhdsiSharing
package already exists for this, however there are times,
particularly in internal studies where study results need to be sent via
gdrive or dropbox. Functionality to borden the possibilities for sending
results would be helpful.
Another function would be to browse the results via a shiny app. This
would require sync with ResultsModelManager and
ShinyAppBuilder.