Essential Project Management Reports in Clinical Development Nalin Tikoo, BioMarin Pharmaceutical Inc., Novato, CA ABSTRACT Throughout the course of a clinical trial the Statistical Programming group is responsible for the development and management of SAS programs that generate various outputs such as datasets, tables, listings and graphs. As the clinical development program moves forward these deliverables become increasingly numerous and more challenging to manage. Details about the programs and the project management reports they produce are described in this paper. INTRODUCTION This paper describes how project level metadata are maintained at BioMarin Pharmaceutical Inc. in the Statistical Programming group and used to generate various project management reports. In the next few sections I will talk about the nuts and bolts of how all the available metadata are processed to generate reports that are essential to successfully bringing a project to the finish line. BACKGROUND Effective and efficient project management requires close monitoring of the status of deliverables, resource management and timely resolution of issues that impact successful and timely completion of a project. These requirements create a business need to develop tools that help us in doing so. At BioMarin Pharmaceutical Inc. statistical programmers use an EXCEL workbook called APD (Activity Programming Deliverables) to maintain project level metadata. This file contains information about the deliverables including but not limited to deliverable priority, development and verification status, who is working on each deliverable ie programmer s userid and any program specific comments. There is a script to convert this file into a SAS dataset every time the file is updated. This project level metadata is then used to put the required reports together. NUTS & BOLTS The report generation is a two step process which is executed via a PERL script. The first step uses the control file to indentify the projects for which the reports need to be generated and updates the metadata for those projects and the second step generates the reports that the user has requested, figure 1 illustrates the report generation process. THE SCRIPT: Purpose: It is a script that uses a control file and the APD workbook metadata to generate project status reports. STEP 1: PROCESS CONTROL FILE Purpose: It provides the information regarding which reports should be generated and for which projects. Control file is a delimited text file that the script expects in the folder where the script is being executed from eg. the users home directory. Syntax: It is a delimited file It is expected to contain the following information o Absolute activity path - required o Default is the user. User IDs for team members to whom the email needs to be sent is optional, o Report identifier keywords - required Example: /xxx/xxx/xxx/xxx/xxx/xxx/xxx/specs <email userid>/ <report1>/<report2>/<reportn>/ 1
Through the use of the # symbol at the beginning of a control file entry, users have the flexibility to exclude a particular project that they might not want to include in the reports. The users have the flexibility to have one control file per molecule which could potentially have multiple entries, one per project, or they can use one file containing all the projects that they are managing and use the # functionality to selectively run reports. The structure of the control file is 1 entry per project. STEP 2: RUN RELEVANT REPORT GENERATION PROGRAMS Purpose: The reports identified from the control file are generated for the projects specified. This is achieved by passing information from the control file to a handler program which uses report identifier keywords to know which reports need to be generated. The advantage to this architecture is scalability. If a new report needs to be programmed, a keyword for that report will be used as a suffix for the program generating the report and the handler program will automatically pick that as a report identifier and generate the report. THE REPORTS: Figure 1: Report generation process In this section I would like to provide examples of the reports generated. We currently have 3 reports programmed namely the summary report, the assignment report and the reconciliation report. Let s go over these one at a time. 1. Summary Report: Purpose: Provide the status of the project as of the report run date. This report has two parts to it; the summary section and the details section. Summary section: This section summarizes the status of the project for each set of deliverables. Based on the program naming convention the deliverables have been categorized into Activity Dataset i. SDTM ii. ADaM 2
Activity Report i. Table ii. Listing iii. Graph Adhoc Dataset Adhoc TLG For each of the type of deliverables identified above, the numbers and percentages are presented for development and verification status. Figure 2: Sample summary report summary section Details section: This section summarizes the details of the project for each set of deliverables. This report sorts the programs in the project by the priority flag (high, medium, low) and presents the program type, the QC method and programming status. Figure 3: Sample summary report details section The number in the parenthesis after the program name is the number of outputs the program generates. Traffic lighting is used which makes the report review easier. 2. Assignment Report: Purpose: Provide the assignment status of each program and track any discussion items. 3
This report is a line listing of each unique program in the project along with the developer name, verifier name and a comments column. This report is useful to keep track of questions, comments or concerns during the course of the project that programmer might want to discuss at the team meetings. 3. Reconciliation Report: Figure 4: Sample assignment report Purpose: To make sure that the last modification dates of development programs & their log files are prior to verification programs dates, the development programs have read only attributes and program verification type match with that in the validation documentation. This report compiles all this information together and the traffic light is used to facilitate the review. DELIVERY MECHANISM: Figure 5: Sample reconciliation report The reports are emailed using the FILENAME statement in SAS. The default recipient of the reports is the user running the script; users also have the flexibility to add the userids of their team members in the control file. The userids from the control file are added to the cc list in the email. For all the activities/projects specified in the control file, one summary report is generated and emailed. For other 2 reports, one report is generated per project and emailed. In other words if you were a user running these reports for 3 projects and all three reports you would expect 4 emails, one with the summary report as an attachment, 1 email for each of the three projects containing 2 attachments each; 1 of each of assignment and reconciliation report. Syntax: FILENAME fileref EMAIL <email-options>; 4
Email Options: TO= email address or addresses of primary recipients If there is more than one email address in the to-list, enclose the group of addresses in parentheses, enclose each address in quotation marks, and separate each address with a space. CC= email address or addresses of recipients who should be copied on the email Syntax for CC option is same as that for TO option. FROM= email address of the sender SUBJECT= subject ATTACH= the full physical path and file name of the file(s) to be attached to the message The full physical path can be retrieved by using the pathname function. Enclose the physical path and file name in quotation marks. To attach more than one file, enclose the group of files in parentheses, enclose each file in quotation marks, and separate each with a space. For details on all email options, refer to the SAS online documentation. Sample code for emailing reports from within SAS : filename outmail email subject="apd Summary Reports Requested" from="&uid@bmrn.com" to="&uid.@bmrn.com" cc=(&cclist_summ.) attach=("xxx/xxx/xxx/xxx/xxx.pdf"); data _null_; file outmail; put "Please find the status reports attached."; put " "; put "Thanks, &uid."; run; CONCLUSION In conclusion I would like to say that clinical development like any other business needs close monitoring to be successful and we as statistical programmers have that responsibility at least in part. The reports described here are tools that can help us achieve our goals effectively and efficiently. I hope this paper is useful to you as you consider your project management approach. REFERENCES Online documentation for SAS software, Version 9.2 Online documentation for PERL scripting: http://perldoc.perl.org/ ACKNOWLEDGMENTS I would like to thank Nick Paszty for his constant support and guidance throughout the course of the project as well as his valuable input in this paper. 5
CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the author at: Name: Nalin Tikoo Enterprise: BioMarin Pharmaceutical Inc. Address: 105 Digital Drive City, State ZIP: Novato, CA. 94547 Email: ntikoo@bmrn.com The output/code for this paper was generated using SAS software. Copyright, SAS Institute Inc. SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc., Cary, NC, USA. SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. indicates USA registration. Other brand and product names are trademarks of their respective companies. 6