Cohort Definition tab: Error in Resolved concepts

[pbr6cornell]

I believe there is an error in how Resolved concepts are being generated. Screenshot of example below:

For the conceptset of Anaphylaxis, which is all standard condition concepts, I am seeing the Resolved list shows source concepts, including records in Observation and Drug domain. For this example, CPRD, I verified that the drug concept shown here does not map to any of the standard concept.

My suspicion is that records shown in 'Resolved' are actually inclusive of concepts that would have been recommended as 'Orphan concepts'.

When I select 'Orphan concepts', i get the following message:

Steps to reproduce:
Select Anaphlyaxis cohort, select anaphylaxis conceptset, select Resolved button and look at results.

[pbr6cornell]

Note:

Expected behavior of 'Resolved', should be to produce the full list of Included concepts from the conceptset expression. It should not have non-standard concepts (unless non-standards are explicitly part of conceptset expression).

'Mapped' should provide the list of all mapped source codes to the included/resolved concept list.

[gowthamrao]

Few additional comments

1. The drop down for databases. i put that drop down before, but now would like the drop down with multi select for databases on the left menu bar like this. I think it makes the UX consistent.

2. The resolved concepts is a bug.

3. The output - given that we now have multi select for databases would be a wide table like this
   

4. Mapped - what do the resolved concept id's map to. one rendering would look like this. Note the first column is the conceptid from the resolved set.
   
   (An alterative UX is the make a drill down experience with reactable. i.e. in the resolved table itself, a row select opens another table with mapped concepts)
   In the UI i rendered for the screenshot - there is a concept id in the first column that is the resolved concept id. concept id in the second column is the mapped concept id.

5. Orphan - the orphan concepts not rendering is a bug. It should be rendered something like this
   

The record count would have counts of occurrence of the concept in the data sources

6. Note the additional radio button for persons/records. This is very useful
   

Depending on what radio button is selected, the counts in the header would change
Example when both is selected - the persons would have the cohorts person count, the record count would give the records in the cohort

If i select the radio button for persons, then the table structure would change from two level header to one level header with person count as the value next the datasourc ename as follows

[gowthamrao]

Also doesnt show numbers - when data exists for numbers

observed

Expected

[azimov]

https://github.com/gowthamrao/CohortDiagnostics/blob/execute2/inst/shiny/DiagnosticsExplorer/R/Results.R to the code in develop it would be easier.

But some summary

• we shouldnt have an inner join here, because it is possible that there will be mismatch between resolved concepts and concept table example Concept data does not get exported in incremental mode in certain situations #907
  

• is pointing to the wrong table
  

• not sure why the complexiting in resolved concepts here. i think it explains why it is taking so long to retrieve

[azimov]

The UX of having the database on the side is not helpful. Multi-select is also not that useful and can wait for a future version.

Orphan concepts were also removed in this tab as only supporting a single tab reduces the chance of error/development burden.

See #943

[gowthamrao]

Multi-select is also not that useful

i am fine with waiting for next version, but i disagree about the usefulness of the multi select. We need to know how the various data sources compare when resolving concept set expression. The side by side view allows us to do the comparison.