Reusables Refactoring

Problem:

The concept for Reusables was originally created to offer users the capability for designing complex logic to be easily shared and recalled across several studies. Reusables are not fully reusable throughout Atlas, as there is specific reusable type logic (e.g. “Initial/Censoring Event” and “Criteria Group”) to align with the various sections of Atlas cohort definitions. However, this flexibility presents a usability challenge in that we have 2 types of Reusables that are specific to sections of Atlas.

Proposal:

Eliminate the option for allowing various Reusable types. Only allow for 1 criteria object in a Reusable, but with all nesting support. Also, remove the “having” parameter, meaning, we can’t use multiple criteria. This ensures that a reusable is not limited in how it can be used and can be imported anywhere in Atlas without distinction. The expected result from this amendment will make Reusables more intuitive for users to find utility while using this feature within the Atlas platform as the creators initially intended.
Atlas Git Issue

Proposal:

Alter GUI to match the WebAPI issue:

1. Remove the “having” parameter
2. Limit the criteria to just the ones that can be used everywhere
   a. Meaning, no demographic or group items
3. Recommend community users incorporating nested logic for layered logic
   a. A mix of Reusables or nested criteria may be compounded to develop a single asset.
4. The use of the “having” parameter may be used outside of Reusable after being embedded into the design.

FYI- @alondhe

The issue does not name files or tests; begin by locating the WebAPI handling for Reusables and reviewing how reusable types, criteria, and the “having” parameter are represented. Clarify the GUI and WebAPI scope before changing behavior, then verify that one reusable criteria object supports nesting and can be used across Atlas sections.