Atlas questions

[PRijnbeek]

I am playing with Atlas a lot (love it) and have a couple of questions:

1. If i import a cohort definition (currently via the export function and reloading the JSON). The concept sets that are imported are not available in the concept set part of Atlas. Is there a good reason these are not imported automatically as well? Is there another way to import Concept Set definitions in the UI that I am not aware of?

2. If I want to do the following in qualifying inclusion criteria of the cohort builder to understand better where I loose my patients in http://www.ohdsi.org/web/atlas/#/cohortdefinition/143801:

• nr patients that do not fulfil the minimum amount of time of observation before the input inclusion event -> i can only find this as part of the inclusion event definition currently correct so it will not appear in the attrition?
• nr patients that experience this condition with all condition_type added criteria -> I need to repeat the inclusion event again to add the extra criteria and (in a time window of zero days)? is there a better way of doing this that I am not aware off?
• same for the visit_type.

So what I like to move all the inclusion criteria that are currently in the initial event cohort definition down to the part that does allow we to make an attrition diagram.

Thanks.

[chrisknoll]

Hi, @PRijnbeek,

Re 1: Cohort defs are completely self contained, so importing a cohort def doesn't have anything to do with your local concept set repository.

Imagine if we did automatically write out all concept sets back to your concept set repository, as new concept sets: You import a cohort def with 50 concept sets, and 50 new concept sets get inserted into your repository..then you import another cohort def that shared 10 of those concept sets...you inset another 50, and 10 of those are dupes. Etc Etc.

Instead, I believe there is an idea out there to alter the cohort editor screen which would allow you to 'save concept set to repository' which gives you the choice to save as new or overwrite an existing concept set in the concept set repository. Conversely, we'd also give you a way to open up an existing cohort definition and overwrite a cohort definition's concept set with a concept set from the repository.

2. In the case you have it, you can't move 'pieces' of the initial event criteria into an inclusion criteria, because the 2 inclusion criteria you want to move into is 'baked' into the initial event criteria. There's no shortcut here, but this is what you do to get your numbers:
   • remove the criteria from your initial event (or cohort start) criteria.
   • Create 3 inclusion rules
   • Rule 1: Having at least 1 occurrence of AMI having condition_type of X starting within 0 days of index.
   • Rule 2: Having at least 1 occurrence of AMI having visit type of X starting within 0 days of index
   • Rule 3: having at least 1 observation period starting ALL days before index and X days before index and ending between 0 days after and all days after index. (where X days is the number of days you want to have of observation prior to index). Note: you have to specify that the index is contained by the observation period, so you need to say that the OP start is prior to index and OP end is after index.

The table will give you the numbers of who satisfied the individual rules. The visualization will tell you the combos that people satisfied, which is 2^3 = 8:

Case	Rule 1	Rule 2	Rule 3
Matching	Y	Y	Y
Only R1	Y	N	N
Only R2	N	Y	N
Only R3	N	N	Y
R1+R2	Y	Y	N
R1+R3	Y	N	Y
R2+R3	N	Y	Y
No Match	N	N	N	N

Note, there difference between the table row that shows the matching for R1 and the visualization is that the table will give you the sum of Only R1, R1+R2, R1+R3, while the visulization cell for Only R1 will be the count of people that only satisfy R1. This may be important for you to know.

-Chris

[PRijnbeek]

Thanks!

Re1: Yes i understand importing all by default would not be the best option. An import option for concept is needed i think though. I like the new Interface tab in the other components that allows you to clearly import or export. Adding this to the concept sets is a consistent solution. This would enable sharing concept sets like cohort etc. An option to select which to import in the cohort screen is an additional nice option indeed.

Re 2: Okay yes that is indeed the solution to get to those number that I now apply. You do have to define your index rule multiple times as a workaround but to avoid that would propably not be so easy in the current setup. Let's see when others are really going to use the tool if this workaround is intuative enough after some training. For now it works.

Not sure I can fully follow the last Note but I will figure it out when looking at the results.

Peter

[gklebanov]

Hi @PRijnbeek, @chrisknoll, @pbr6cornell - Re 1 is a great topic. Not only we should think about enabling a better cohort, concept set and - in the future - more complex design exchanges between ATLAS instances, but also across across other systems. We should also consider that in some cases we might even want to preserve a reference link back to the original cohort vs a full import.

There are multiple things that we need to consider:

a) adding additional metadata describing cohorts and concept sets, not only the actual design related metadata. For example, adding the following fields would enable a better exchanges between systems, including referencing back:

• GUID (guaranteed uniqueness)
• Local ID
• Name
• Description
• Author
• Organization
• CDM Version
• Vocabulary Version
• Last Updates datetime

For example, having GUIDs would help us avoid duplication as well as referencing back to that cohort in other systems.

b) To make cohort exchanges consistent, we should consider creating and maintaining a detailed entity model describing Cohort and Concept Sets which then can be used by ATLAS/WebAPI - and other cohort builders out there - to generate cohorts in a standard JSON format. An existing ATLAS/WebAPI JSON could give us a great start, it could be - as Patrick once called it - our version 0.1 from where we can build it up.

c) In ATLAS, it would be great to have an explicit "Import" tab for both Cohort and Concept Set. I like your idea of giving more complex options on how to handle imports from both cohort and concept set perspectives.

Great stuff, I would love to team up with you and jointly develop all 3 I listed above.

Greg

[chrisknoll]

@PRijnbeek , sorry for the confusing note at the end, I was just trying to be comprehensive in my information. To put it another way: if you want to find the number of people that satisfy rule one, then you'd sum up the counts of people in the 'Rule 1' column that has a Y in the cell. This is what the 'summary table' gives you when you view the cohort generation results. However, the visualization gives you the detail numbers about the number of people that are found in each cell. so, the summary table answers 'how many people satisfy a rule' while the visualization answers the question 'how many people satisfy a combination of rules.

Hope that's clearer. Admittedly, most of the time, people just have the question 'How many people satisfy rule 1' but from your case where you want to have people based on condition type and visit type, you'll be able to get the following answers from the summary table:

• How many people satisfy looking for the condition type?
• How many people satisfy the visit type?
• How many people have the prior observation duration?

And from the visualization, you'll be able to find the cells that answer these questions:

• How many people had the visit type, but not the prior observation?
• How many people had the condition, but not the visit type?
• How many people had the visit type and condition type, but not enough prior observation?

Once you see the results in the UI and play around with the visualization, hopefully this will be clear.