New Cohort Characterization

[pavgra]

Today there are several mechanisms in Atlas which provide cohort characterization: Heracles (adoption of Achilles for cohorts), Feature extraction (Generate w/ Features) and Cost & Utilization reports. All of them try to accomplish the same goal, but at the same time introduce extra complexity both to business users and developers since being placed in different parts of the application and doing their job in different ways. This is not obvious which to choose and which to extend during development. The suggestion is to provide a single mechanism which will support both current needs and be simply extendable by business users (ad-hoc) and developers.

The core idea is to re-use https://github.com/OHDSI/FeatureExtraction package by providing a user options either to select existing FE analyses, create analysis on the fly based on Criterias or raw SQL:

First thing is to provide a library of FE analyses and ability to create new ones:

When a user has available analyses, he/she can create a Cohort Characterization report by picking cohorts to analyze, analyses set and configuring the analyses parameters:

Database for such solution could look like:

DAO layer:

Service layer

Original discussion of the solution was held at Janssen R&D. Following contributors took participation

@pbr6cornell, @gowthamrao, Dave Kern, @chrisknoll, @pavgra.

[davekern]

@pavgra i meant that if we have a lot of continuous variables in one table then there will be just as many box plots next to them. It would be ideal to have the box plots take up as little vertical space as possible and have them labeled with the variable being analyzed because if they end up not exactly next to where the variable is in the table you won't be able to easily tell which plot corresponds to which variable in the table.

[pavgra]

@davekern, but we discussed that we won't allow choosing more than 2 cohorts for comparison now, so the situation when there are a lot of continuous variables in one table is not possible currently.

[davekern]

@pavgra Yes 2 cohorts, but there can be multiple variables. For example, in that conditions table you could have Charlson, DCSI, Chads2, Chads2vasc. So there's 4 variables which means you'll have 4 of those box plots stacked on top of each other. It might not be a big deal in that case but what about when we expand this to include the utilization outcomes? you could easily have a dozen or more continuous variables (e.g., number of total visits, # of inp visits, # of er visits, length of stay, # of visits with a diagnosis for diabetes, etc.). I'm just trying to think of how this is going to scale when we have a lot of continuous variables down the road. A large box plot for every single variable isn't going to work well, we need to find a way to shrink the footprint. turning them 90 degrees and eliminating the white space will help.

[chrisknoll]

@davekern : would it work if the boxplots were oriented horizontally (not vertically as @pavgra shows in the latest mockup)? I'm pretty sure we can update the charting library to orient the boxplots horizontally instead of vertically.

[davekern]

@chrisknoll yeah i think that could work.

[gowthamrao]

Team, could you please share your ideas about this question that came up in a discussion between @pavgra and me

My understanding is - to build a new variable for characterization we would use circe-be. The user interface would look something like.

In the above example, we get 'number of people with atleast two paid facility claims with inpatient starting between 0 days before cohort_start_date and all days after cohort_start_date'. Every subject that meets the criteria gets a boolean yes/no - that would then be summarized to cohort level.

Using this same framework, is there a way to get 'count of visit_occurrence_id records among people with alteast two paid facility claims with inpatient starting between 0 days before cohort_start_date and all days after cohort_start_date'.

Thank you

[chrisknoll]

In the above example, we get 'number of people with atleast two paid facility claims with inpatient starting between 0 days before cohort_start_date and all days after cohort_start_date'.

Not quite: we get the cohort episodes that meet that criteria. It doesn't return 'a number of people' directly, but it does return the set of people that meet the criteria, and from that you could aggregate to a count of people. But that 'counting people' is not part of the criteria.

Right now, the framework allows for you to specify the criteria, and you find out who meets the criteria (ie: boolean). There's nothing in the framework that would return a scalar value from that query (ie: number of visits, total costs, total duration, etc).

Using this same framework, is there a way to get 'count of visit_occurrence_id records among people with alteast two paid facility claims with inpatient starting between 0 days before cohort_start_date and all days after cohort_start_date'.

The only way to do this is to positively identify a person that meets the criteria of having a visit occurrence with 2 paid facility claaims with X and Y of cohort_start. If you can define a criteira, then you just count the people/episodes, and that's your count. But, counting the number of visits these people had is a separate aggregation and not related to identifying people. I think that's the key here: identifying people vs. counting up events.

[gowthamrao]

Thanks @chrisknoll

Not quite: we get the cohort episodes that meet that criteria.

When you say cohort episodes - are those row records in the cohort table for that cohort definition id?

Right now, the framework allows for you to specify the criteria, and you find out who meets the criteria (ie: boolean). There's nothing in the framework that would return a scalar value from that query (ie: number of visits, total costs, total duration, etc).

Thanks. So, we will have to rely on Feature Extraction framework or custom SQL support for it? e.g. the cost and utilization work we did mostly did number of visits, total costs, total duration, etc

[pavgra]

@chrisknoll, as for me, since we have criteria design in abstract form (JSON), it shouldn't be too difficult to cover both cases with proper SQL and add the switch: person level counts / record level counts. Do I miss anything?

[chrisknoll]

When you say cohort episodes - are those row records in the cohort table for that cohort definition id?

That's right, those are the 'event index' the criteria expression UI is referring to. We could have an option to use 'first episode per person' as a CC setting, but, if you don't limit it somehow, each episode will be independently evaluated to determine if the criteria 'passes' for that person on that index date.

@pavgra : yes since it's just a json structure you can implement anything around it that is necessary. Just, there's nothing in the criteria language that says 'select the number of days of the visit duration' because that's not the scope of what the Criteria is doing...Criteria is just identifying records.

That's why I said 'Right now, the framework...'. In order to do those maneuvers you guys are talking about, we need to provide additional information (which could be something that 'wraps' the criteria to indicate what statistic you want to extract from the record) ie soemthign like:

{
  statistic: {some way of specifying a value you want to select from the data}
  criteria: {the criteria expression that will identify those records you want to select from}
}

Hope that makes sense.

[chrisknoll]

Also, I should add from Gowtham's origional screen shot of that criteria:

That's a criteria fragment that could be part of larger criteria. Meaning: if that expresson he gave was labeled 'A' and there were 2 other things: B and C that you might want to include in a Criteria that identifies a 'person fitting the criteria', you could have an expression that looks like:

(A AND (B OR C))

A, B and C could be from different domains, too. So there's nothing to select from a value of (A AND (B OR C), since that is simply a statement that is either true or false.

If we want to talk about a mode of features that return values, then it would take the form:

SELECT {some value} from X
WHERE X HAS (A AND (B OR C))

The WHERE X HAS (A AND (B OR C)) is what we can re-use from the current framework. The selecting the value from X is something we need to think about.

Hope that makes sense, too.

[davekern]

Couldn't we count the number of unique patients who meet that criteria (i.e., statement is true or false for each patient), or count the number of events that bet that criteria and then sum the number of events that bet the criteria over each individual. That way we're get a count for each person. Kind of like how we can keep 'all events' in the cohort creation. I don't know how the backend works so this might be a naive question.

So even in the case where there's multiple criteria across domains it could be possible for those criteria to be meet several times in a patient's history (e.g., number of inpatient stays with dx for MI followed by a fill for an anticoagulant within 30 days)

[cgreich]

@chrisknoll: Criterion. ON. Can we fix that in the next release? It's also Nation, not Natia.

[gowthamrao]

@chrisknoll thank you

said 'Right now, the framework...'. In order to do those maneuvers you guys are talking about, we need to provide additional information (which could be something that 'wraps' the criteria to indicate what statistic you want to extract from the record)

Sounds like we need to give this some thought? And need a discussion?

[davekern]

A discussion would be good. A good starting point would be to deal with counts (i.e., number of events meeting the defined criteria for each person), i think that is simplest. And then seeing how that can be expanded to something like costs where we would need to sum the values of records meeting the defined criteria (e.g., inpatient costs during the 6 month pre-index period).

[chrisknoll]

@chrisknoll: Criterion. ON. Can we fix that in the next release? It's also Nation, not Natia.

No. Get over it.

[davekern]

So plural should be "Criterions" as the plural of nation is "Nations"?

[chrisknoll]

Couldn't we count the number of unique patients who meet that criteria (i.e., statement is true or false for each patient),

Yes, that's what we have,,,tho the criteria doesn't count, but criteria can be used to locate the people...

or count the number of events that met that criteria and then sum the number of events that bet the criteria over each individual.

...and this I don't know how we'd accomplish this in the (A OR (B AND C)) form. Do we need to count up all the events that were used in A, B and C or just the ones that were TRUE in A, B and C?

So, if you just want to count people (unique or not), you use what we have today to select the people that have all the criteria (stink-eye at Christian) and decide how you count them (unique or each cohort episode).

If you want to aggregate on some value (like total cost, or total days, or average days, or whatever), we'll need to go a step further. We can still use Criteria to identify which records to count (since Criteria at the core just represent WHERE clauses to DOMAIN tables), but we need to extend this in some way to specify 1) Which column to use from the Domain Table to select a value and 2) what aggregation operation to apply to all the records to get the counts...and to make it even more complicated a mechanism to group the records by things so you have strata. At this point, we're talking about implementing a full-blown SQL query language expression, and that is going to be very hard to implement for symposium.

And, if it requires that level of complexity, I think @gowthamrao has a good point that you get these types of statistics from custom SQL or put the complex sql as a core feature in FeatureExtraction.

I do get the use case, and maybe we can start with simple counts so that you can ask:

How many visits, where the visit has a procedure of X and diagnosis of Y during the same visit, and the visit was IP did each person have?

So, from a query perspective, we need to join to the cohort in order to determine 'visits for whom?' and also if we have a time window on those visits, then we'll need to specify a time window...

So, actually thinking on this further: The current framework makes you choose how many events to find within a time window around the index. The boolean result comes from the check if you meet the how many statement. But, maybe we can break this up into 2 steps where we just return the counts, and remove the how many check to make it true/false, and then use that count value in the result.

This doesn't solve the issue where you want to find the average or total of a numeric value: ie: the cases where we want the total duration of IP visits, the total cost paid, etc. That's the more complicated case I've been talking about with respect to 'SELECT X HAVING (A OR (B AND C))'. But @davekern statement about returning counts, that may be somethign we can do with the current framework by splitting up some of the operations to not always do the 'having at least X' checks in the queries....

[davekern]

@chrisknoll For the symposium it would be best to focus on the first part (not the aggregate).

...and this I don't know how we'd accomplish this in the (A OR (B AND C)) form. Do we need to count up all the events that were used in A, B and C or just the ones that were TRUE in A, B and C?

This is where i think it would be good to have a conversation. We'd want to treat (B and C) as a single criterion (!) -- let's call it Z. And then it would be counting up all the events that are TRUE in either A or Z. (while not double counting events that are true for BOTH A and Z).

[chrisknoll]

Right, let's tease that apart a bit: Label (B AND C) as Z Label A OR Z as Y

Y is the criteria (!) that we want to use to identify the events to count. Normally, it's the cohort episodes that we use with Y, using the episode's start date as the index. But, we can also apply it to any domain object (ie: Find me Conditions that have Y). But, we need to associate a count to a person, so you still need to join back to the population (the cohort) and possibly specify a time window relative to the cohort to find the records (before cohort start? during time at risk (between cohort start and cohort end?)

So, today, we can absolutely say:

Find Conditions
having any (OR) of
A: at least 1 procedure with criteria (!) between X and Y of condition start date
OR having all (AND) of
   B: at least 1 drug exposure with criteria (!) between X2 and Y2 of condition start date
   AND C: exactly 0 observation with criteria (!) between X3 and Y3 of condition start date

But, that's all Conditions...we need to then restrict those conditions to the right population, and the right time window for the population. This is what we'd count and report as the population characterization. I don't think we need to extend CIRCE criteria to support this, but I think we can leverage the CIRCE criteria expressions to generate the queries that you can use to count.

I know this is way into the weeds, but I really do appreciate everyone keeping an eye on this and asking questions, it will help us drive the final requirements and functionality, so keep at it!

[gowthamrao]

Citing @chrisknoll about the types of feature criterion we are trying to solve for

Boolean: Does this person have Criteria C? Counts: How many events with Criteria C exist among the population? Aggregations: What is the SUM/Avg/Max/Min of some value for all people from an event which you can pull a value to count from the event? Stratification: How do we see stratification (ie, bucket counts of people by a period, or by an age group?)

Some of these are out of scope for symposium.

[gowthamrao]

@chrisknoll you are a genius. Please help us digest your post

those are the 'event index' the criteria expression UI is referring to.

My current understanding is that every cohort_start_date/cohort_end_date from cohort table would become the subject_id's initial event_start_date/initial event_end_date - in a fashion similar to cohort definition.

each episode will be independently evaluated to determine if the criteria 'passes' for that person on that index date.

So circe-be criteria expression is identifying event records relative to that date.

if that expresson he gave was labeled 'A' and there were 2 other things: B and C that you might want to include in a Criteria that identifies a 'person fitting the criteria',

Is it not event-records for a person, not just the person fitting the criteria. I understand it could be person if we use demographics.

SELECT {some value} from X
WHERE X HAS (A AND (B OR C))

Yes - this maybe used for somethig like

SELECT sum(cost) from cost
WHERE X HAS (A AND (B OR C))

Do we need to count up all the events that were used in A, B and C or just the ones that were TRUE in A, B and C

I think those that were TRUE in (A AND (B OR C))

we need to extend this in some way to specify 1) Which column to use from the Domain Table to select a value and 2) what aggregation operation to apply to all the records to get the counts

We should somehow restrict it to one of the tables primary key e.g. visit_occurrence_id or condition_occurrence_id. It allows us to do something like

select count(*) 
from visit_occurrence
where visit_occurrence_id in ( (A AND (B OR C)))

or for days

select sum(visit_end_date - visit_start_date)
from visit_occurrence
where visit_occurrence_id in (select visit_occurrence_id from (A AND (B OR C)))

or for cost

select sum(cost)
from cost
where cost_concept_id = (34343)
and cost_event_id in (select visit_occurrence_id from (A AND (B OR C)))

I think @gowthamrao has a good point that you get these types of statistics from custom SQL or put the complex sql as a core feature in FeatureExtraction.

agree

But, maybe we can break this up into 2 steps where we just return the counts, and remove the how many check to make it true/false, and then use that count value in the result.

nice!

[pavgra]

Work is going forward, front-end for Cohort Characterizations section (list, view-edit) is finished. Back-end is being rapidly developed.

Feature analysis page UI is in final stage:

[cgreich]

Criterion, guys. Let's introduce a singular. It is confusing. I know people use criteria as singular, but our UI is struggling as is already. we don't need further distractions.

[chrisknoll]

moved to OHDSI/Atlas#824

[cgreich]

@chrisknoll: Actually, I am exactly about that. When you talk about a group, call it "criteria", when you talk about a single one, call it "a criterion". Right now it is all over the place, and there is no need to insist on wrong grammar. Even though people sometimes use it that way.

So, in the above screen I would change: Add criterion to group (you are adding one at a time) Add criterion attribute (an attribute is something belonging to one criterion) Delete criterion (you are deleting just one) With the following event criterion

Criteria (blue button) - makes sense Having all of the following criteria - makes sense

Ok?

[chrisknoll]

moved to OHDSI/Atlas#824

[cgreich]

@chrisknoll:

I see where you are coming from. What you are saying since in each box there could be more than one clause, even a blue box is a plurality of criteria.

I understand, but it still find it highly counter-intuitive. Everything that is inside the innermost box should be a singular criterion. Even if there is more than one condition. Look at any study in clinicaltrials.gov. They, too, have more than one clause combined into a single criterion. They usually number the single criteria, and use bullet points to provide more details and conditions.

[chrisknoll]

Friends, I've opened a new issue in the Atlas repository to discuss the cohort editor UI: OHDSI/Atlas#824. Please continue the discussion there.

Also, for purposes of keeping this thread clean and on topic of 'cohort characterization' please go back to any messages you've put into this thread related to the cohort UI, and take those messages and apply them to the other thread. We are trying to keep this thread on topic.

Thank you.

[pavgra]

Today @chrisknoll, @gowthamrao, @davekern, @anthonysena and I had a discussion regarding extended use-cases of Criteria Feature in Cohort Characterization. Here are outcomes:

Stage 1

• Criteria Feature (or whatever new name we use for the new generalized entity) should support calculation of not only the number of distinct Persons fitting given conditions (this was in original reqs) but also, as an alternative mode, all Events, e.g. visits, fitting given conditions (this is new thing). Appropriate selector is going to be added to UI to allow choosing type of the aggregation;
• Since CriteriaGroup class cannot be used for the events calculation case (it represents logical condition but doesn't point to the only one, specific events table), we are going to use another data structure for events calculation design (may be Criteria class from circe-be). It should extend the same base entity as CriteriaFeature (there will be three classes, smth like: BaseCriteriaFeature, BooleanCriteriaFeature, CountCriteriaFeature; subject to discussion);
• Table for storing results of both calculation modes should have following structure:
  • analysisId
  • personId
  • value (which is hasCriteria for Persons mode and countPerPerson for Events mode)
• Results for both calculation modes are going to be displayed in Prevalence type of table for stage 1;

Stage 2

• Ability to select Prevalence / Distribution type of stats calculation is going to be introduced. So for Events calculation we'll be able to show mean per person, median per person, etc

Stage 3

• For Events calculation mode selection of field and SQL aggregation function for target event table is going to be introduced. In this way we'll be able to calculate not only events count but some characteristics of related to the events. E.g. average length of stay during inpatient visits.

[pavgra]

Gentlemen,

Now we have a full-blown reporting framework in Atlas with Feature Analyses library. This is an extremely powerful capability which allows us to characterize cohorts and compare their characteristics. Not only we can use pre-canned analyses from Feature Extraction package, but we have also given a user an ability to define ad-hoc reports via GUI builder - Criteria Analyses, same as a chance to go wild and define feature analyses in Raw SQL. Stage 0 is complete, stage 1-3 are in queue.

And this is another thing which has shown the power of collaboration where multiple organizations - Odysseus, Janssen, and BCBS - have contributed. Without such a community, we wouldn't be able to achieve it!

Thank you, guys. I appreciate working with you.

tagging @pbr6cornell , @chrisknoll , @anthonysena , @davekern , @gowthamrao , @gklebanov , @cgreich

[davekern]

Awesome work! I can't wait to start hammering on this.

[pbr6cornell]

Very exciting work, thank you @pavgra https://github.com/pavgra for your leadership on this important project.

On Thu, Oct 4, 2018 at 9:31 PM Pavel Grafkin notifications@github.com wrote:

Gentlemen,

Now we have a full-blown reporting framework in Atlas with Feature Analyses library. This is an extremely powerful capability which allows us to characterize cohorts and compare their characteristics. Not only we can use pre-canned analyses from Feature Extraction package, but we have also given a user an ability to define ad-hoc reports via GUI builder - Criteria Analyses, same as a chance to go wild and define feature analyses in Raw SQL. Stage 0 is complete, stage 1-3 are in queue.

And this is another thing which has shown the power of collaboration where multiple organizations - Odysseus, Janssen, and BCBS - have contributed. Without such a community, we wouldn't be able to achieve it!

Thank you, guys. I appreciate working with you.

[image: image] https://user-images.githubusercontent.com/10010071/46511443-b0769100-c81c-11e8-8901-50336aa22288.png

[image: image] https://user-images.githubusercontent.com/10010071/46511427-976de000-c81c-11e8-8173-180217f05811.png

[image: image] https://user-images.githubusercontent.com/10010071/46511432-9b99fd80-c81c-11e8-9378-97802d444c1f.png

[image: image] https://user-images.githubusercontent.com/10010071/46511436-a48acf00-c81c-11e8-80df-a26bb65a0f26.png

tagging @pbr6cornell https://github.com/pbr6cornell , @chrisknoll https://github.com/chrisknoll , @anthonysena https://github.com/anthonysena , @davekern https://github.com/davekern , @gowthamrao https://github.com/gowthamrao , @gklebanov https://github.com/gklebanov , @cgreich https://github.com/cgreich

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OHDSI/WebAPI/issues/495#issuecomment-427219510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAsrGjmN_l-sw32q36qAmuKKdNiisrgrks5uhraEgaJpZM4U8Rjc .

[gklebanov]

Well done! The team work here is incredible!

[pavgra]

@chrisknoll was too optimistic to close the issue - we still haven't finished even Stage 1 😏

[chrisknoll]

Sorry, I got excited.

[pavgra]

For Step 1 it is also required to bring back Vocabulary browsing feature for Concept records which was available in "Generate with features" thing.

[pavgra]

Clarification for Stage 1 / Stage 2 and Count persons vs Count events:

We may want to see a distribution (Distribution analysis type) of inpatient visits (or conditions / procedures / etc...) per person during a baseline period or cohort period. This currently cannot be done via preset analyses (e.g. visit_occurrence concept count during day -365 through 0 concept_count relative to index puts out all visits and we'd like to be more specific), and criteria at this moment only support prevalence (but it makes sense to understand not just the prevalence of visits because a person who had 1 visit is not the same as a person who had many visits). That's why there is a need to calculate events and display the distribution data.

(request from @gowthamrao)

Therefore, proposal is:

• Add Prevalance / Distribution selector for Feature Analysis
• If Prevalance type is chosen, FA works as it does today - number of persons fitting criteria is calculated
• If Distribution type is chosen, FA caluclates events mean per person, events median per person, etc (all distribution stats)
• Add description below Prevalance / Distribution selector clarifying the logic

[chrisknoll]

The 'Distribution' type:

I think the distribution type of criteria is going to need to be more sophisticated: getting a distribution means that you're projecting some value per person (visit counts, distinct drug concepts, total cost, visit duration, etc) that comes from a set of records. So the criteria can be leveraged to identify those records we wish to calculate some value from, but what we'd also need is a way to specify what value we are getting from the data that we want the distribution of.

I feel like the UI would provide a set of pre-canned calculations based on the domain criteria selected: if you pick visits, you can get length of stay (where a person can contribute multiple values to the overall distribution), avg length of stay (where each person contributes a single value, but is an average of the person's length of stays for all their visits)..etc. This is a pretty complicated thing since sometimes each individual record contrbutes a value, sometimes a aggregate value by person contributes a value...but to keep it simple for the user, we don't make them do anything except pick from a dropdown the type of measure they want to get a distribution of. Over time, this list can grow and get more sophisticated.

[davekern]

The way I see these distributions is a little more straightforward: Take the aggregate of the variable for a given person. Report the average of that aggregate per person (SD, median, or whatever else we think is relevant... but avg/sd/median i'd assume are definites) within the cohort of interest. E.g., this would give you things like:

• Avg. number of outpatient visits per person
• Avg. length of stay over a one year period per person
• Avg. ER costs per person -- etc., For the most part i think we can treat them all the same.

The only exception to this is that we should probably report certain stats within patients that had a relevant event. For example, average length of stay within patients that had at least one inpatient visit. This way we aren't getting a whole bunch of 0's for people that had no length of stay. Similar for costs, you might want to see the average ER costs over a one-year post-index period, and may only be interested in getting that data for those that actually had an ER visit.

[pavgra]

@chrisknoll , @davekern , if I get you right, you are talking about calculation of specific values of events which satisfy selected criteria. But this is what we discussed for Step 3:

For Events calculation mode selection of field and SQL aggregation function for target event table is going to be introduced. In this way we'll be able to calculate not only events count but some characteristics of related to the events. E.g. average length of stay during inpatient visits.

And before that, as we discussed with @gowthamrao (and previously discussed all together), for Stage 2 it would be useful to have a simple version, which calculates the distribution of satisfying events per person (not some values from the events, but just their presence).

[gowthamrao]

Summarizing the discussions that involved @chrisknoll @davekern @fdefalco @schuemie @gklebanov @jreps @pbr6cornell @pavgra @PRijnbeek and others

We would like to use the new Atlas Cohort characterization functionality to manage library of feature-specifications that may be used throughout OHDSI applications for functions such as cohort build criteria, stratification criteria in incidence rate, as features in PLP/PLE, and as features in profiles.

In a conversation that involved @schuemie @PRijnbeek @gowthamrao at 2018 OHDSI Symposium - we discussed idea of using additional person level features computed outside of Feature Extraction package as covariate in plp/ple. Technically this was considered feasible if output of person level feature computation was made available in the input format needed for PLP/PLE i.e. PLP and PLE require the following format: RowId, covariateId, covariateValue. RowId is a unique identifier for a patient_id and cohort_start_date.

Current CC design outputs aggregate statistics at cohort level. This request is to NOT create an output of person level datasets with computed features; but to maintain a enhanced feature specification library in Atlas that extends the standard feature specifications already in FF using the Atlas GUI interface. These additional feature specifications defined in Atlas GUI, should be importable/exportable such that they can blend with standard pre-defined feature library in Feature Extraction R-package.

[davekern]

@gowthamrao Thanks for summarizing some of our conversation.

I wonder if we create a new GitHub thread for this? The custom feature creation tool should be separate from the cohort characterization tool. The custom feature creation tool should look very similar to what the cohort creation tool looks like in Atlas, but instead of creating a single cohort with multiple criteria, you are able to create multiple feature definitions using similar logic. Those features can then be loaded into various tools, including PLP (as predictors or outcomes), PLE (as covariates or outcomes), and the cohort characterization (as characteristics to be described).

[pavgra]

@davekern

The custom feature creation tool should look

Hm, I think I miss your point - have you seen the Feature Analysis tab? You are already able to create Criteria Features there. So the designer is already in place

[davekern]

yeah, you're right, that's good