Disclaimer

• This presentation is based on publicly available information (including data relating to non-Novartis products or approaches).
  
• The views presented are the views of the presenter, not necessarily those of Novartis.   
• These slides are intended for educational purposes only and for the personal use of the audience. These slides are not intended for wider distribution outside the intended purpose without presenter approval. 
  
• The content of this slide deck is accurate to the best of the presenter’s knowledge at the time of production. 

The process of clinical drug development is highly regulated

In clinical drug development the goal is produce reliable evidence on whether or not a product is both safe and efficacious

This process involves multi-disciplinary stakeholders coming together to review evidence which is generated a highly regulated manner.

Working a regulated way as a statistician or programmer in pharma has three key pillars?

1. Traceable
   
2. Reproducible
3. Accurate

How do we manage tech evolution and adaption in pharma?

• Big-bang, disrutptive change takes time in a regulated environment.

• Non-disruptive change can help us make incremental progress to get ready for change.

Non-disruptive change for automated report generation

Let’s bring the modern tooling and practices to static document generation so that we can retain reproducibilty and work at scale.

From data to evidence

• Report generation relies on copying and pasting static outputs into a document
• This can be error prone, time consuming and doesn’t scale.

Additional pathway using {rdocx}

• We created a new package {rdocx} and process that leverages good data science practices that can generate company compliant reports

Use case: sample size estimation and reporting

What: Sample size report generation

Our trial statisticans estimate and document the sample size for studies using a company template in docx format. It is mandatory that the report complies with the company template.

How: successful development and change is so much more than good code

1. Get experts onboard (compliance, statisicians)
2. Co-design
3. Leverage good software development practices
4. Develop incrementally, demo-ing regularly

Let’s make a title page

Mandatory elements are represented as R6 classes where each attribute has a unique input requirement that goes through a series of checks.

tp <- rdocx::TitlePage$new(
  compound= "Compound",
  study_number = "Study number",
  study_title = "Study title",
  doc_status = "Final",
  release_date  = "01-Jul-2024",
  n_pages = "10")

# Generates the title page
tp$get_title_page()

Let’s make a change log

Mandatory elements are represented as R6 classes where each attribute has a unique input requirement that goes through a series of checks.

# Initiate change log table
changelog_table <- rdocx::ChangelogTable$new() 
 
row_1 <- rdocx::ChangelogTableRow$new(
  date = '01-Feb-2024',
  time_point = 'Before protocol finalization',
  reason_update = 'Creation of first version',
  outcome_update = 'NA - First version',
  section_title_impacted = 'NA')

changelog_table$add_row(row_1)

Let’s make a complete report

Check document template and render:

rdocx::print_ss_template_version()

rdocx::rmd_render(
  rmd_filename = "path/to/rmd_file",
  output_path= "path/to/final_docx",
  report_type = "sample_size",
  version = 00
)

A log file will be generated documenting the following:

• User, system, date and time
• Final document name and location
• Location of R packages and R session info (sessionInfo())

Inspect compiled document

The template is copyright protected by Novartis and should not be used for template preparation.

We embedded {rdocx} in good software development practices

We use object-oriented (R6 classes) to structure our package.

We embedded {rdocx} in good software development practices

We could create many assertions to do perform upfront checks.

tp <- rdocx::TitlePage$new(
  compound= "Compound",
  study_number = "Study number",
  study_title = "Study title",
  doc_status = "Final",
  release_date  = "01-07-2024",
  n_pages = "10")

Error in check_string_is_date(release_date) : 
  `Date` was not provided in the expected format (%d-%b-%Y). For example: 01-Oct-2023

We embedded {rdocx} in good software development practices

We have automated tests and check for each incremental change in to the rdocx package.

What’s next

• We plan to open-source our {rdocx} package with a generic template example
• We want to adapt it to more use-cases, e.g. pre-clinical safety report

Acknowledgements

• Jana Linnik (Developer and SME)
• Ines Gimeno Molina (Developer)
• Ivan Demin (Contributor)
• Maritza Cuero Melendez (Compliance)