Capr v2 Feedback Forum

[mdlavallee92]

Hello 👋

Intro

I have created this discussions page as a forum to receive commentary on Capr version 2. Since this update poses significant changes to the Capr user-interface, we thought it would be a good idea to survey the feel of the new interface before releasing in HADES. Some things that we are looking for:

1. readability - Does the Capr code read like a description of a cohort? Are you able to interpret what is being constructed solely using the code? What areas of the code remain confusing? A major focus of this overhaul is to make the code more readable, thus making it easier for people to adopt in their analytical pipelines or use the templating idea in their projects.

2. usability - With these changes are you more likely to use Capr in your projects? What has prevented you from using Capr in the past and does version 2 bridge those gaps? What other tweaks would you suggest that would promote greater usage?

3. templating - based on feedback from original Capr, the perceived advantage of this package is to use it for templating cohorts. For example if we wanted to make 50 simple prevalent cohorts, we can make a basic Capr template of a condition cohort and cycle through different concept sets. We want this to remain the main focus in version 2. Is this a feature you would use with Capr? Is it clear how to template using Capr? What can the Capr development team do to improve the understanding of this feature. The following gives an example of a Capr template in action demo.txt

4. additional comments - do you have additional comments or suggestions on Capr version 2? Are there other features you wish to see? Do you have any questions?

Overview

Capr is a programmatic interface to defining cohort definition for the OMOP CDM. Capr builds a representation of a cohort through R that can be serialized to json. The json structure can be imported into ATLAS. This structure follows that of circe-be, that object representation of cohort definitions in OHDSI. A valid circe-be json can be serialized into ohdsisql, a parameterized version of sql that builds cohort under the assumptions of the OMOP CDM structure.

Capr Example

[sutsabs]

I have been using Capr to create conceptsets and cohorts in R and then load these to Atlas tool. A common workflow would be to pull existing conceptsets or cohorts to R system using ROhdsiwebApi. Using these conceptsets either build new cohort or use existing cohorts as templates for new Cohort.

One issue I have been having is converting the cohorts and conceptsets ROhdsiwebAPI list object to Capr compatible. I am having to rebuild from scratch. Once I create the cohorts using Capr I am able to use toCirce function and post the cohort to Atlas. I would love to see how one would using existing cohorts and conceptsets from Atlas and reuse them.

I having been also struggling to add date criterias. For instance: If I want occurrence start date between 01/01/2018 and 12/31/2021. I can create the cohort object but it seems to fail when posting to Atlas.

Also I think adding some more examples would be nice. For instance, examples of inclusion criteria, exclusion criteria, complex queries, using dates, multiple events. I had to dig deep into the code to figure out some of the capabilities.

[mdlavallee92]

Thanks for the post @sutsabs! Yes I will add more examples, I know this has been sorely lacking. Hopefully I can spend some time with that this week or next.

As for your workflow....this is a good idea. I need to check how ROhdsiWebApi parses json. I know there can be differences based on the tool you use. I try to use jsonlite, not sure what ROhdsiWebApi uses, think its RJSONIO. Also WebApi stores the json differently which can be causing issues when importing a definition in as an R object. I will look into this.

In older Capr, we spent time working on being able to save out component parts. For example save the concept set as a json or the query as a json. Capr 2.0 I have not fully incorporated this feature into the package because I was unsure to this point how many people would actually use this. What would be nice is to build out component libraries and then chop and change the definitions from your institutional knowledge. You could save these components in a directory locally however I also see the advantage of storing them via ATLAS since it may serve as a more central location. ATLAS has a reusables feature, but I am not familiar with how the object is saved in WebApi as json. I can take a look into this over the summer.