OHDSI Home | Forums | Wiki | Github

ATLAS / CIRCE Integration

Developers
#1

All,

I’ve taken a first pass at mocking up an approach for integrating the CIRCE editor into ATLAS. You can access it here:

https://invis.io/7D5NSUK8T

The workflow is as follows:

  1. Click the New Cohort Definition Button in the top right
  2. Clicking the button labeled ‘Autism’ allows you to choose a different Concept Set. By default this button would read ‘Choose Concept Set’ Choosing a concept set would close the dialog and replace the text with the name of the concept set. If the concept set browser is used to select a cohort from the repository then a copy of the concept set will be imported into the cohort definition.
  3. Clicking the Concept Tab button takes you to a list of the concept sets currently embedded in this cohort definition. Here you can
    a. remove a concept set from the definition,
    b. import/load a concept set into the cohort definition using the Load button
    c. refresh a concept set that has been updated in the repository since it was imported into the cohort definition. (the update functionality while nice may be something we postpone until a later release)
    d. edit a concept set by clicking the edit icon. Editing will load the concept set as the ‘Current Concept Set’ in ATLAS and open the Concept Set Editor screen.

The menu in ATLAS will be modified to show a list of Concept Sets when the left menu link is clicked. A separate line will appear in the menu any time there is a current Concept Set in edit mode. The same will appear for a current Cohort Definition. This appears in some of the mockups.

Please provide any feedback you might have.

A few CIRCE workflow screens
#2

Hi, Frank,

I’d suggest not requiring any changes to the core cohort editor. But I do like the integration points you have made, and the ‘compare codeset’ functionality is a good idea. I would recommend exposing that functionality under the ‘concept sets’ tab where the user can focus on managing the concept sets for the cohort definition, and then separately work on building the logic to define the cohort criteria.

-Chris

#3

Hi Community!

I’ve created 2 workflows for creating concept sets in ATLAS and how they could be incorporated over into a cohort definition. The current issue we’re seeing in ATLAS is that we have to copy-paste a JSON form of the concept set expression.

The first workflow demonstrates the path that a user would follow to search the vocabulary, build the concept set, then send it to a cohort definition:
https://invis.io/FQ5P2LOYP

The second workflow shows how you would get into the vocabulary search/concept set editor from within a cohort definition. The important feature here is that as the user is creating/modifying the concept set expression, a new concept set context is created that allows the user to try changes out and see how descendant/exclude settings impacts the concept set, but gives them the ability to ‘cancel’ out of the changes. The changes are only saved into the cohort definition once the apply button is clicked.
You can see this workflow here:
https://invis.io/CP5QXF9DB

Comments are appreciated. I believe this workflow is set up so anyone can comment. Or you can follow up here.

Thanks!

-Chris

#4

@Chris_Knoll @Frank, I 've merged these two threads as they are so tightly related and to keep the discussion in one spot.

I’ve looked through all three designs and here are my initial thoughts:

As a user, my simplest need is to create concept sets in one consistent place and to use them anywhere.

The place they should be created, edited, and saved, is in the Concept Sets section. I do not believe CIRCE should have an integrated pop-up window or anything else that allows creation of concept sets. CIRCE should allow only loading of concept sets or sending the user over to the full page Concept Sets editor.

In terms of the @Frank’s mockup, I understand why we would want the ability to save to different repositories (e.g., OHDSI public, Janssen, etc). But I do not agree with the idea of saving to a New Cohort Definition. The confusion created by supporting this type of use-case specific saving is not worth its benefits.

I recommend we keep things simple:

– Concept Sets runs the show for managing and creating concepts. All saving happens there.

– CIRCE loses its concept set building features All it can do is load concepts that have been created and saved using the above.

#5

Thanks @jon_duke for the feedback.

I thought that putting the whole concept set editing in the popup was complexity, but it does have the advantage of allowing the user to work in a temporary space to try things out and at the end be able to either cancel the changes or apply them to the concept set.

Alternatively, we could just have that popup provide a search facility that lets users put concepts into a basket and when they close the popup, the selected concepts get put into the current concept set (and defaults to include descendants). I don’t think we can remove the ability to add new concepts into a concept set that’s defined in a cohort definition. I can mock up what this would look like, if you are interested.

Also, your first point in your recommendations seems to indicate that concept sets can only come from the process of saving and loading them form the concept sets section. But concept sets can be just stand-alone lists of concepts that are used for a specific cohort definitions. Much of the time it’s just experimentation that you wouldn’t want to clutter a repository with saving them…but then there’s the refined concept sets that you do feel worthy to be persisted for the long term and so that’s where you’d save to the repository. Our current experience with the concept set repository is that we have several definitions for Diverticulitis, Stroke, and others. There’s good reasons for this: sometimes we’re trying to replicate another study and are using some codelist from literature. Other times, the researcher just wants to loosen up or tighten up the meaning of ‘hypertension’. So I think it’s the case that not every concept set that’s used in Circe is going to come from a persisted repository. But I do think that there should be an easy way to push concept sets from circe into the repo and also pull from the repo into circe.

-Chris

#6

@Chris_Knoll, your points are well taken, and I should amend my comments to say that I that “Import Concept Set” (whether as JSON or as a concept id list) should be retained in CIRCE. But I’d like to peel back the onion a bit further so we can address some underlying questions in the coming weeks.

Are we positioning ATLAS to be a collection of applications? Or rather is it destined to be the primary OHDSI Platform application?
My bias is towards the latter, that ATLAS should be essentially an IDE for CDM-based analytics. This gets to my comment the other day regarding a “Wizard” type navigation for novice users. What matters are the functions, not their ancestral applications. Right now, CIRCE has been tasked with too much-- being a phenotype library, a phenotype designer, a concept set builder, and a cohort generator. It’s a remarkable package. But we now have the opportunity to look across all our functionality-- from all of our apps-- and think about what is the right flow to perform observational analyses. ATLAS’ evolution should reflect that flow and make it intuitive for the user.

Can we move from concept sets and cohort definitions to a true Knowledge Base?
Keeping track of assets for projects is tricky. Coders figured out a long time ago how to keep things clean by importing from libraries and tracking exactly what is being used in any given project (thanks npm install!). That is every bit as critical for OHDSI to achieve our transparency and reproducibility objectives. We’ve made great strides in transparency-- any cohort definition can be viewed so people can look through it and figure out what what defined as what. But we can do a lot better.

What is better is having a unified knowledge base of:

  • Concept sets
  • Clinical facts - e.g. Hypoglycemia = ([glucose in mg/dL concepts] < 70 OR [glucose in mmol/L concepts] < 3.9)
  • Phenotypes - our current cohort definitions, along with metadata on performance in different environments, studies in which they are used, etc

Accepting the fact that Clinical Facts are not currently in our toolkit, I would still advocate that ATLAS should have a centralized Knowledge Base, and the first step in any “Project” is creating or selecting the assets you wish to use. ( Of course, you can always go back and edit your assets later in the project workflow.) CIRCE’s cohort definition editor is actually part of this Knowledge Base workflow, as is the Concept Set builder.

How to keep the Knowledge Base from becoming a huge mess?
I definitely catch your point about not wanting to formalize everything that goes into a cohort definition. You should be able to Import a list of concepts or paste in some JSON for a concept set. No problem. But ultimately, there is only one way for us to avoid creating a huge mess of Knowledge, and that is user context.

As we begin dealing with Auth this year, we’ve got to consider our plans for user context as well. At Regenstrief, we’ve got a massive NLP query library, but we allow users the option of sharing a definition or keeping it private. When something is good, you share it out and everyone has access. That keeps things clean and manageable while still letting people go to town on draft versions of stuff.

Sorry if I cruised beyond the core ATLAS/CIRCE scope, but I think that’s kind of the point. The old gods are dead. Let’s inventory their functions, erase their territorial boundaries, and make ATLAS the OHDSI platform to rule them all. :smile:

#7

Thanks @jon_duke for putting forward this vision for Atlas! I want to throw my support behind everything you outlined. I know that @Frank and @Chris_Knoll are focused on this near-term release to bring Circe into Atlas but it is hard NOT to think of the longer term goals for a single OHDSI platform when we have these types of conversations.

I think the design approach that is being utilized for this effort is worth re-using to envision the single OHDSI platform in Atlas. While I think I understand the aims and ideas you’ve put forward here, it always helps me to see how those materialize in a design using mock-ups and wire frames. It will help us to begin with the end in mind. I also think the architecture calls are a useful forum for discussing this - much of what we’d envision for Atlas will touch all aspects of the architecture in my opinion.

t