Combine "like forms" into the same item_group tab

[aclark02-arcus]

As discussed at a previous meetup, it would be advantageous to display multiple "like" forms (listings) within a single tab (item_group). For example, displaying SAEs vs AEs on the 'Adverse Events' tab. To do this, there is a handy column in the app's example raw data called formid, so we'd just have to formalize it's use in the app.

In the proposed changes, there will be some big changes on the metadata.xlsx side of things. Two new columns have been added to the "common_forms" tab, primarily:item_form and secondarily: form_level_id_var.

Note that item_form should be populated...

1. To keep track of multiple forms (listings) we want to display on a single tab in clinsight or...
2. When we want to display a table title that is different from the tab title (item_group). What do I mean? Well... two examples:
   a. for con meds... traditionally been called "Medication" in the app. However, our DM suggested that we switch over to calling them by their "correct" names as defined in the EDC. In the EDC, CM is called "Prior and Concomitant Medication" which is waaay to big for a tab name. So, using this schema, we can use a brief name (item_group) to label the tab and a long form name to label the table (item_form).
   b. The code current has hardcoded a bunch of stuff in the app to depend on the presence of an item_group called "Adverse events" with a lower case "e". However, our EDC calls it "Adverse Events" with a capital "E". So, this pathway allows us to keep that code AS-IS, yet delineate the two.

In addition, you'll notice that the proposed solution will need another new column in the metadata called form_level_id_var. Why is this needed? Well, it's because of this chunk of code right here:

clinsight/R/fct_appdata_summary_tables.R

Line 156 in 573c633

dplyr::select(subject_id, "item_name" = Name, form_repeat) |>

.

Previously, the code assumes that any common_form will have a variable called "Name" which helps identify unique rows (to a certain extent). However, we've introduced a huge swath of domains into clinsight, and trying to label a column as "Name" in eacha one just doesn't make sense anymore, so usingform_level_id_var to identify which variable can act as the "Name" var will allow this code to still work. If you think there is a better way of doing this, I'm all ears.

Something required:

• As a result of the above, we'll have to create a new app_vars list object called item_form_group (a df) so that certain functions can parse out which variables belong to which form.

Something unexpected:

• Something else you'll notice about the proposed solution is that classes won't get applied to the "sub tables" defined by item_form. That is, the class of it's item_group parent won't automatically get carried down to the new list, so we'll have to write a little code to carry those forward a sub-level. That way, as we use create.table(), it will know which one to use.

Some things that I don't think are pretty:

• when using purrr to cycle through the forms (x), it didn't work as expected when length(x) == 1, so often times I had to say if(is.data.frame(x)) [do it the old way] else [do it with {purrr}] which I'm not really a fan of. That's because if x was a data.frame purrr would increment over all the columns of the df! I think it'd be nice to clean this up.

Some notes:

• There are a few sections where Leon's code refers to a group (item_group) as a "form" but now that "form" has a more literal meaning in the app, I think it'd be a good idea to rename these objects. I didn't rename them yet because I wanted to minimize code changes in the PR. Maybe I'll submit another commit at the end that changes these names first.