SAMPLE DATA MANAGEMENT PLAN (DMP)

STUDY NAME	Prospective, Multicenter, Single Arm, Phase 2 Assessment of the Safety and Efficacy of Myelator for Relapsed or Refractory Myeloma
PROTOCOL NO.	C115679	VERSION NO.	1.30	DATE	02/28/2024
INVESTIGATIONAL PRODUCT NAME	Myelator
IND NO.	0000	TRIAL PHASE	2
SPONSOR(S), NAME, AND ADDRESS	Novartistic PO Box 1567 8090 Zurich, Switzerland
FUNDING ORGANIZATION	National Institutes of Health
PRINCIPAL INVESTIGATOR, NAME, AND CONTACT INFORMATION	Alfred Bonner, PhD University of Unknown Department of Medicine Seattle, WA, USA

APPROVED BY:

Project Data Manager Name (Printed)
Project Data Manager Signature	Date

Principle Investigator or Sponsor Name and Title (Printed)
Principle Investigator or Sponsor Signature	Date

REVISION HISTORY

Table 1: Revision History

VERSION NO.	DATE	SUMMARY OF REVISIONS
Original	06/28/2023	First approved revision
Version 1.1	08/30/2023	Revised protocol number and updated data security plan.
Version 1.2	10/16/2023	Updated data validation plan and added data types.
Version 1.3	02/28/2024	Updated data anomaly software version number and process.

TABLE OF CONTENTS

1.	INTRODUCTION	3

2.	DATABASES	3

3.	NETWORK DIRECTORIES	3

4.	DATA VALIDATION PROCESS	3

5.	VERIFICATION OF DATABASE SETUP AND IMPLEMENTATION	3

5.1	SOFTWARE SPECIFICATIONS	3

5.2	USER ACCEPTANCE TESTING	3

6.	DATA ENTRY AND DATA CLEANING	3

6.1	SITE DATA ENTRY TRAINING	3

6.2	SOFTWARE PRODUCTION VERSION ACCESS	3

6.3	DATA ENTRY	3

6.4	DATA SECURITY	3

6.5	QUALITY CONTROL	3

6.6	QUERIES	3

7.	ELECTRONIC FILES	3

7.1	ELECTRONIC FILE INTEGRATION	3

8.	MEDICAL CODING	3

8.1	ELECTRONIC FILE INTEGRATION	3

9.	EXPORTED DATABASES	3

10.	EXPORTED DATABASES	3

11.	SEVERE ADVERSE EVENT RECONCILIATION	3

12.	CHANGES TO PRODUCTION DATABASE	3

13.	DATABASE CLOSURE	3

13.1	DATABASE CLOSURE CHECKS	3

13.2	CLOSURE QUALITY ASSURANCE	3

13.3	DATABASE UNLOCK	3

14.	DATA ARCHIVING AND FINAL PROVISION OF MATERIALS TO SPONSOR	3

15.	REFERENCE DOCUMENTS	3

16.	TERMS AND ABBREVIATIONS	3

INTRODUCTION

This study is a prospective, multicenter, single arm, phase 2 assessment of the safety and efficacy of Myelator for 50 adult patients with relapsed or refractory myeloma. The study will treat each patient for up to two years until disease progression, unacceptable toxicity, or consent withdrawal, whichever occurs first. The primary objectives are the following:

To investigate the efficacy of Myelator as drug therapy in relapsed and refractory myeloma patients. Efficacy is the overall response rate (ORR) primary endpoint as complete response, very good response, or partial response.

To investigate the safety and tolerability of Myelator as therapy. Safety refers to the incidence and severity of adverse events and tolerability refers to the total dose and percent of planned does delivered.

The purpose of this clinical data management plan (CDMP) is to document the data management, data handling practices, and responsibility of the study staff. The principal investigator and study manager will authorize this document. The study sponsor will also review and authorize this document. Following these authorizations, the clinical data manager will create a read-only copy of this document and manage the versioning. Each original, signed version will remain on file for audit purposes. The following staff members will circulate this document to appropriate study staff, as required:

Clinical Project Manager- USA

Clinical Data Manager- USA

DATABASES

This study will use the database software X, version x for electronic data capture. This software is cloud-based and provides document and signature control in compliance with 21 CFR Part 11. This software also supports differing levels of security based on the user credential, as assigned by the study clinical data manager in concert with the study information technology lead. In addition, cloud-security software backs the software and mitigates disaster, as per NIH requirements to be HIPAA compliant.

Ancillary software includes X, version 9.2 for data analysis and trending, and X, version 3 for data query alerts.

NETWORK DIRECTORIES

The staff will store data for this study in secure folders on the site’s closed network drive. Passwords protect access to the drive and folders. The data manager will store documents. These documents possess information that can identify patients in an electronic folder only accessible to Level 1 staff (i.e., the Principal investigator, Project Manager, and Clinical Data Manager). The Information Technology Manager will perform a daily backup of this drive. On a weekly basis, the Information Technology Manager will download data from the database into the e-folders for statistical analysis purposes.

DATA VALIDATION PROCESS

See attached Data Validation Plan.

VERIFICATION OF DATABASE SETUP AND IMPLEMENTATION

5.1	SOFTWARE SPECIFICATIONS

For protocol C115679, set up and verify the database schema by running the database scripts. Then, verify the scripts in the setup.

To run the database scripts, follow these steps:

A. Locate the folder with the scripts for the database. The default location is:

<FIELDING_HOME>/dbscripts/mssql

Run the scripts in the following order by using these database vendor tools:

fielding-db-config-for-common-8.1.sql

fielding-db-config-for-webfort-8.1.sql

After you run the database scripts, use the X tool to verify that you seeded the schema correctly. Follow these steps:

Open a command prompt window.

Navigate to the following location:

Linux: <install_location>/fielding/sbin

Windows: <Install_Location>\Fielding Systems\bin

At the command prompt, enter the following command:

Linux: ./X vdb

Windows: X.exe vdb

The preceding command creates the fieldingwebfort-vdb-<dd>-<mmm>-<yy>.txt file in the <FIEDLING_HOME>/logs directory.

Open the fieldingwebfort-vdb-<dd>-<mmm>-<yy>.txt file in a text editor, and search for the following items: FIWF* FOUND

These lines indicate that your database setup was successful.

Close the file.

5.2	USER ACCEPTANCE TESTING

See Test Summary Report for details of user acceptance testing.

Table 2: User Acceptance Testing System Checks

SYSTEM CHECK	TESTING DETAILS
1. Univariate value checks	Perform manual testing of subset of checks. Confirm that database imports data properly.
2. Multivariate cross checks	Trigger a query via test data.
3. Custom checks	Second programmer reviews code. Perform a query to test.
4. Confirmation of subject numbers	Confirm appropriate generation of subject numbers.
5. Data completion	Confirm that software properly completes each field guideline.
6. Email alerts	Confirm email alerts with test data.
7. Software role assignment	Confirm role functionality with tester roles.
8. Data extracts	Confirm that extracted data matches data specifications.
9. Data imports	Confirm that imported data matches data specifications.
10. System reports	Run reports with test data. Ensure that reports meet requirements.
11. Custom queries	Confirm using specifications.
12. Variable computation	Confirm using specifications.
13. E-learning	Confirm that e-learning meets requirements.

DATA ENTRY AND DATA CLEANING

6.1	SITE DATA ENTRY TRAINING

The staff will train on X software within one week of its employment with this study.

6.2	SOFTWARE PRODUCTION VERSION ACCESS

For access to the production database, the staff will give a request in writing to the clinical data manager, including date, length of use, and purpose. Only the clinical data manager can grant privileges for this level database. The clinical data manager will maintain a comprehensive list of all the staff members who have access to this database at this production level.

6.3	DATA ENTRY

On-site level 1 staff will enter CRF data directly into the database. A second level 1 staff member will also perform a secondary review of the CRF data on the same day of original data entry. Log and date all reconciled data. Level 2 staff will sign the data reconciliation log on a weekly basis.

6.4	DATA SECURITY

X software provides varying level of data security. X software is cloud-based, without a physical server on site. All e-folders will follow the company-level security requirements.

All staff members will change their passwords every 30 days.

Level 1 staff will have access to data entry screens, including the ability to edit on data entry screens (first pass only).

Select Level 1 staff members who will have access to data edit functions, as per the clinical data manager.

Level 2 staff will have access to all data edit functions.

Level 3 staff will have access to the production database.

X vulnerability scanner software will perform on a weekly basis. Information technology staff will perform necessary fixes, as per the software.

6.5	QUALITY CONTROL

Information technology staff will perform unit testing before using the database. Staff will perform system integration testing procedures:

Data integration testing

Staging testing

Target testing

Database integration testing

Application extract testing

Campaign mart testing

Staff will perform user acceptance testing before using the database (as per section 5.2).

6.6	QUERIES

X software auto-generates queries for response and resolution. Level 1 staff will respond and resolve queries on a weekly basis. X software keeps a log of all queries and query responses. No manual queries are necessary for this study.

ELECTRONIC FILES

Describe how the staff will integrate data files from outside the database with the database (i.e., clinical data). Detail the data transfer schedule, frequency, and format. Also, detail the security procedures to prevent malware during data integration. If the staff stores the data before integration, detail the location and security procedures. Detail any procedures to fix issues and the staff members who will be responsible. Use the table below to detail the different data types and integration processes. If receiving normal-range laboratory data, detail the receipt and processing procedures.

7.1	ELECTRONIC FILE INTEGRATION

Table 3: Electronic File Integration

DATA TYPE	CRF LOCATION	SOURCE OF DATA	TRANSFER FREQUENCY / SCHEDULE	NEW OR CUMULATIVE	ADDITIONAL INSTRUCTIONS
Hematology	HEMA	X-Lab	Daily/Secure FTP	Cumulative	Store in F:\Myelator\Data\HEMA, Conversion program runs nightly to map subject ID to medical record number. The software will send an email to the CDM if errors occur.

MEDICAL CODING

X Software uses MedDRA and WhoDrug dictionaries. On a weekly basis, the staff will apply X software for the medical coding of data from patient visits. Additional Level 1 staff will perform reviews on a weekly basis. Level 2 staff will perform adjudication, if necessary.

8.1	ELECTRONIC FILE INTEGRATION

Table 4: Medical Coding

DATA TYPE	SOURCE OF DATA	CODING DICTIONARY	VERSION	ADDITIONAL NOTES
Adverse Events	Level 1 Staff	MedDRA	2
Medical and Surgical History	Level 1 Staff	MedDRA	2
Concomitant Drugs	Level 1 Staff	WHODRUG	2013

EXPORTED DATABASES

Staff will export data from the database at monthly intervals for statistical analysis. Export the database objects to an XML file using the schema, either manually or with the custom controller. Transfer the files from the instance to the back-end system. Configure the secure connection and deliver to the SFT.

EXPORTED DATABASES

List data management reports in the table below.

Table 5: Report List

REPORT	PURPOSE	FREQUENCY	RECIPIENT	HOW RECEIVED
Test Summary Report	User acceptance testing	Beginning of study, after updates	CDM	.xls
Medical Coding Report	Comparison of notes and coded materials	Prior to DB lock	Medical official	SFT file

SEVERE ADVERSE EVENT RECONCILIATION

Level 1 staff will:

Perform SAE reconciliation monthly and prior to the database lock. Before reconciliation, the data in the clinical database should be complete and validated, and any outstanding issues should be resolved.

SAEs will not be included in the clinical database two months prior to the close of the study.

Create a full list of SAEs from the database. Compare the listings, check that all SAEs have been captured in the database, cross-check all data variables that have been identified as critical for reconciliation, and summarize the reconciliation process in a SAE reconciliation report.

Document discrepancies identified during SAE reconciliation. Reconcile any inconsistencies with Level 3 staff as mitigators.

Document any final inconsistencies.

CHANGES TO PRODUCTION DATABASE

Prior to making changes to the production database, information technology staff must receive written authorization from the clinical database manager. Submit the request with the issue, date, and requested changes to the clinical database manager.

All production database changes will use small batches: one script, one operation type, one object to reduce the merge conflicts.

Additional notes:

Staff will validate changes before, during, and after deployment. Staff will first run scripts in test environments.

Staff will announce deployment downtime no less than one day before expected. They will allow ample time for recovery and address any affected applications.

Staff will maintain the database change script in production. Tracking will include Script Unique ID, the name of the staff member(s) who executed the script, when that staff executed the script, the status of execution (fail/success), and the script output log.

After the staff makes changes, update this document in the testing section.

DATABASE CLOSURE

Describe all processes and staff responsible for closing the database at the completion of the study.

13.1	DATABASE CLOSURE CHECKS

Before data management staff can close the database:

All participants must complete scheduled follow-up and final visits.

All clinical trial data - CRFs, laboratory reports, SAEs, etc. - should be entered into the database and cleaned.

All data coding must be complete.

All SAEs must be reconciled.

All outstanding data queries or questions to the investigators or site personnel must be resolved and entered into the database.

Permission to lock the database must be approved by the clinical data manager.

13.2	CLOSURE QUALITY ASSURANCE

Before the staff closes the database, they must ensure that they’ve done the following:

Finalize drug accountability records.

Destroy, return, or dispose of unused medication.

Resolve all data.

Prepare all data for storage.

Notify sponsor and Institutional Review Board at trial closure.

The clinical data manager will approve the database lock prior to locking.

13.3	DATABASE UNLOCK

Only critical errors can justify database unlock. The staff does not need to unlock the database or update non-critical errors. The staff will document non-critical errors in the analysis plan. The staff will archive copies of the original database and the corrected database. They will also give clear documentation of the archived databases, with reference to the publication.

DATA ARCHIVING AND FINAL PROVISION OF MATERIALS TO SPONSOR

The staff should archive the clinical trial data appropriately to enable supervision after the study’s end and preserve the dynamic character of the audit trail. The staff can archive the data only after the principle investigator and sponsor have completed their documentation. After archival, the staff will restrict access to archived data/documents to Level 3 staff.

REFERENCE DOCUMENTS

Describe in the chart below any references that are important for clinical data management of the study, but are not included as a part of this clinical data management plan. These reference works can include documents signed by someone other than the principal investigator, frequently updated documents, and documents owned by someone other than the principal investigator.

Table 6: Reference Documents

REFERENCE	CONTENT	OWNER	LOCATION CURRENT VERSION STORED
Data Validation Plan	Description of edit checks and any additional manual checks.	Clinical data manager	F:/Myelator/DVP
Data Dictionary	List of dataset names with variables and corresponding values/labels	Clinical data manager	F:/Myelator/Data/Coding

TERMS AND ABBREVIATIONS

In the table below, include definitions for any terms or abbreviations in this document.

Table 7: Definitions

ABBREVIATION / TERM	DEFINITION
CFR	Case Report Form
CDMP	Clinical Data Management Plan
MedRA	Medical Dictionary of Regulatory Affairs
SAE	Severe Adverse Event
WHODRUG	World Health Organization coding system of medications

DISCLAIMER Any articles, templates, or information provided by Smartsheet on the website are for reference only. While we strive to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the website or the information, articles, templates, or related graphics contained on the website. Any reliance you place on such information is therefore strictly at your own risk. This template is provided as a sample only. This template is in no way meant as legal or compliance advice. Users of the template must determine what information is necessary and needed to accomplish their objectives.