search

OHDSI / Atlas

ATLAS is an open source software tool for researchers to conduct scientific analyses on standardized observational data
http://atlas-demo.ohdsi.org/
Apache License 2.0
258 stars 126 forks source link

Reusables Refactoring #2836

Open mrechkem opened 1 year ago

mrechkem commented 1 year ago

Linked issue within WebAPI Repo

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.

image

FYI- @alondhe

chrisknoll commented 1 year ago

Hi, @mrechkem . Thank you for the well thought out proposal.

I think eliminating the different reusables is something that would simplify things, but at the same time could have some backwards-compatabity concerns (ie: someone may already have used these other types). I think the only issue I have with the current operation is that there isn't the notion of the 'singular criteria' reusable that you describe in your proposal...and this 'singular criteria' could be used in entry events, censoring events, or as an element of a criteria group.

@alondhe presented the use-case of the 1 IP or 2 OP logic for determining if a clinical event is valid. The logic can be described as:

Find condition of X having: (nested) event occurrs in patient or event has another condition X between 183d prior and 1d prior

I've developed this logic as a reusable on the atlas demo site here: image

Some notes: the above UI has a 'delete criteria' button because when you create this type of reusable, it's inside a 'collection' , which makes it not work well for using this as an element in a group.

The way I'd like to use this reusable is that when I'm in a group, i should be able to import the reusable:

image

In the above: the 'add criteria to group' is only letting you add a 'group reusable' to the group, even tho the button says you can add a criteria to the group (which is what our first reusable that I presented is). So, in the case you just added a condition occurrence to the group, it defaults to 'having at least 1' and 'all days before to all days after'. Why couldn't we add a criteria reusable here and have it use the same defaults? The reason is twofold: the way 'group reusables' were implemented, when you add the reusable to the group, you're adding an entire group, not a criteria element...the other reason is that 'critreia reusables' are actually lists of reusables, and the element of a group is just a single criteria, not a list...

Taking your proposal, it would solve this problem: introduce a reusable type that is just a singular criteria (note: nested criteria is allowed, just you have a single 'parent' criteria as the root). We'd allow the 'Add criteria to group' select either a group reusable or a singular criteria....and if a group is selected, do the current implementation, and if a singular criteria is selected make a default of 'at least 1...between all days before and all days after' exactly as if you added a drug exposure or a procedure occurrence or a condition occurrence....

Perhaps it's even possible to allow the 'list of criteria' reusables to be used here as well: for each criteria in the criteria list reusable, just add it to the group as a 'at least 1 ... between all days before and all days after'.

The thing that the criteria group reusable captures that your singular criteria does not is the 'at least .... between all days before and all days after' part...I can see potential where someone might want to define an entire group with these parameters set, but the cool thing is that once we allow 'singular reusables' to be used in groups, we could define a reusable group that lets you import a reusable criteria as part of the construction of the group. So that could be a win-win.