Tool Summary Sheet: Blue Italics

Tool Summary Sheet
Tool: Clinical Data Management Plan Template External

Facing
Purpose: This Clinical Data Management Plan (CDMP) template
may be employed for studies using an Electronic Data
Capture ystem (EDC)! unless another template has been
agreed upon"
Audience/Use
r:
#ead Data Managers and Principal $n%estigators of studies
using Electronic Data Capture ystems
Details: The template should be customi&ed to the protocol! the
study's special needs ( circumstances! and the
re)uirements of the data capture system" ections may
be edited or deleted as needed"
*s an alternati%e to this detailed template! indi%iduals
may prefer to reference the +Data Management
Considerations (Condensed)' tool! ,hich is a%ailable in
-$DC.'s Tool/it for Clinical .esearchers
(http0((nidcr"nih"go%(research(tool/it)" This considerations
tool lists important issues to consider ,hen e%aluating a
group's ability to electronically capture and %alidate
clinical research data! and summari&es the ,ide array of
data management tas/s re)uired" The tool could also be
used to suggest headings and content for a simpli1ed
clinical data management plan"
Best Practice
Recommenda
tions:
$tems in blue italics and enclosed in braces { } are
instructional text that should be deleted prior to
appro%al"
$tems enclosed in single 23 are placeholders" .eplace
as clari1ed in the enclosed text"
.eferences to 4ponsor5 may refer to the funding
sponsor or to the study P$! depending on the context of
the sentence and on the decisions at the time of CDMP
de%elopment" 6pdate the template at the time of
implementation to refer to the appropriate party"
Please retain the CDMP Template identi1er in the lo,er
left hand section of the footer"
.emo%e this Tool ummary heet prior to use of this
template"
Tool Revision History:
Version
1
Clinical Data Management Plan <Protocol Abbrev. Title>
Version Date: Protocol: <#>

Numer Date Summary o! Revisions "ade:
#$% #&'an&%#& Approved version
2
Template Version 1.0 20120112

Clinical Data Management Plan
Protocol Title: <Protocol Title>
Protocol Number: <#>
Version Numer
and Date:
7ersion 2x"x3! 2DDMMM88883
(undin) Sponsor:
-ational $nstitute of Dental and
Craniofacial .esearch
Study Principal
*nvesti)ator:
2P$ -ame and credentials3
Data
+oordinatin)
+enter Data
"ana)ement
+ontact,s-:
Summary o! +han)es:
Version A.ected
Section,
s- Summary o! Revisions "ade: Numer Date
!

Clinical Data Management Plan
Protocol Title: <Protocol Title>
Protocol Number: <#>
"

APPROVAL SIGNATURES
{The primary signatory should be clarifed at the beginning of the study
and then documented beneath the relevant line below. It may be a
representative of OCTOM the !rogram O"cial or the study principal
investigator.
#nsure that the C$M! version number and date are correct before
providing the document to the primary signatory.}
####################################################### ####################
< $ignator%& 'ole& A((iliation> Date
###################################################### ####################
Pro)ect Data Manager& <A((iliation> Date
*

TA+,- ./ C.0T-0T$
APPROVAL SIGNATURES...................................................................................................... 4
TABLE O !ONTENTS........................................................................................................... "
ABBREVIATIONS AN# #EINITIONS....................................................................................$
#%NA&I! REEREN!ES....................................................................................................... '
( INTRO#U!TION.............................................................................................................. ()
* T+E ELE!TRONI! #ATA !APTURE ,E#!- S%STE& AN# T+E UN#ERL%ING
!LINI!AL #ATABASE.......................................................................................................... ((
. NET/OR0 #IRE!TORIES.............................................................................................. (*
4 #ATA VALI#ATION PRO!ESS....................................................................................... (.
".1 102VA'2AT- A,-'T$........................................................................................................1!
".2 M1,T2VA'2AT- A0D C'.$$M.D1,- A,-'T$....................................................................1!
" VERII!ATION O E#! SETUP AN# I&PLE&ENTATION............................................("
*.1 $3$T-M $P-C2/2CAT2.0$................................................................................................1*
*.2 1$-' ACC-PTA0C- T-$T204..........................................................................................1*
$ #ATA ENTR% AN# #ATA !LEANING.............................................................................('
5.1 P'-'-612$2T-$ /.' $2T- DATA -0T'3.........................................................................17
5.2 4'A0T204 ACC-$$ T. T8- P'.D1CT2.0 V-'$2.0 ./ T8- -DC.....................................17
5.! -0T-'204 DATA.............................................................................................................17
5." DATA $-C1'2T3..............................................................................................................17
5.* 61A,2T3 C.0T'., P'.C-D1'-$...................................................................................17
5.5 61-'3 4-0-'AT2.0......................................................................................................19
' LOA#ING ELE!TRONI! ILES......................................................................................(1
7.1 ,A+.'AT.'3 0.'MA, 'A04-$......................................................................................21
2 &E#I!AL !O#ING.......................................................................................................... **
9.1 ADV-'$- -V-0T:M-D2CA, 82$T.'3 C.D204..................................................................22
9.2 M-D2CAT2.0 C.D204......................................................................................................22
1 E#! E3PORTE# #ATABASE......................................................................................... *4
() REPORTS..................................................................................................................... *"
(( SAE RE!ON!ILIATION................................................................................................ *$
(* !+ANGES TO A PRO#U!TION E#!..........................................................................*'
(. #ATABASE !LOSURE................................................................................................. *2
1!.1 C,.$1'- C8-C;$......................................................................................................29
1!.2 61A,2T3 A$$1'A0C- A1D2T A0D DATA+A$- ,.C;........................................................29
1!.! DATA+A$- 10,.C;.....................................................................................................29
(4 #ATA AR!+IVING AN# PROVISION O INAL &ATERIALS TO SPONSOR............*1
5

ABBR/V*AT*0NS AND D/(*N*T*0NS
*E *d%erse e%ent
CDMP Clinical Data Management Plan
C.F Case report form (may be paper or electronic
representation of the data collection tool)
Cross9chec/ *n edit chec/ that compares %ariables from
di:erent C.F pages or sub;ects %ariables from
di:erent C.F pages to an algorithmic
e%aluation (term of con%enience used to
di:erentiate from multi%ariate edit chec/s)
CTM Clinical trial material
DCC Data coordinating center
EDC Electronic data capture
MedD.* Medical Dictionary of .egulatory *:airs"
Dictionary for coding ad%erse e%ents! medical
history! and physical exam 1ndings
Multi%ariate Edit Chec/ *n edit chec/ (abo%e and beyond a range
chec/! %alid %alue chec/! or re)uired criterion)
on a %ariable or set of %ariables on the same
C.F page (term of con%enience used to
di:erentiate from cross9chec/s)
Pro;ect Manager $ndi%idual ,ho manages the pro;ect at the data
coordinating center" This person's ;ob title
might pro;ect manager! study coordinator! or
study team lead"
*E erious ad%erse e%ent
<P tandard <perating Procedure
=><D.6? =orld >ealth <rgani&ation coding system for
medications
{%d&ust this list according to the abbreviations actually used in the fnal
document.}
7

D1NA"*+ R/(/R/N+/S
{$ynamic references are documents that are relevant to clinical data
management activities but are not considered part of the C$M!' they are
stored separately. The reasons that these documents are separate from
the C$M! are threefold. (irst the dynamic references may re)uire
individuals other than the C$M! primary signatory to approve them when
approval is re)uired. *econd they may be updated on a fre)uent basis
which would create an unnecessary administrative burden for the C$M!
signatories. Third they may have a document owner that is someone
other than the pro&ect data manager. This section should discuss the
above issues as they pertain to this study and the e+ternal documents
listed in Table ,. Table , should list the full set of dynamic references to be
created for this study including a description of their content and the local
storage location of the item.
*ome items may be handled di-erently than listed .e.g. some may be
combined/. Customi0e the list to the needs of the study.
1ot all dynamic references will be prepared at the time of the initial C$M!
signing. If the dynamic reference is e+pected include it in the list below
and create a placeholder fle in the local storage location indicating that it
is not yet available and the appro+imate time it is e+pected to be prepared
along with the study title of the document owner .e.g. pro&ect manager/.}
Tale #$ Dynamic Re!erences
*tem +ontent
Docume
nt
02ner
+urrent
Version
Stora)e
3ocation at
D++
tudy Contact #ist -ames! roles! and
contact information for
/ey sponsor and DCC
study team members
Pro;ect
lead
{#.g. the study
website the
communication
plan .including
networ2
location/}
*nnotated Case
.eport Form
The full set of C.Fs!
including dataset and
%ariable names! sorted
in protocol schedule
order
Pro;ect
data
manager
Data Dictionary #ist of dataset names"
#ist of %ariable names!
Pro;ect
data
9

*tem +ontent
Docume
nt
02ner
+urrent
Version
Stora)e
3ocation at
D++
,ith corresponding %alid
%alues! data types!
labels"
manager
Data 7alidation
Plan
6ni%ariate ranges!
description of each
electronic edit chec/
and custom function
edit chec/! and any
additional manual
chec/s that ,ill be
performed
Pro;ect
data
manager
Clinical Data
.e%ie, Plan
Description of process
for pro%iding data to
one or more clinicians
,ho ,ill complete a
clinical re%ie,"
{Only include if a
clinical review will be
conducted. If a clinical
review will be
conducted this plan
would also specify the
felds that will be
reviewed and the timing
of the review. This
document may be
created well after the
initiation of the study in
the #$C.}
Pro;ect
data
manager
EDC peci1cations
.e%ie, Chec/list
Describes and trac/s
the process for re%ie,
and appro%al of the
study9speci1c EDC
re)uirements (e"g"!
blan/ and annotated
C.F! edit chec/ plan)
prior to the initiation of
6ser *cceptance
Pro;ect
data
manager
<

*tem +ontent
Docume
nt
02ner
+urrent
Version
Stora)e
3ocation at
D++
Testing"
tudy tartup
Chec/list
#ist of items to be
completed during study
startup"
Pro;ect
data
manager
tudy Timeline Pro;ected timeline of
study e%ents and
deli%erables
Pro;ect
manager
ponsor
Con%erted
Database
peci1cations
Describes the
re)uirements of the
clinical database that is
deli%ered bac/ to the
sponsor after database
loc/"
{This conversion may
not be re)uired. $elete
item if not applicable.
%lternatively this may
be the specifcations for
the creation of de3
identifed public use
data}
Pro;ect
*
program
mer
De%elopment and
Testing
.esponsibility
Matrix
$denti1es tas/s and
deli%erables for this
pro;ect and indicates
,ho is responsible for
,riting! executing!
re%ie,ing! and
appro%ing each item"
Pro;ect
data
manager
Clinical Monitoring
Plan
Description of clinical
monitoring acti%ities
{This often includes
plans for site initiation
visits and site user
training on the #$C
which is why you may
want to reference it in
#ead
clinical
research
associate
10

*tem +ontent
Docume
nt
02ner
+urrent
Version
Stora)e
3ocation at
D++
the C$M!.}
11

# *ntroduction
{4rie5y describe the study including the clinical phase and high3level
protocol design components that are not included in the protocol title .e.g.
6a phase 738 randomi0ed double3blind placebo controlled study of
sub&ects with hypoparathyroidism. #ach sub&ect will be treated for up to 8
years.9 Consider the nature of the study .e.g. minimal ris2 study clinical
trial re)uiring an I1$/ and indicate. 6%ctivities for this study must comply
with all relevant regulations.9
!rovide general introductory te+t as to the purpose of the clinical data
management plan .C$M!/ including its central role in ma2ing e+plicit to all
sta2eholders specifc information regarding the data management
practices needed to ensure appropriate handling of data at all steps of the
pro&ect to assure a high3)uality database at the end of the study ready for
analysis. $escribe how the document will be reviewed approved and
fnali0ed .i.e. signed by whom/ how it will be modifed .minor or
substantial/ if needed during the pro&ect and any *O!s in place governing
its use and modifcation.}
12

& The /lectronic Data +apture ,/D+- System and the
Underlyin) +linical Dataase
{$escribe the #$C system proposed for use in this study including its
version number or other identifying information and validation status with
respect to 7, C(: !art ,, regulations. More generally describe the
system;s primary information security disaster mitigation audit trail and
electronic signature features. Identify ancillary software pac2ages
associated with the #$C such as underlying database stac2s and
statistical analysis software. $escribe the physical relationship of the
server.s/ used to house the database and statistical or other support
software pac2ages vis3<3vis the computers used by the pro&ect team.}
1!

4 Net2or5 Directories
{$escribe the security disaster mitigation and structure of the networ2
directories .physical and directory=subdirectory/ used by the pro&ect team
to store study3related information.}
1"

6 Data Validation Process
{*ubsections here should describe the computeri0ed portion of the edit
chec2 validation employed by the #$C system. 1ote> often full data
validation specifcations are documented in a standalone $ata ?alidation
!lan cited in the dynamic references table above.}
d$ Univariate Alerts
{$escribe the 2inds of univariate alerts a-orded by the #$C system.
#+amples might include valid3value valid3range and missing3value alerts
and may be separately specifed for each electronically captured feld. (or
each subsection @.,.+ provide additional details on the nature of the
automated chec2s. %n e+ample is provided for *ection @.,., for valid3
value chec2s' other subsections @.,.+ should be added as appropriate for
each category of univariate alerts.}
d$ Valid Value Alerts !or
"ultiple7choice (ields
,Select only #-
{%ssuming the #$C provides for valid3value edit chec2s provide te+t to
e+plain the available 2inds of chec2s. *ome e+amples include>
,. The user is re)uired to choose at least one chec2bo+ from a series that
represents di-erent data choices
7. The user is re)uired to choose only 6yes9 or only 6no9
8. The user must record a coded value ta2en from a list that is usually presented
on the page or in an instruction guide. Incorrect codes must be detected and
re&ected by the edit chec2 scripts.}
d$ "ultivariate and +ross7module Alerts
{In addition to univariate alerts that may be described in *ection d
describe here any relational alerts among groups of variables and among
the same variable for protocol3specifc assessment times. *uch alerts are
referred to as multivariate alerts .within one module same assessment
time/ and cross3module alerts .across two or more modules or assessment
times/. (or e+ample a cross3module alert could be specifed to generate a
)uery for sub&ects whose C:(s indicated that they were male .$emography
module/ and pregnant .!regnancy module/.
Common types of multivariate alerts include the following>
1*

,. Confrming that only valid options are selected in a 6choose all that apply9
multiple choice feld where the range of options deemed valid depends on
some other parameter.
7. Confrming that diastolic blood pressure reading is less than the associated
systolic blood pressure reading.
8. Confrming that 6Other specify9 is completed when 6Other9 is mar2ed.
Common types of cross3module alerts include the following>
,. Comparing the dates and times of all assessment time points to confrm that
they occur in an appropriate se)uence. (or e+ample a *tudy $ay ,
assessment should occur before a *tudy $ay A assessment.
7. Confrming that all visit dates occur before the date of the investigator;s
signature.
8. If applicable confrming that all screening and baseline assessments occur
before the frst dose of clinical trial material .CTM/ is administered.
@. Confrming that the recorded onsets of all treatment emergent adverse events
are after the frst dose of CTM is administered.}
15

8 Veri9cation o! /D+ Setup and *mplementation
{$escribe here the procedures and documents used to create and validate
a protocol3specifc implementation of the #$C.}
e$ System Speci9cations
{$etail the functional and other system specifcations for the #$C system.
The pro&ect lead pro&ect manager=study coordinator clinical research
associate biostatistician clinical site team and sponsor can be consulted
for guidance on the development of these specifcations.
*ystem specifcations for the #$C system typically include> data entry
screens annotated C:(s and the data validation plan. % process should
be developed to guide and document review and approval of #$C system
functioning with respect to these items. This process should be completed
before underta2ing user acceptance testing.
1ote> it is acceptable for the developed data entry screens to act as the
6specifcations9 for the data entry screens and for the annotated C:(
generated for the pro&ect to act as the specifcations for the database.}
e$ User Acceptance Testin)
{#ach study3specifc implementation of the #$C system should be tested
by candidate users with the results being documented in a Test *ummary
:eport. Bser %cceptance Testing commonly includes confrmation of the
proper functioning of the items listed in the table below.
%dd or remove items as relevant and update details of testing based on
study3specifc needs.
It may be helpful to include in the testing an e+ercise involving entry of
data for .a/ a complete moc2 sub&ect from start to fnish and .b/ a moc2
sub&ect who discontinues early. This can be one way of testing several of
the items below.}
*tem Details o! Testin)
@" 6ni%ariate and %alid %alue
chec/s
Con1rm that chec/s ha%e been
properly imported from speci1cations
document" Manually test a subset of
chec/s (e"g"! A per page)"
A" Multi%ariate and cross9
chec/s
Con1rm each 2or a speci1ed subset
of3 chec/s %ia test data designed to
trigger a )uery"
B" Custom functions
Con1rm each custom function ,ith
test data designed to trigger an e%ent"
17

*tem Details o! Testin)
econd programmer code re%ie,! if
possible"
C" ?eneration of sub;ect
numbers
Con1rm that ne, sub;ect $Ds are
generated according to speci1cations
D(e"g"! site numberEnumber of sub;ect
enrolled at that siteEchec/ digitFsub;ect
@GHAI is from site @G! the second sub;ect
enrolled (HA)! and I reJects the chec/
digit generated by an algorithm used to
con1rm that the number is %alid)K
L" Customi&ed form or %ariable
deli%ery (e"g"! dynamic
1elds)
Con1rm against schedule of e%ents
and against other speci1cations"
G" Data completion guidelines
Con1rm that the completion guidelines
are properly associated ,ith each
form(1eld"
M" Deri%ed %ariable
computation
Con1rm against speci1cations using
test data"
I" Email alerts
Con1rm ,ith test data designed to
trigger email alerts"
N" .ole assignment
.e%ie, system" Con1rm using list of
role functionality! ha%e testers
assigned to each role! and ensure that
they are only able to do(see ,hat they
are entitled to per their assigned role"
@H" Data Extracts
.e%ie, extracted data! ensure that it
matches speci1cations (e"g"!
annotated C.F)"
@@" Data $mports into EDC
Create test data! import! and re%ie,
imported data"
@A" ystem .eports
.e%ie, system reports and ensure that
they are functioning according to
expectations" .un reports on test
data"
@B" E9#earning peci1cations
Ensure that any e9learning items are
deli%ered based on stated
re)uirements and roles"
19

: Data /ntry and Data +leanin)
!$ Pre7re;uisites !or Site Data /ntry
DEach site user must be trained on the EDC system prior to being granted
permission to ,or/ in the production %ersion of the EDC system" Describe site
speci1c training re)uirements such as 4the clinical research coordinator must
ha%e completed the data entry and )uery resolution modules of the EDC and(or
must enter test data for the demographics! *E! and study termination pages"
These data must be re%ie,ed and appro%ed by the lead data manager"5K
!$ <rantin) Access to the Production Version o! the /D+
DDescribe the process for granting access to the production %ersion of the EDC
system for site and other sponsor sta:" For example! 4<nce the test data ha%e
been re%ie,ed and appro%ed! the lead data manager ,ill send a ,ritten re)uest
to the helpdes/ or study speci1c user administrator to grant production system
access"K
!$ /nterin) Data
{Clarify what data will be entered by trained site personnel as opposed to
by e+ternal individuals such as $CC personnel. *pecify which felds will be
double3entered in the #$C system.
(or the most part data entered into the #$C system are based on source
documentation maintained at the clinical site. (or cases where the #$C
system will be used as the initial data record .e.g. direct data entry of a
dental e+am/ and there is no other source documentation CC! re)uires
that these items be identifed in the protocol. (or completeness identify
those items in this section as well.}
vi$ Data /ntry +ompletion <uidelines
{$escribe any documents or in3system resources that will be developed to
help users during the data3entry process. $escribe where these resources
may be found .i.e. networ2 drive location B:D or functional area within
the #$C etc./}
!$ Data Security
{$etail here the procedures and methods to be used to ensure data
security. #+amples include employing individual user accounts with role3
based data management and access privileges website security
technologies database access security server physical plant security
features and bac2up or restore processes that constitute the #$C
system;s disaster3mitigation plan.}
!$ =uality +ontrol Procedures
{$escribe the )uality control .EC/ processes to be employed. *uch
procedures may include built3in procedures of the #$C system such as
1<

automated chec2s to ensure manually entered sub&ect numbers conform to
study3defned site=sub&ect F format rules and real3time data value edit
chec2s as referenced above. More3manual chec2s may include strategies
such as developing *%* code to ensure the right number of entries is
present for a given data domain.
!$ =uery <eneration
vi$ /D+7)enerated =ueries
{*ummari0e how )ueries are generated from within the #$C system such
as those that should result from automated edit chec2s. $escribe how the
user is alerted and then allowed if applicable to ma2e a correction or
alternately to override the alert .along with rationale for overriding the
alert/. *ome data felds may re)uire correction .i.e. should not allow users
to override a correction alert/' specify these here. %lso describe who=what
role is tas2ed with reviewing overrides.}
vi$ "anual =ueries
{Eueries issued by $CC study sta- .e.g. data managers $CC study
coordinators clinical research associates/ are referred to as manual
)ueries. In this section e+plain how manual )ueries are generated and
trac2ed to resolution including whether such )ueries are trac2ed in the
#$C system. Manual )ueries are used in cases where the data issue is a/
su"ciently comple+ as to be impractical to program as an automatic
system chec2 and=or b/ re)uires human &udgment. #+amples of these
cases include misspellings that hinder medical coding and chec2s that
re)uire interpretation of meaning in order to ascertain whether an entry
should be )ueried. (or e+ample a programmed logic chec2 between free3
te+t felds would not be practical because of the human interpretation
needed to understand the relationship between 6high3blood pressure9 on
one form and 6hypertension9 on a corresponding form.}
20

> 3oadin) /lectronic (iles
{$escribe here how electronic data fles generated outside the #$C
system will be integrated with the #$C database. #+amples of such fles
include clinical laboratory data or pharmaco2inetic data generated at
o-site facilities. $etail how often such transfers will ta2e place whether
the transfers will be cumulative or incremental in what electronic format
the transfers will be provided and how transfers will be logged or
documented. %lso detail what security procedures will be implemented to
protect against malware in the data fles. Indicate whether the data are
integrated directly into the database stored on a networ2 share for later
processing or some combination of the two. If data fles are to be
integrated into an e+isting database describe procedures in place for
verifying proper database structure and for resolving problems when the
data are not in the proper data structure or fle format.
It may be helpful to summari0e this information in tabular format as shown
in the sample Table 7 below.}
21

Tale &$ /lectronic Data to e *nte)rated in the /D+
Data Type +R(
Pa)e
Data
Source/
(ormat
(re;uenc
y o!
Trans!er/
3ocation
+umulati
ve or
Ne2
0nly
Special *nstructions
>ematolog
y
>EM* -$> lab(
"xls
-ightly(
ecure FTP
Cumulati%
e
tore in mas/ed directory
0Opro;ectOdataOfromnih" *utomated
con%ersion program runs nightly to
map medical record number to
sub;ect $D and to import into EDC"
$f errors occur! an email ,ill be sent
to the lead data manager and EDC
setup expert"
22

>$#3aoratory Normal Ran)es
{Clarify the process for receiving and using laboratory3issued normal range
data. (or instance 6Daboratory normal data will be collected from each
site or central laboratory if necessary for the study. Those data will be
included in multivariate edit chec2s to identify clinically signifcant values.9
Or 6Daboratory normal data will be collected from each site as part of each
sub&ect;s C:(. Gence there will not be a separate laboratory normals
database for this study.}
2!

? "edical +odin)
{*ummari0e the tools methods and conventions established for this study
regarding medical coding. Medical coding is the process of deducing from
literal or free3form te+t a set of terms that conform to a pre3defned
dictionary. Coding is commonly used to derive standardi0ed terminology
for adverse event descriptions and medications apart from the
investigational product that are used in a study. *tandardi0ed terminology
is essential for analy0ing study data programmatically.
*pecify the coding dictionary version and the level down to which coding
will be performed. % tabular summary by data type .i.e. adverse event or
medication/ may be helpful.
$escribe how often medical coding for new and updated
events=medications will occur during the course of the study. It may be
helpful to schedule interim reviews of medical coding prior to $*M4
meetings or formal interim analyses. The review schedule must be
detailed in the C$M! or elsewhere. % fnal review of coding must be
performed before database loc2.}
h$ Adverse /vent/"edical History +odin)
{#ach reported adverse event=medical condition will be assigned both a
symptom coding symbol .term/ and a Med$:%TM body system value. If an
automated software pac2age is used to facilitate coding describe the
pac2age and how it will be used in con&unction with any manual coding
procedures.
This is particularly relevant for coding adverse events that fail to provide a
direct match between verbatim and preferred .coded/ terms. (or e+ample
a coding program may be employed to map each verbatim term in a
specifed C:( feld to a standard term or its synonym listed in an e+isting
dictionary defnitions or described in a set of pre3determined study3
specifc rules. % coding rule is a specifcation that maps a verbatim term
to a standard dictionary term. Hhen dictionary entries and study3specifc
coding rules fail to provide matches a medical coding specialist under the
direction of the lead data manager may review candidate dictionary
entries as well as other related information such as comment felds to
identify an appropriate match. *pecify whether )ueries to the site will be
issued to facilitate this process.
This section also should detail how compound verbatim events such as
6cough induced sei0ures9 are to be handled. Many but not all such
events must be split into more than one record for purposes of medical
coding. Indicate whether the data manager will )uery compound events
2"

.re)uesting data updates from the site/ or whether the events will be split
into separate entries by the medical coder during coding.}
h$ "edication +odin)
{$escribe here the processes planned for coding medications and the
dictionary that will be used .e.g. HGO$:BC 7I,, E@/. %s with %# coding
describe any software that will be used to facilitate coding how human
review or fnal ad&udication will be managed when automated coding fails
and under what circumstances )ueries may be issued to the site for
clarifcation or additional details. Hhen multiple drugs are listed in a single
feld each should be coded into separate entries to facilitate separate
trac2ing of each medication.}
2*

@ /D+ /Aported Dataase
{$etail the scope fre)uency and format of data e+ports from the #$C
system. #+plain how predefned vs. custom e+ports will be created and
handled.}
1ote> it is sometimes necessary to transfer clinical data in a pre3specifed
dataset format that may not be supported by the #$C system for e+ample
when transferring to an e+ternal entity such as a sponsor. If this is the
case it will be necessary to write code to convert the data. The resulting
datasets are distinct from analysis datasets whose creation is supervised
by a pro&ect statistician.
If conversion and=or transfer are not re)uired please indicate 61ot
applicable for this study.9 Otherwise describe the processes for
converting data according to the re)uired specifcations and for validating
the data conversion. %lso describe any pre3established data transfers.
If the data are being converted to a !ublic Bse dataset per federal
re)uirements identify that dynamic reference document in this section.}
25

#%Reports
{Dist reports anticipated to be generated for this study in Table 8'
e+amples are shown below. %dditional reports that are agreed upon during
the course of the study do not re)uire an immediate amendment to the
C$M!. *imply ensure that the fnal version of the C$M! .usually signed
immediately prior to database loc2/ re5ects all delivered reports.}
Tale 4$ 3ist o! Data "ana)ement Reports
Report
Name
Description/Purpo
se
(re;uenc
y
Recipient
s/
Users
"ethod !or
Provision
Medical
Coding
.eport
ummaries of
%erbatim and
corresponding coded
*Es and ConMeds"
For appro%al of
medical coding!
including split
e%ents! preferred
terms! and ystem
<rgan Class"
@ month
prior to DP
free&e for
DMP
reports
and prior
to
database
loc/"
Medical
<Qcer or
designee
Emailed &ip
1le
Ruery
o%erride
report for
EDC
#ists all )ueries
,here the data entry
user o%errode the
)uery ,ith no
change! includes the
explanation for the
change(DM re%ie,
for acceptability of
o%errides"
Monthly Data
Managers
and other
DM sta:
*utomated
* report
stored on
local
net,or/"
27

##SA/ Reconciliation
{This section should detail the processes and specifc details to be used in
reconciling the safety and clinical databases. The safety database may be
a separate database used to hold emerging *%# data as they arise during
conduct of the study and is sub&ect to di-erent data management
timelines and EC processes than the #$C database.
%t intervals during a study and=or at the end of the study the two
databases must be reconciled to ensure all information has been
appropriately captured and reported to cogni0ant I:4s and regulatory
authorities as applicable. *pecify here the milestone events .e.g. $*M4
meetings/ and=or basic fre)uency during study conduct at which
reconciliation will be underta2en. Identify which study team roles will be
involved in the reconciliation process.
The specifc data felds to be compared between the two databases must
be listed' these commonly include verbatim and preferred terms onset
and stop dates severity causality action ta2en etc. !rocedures for
handling discrepancies between the databases including identifying which
database needs modifcation and trac2ing=documentation of discrepancies
should also be clearly detailed.
1ote> If *%# reconciliation is not re)uired please indicate 61ot applicable
for this study9 and remove the te+t in this section. If !roduct *afety is
being handled by a 8rd3party update this section accordingly to re5ect the
*%# reconciliation process being used.}
29

#&+han)es to a Production /D+
{%s with a study protocol changes are sometimes needed to the data
management plan. Hhen such changes result in modifcations to the #$C
system special considerations apply and should be detailed in the C$M!.
In this light describe here the process of proposing reviewing and
documenting changes to a production #$C system. The impact on the
system and the user should be evaluated by the lead data manager and
the team should establish a process for communicating the changes and
the impact of the changes to site personnel. (urther the methods for
evaluating the changes and determining the level of testing re)uired
before the changes are applied to the production server should be
described. Testing needs to include not &ust performance assurance but
also user acceptance testing conducted in the development environment
with all testing being documented. Indicate where and how testing
documentation will be stored. (inally indicate the study personnel=role
authori0ed to approve the proposed changes to the production #$C
system.}
2<

#4Dataase +losure
{This section should describe all processes associated with fnal database
closure. *ubsections proposed here include fnal pre3closure data chec2s'
E% review and actual database loc2' and procedures for unloc2ing a
database in the event that data must be corrected after loc2.}
m$+losure +hec5s
{$escribe the set of closure procedures that will be performed prior to
database loc2 to verify the integrity and completion of the database. In
some cases these may be the same data chec2s described in above
sections repeated until all )ueries are resolved and the data are
determined to be clean. Other appropriate chec2s at this stage may
include>
Chec2 that all e+pected C:(s have been entered'
Chec2 that the pro&ect database is consistent with the
specifcations in the pro&ect data dictionary'
$etermine the status of each sub&ect entered .i.e. e+cluded
ongoing completed withdrawn lost to follow3up etc./'
Chec2 for value formatting problems in database e+ports'
Chec2 for consistency between whole3date felds and associated
part3date felds'
Confrm that all e+pected site signatures have been applied.}
#4$& =uality Assurance Audit and Dataase 3oc5
{$escribe E% processes to be employed during study conduct to assure
data )uality such as clinical site monitoring. *pecify E% procedures after
study conduct to be performed to ensure all possible errors are detected
and corrected before fnal database loc2. (or e+ample an audit may be
performed of a sample of completed C:(s in the #$C system against
e+ported *%* datasets to ensure the integrity of the fnal study data.
#+plain how approval for fnal database loc2 will be sought and
documented and how the loc2 will be achieved at the database level. If a
separate soft loc2 will ta2e place prior to fnal loc2 describe how the two
events will ta2e place and what may distinguish soft from hard loc2 in
terms of user access and write privileges.}
m$Dataase Unloc5
{$atabase unloc2 should only occur in e+traordinary circumstances. %s
such special controls are needed to limit the scope of unloc2. #+plain here
the conditions necessary to &ustify database unloc2 the procedures for
!0

documenting &ustifcation and approval by relevant personnel .e.g. the
!rincipal Investigator Medical Monitor !rogram O"cer etc./ personnel
authori0ed to unloc2 the database and procedures for ma2ing and
documenting the approved changes.}
!1

#6Data Archivin) and Provision o! (inal "aterials to
Sponsor
{Identify what paper or electronic datasets programs and documents will
be maintained in archive status after study completion.
Include the scope format and process for delivery of fnal electronic data
to other entities if the data are not to be retained solely within the study
#$C. If sub&ect3specifc pdf renderings of the C:(s are to be provided
include that information herein.
If !ublic Bse datasets will be delivered after study completion indicate that
information in this section. The detailed plan for the development of the
!ublic Bse datasets need not be included in this document but the
deliverable re)uirement should be documented here.}
!2

Tool Summary Sheet: Blue Italics

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tool Summary Sheet: Blue Italics

Încărcat de

Drepturi de autor:

Formate disponibile

Tool Summary Sheet

Tool: Clinical Data Management Plan Template External

S-ar putea să vă placă și