 Welcome. My name is Alessio Maggiorelli. I'm a data scientist, and this is my presentation about methods of report generation in clinical trials using R and DER. So a short introduction about us. We are the biostatistical group of the Coordination Center for Clinical Trials in Düsseldorf, and the Coordination Center is part of the medical faculty of the Heinrich Hall University in Germany. Usually clinical trials are highly regulated, so we provide support in executing clinical trials. Our history with R starts in 2001. Before 2001, we basically, this was basically the way we conducted statistical reporting. So we had our three sources of information, the study protocol, the database, and the notofiles if they existed. And with all of these three sources, we prepared the data, or as Hedley-Rickham likes to call it, data wangling, which is just a lovely term in my opinion. And we created tables and plots out of that, and this was usually done in SPSS and Excel. After that, we switched the word for formatting and adding some final additional explanation and text. So with the introduction of R in 2001, SPSS and Excel was switched for R. And between R and Word, we had to do a lot of copy and pasting from the R console, especially regarding tables. Now this got redundant with SWEF, or basically NITR in 2014, because now all of these four steps could be done from one Markdown document with R and NITR. We used, at that point, LaTeX as a formatting language, but last year we switched to Markdown because Markdown is a little bit easier to understand and also easier to write. A few notes on our history with R. So R was and still is not the standard in the medical field. The SPSS Excel and SAS is still used and switching to R was regarded as an unnecessary change from the norm. So people were a little bit never minded. However, of course, a lot of advantages. One is that the software is just free. And also the fact that you can control the whole report from one Markdown document basically is a huge plus regarding reproducibility and transparency. So we never have problems with inspections, for example. And also automation is, of course, another advantage in which I want to talk about more now. So let's dive into methods and specifically periodic reports. Periodic reports or safety reports are usually done in three to six month intervals within the clinical trial. So you have to do them over and over again. And with NITR, we implemented a template for periodic reports so that only one code chunk has to be changed and the rest is done automatically. So here's an example of how this might look. This is the code chunk you have to change. This is, for example, the path where the data can be found and the date of the last export date and so on and so on. If you change that manually and then knit the report, the NITR will do the rest automatically. Now this, of course, saves a lot of time. We are also currently creating a code library for the purpose of speeding up repetitive tasks regarding reporting. The code library contains functions to automatically generate nicely formatted tables and plots. And usually we use packages like Cable, Panda and GGplot for that. Over time, we plan to standardize our process of reporting in clinical trials in a comprehensible way and put all of these functions for free use in a package so that everybody can use them. An example of how that might look in a final analysis report is provided as a downloadable resource. I provided you here with an excerpt of our statistical analysis of Combine, which is a clinical trial about a combination treatment of patients with schizophrenia. Now we also face, of course, some challenges. Some R packages can be unstable. This can usually be a workaround by either using base R or just using stable versions of R packages by implementing some few lines of codes. And also, big reports can be a problem if you want to do small changes and want to look how they look in the final report, because big reports take a lot of time to compile. Now this can be, there's a workaround there by using, by splitting up the markdown file into multiple components so that you only compile the markdown file you want to take a look at. Now as an outlook, we are currently investigating Shiny apps to monitor our trial data on the fly. Now this is especially useful for colleagues who want to take a look at the data but are not familiar with the R terminology, so Shiny apps provide them with a nice interface they can use. And in addition, we also take a look on the G report and H report packages which are written by Frank Haver. He did a talk this year in January or February, I think, in the R Studio conference, which was really nice. So my suggestion for you would also be to take a look on that. And yeah, that's basically it. If you've got any questions or feedback, don't hesitate to send me a mail. I will gladly respond. And yeah, thank you for your attention and see.