Background information

The Data Management Plan (DMP) has multiple purposes and is used to comprehensively document the collection and handling of the data. This should represent the accountability of every operation performed on data from the time it is collected until finalized as part of a dataset for analysis and can be reconstructed if needed. As this is a comprehensive document of data collection and processing, how the data will be managed, described, and stored, what standards you will use, and how data will be handled and protected during and after the completion of the project. The DMP will also be audited to determine regulatory compliance and adherence to the documented processes. Audits or inspections usually include review of Standard Operating Procedures (SOP’s), training records, and the DMP as well as review of actual data, this is to ensure data integrity.

Procedures for data collection and processing also serve as a reference for personnel performing data collection and management tasks to ensure consistency of the work. The DMP should be clear, concise, and consistent.

The DMP is typically developed with the aid of the Clinical Study Protocol. Case Report Forms (CRF)/data collection forms, SOP’s/working guidelines and study specific key factors considered by the author and reviewers.

This is a working document to be reviewed and updated on a scheduled basis.

Instruction for use

This template is created based on experience within the Association of Clinical Data Managers (ACDM) and covers most aspects of Data Management (DM), you should however, always follow your companies processes and structure.

Add and remove sections as applicable.

[Text in Blue] = Information, instructions and what considerations are needed, this text should be removed prior to finalisation.

[Text in Red] = Information or examples to assist with the creation of the DMP.

[Text in Black] = Example text that can be used and amended to meet your company requirements.

Protocol Details:

Sponsor
Vendor Partner
Program
Study Identifier1 (Study Code)
Study Identifer2 (CRO Study Identifier)
[Eudract Identifier (if applicable)]
Protocol Title
Protocol Date/Version	Version 1.0 01Jan2021 Version 2.0 01Mar2021 (Amendment)
Protocol Phase
Local or Multi-national

Document Control: By signing below, the contents of this document have been agreed and approved (dependant on Study Operating Procedure approval requirements):

Company	Function	First Name| Last Name	Signature	Date (DD-Mon-YYYY
Author
Study Team Member1
Study Team Member2
Study Team Member3

Revision/Version History

Version #	Effective Date	Author	Summary of Change

[Please follow you company’s template and /or SOP on creating documents]

Contents

Purpose	5

Protocol Summary	5

Timelines	5

Roles/Responsibilities	6

Study Documentation	6

Data Management Tools/Systems	6

Standard Operating Procedures & Governance	6

Data Flow	7

Study Set Up	7

Randomisation	8

System Integrations	9

Medical Coding	9

Data Validation Specification	9

Study CRF Completion Guidelines	10

Transfer Agreements – Non-CRF Data	10

Initial Clinical Database Release and Change Management	10

Conduct	11

User Access	11

Data Extraction	12

Data Cleaning	12

Continuous and Critical Data Review	13

Standard Reports	14

Coding Review	15

SAE Reconciliation	15

Non-CRF Data Reconciliation	16

Risk Assessment	16

Closeout	17

Database Lock	17

Database Unlock	17

Additional Sections	17

Protocol Deviation	17

Withdrawal of Consent	18

Handling Early Termination and Lost to Follow-up	18

Handling Screen Failures	19

System Back-ups, Scheduled Downtime & Disaster Recovery	19

Archiving & Decommissioning	19

Definitions/Abbreviations and Terms	19

Appendices	20

Appendix A - Links	20

Appendix B – Dictionary Coding Specification	21

Appendix C – Database Lock Checklist	22

Purpose

The purpose of the Data Management Plan (DMP) is to provide an overview of the data management process to be applied to this study, as per specific protocol and [study/sponsor] requirements. This plan is a summary representing how the data management processes will be conducted from the set-up of the required systems and apply them to deliver complete, clean and consistent data for analysis.

[The DMP describes the procedures for data collection and processing of study data and serves as a reference for personnel performing data collection and management tasks. As a reference or job aid, the DMP should be clear, concise, and consistent. Information contained in this document should be enough for a replacement data manager to understand functionalities and tasks to be performed.]

[Further detail for many of the processes should be found in the relevant SOPs and specification documents. This document is intended to a provide data management process over-view and study specific details, to ensure that data management functions can be completed from set-up to close-out activities].

Protocol Summary

A [Phase 3 randomised double-blind study to compare placebo with substance ABC in the indication XYZ].

[Include the Clinical Study Protocol Summary – this should be a direct verbatim copy.]

Timelines

Current Study team timelines [link OR location] can be found in Appendix A.

[All study timelines should have input from all functions, the Data Manager will need to provide reviews and feedback to ensure Data Management milestones are met, example of functions below:

Gap analysis/eCRF Specification based upon the Protocol requirements– how much can be copied from a Global Library with no or minimal changes, will reduce set-up time.

Edit Check Specification

eCRF Set-up activities

User Acceptance Testing/ Validation activities

eCRF Go-live

Edit Check Go-live

Vendor data (inc. Transfer and handling)

First Subject In

Interim Lock dates (if applicable)

Last Subject In

Database Lock

Archiving & Decommission

Timelines including activity type and action/deliverable must be reviewed and updated regularly. [A link or location should be included so that an end-user can locate this information easily. – Add Timeline link]

Roles/Responsibilities

[This can be a table or list of the key personal and contact details; this can be split in to CRO and Sponsor]

Role	Name	Contact Details
[Study Data Manager]
[Data Management Assistant]
[Biostatistician]
[Clinical Coder]

Study Documentation

All Documents relating to this study will be stored according to the current SOP, this list can be found [link OR SOP list location documented in Appendix A.]

[If you have a SOP relating to how the eTMF is set up and managed then reference it here. If working as or with a CRO it’s a good idea to define who will store what in their e/TMF to avoid duplication.]

[At study close, all DM documentation stored in the e/TMF will be prepared for archiving and supplied to the sponsor.]

Data Management Tools/Systems

The following tools/systems will be used for this study.

[It is a good idea to have a list of the systems being used for the study, version being used and the purpose. Remember if systems are updated then this table needs to be updated too]

System/Tool name	Version #	Function
[EDC/Database (e.g Medidata Rave]	[1.111]	[Clinical Data Management, eCRF entry, data cleaning, standard report tool]
[SAS]	[2.222]	[Programming tool – for creation of listings/reports]
[eTMF e.g. Veeva Vault]	[3.333]	[Electronic/Trial Management File]
[SAS]	[4.444]	[Storage repository (Pharma only)]

Standard Operating Procedures & Governance

A link to the list of SOP and governance documents can be accessed in Appendix A.: [Add hyperlink]

[All data management tasks will follow SOPs and company governance, which is mandated. Such documents are in place to ensure that current regulatory requirements and laws are adhered to, during the set-up, conduct and end of the data management function activities.

During the course of the trial, SOPs or Governance documents maybe updated, therefore it is important to document which SOPs/governance are applied and during which time period. Any updates to SOP’s that have been recorded in the DMP will need to be updated, so be careful when listing these in studies that run for a long time. This can be done as a table or a link to a location (see below)].

Data Flow

[Location of the data flow for this study can be located here <Add link>:

See below for the high-level data flow for the study]

[Example of a data flow can help with the data integrity, work flow and understanding of where the data are being shared, review, stored and analysed.]

Study Set Up

[Electronic Data Capture (EDC)/Software] is being used for this study to capture the Subjects data and is listed above in the DM tools/systems.

[EDC/Software] will be built based on information provided in the protocol and any other project-specific information that may be obtained. [CDISC standards/Global library] will be used, new and amendments to standards or study specific forms [will be requested, created and approved if required].

The [Data Validation Specification (DVS)] will be developed [from a template] and made study-specific based on the most current version of the protocol and eCRF. The [DVS] will include standard and protocol-specific checks, and any checks that are specifically requested by the [sponsor/study team], if applicable. Any revisions to validation checks will also undergo the same process for validation and approval before implementation.

[User Acceptance Testing will be performed and approved, prior to go-live.]

[Alerts and integrations will be tested and approved prior to go-live.]

[The validated tool selected for the eCRF build needs to be Part 11 21CFR compliant, must reflect the Clinical Study Protocol this maybe initiated as a direct creation or from a GAP Analysis:

The use of a Sponsor or CRO Global Library or Data Standards waivers should be documented, a GAP analysis should be conducted to identify where new standards are required.

Data Validation Specification

Alert Notifications

User Roles and Privileges e.g. Principal Investigator, CRA, Data Manager, Sponsor, Coder

Audit trail

Reports/Metrics

The CRF build and above functionality must be validated and user acceptance testing is performed and documented].

Randomisation

[Not applicable as Open label] [delete as appropriate]

[In this study randomisation will be conducted by A Vendor using a Good Clinical Practice (GCP) compliant computer software validated application Integrated Randomisation Tool (IRT). IRT will be integrated with the Clinical Database using a one/two-way transfer and populate non-enterable fields within the Clinical Database.

The IRT specification document and User Acceptance Testing will be created and filed in the eTMF, detailing the fields that will be received.

This study is a double-blind randomised study and must follow A Company SOPs in maintaining the study blind until Database Lock has occurred and unblinding is request, via the Release Memo.

All data management activities will be performed in a blinded state and data must be considered by the study team prior to go-live and documented within the Unblinding Plan. Data values maybe masked until the end of the study such as Pharmacokinetic or Biomarker data in order to ensure unplanned unblinding does not occur.

Unblinded counterparts maybe allocated in the provision of data to the Pharmacovigilance team and Dose Escalation meetings. Should unblinding occur then staff must sign the Dose Un-blinding sheet as per the A Company SOP]. [delete as appropriate]

[If the study is a randomised control trial (RCT) then the allocation of the interventional therapy may be performed using many different procedures. Some maybe manually randomised, others may have third-party providers that integrate their application with the Clinical Database and provide an independent service to reduce bias in intervention allocation.

Whichever method is used, be aware of the process and ensure that details which include the randomisation code, randomisation date are collected from either the Clinical Database or via an TPV data transfer]

Further reading An overview of randomization techniques: An unbiased assessment of outcome in clinical research (nih.gov)

System Integrations

System integrations being used for this study are listed below:

[Safety database (PV)

Interactive Response Technology (IRT)

Clinical Trial Management System (CTMS)

Coding Tool]

All system integration will require User Acceptance Testing (UAT) and following [A Company Integration SOP/WIN]. Integration specifications must be created, reviewed and approved by the study team representatives. Subsequent changes to the underlying Clinical Database will require a change review performed. All documentation must be signed/dated and filed in the eTMF with a logical naming convention and version number.

Medical Coding

Medical Coding dictionaries will be [integrated within Clinical Database]/ [Manually assigned and incorporated in the Clinical Dataset]. As the study has [a short duration then up-versioning is not required / a long duration, up-versioning will be performed.]

MedDRA – Twice yearly or prior to lock

WHODrug – Annually or prior to lock

…..

[Expected Verbatim terms will be linked between Clinical Database and the Coding module Coder during the study set-up. Verbatim terms that do not code automatically, will be manually assigned as per SOP XXX (amend or delete as appropriate)]

[Manual Coding will be performed for this study, as per SOP XXX (amend or delete as appropriate)]

[Medical Dictionaries require a valid license].

Data Validation Specification (or Equivalent)

[The Data Validation Specification document contains a list of all the cleaning activities that will be performed, it may also be referred to as the Data Handling Plan, Edit Check Specification. Rename according to company SOPs. The aim of the DVS is to ensure that critical data such as primary, secondary objectives and safety data as a minimum step reflect accurate and cleaned data in preparation for statistical analysis.

Traceability, between the check scenario/test, Check type, Check Name and version is recommended].

A [Data Validation Specification (DVS)] will be created according to [A Company SOP/WIN] and include all data cleaning checks that will be conducted for the Clinical Study. This [DVS] must be reviewed and agreed by the study team and all final versions filed in the eTMF.

The [DVS] must indicate the data source, data point(s), scenario/test description, Check Type and name, to ensure the data check is created. The different Check Types used in this study are:-

System Checks: A mandatory data field configured using the validated Clinical Database functionality e.g., Visit date must be entered.

Programmed Checks: A validated program configured with syntax, using the Clinical Database given a unique name and version number e.g., Subject gender = Male, but Pregnancy test is completed.

Manual review: Validated listings or output that can be manually reviewed for non-programmable check and may include comment.

Reconciliation: Non-CRF data received in-house compared to the CRF data values, typically created using validated SAS program e.g., CRF data confirms that V1 labs are received – but V1 lab data not received.

[…..]

Study CRF Completion Guidelines

Study CRF Completion Guidance can be located [on the EDC data point or form, using the link [?] (amend or delete as applicable).

Study CRF completion Guidelines, including CRF Specific dynamics can be located [folder location] or [in document] (amend or delete as applicable).

Study CRF completion Guidelines are located [folder location] or [in document] (amend or delete as applicable).]

[In most cases completion guidance or help is built in to the EDC and this is not needed to be duplicated, however study specific and dynamic information around how to enter the data or fire the dynamic can be provided. This is typically a separate document and can be reference here with a ‘document name’ or ‘file location’]

Transfer Agreements – Non-CRF Data

Non-CRF data being collected for the study will be provided by the vendor/suppliers list in the table below:

[Non-CRF collected or provided by a third-party vendor (TPV) will have specific agreements and specifications on how, what and when data will be transferred. This should also include the secure location or portal where the data will be located/shared and have restricted access for blinded studies]

Note: Patient/subject data should not be shared over email

Name of Vendor/Supplier	Type of Data	Is data blinded/Unblinded?
[LAB]	[PK]	[Blinded]

Initial Clinical Database Release and Change Management

[Where integrated tools are used e.g. medical coding, IRT) all must have undergone system validation and an accepted User Acceptance Test (UAT), a ‘Go-live/ initial release checklist template is recommended and should be approved by all Stakeholder, such as the Study Data Manager, QC Data Manager, Data Management Programmer, Study Statistician/Programmer and Study Lead]

Initial and subsequent updates to the Clinical Database must follow [A company Clinical Database Set-up SOPs and an Initial/subsequent Release checklist completed and approved by all Stakeholders]

[The Clinical Database Set-up SOP must detail the quality checks in place to ensure that the clinical database accurately reflects the requirements of the Clinical Study Protocol, a UAT must be conducted to ensure System Integrations and configured functionality such as system and programmable checks work as expected].

After the initial release of the clinical database, any subsequent changes to the Clinical Study Protocol or updates required on the Clinical Database or integrated software, may require a migration as per the [A company Clinical Database Set-up SOP] and approved. [Protocol amendments may not always result in an update to the initial build. A Change log or similar must be created and approved by stakeholders to document the decisions made by the team].

Conduct

[After the Clinical Study Database has been approved, the study is considered to be in the ‘Conduct’ Phase.] The main areas of Conduct are [add and remove as applicable to your companies' requirements or DM process regarding conduct of studies]:-

[User access

Data Extraction

Data Cleaning

Continuous/Critical Data Review

Metrics Reports

Medical Coding

Serious Adverse Event Reconciliation

Non-CRF Datal Review

Risk Assessment]

User Access

[Prior to access to the Clinical Database all end users must have successfully completed role specific training, user access must be provided based upon a restricted functional and study and or site specific access level].

User access to the Clinical Database will follow [A Company User Access SOP], the [Clinical Study Team] will inform the Data Manager or DM delegate of study access requests.

[The individual username, one-time password and URL to access the production environment should be distributed via email, after completion of role-based training has been confirmed].

[User access is system specific].

[If the study is planned to be running in excess of 6 months, a review of user access is recommended on a regular basis <6> months. Standard reports can be created and compared against <Clinical Study Team> reviews. On receipt of a user that no longer requires access (this may be due to transition) then immediate removal of all user access is performed for all clinical database environments including Production and Test.]

Data Extraction

During the course of the study, data extraction of the clinical database can be performed adhoc or on a regular basis. Statisticians and Statistical Programmers may require regular data extractions, which can be executed as an [automated/Manual] process on a regular [add frequency] basis.

Production data will be extracted as format [SAS7BDAT on a [daily/weekly/monthly] or on an [adhoc basis] and filed in a secure validated repository [directory location].

An appendix of the expected data extraction files can be added for reference.

Optional:

Data extraction and non-CRF data requires re-mapping by the [Data Management Department] to the [Sponsor Clinical Data Standards/ Standard Data Tabulation Model (SDTM)] format, validated programs and Quality Checks will be performed following [Validation of programs SOP]. All programs, logs and output will be filed as evidence within the study location [Study remapping location. Pinnacle 21 CDISC Compliance tool will be executed on the output to ensure compliance].

Data Cleaning

In addition, to Source Data Verification (SDV) conducted by the [Clinical team]. Data Cleaning is performed to ensure data completeness and data integrity, there are multiple tools and processes that can be applied to perform this task and checks are based on the DVS:

System Checks – Configuration within the Clinical Database functionality, to enforce data field rules. These include but are not limited to:-

[Mandatory fields

Dynamics,

Restricted Code-lists,

Date checks (past or impossible dates not accepted e.g., 30FEB2021)

Maximum and Minimum Range checks

Data value formats (e.g., numeric, integer, code-list, date)

Add..]

[System Checks are typically routed to Site staff and can aid study eCRF training and apply consistency.]

Programmable Checks – All System and Programmable Checks are based on the approved [DVS] and are configured within the Clinical Database at/after [Go-Live/ Split Release].

[these are manually programmed (which maybe study specific or generic and available from the Global Library). Each programmed check must be validated and applied to the Clinical Database. Programmable checks are more complex and may reference multiple events and data forms. Programmable checks may initially be routed to the Data Manager for first pass review before being routed to Site staff for an action (confirmation or subsequent data update).]

Continuous and Critical Data Review

Continuous Data Review (CDR) will be conducted on an [Ongoing basis/After SDV] is performed at the end of every [Cohort/Part/At the end of the study].

[During the conduct of a study both Continuous and Critical Data Review will be conducted, the Data Manager will co-ordinate Continuous Data Review, this will include a review of the System and Programmable Checks.

Where Non-CRF data is received, extractions of the Clinical Database and the Non-CRF data can be executed with a reconciliation program using <SAS> and based on the <Data Validation Specification> to create an output for the Data Manager to review and where appropriate, a manual query can be created with in the Clinical Database and/or a Non-CRF Data Reconciliation Issues log or equivalent.

Identification of areas of high data queries, may result in site re-training, data checks updates or eCRF completion guideline updates. Routing of data queries and review of response must be conducted in a timely manner.]

[The frequency of CDR is based on the study requirements; this may occur on an ongoing basis or at the end of every cohort intake and after SDV. For very short studies, CDR may also only be conducted after all Subjects are complete – as agreed by the study team]

Based on the Protocol and the Study Team the following data has been identified for Critical Data Review. The Data Manager will be responsible for providing the Critical Data listings and the Study Manager will coordinate the review, based on the study timeline schedule with the study statistician and study physician.

[Demography

Laboratory Assessments

Electrocardiogram (ECG) (12 Lead/Continuous)

Telemetry

Physical Examination

Pharmacokinetic Assessments (PK) (e.g., Blood, Urine)

Vital Signs

Protocol Deviation

Medical History

Adverse Events (AE)

Liver diagnosis/Symptoms

Concomitant Medication (CM)/Nondrug Therapy

End of Study & Treatment

Details of Death

Add…]

All reviews may require data queries to be generated, which will be the responsibility of the DM to manually create them, either within the Clinical Database and routed to site for edit or clarification and where applicable via the Non-CRF vendor in a versioned issue log.

Data flow 1: Reconciliation of CRF data

Data flow 2: Reconciliation of Non- CRF data

Standard Reports

[Standard reports are required to understand the status of the study during the conduct of the study, to ensure timelines can be met or identify issues with Sites, Subjects or Pages. Validated metric reports provide the study team within an insight on to the progress of the study, these may include <but not limited to:-

Number of Subjects enrolled/ screened/Early Terminated or Completed.

Number of Pages missing, partially entered, expected, clean, requires coding, SDV’d, signed.

Number of Queries raised, resolved/closed, outstanding for <14 days>.

Number of Sites and Countries

Clean Subject Tracker

….or add a table with the following information]

The location or access to the study specific metric reports is documented in the table below:-

[Where possible study team members should be able to generate or locate reports directly. Where functionality exists user access privileges and training should be given to the following study team roles] [DM, Sponsor, CRA, Study Team user].

[Example: Data Cleaning Report – timed outstanding queries, data points created large volumes of queries – deep dive to find out what is going on with this form, edit check issues or site confusion, format issues].

Report	Frequency	Location	Responsible
[Missing Pages	[Weekly]	[Study location]	[All users]
[Outstanding Coding	[Adhoc]	[EDC Interactive]	[All users]
[Subject Completeness	[Adhoc]	[EDC Interactive]	[All users]
[…..

[The frequency of the reports is defined by the study team, it is suggested to highlight key metrics at the regular study team meetings, to ensure that appropriate actions are taken. The Metric Champion Consortium have some guidance on DM and Stats metrics (https://metricschampion.org/)]

Coding Review

All terms will be approved by [Sponsor/Role] as per the study schedule based on the approved listing specification (See Appendix B).

Queries will be generated as necessary, and the process will continue until all terms are coded and approved as per [Company SOP].

[More information can be found here:

https://www.meddra.org/

https://www.who-umc.org/whodrug/whodrug-portfolio/whodrug-global/

The medical coder will review the coding on a regular basis and raise queries directly in the Clinical Database for site clarification, where required. Prior to database [Interim/Full] lock appropriate sign off [Medical/Pharmacy qualified personnel] of all complete and applied terms will be documented and filed within the eTMF.

SAE Reconciliation

Reconciliation will be performed adhering to the [A Company SAE Reconciliation SOP] on a [monthly] frequency. All reviewed output must be signed/dated filed into the eTMF with a logical naming convention.

[Reconciliation between the clinical and safety databases needs to be performed either during the conduct of the study and/or prior to database lock. A clear outlined process of who is providing what to who]

The [PV Function] will provide a Serious Adverse Event (SAE) output on a [monthly] frequency of the following terms:-

[Study ID

Subject ID

Site

Day 0

AETerm

MedDRA Preferred term

Action

Start Date

End Date

Reason for Seriousness

Relationship to IMP

...]

The above list will be reconciled against the Clinical Database by Data Management and any discrepancies will be raised back the [PV Service Provider/Safety Team/Site].

or

Data Management Team will provide an output on a [monthly] frequency from the Clinical Database of all AE’s marked as serious to the [PV Service Provider/Safety Team]. This will then be reconciled against the Safety Database and any discrepancies will be raised back to Data Management and/or the Site.

Non-CRF Data Reconciliation

Reconciliation of Non-CRF data will be performed on a [monthly] frequency or on receipt of a successful [Data Transfer] throughout the study conduct.

[Transfer agreement/specifications created in set up should include the frequency of transfers, how reconciliation will be performed, query process, key contacts, and agreed process for receipt of unblinded data should be included. A clear process on the activities should also be followed., logs and trackers are used to share discrepancies and queries between the Clinical Database and output provided by vendor]

Name of Vendor/Supplier	Type of Data	Frequency	Key Contact
[Lab xx]	[PK ]	[Monthly]	[XXX@XX.com]

Risk Assessment & Action/Decision Logs

Risk Assessments must be regularly reviewed and documented in the Risk Assessment log located in [folder] and is updated [monthly] during the [study team meeting] or [risk assessment meeting].

Action and decision log is located in [folder] and is reviewed [monthly] during the data management meeting.

[Identifying risks, logging actions and decisions and reviewing critical to quality datapoints throughout the study is now a key part of the study life cycle. DM is not solely responsible but as an expert in data should be able to provide input to the risk assessment process.]

Closeout

Database Lock

Locking procedure begin once the following tasks are complete: (see Appendix C)

[Database lock is a significant milestone in the clinical trial and has a number of checks to go through before the task can be completed. DM are accountable for delivering clean data in a timely manner which is normally aided by a pre-lock checklist. Some database’s have a twostep lock, soft lock and the hard lock, these are defined as:-

Soft lock or data freeze is deemed data complete and clean, but still allowing data to be queried and edited if needed.

Hard lock or database lock is deemed data clean and ready for analysis. Data can no longer be edited and edit access is removed from users.

Database Unlock

[A Company Database Lock SOP] must be adhered to for all activities leading to [Database unlock].

Approval from all stakeholders including [Senior] Management/Sponsor will be required to unlock the database.

Once the database is unlocked the agreed data corrections are made, Quality Checked (QC) and the database is re-locked. Confirmation should be performed to ensure not additional changes to the database have been performed [using tools such as SAS Compare]. All post lock output should be signed/dated and filed with a logical name in the eTMF.

[Approval is required to unlock a database once locked and a clear rationale is often needed. Most companies have a DBL/unlock process, and this should be followed. It is a good idea to have an unlock section in your DBL form to document the unlock reasons, approval and date]

Additional Sections

Below are some additional sections that you may wish to incorporate into the DMP depending on company needs or documentation already in place.

Protocol Deviation

Protocol deviations (PD) are collected using [deviation log in EDC] and are reviewed as part of the data review.

[Protocol deviation (PD’s) are not just recorded by the monitor at site but can also be programmed in the database and identified via listings. These are typically ‘out of window timepoints’, ‘missing critical datapoints’, ‘missing visits’, etc. Categorisations of PD’s is typically discussed as a team and during the data review meeting (DRM).

Detection may come from multiple sources, a robust PD specification should list Major/Minor PD type and if a programmed check is used, then a unique name and version of the program/checks should be documented.

An PD dataset if not extracted directly from the Clinical database, in the correct format may require transformation step to ensure dataset standard formats are adhered to].

Withdrawal of Consent

During the conduct of the study and prior to Data Lock, ‘Informed Consent’ status should be regularly reviewed with the Study team for awareness. The Data Validation Specification should include programmable or manual checks to ensure that assessments collected are consistent with withdrawal of consent and the reason for withdrawal.

In accordance, with the Inform Consent form (ICF) biological samples may require disposal and may not be used for future storage. Reconciliation should be performed to ensure this action is performed and will be included within the DVS, for regular review by the study team.

[A Subject may withdraw consent during the conduct of a study, depending on where the study sites are geographically located, may affect the content of the Informed Consent Form (ICF). The U.S Food and Drug Administration state that the Subject’s data collected so far should be used, but no further assessments collected after withdrawal of consent. General Data Protection Regulation (GDPR) applies to the European Union and will also contain regulations specific to the study country ICF version.

Therefore, please consider that depending on where the study is run, the country/study specific Informed Consent Form data collection requirements will require consideration for Subjects that withdraw from the study early or after completion.]

Links: Informed Consent for Clinical Trials | FDA

Handling Early Termination and Lost to Follow-up

Subjects which have withdrawn from the study early must have a reason for withdrawal documented on the End of Study Page(s) or equivalent. In some case contact with the subject may be lost and final assessments may not be captured. All efforts should be made to obtain this information, ‘Lost to Follow-Up' may be the only reason that can be entered.

Handling of this data will be the same for all study data in that data is cleaned, coded and all activities performed. Missing pages should be marked as blank (or similar) to prevent Missing page reports expecting future visits as expected.

Data cleaning activities should be performed as soon as possible, although non-CRF data reconciliation activities may still raise queries at a later timepoint depending on transfer scheduling.

[During the course of a study, subjects which have passed the Screening assessment may withdraw from the study earlier than expected. The Clinical Study Protocol must clearly state the information that is required for subjects who do not complete the trial. This may include a dedicated Early Termination CRF form and final assessments to ensure statistical analysis can compare safety/efficacy results from baseline to the last visit.

In addition, a reason for non-completion is required and entered as part of the CRF data. This information maybe due to safety issues or the subjects lack of efficacy, which is important information.

Setting up studies and subsequent reports should be based on the expectation that some subjects will withdraw from the study and therefore the eCRF database should be set-up accordingly and be part of the User Acceptance Testing scenario.]

Links: Data Retention When Subjects Withdraw from FDA-Regulated Clinical Trials | FDA

Handling Screen Failures

The Clinical Study Protocol referenced in section [section] must clearly state whether Screen failure data should be collected and if a subject can be re-screened.

Refer to the Consort - Welcome to the CONSORT Website (consort-statement.org) & Publications & downloads (spirit-statement.org)

If a Subjects reason for not participating in the study is due Screen Failure, then the following data should be collected:-

[Date of Screening

Inclusion Exclusion Criteria

Demography

Informed Consent

Reason for Withdrawal = Screening Failure

Date of Withdrawal]

System Back-ups, Scheduled Downtime & Disaster Recovery

In the event of a disaster as Disaster Recovery Plan will be referenced should an incident occur that effects critical internal functions.

The Clinical Database will have regular backups as well as frequent replication of data to protect the integrity of the clinical study.

Where system maintenance is required, a notification will be issued to all users to inform of any scheduled downtime. This should aim to be provided 1 week and then again 24 hrs prior to scheduled downtime and arranged during a period of low activity (e.g. Weekends).

Archiving & Decommissioning

All study data documentation will be archived. Submission ready Subject Data Files must be uploaded to the eTMF, or designated repository and approved, after an acceptance Quality Check has been performed.

The Clinical Study Database can be decommissioned as per Company SOP, only after the submission ready Subject Data Files [eCRF including audit trail] are created and have undergone a Quality Control step, issued and receipted by the Clinical Study Site.

[After database lock has been performed, preparation for archiving and decommissioning of the Clinical database can begin and should have a separate timeline for this activity to be started and completed, with adequate resource assigned.]

Definitions/Abbreviations and Terms

Abbreviation	Definition/Term
ACDM	Association of Clinical Data Management
AE	Adverse Event
CDISC	Clinical Data Interchange Standards Consortium
CDR	Critical/Continuous Data Review
CTMS	Clinical Trial Management System
CRO	Contract Research Organisation
DM	Data Manager
DMP	Data Management Plan
DRM	Data Review Meeting
DVS	Data Validation Specification
eCRF/CRF	Electronic/Case Report Form
eTMF	Electronic Trial Master File
FDA	Food & Drug Administration
GDPR	General Data Protection Regulation
GCP	Good Clinical Practice
ICF	Informed Consent Form
IRT	Interactive Response Technology
MHRA	Medicines and Healthcare products Regulatory Agency
PK	Pharmacokinetics
PV	Pharmacovigilance
QC	Quality Checked
RCT	Randomised Control Trial
SDTM	Standard Data Tabulation Module
SDV	Source Data Verification
SOP	Standard Operating Procedures
TPV	Third Party Vendor

Appendices

Appendix A - Links

Description	Links - Location
Clinical Study Protocol	Add hyperlink or location within your organisation
Study Timelines	Add hyperlink or location within your organisation
Study Team List	Add hyperlink or location within your organisation
SOP list specific to Protocol	Add hyperlink or location within your organisation
Study Specific Blinding/Integrity Plan	Add hyperlink or location within your organisation
[ADD….]	Add hyperlink or location within your organisation

Appendix B – Dictionary Coding Specification

[Dictionary Coding Specification

Data Type	Verbatim	LLT	PT	SOC	Version	Change	Extra Fields	Protocol and Subject ID
AE	AETERM	X	X	X	X	X	Start/Stop	X
MH	MHTERM	X	X	X	X	X	Start/Stop	X
CM	INTERM	X	X	X	X	X	Start/Stop	X

Sort order: SOC, PT, LLT, Verbatim, Subject ID,

WHODrug Coding Specification

Data Type	Verbatim	Trade Name	PN	Version	Change	Extra Fields	Protocol and Subject ID
CM	CMTERM	X	X	X	X	Start/StopRoute Indication	X

Sort order: Preferred Name, Trade Name, Verbatim, Subject ID, Start date]

Appendix C – Database Lock Checklist

[All expected CRF data has been [received/entered

Non-CRF data has been received, reconciled and no outstanding discrepancies

SAE reconciliation is complete and no outstanding discrepancies

Validation/edit checks run and no new discrepancies

Data clean based on Data Validation Specification

Manual review complete and no outstanding discrepancies

Medical coding complete, reviewed and signed off

Study team dry run review of listing

Protocol Deviations reviewed

<Add> ]