changes to concept set

[gowthamrao]

This PR creates a new function called 'resolveConceptSetId' that given a conceptSetId resolves the expression to return the included and mapped concepts as a data frame. This new function is useful to use included concepts/mapped concepts from a conceptSetId. Data frame is in camelCase.

Existing function createConceptSetWorkbook can now use this new function to create workbook.

Function has been tested/checked.

[codecov-io]

Codecov Report

Merging #32 into develop will decrease coverage by 9.15%. The diff coverage is 0%.

@@           Coverage Diff            @@
##           develop   #32      +/-   ##
========================================
- Coverage     9.15%    0%   -9.16%     
========================================
  Files            4     4              
  Lines          448   531      +83     
========================================
- Hits            41     0      -41     
- Misses         407   531     +124

Impacted Files	Coverage Δ
R/ConceptSet.R	0% <0%> (ø)	:arrow_up:
R/WebApi.R	0% <0%> (-75.93%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 8ed2756...5be55df. Read the comment docs.

[schuemie]

Why is conceptSetExpression.xlsx in the root folder?

[gowthamrao]

Why is conceptSetExpression.xlsx in the root folder?

Mistake - needs to be deleted

[alondhe]

Hi @gowthamrao -- did you get my email suggesting an alternate way to build this functionality based on existing functions?

[schuemie]

@alondhe , @gowthamrao : I badly needed some functionality for COVID-19, and went ahead and added it without consulting you.

The up side is that it already provides the functionality @gowthamrao was looking for. See the example code here for how you can now take a concept set either from within a cohort definition, or from WebAPI's list of concept sets, and output it either as (1) a cohort set expression table, (2) the list of included standard concepts, or (3) the list of mapped source concepts.

I noticed ROhdsiWebApi is growing in an odd way: for every output we require we build a function that gets JSON from WebAPI and outputs it to the required format. I propose a principle that I've attempted to implement in the new functions:

• There are functions for extracting (complex) R objects from WebAPI. These R objects no longer contain any JSON, but are full R object representations of the JSON, and can therefore be easily used in R, for example cohortId <- estimation$cohortDefinitions[[1]]$id
• These R objects can serve as input to functions that interact with WebAPI, which means in the back-end they're converted back to JSON (for example conceptIds <- resolveConceptSet(conceptSet = conceptSet, baseUrl = baseUrl))
• We have separate functions that convert the R objects to the various required output formats, such as pretty tables, JSON, or anything else.

Let me know what you think

[gowthamrao]

• There are functions for extracting (complex) R objects from WebAPI. These R objects no longer contain any JSON, but are full R object representations of the JSON, and can therefore be easily used in R, for example cohortId <- estimation$cohortDefinitions[[1]]$id

Maybe we should ensure that these are convertible both ways - i.e. JSON -> R-object, R-object -> JSON. It would support use cases where we want to store/export a specification such as wanting to export (post) JSON back into Atlas (maybe another instance). I have found that in Atlas we are using nested JSONs, which makes this complex. So we will need to test this strategy.

These R objects can serve as input to functions that interact with WebAPI, which means in the back-end they're converted back to JSON (for example conceptIds <- resolveConceptSet(conceptSet = conceptSet, baseUrl = baseUrl))

We have separate functions that convert the R objects to the various required output formats, such as pretty tables, JSON, or anything else.

I have struggled with using R-objects as storage, but it makes it easier. Are you thinking of persisting the R-object in local drives like e.g. rds objects? Or just in-memory objects?

are we thinking of using this same framework for data pulls too - e.g. extract (large) data into an R-object and then push to local dbms like sqlite (or ff?). Or, is this framework limited to objects that are not data.