DPP Builder - Requirements

[JohnCoene]

This is a list of requirements that I foresee will be needed for the DPP Builder, feedback is of course welcome.

Quick recap of the core features the product and usage of the final product:

• User uploads a Study Analysis Plan (SAP), this document contains all information required to conduct the study, including the tables and figures that need to be produced. Handling re-upload of SAP and diff on outputs seems difficult
• Use the uploaded SAP to generate the initial list of outputs that need to be generated.
• User can create tabs to organise their outputs (likely 1 tab = 1 section, e.g.: AE)
• User can create and edit stacks
• User can save workspace and dashboard state to database
• User can export entire workspace ~ generate the DPP document from the application
• Tables should be available in rtf format for submission

We'll have one app/deployment per study. This makes the management of the deployments more cumbersome but allows freezing some deployments on certain versions of blockr.

Thoughts on table creation

Some tables follow well defined standards, others may not. We need to accommodate to both: the user can build a table from scratch, or use a standard template. We need modular blocks to construct those non-standard tables and make a decision as to how the standards tables are built:

• A standard table is a specific configuration of modular blocks
• A standards block is a single block with a pre-defined set of fields

The former implies 1) a very good modular system of blocks to generate the tables (which is more difficult than it may seem) 2) a "library of standards:" serialised stacks (one per standard) that the user can import in the app.

I personally lean towards the latter because it removes the need for the library of standards and because I do not think we can come up with a modular set of blocks that allows creating all the tables by EOY.

(Share any other ideas you may have)

Current Issues

We have 13 issues marked as bug, 7 of those are marked critical, it would be good to tackle these.

Save and Restore

We're going to heavily rely on the "save and restore" feature so we need to make sure it's robust and fully functioning. We still have some issues in places, primarily with connected stacks.

Add block

We're going to need a nice interface to add blocks. If #325 does not suit feel free to create something else.

Field keywords

We should allow fields to be set to NA, NULL, and other such keywords.

Exposing inputs

Allow selectively toggle inputs to non-admins of the dashboard, if #337 does not suit we need to create something else.

Table generation

We need to do some exploration as to which way is best to create those clinical tables in R (blockr aside), it's no easy task. Note that we also need to be able to create those tables in rtf format.

Library of stack

Library of stacks to reuse, this requires the serialisation and restoration to work so we can serialise stacks, store them on disk/database then import them into the app.

We may not need this depending on the approach we take to create the tables (see above)

Export workspace

We need to be able to export entire an entire workspace to a document, ideally that document could be rendered to the DPP document (quarto|Rmarkdown). I've started work on this on blockr.export but it still misses a few features.

We probably also need to simplify some things to make sure we can deliver. I would considerably simplify it so we can reduce complexity outside of blockr and ensure it is stable.

Feel free to comment on this, suggest changes, additions, etc.

@karmatarap @christophsax @nbenn @MikeJohnPage