Roadmap & contribution guide

[anthonysena]

We do not currently have a clear roadmap or contribution guide for the project. We should aim to have one and make this known to the OHDSI community ahead of our next planned release.

Currently, this repository and project are discussed as part of the ATLAS/WebAPI working group which meets monthly to discuss the project and weekly to provide support for developers. Our 2023 OKRs aimed to expand our outreach to the OHDSI community to provide transparency for our future work and to solicit feedback for the platform as we move forward. As we start 2024, we should continue this work while also providing a high-level strategy and roadmap for the project.

To that end, here are some draft thoughts on how we can continue to mature in that direction:

• Define the strategic objectives for Atlas/WebAPI moving forward so our goals and objectives are clear to those that are interested in the future of the project and have an interest in making code contributions. These aims have been discussed on the Atlas/WebAPI working group and this should be documented in this repository. Specifically, the README in the project repository should include the strategic objectives of the project and the CONTRIBUTING document should define how to contribute to the project via the Atlas/WebAPI working group. The https://www.contributor-covenant.org/ provides a nice starting place for a code of conduct that we should adopt as well and @leeevans may have suggestions from the OHDSI TAB on this topic.
• Use the issue trackers for Atlas/WebAPI to provide a mechanism for members of the OHDSI community to contribute ideas for consideration into future releases. This is our current process for working and it should be documented in a contributing guide as described in https://opensource.guide/how-to-contribute/.
• Use a GitHub project to collect all ideas for future releases for consideration by the OHDSI Atlas Product Owners (@pbr6cornell, @gklebanov ) with an aim to ensure these align to the strategic objectives (see above).
• Project managers (@anthonysena, @alex-odysseus) will identify developers to lead the design and implementation. All issues will be assigned to a milestone in GitHub to track progress towards the release.
• Developers will produce design specification document for each feature and the Technical Lead (@chrisknoll) will review and approve prior to development.
• Once all features are implemented, Project Managers will coordinate testing across participating sites.
• Once Product owners approve a release, Project Managers will then communicate release and documentation to the OHDSI community

Please consider this a first draft and this will be a topic for future discussion within the Atlas/WebAPI Working Group this month.

[anthonysena]

From the first bullet above, here is a first pass at how we might define a strategy for ATLAS/WebAPI. Here I'm following the format as described in Red Hat's "Developing a strategy for your open source project". Please take a read of that before considering this draft write up.

1. What is the project?

ATLAS/WebAPI is a web-based tool for desiging observational studies using HADES Standardized Analytics for patient-level health data converted to the OMOP Common Data Model.

2. Who are the project's users?

ATLAS/WebAPI's users are researchers (individuals and teams) who want to design cohort definitions. They will then use these cohort definitions to run analytics to perform characterization, and population-level effect estimation and patient-level prediction for these populations of patients.

3. How do you engage with your user base today?

Users of ATLAS are encouraged to participate in the ATLAS/WebAPI Working group.

4. What alternatives to your project already exist?

i2b2 provides an open-source cohort definition solution that is now compatible with the OMOP CDM.

5. Are you already associated with adjacent projects?

ATLAS/WebAPI is adjacent to a number of projects in the OHDSI open-source ecosystem. ATLAS/WebAPI provides a designer for HADES Standardized Analytics. Athena provides capabilities to search the OMOP Vocabularies to download these vocabularies. ARES provides database level characterization and data quality assessments. Arachne provides the capabilities to execute studies designed in ATLAS.

6. What are your goals for the project?

We have the following goals and priorities for the ATLAS/WebAPI project:

• ATLAS for phenotype development and evaluation: ATLAS should provide a cohesive set of features for phenotype development and storage.
• ATLAS for study design and execution via Arachne & Strategus: currently cohorts are the only reusable element of design that is produced by ATLAS for consumption in Strategus. We should aim to make all of the Strategus HADES modules available for design in ATLAS. We should also have a documented solution for running Strategus via Arachne integrated with ATLAS.
• Modernize the application stack: ATLAS/WebAPI has fallen behind on some core libraries which require prioritization to fix.

7. Who are your key stakeholders?

Researchers who want to design observational studies using the OMOP CDM.