CDM

Pristyn Research Solutions, Pune.
1 Clinical Data Management
Clinical Data Management
Contents: 1. Definition & Introduction:
 Introduction to CDM
 Good Data Management Practices
 Data Collection tools
 Data Entry Methods
 Query generation and management
 Data review and management
 MedDra
 Electronic Data Capture
 Future of Data Management
 Software packages for CDM process
Application of informatics like definition,
methods and collection of data for the
purpose of clinical studies is called as CDM,
or a technology and process that manage
clinical data to produce high quality, clean
and analyzable data base.
It captures the data into data base, corrects
and validates data. The clinical data
gathered at investigator site in the case
report form (CRF) and finally stored in the
clinical trial data management system
(CDMS).

2. Concept Origin:
The term (CDM) was first proposed by Jon Claerbout at Stanford University he gave the idea
that the ultimate product of research is the paper, and to produce the results in the paper such as
the code, data, etc.
End result for the CDM is a study database which is more accurate, secure, reliable and ready for
analysis. Clinical data management (CDM) consists of various activities involving the handling
of data or information that is outlined in the protocol to be collected /analyzed. CDM is a
multidisciplinary activity.
3. Purpose and Need:
1. CDM provides clean data in a good format.
2. It also provides a database fit for managing clinical data.
3. It ensures the quality of data being transferred from trial subjects to a database system.
4. It delivers quality database for statistical analysis.
5. It also provides more accurate and valid data.
6. It supports accuracy of final conclusion and report.
7. It is a web based technology with large volume of data storage.
4. What CDM describes:
CDM describes an overview of clinical data management and introduce the clinical research
database. It also:
•Discuss what constitutes data management activities in clinical research.
•Describe regulations and guidelines related to data management practices.
•Describe what a case report form (CRF) is and how it is developed.

•Discuss the traditional data capture process.
•Describe how protocols are developed.
5. Organization/Management / key players of CDM:
CDM is a multi-disciplinary activity that includes:
 Investigators
 Clinical data managers
 Research nurses
 Support personnel
 Biostatisticians
 Database programmers
 Project Leader
 MD or Clinical Scientist
 SAS Programmer
 Clinical Pharmacokinetics
 Clinical Research Associate/Monitor
 Clinical Pharmacovigilence
 Regulatory Affairs personnel
 Regulatory Operations personnel
 Clinical Quality Assurance personnel
 Medical Writing personnel
 Information Management/Information Technology personnel
 The Investigator:
Investigator is a person responsible for the conduct of clinical trial at a trial site. If a trial is
conducted by a team of individuals at a trial site, the investigator is the responsible leader of the
team and may be called the principal investigator. [ICH].

Investigator is the heart of the clinical trial who must maintain adequate and accurate case
histories that record all observations and other data pertinent to the investigation on each
individual administered the investigational drug or employed as a control in the investigation.
 The Clinical data manager:
An Effective Clinical Data Manager should:
Understand protocol, documentation, SOPs, regulations, roles and responsibilities and other
duties he should carry out are:
Execution of tasks–discrepancy management, data review, data locking
Effective communication–with study team, monitors, study data manager
Issue identification and Process improvement identification
6. CDM Activities:
Following activities are performed under CDM:
 Data collection
 Data abstraction/extraction
 Data processing/coding
 Data analysis
 Data transmission
 Data storage
 Data privacy
 Data QA

7. Guidelines and Regulations for CDM:
"Each individual involved in conducting a trial should be qualified by education, training, and
experience to perform his/her respective task(s).”
I. Good Clinical Practice (GCP):
•Data handling, record keeping (2.10, 5.5.3 a-d)
•Subject and data confidentiality (2.11; 5.5.3 g)
•Safety reporting (4.11)
•Quality control (4.9.1; 4.9.3; 5.1.3)
•Records and reporting (5.21; 5.22)
•Monitoring (5.5.4)
II. 21 CFR part 11:
The code of federal regulations deals with the food and drug administration (FDA) guideline on
electronic records and electronic signatures in the United States. 21 CFR part 11 has a significant
impact on CDM processes due to focus on validity and reliability of the record. It has a specific
requirement for audit trail system to determine incorrect and altered records.
III. ICH E6 Guideline:
It indicates that the quality control for data handling should be maintained. All data should be
credible and correct. Any change and corrections to CRF should be dated, initiated, explained

and will not obscure original entries. It applies for both paper and electronic changes. The audit
trials should be maintained. All procedures during clinical trials s should be available for audit.
IV. FDA Guideline on Biomedical research monitoring:
It provides a specific instruction on data collection n, handling and review of data for each
subject. This guidance also covers the requirements for automated entry of clinical data in
compliance with 21 CFR part 11.
8. Process Related to Clinical Data
1. Develop Clinical Development Plan for each Drug Project
2. Develop Protocol
3. Select Investigators
4. Develop (e)/Case Report Forms (and system)
5. Study setup includes: Select vendors (e.g., laboratory) and test data interface and Train
project team
6. Prepare investigator’s site and people
7. Collect data
8. Handling of Serious Adverse Events by Sponsor’s Pharmacovigilence personnel
9. Quality Assurance Audits by Sponsor
10. Determine patient acceptability
11. Deliver to Statisticians/SAS Programmers
12. Finalize database documentation
13. Write clinical study report
14. Prepare e-submission CRFs, electronic Case Report Tabulations with documentation for
NDA submission

Process Related to Clinical Data
 Plan (Data Management Plan) development:
DMP (Data Management Plan) is a document throughout the life cycle of a study, to address
any updates/changes made during conduct of the study; DMP should be developed for each study
and early during the setup of the study and it:
•Describe all the components of the DM process
•Each component in the DM process should specify
•Work to be performed
•Responsible staff for the work
•Guidelines and/or SOPs will be complied with
•Output will be produced
Plan
Protocol
Investiga
tors
(e)/CRF
Study
setup
Prepare
site
Collect
data
Handling
of SAE
QA
Audits
Patient
acceptabilit
y
Statistici
ans/SAS
Databas
Clinical
report
e-
submission/NDA
submission

 Development/ Design of CRF:
In clinical trials CRF is used as a data collection tool. CRF should be design in a way that
prompts simple database design, data capturing and data validation. The CRF are filled in by the
investigator and then forwarded to the data management unit for entry and review.

Data Collection tools
Data: Representations of facts, concepts, or instructions in a manner suitable for
communication, interpretation, or processing by humans or by automated means. [FDA]
1. Data is collected basically from:
 Investigator/staff record observations/data onto source documents
 Source document: where data is first recorded or a certified
 Data is transcribed by Investigator staff onto Case Report Form (CRF) or entered into
electronic Case Report Form (eCRF)
 Vendor data usually transmitted electronically to sponsor database (e.g. lab data)
 CRF data entered/transferred into sponsor database
2. Clinical data capture at study sites basically includes:
 Paper CRFs (pCRFs)
 EDC system ( Electronic Data Capture) or RDC system ( Remote Data Capture)
3. GCP requirements for data collection:
 All clinical trial information should be recorded, handled, and stored in a way that allows
its accurate reporting, interpretation, and verification.
 Data reported on the CRF, that are derived from source documents, should be consistent
with the source documents or the discrepancies should be explained.

4. Primary modes of capturing data for a CT:
Offline
•Traditional paper-based method
•Collects clinical data at the sites
•Sends CRFs to DM center
•EDC system that works without Internet connection
Online
•EDC method
•Records clinical data online (eCRFs)
•Stores data at a central server
Combination of offline
Online methods: that involves the use of both offline and online EDC methods.

Data Entry Methods
1. Data Entry: Data entry refers to the process of transferring data from the paper CRF to the
database in computer system. Data entry results in creation of electronic data, which
corresponds to the CRF data. (After entry of the data it has been reviewed and validated).
2. Data entry has various types:
Local DE system:
•Data entered onsite
•Quick data resolutions for omissions, errors, inconsistencies
Central DE system:
•Completed CRFs were sent to DM center
•Data entered by experienced DE operators
•Forms stored centrally
Web-based DE system:
•Software requirements (Internet Explorer)
•No specific hardware requirements
•Require internet connection
•Secure link provided
Double DE - independent verification: Two people enter data and a third person resolves
discrepancies between both entries

•Double DE - blind verification: Two people enter data (unaware of what values the other
entered) and the 2nd DE operator verifies data, determines the appropriate entry and saves data
(overwrite the prior value)
Double DE - interactive verification: Two people enter data and the 2nd DE operator resolves
discrepancies between 1st and 2nd entry while being aware of the previous values
•Single data entry – review: One person enters data and 2nd person reviews the entered data
against the source data
•Optical character recognition (OCR): Software is used to recognize characters from eCRFs
or faxed images then these data are placed directly into the database. Data obtained through OCR
should always be reviewed for accuracy

Query (discrepancy) generation and management
1. Query:
Sometime it is also called as discrepancy which is a Request from a sponsor or sponsor’s
representative to an investigator to resolve an error or inconsistency discovered during the
product and may be assessed by laboratory testing of biological samples, special tests and
procedures, psychiatric evaluation, and/or physical examination of subjects.
2. Query management:
Ongoing process of data review, discrepancy generation, and resolving errors and inconsistencies
that arise in the entry and transcription of clinical trial data, in clinical trials, the collected data
can be inconsistent and need to be corrected. Basically, the cleaning of data consists in first,
identifying inconsistencies and then sending appropriate queries to the investigator for data
correction. From the data management side, checking data for discrepancies is done using edit
checks to target missing or out-of-range values, or checking consistency between item values.
However, off-line checks, which are applied by the data manager on the study database using
dedicated programs, are still widely used. In fact, even if on-line controls are cost-saving due to
the limitation of errors at the time of data entry, the implementation of complex controls
becomes rapidly cumbersome in EDC platforms. On the other hand, bias that could result from
exhaustive on-line controls can be subject to controversy.
SAS is an interesting alternative for the implementation of edit checks, especially in the working
context of our company which is specialized in providing in-house fully integrated EDC
solutions. SAS offers the possibility for creating optimized and flexible programs, needed for
edit checks implementation. Therefore, we have on the one hand, an EDC solution which
provides a sophisticated feature to write manual queries and on the other hand, an efficient
workflow for the implementation of off-line edits checks.

Our motive for interfacing our EDC solution queries module with our SAS programs is obvious
and explained further in this paper.
3. On-Line Edit Checks:
Most EDC solutions provide on-line edit-checks in a rather effective way to reduce data entry
errors and/or data discrepancies from the investigators’ sites: the error is detected at the time of
the data entry and the correction can be performed directly online.
Such processes avoid numerous human omissions or errors (missing values, inconsistency of
dates for example). Clinical Data Management's EDC application, which is a web-based
application developed in Microsoft C#.NET, enables classical on-line edit checks during data
entry as well.
Moreover, even if an inconsistency is found in the data, it is not obvious to define whether the
correction should be mandatory or not. Exhaustive mandatory corrections would put the
investigator under unreasonable pressure to enter data, which is of course not acceptable in the
context of clinical trials where reliability of collected data must be ensured.
4. Off-Line Edit Checks Using Manual Editing Tool:
EDC application includes a query management module used during the data cleaning process by
clinical research associates (CRAs), data managers and of course by investigators.
5. Query generation and management Guidelines:
Since the existence of a query means there is some confusion, it is helpful when a query
communicates clearly, without adding to the confusion. Considering the importance of queries to

statistical analysis and the various roles of the people that may be writing and reading queries, it
is useful to have some guidelines for dealing with queries on a day-today basis.
A successful query is one that will be understood. When writing queries, ensure the person
reading the query understands what the query is asking.
A query is sent to a site to address an issue with a specific data point or set of data points,
perhaps out of thousands of data points that were reported. Guideline one for writing proper
queries is thus:
Guideline 1. Tell the site what it reported.
Begin queries by explaining there are data points the site needs to review, where those data
points are, and what is recorded as the values for those data points.
Guideline 2. Tell the site what is wrong with what it reported.
Continuing with the previous two examples, our first two query writing guidelines could now
read something.
Guideline 3. Ask the site to correct or verify what it reported.
Guideline 4. Do not suggest to the site what to report.
6. Query Management For Paper-Based Studies:
Like data collected in trials managed by EDC systems, data from paper-based trials are cleaned
by sending queries to the investigators. However, unlike in EDC-based studies, the query
management process is not handled within a system.
In paper-based studies, queries are generated by completing a query form that is sent to the
investigator sites for resolution by email, fax or mail. The answers are then passed on to the
sponsor. Tracking and managing these queries can be difficult without the right tool. While some
companies use spreadsheets for managing their queries, and while Microsoft Excel VBA

applications may be quite sophisticated, they come with many drawbacks: maintenance issues,
lack of authentication and audit trail, single-user, formatting constraints.
In short, Query (discrepancy) generation and management means information about the query is
sent to the site or monitor and request for the correction. After resolution of queries or
discrepancies data validation and quality control is done.
Sending
queries
Receiving
at site
Tracking
and
resolving
queries
Update/data
base
Creating
queries

Data Review and Management
After data is received at site its review takes place where data tracking and resolving carried out.
Examples of data review and management by PPD software:
1. Discrepancy not reviewed by user:
This is the unreviewed status of a discrepancy that requires site personnel review i.e.
coordinator or Investigator. This is the initial status of a system generated discrepancy.
When logged in as a CRA or other study team member, you will see these discrepancies
in yellow as “Other Discrepancy”. They will appear Red to the site as “Open
Discrepancy”.
Discrepancy not reviewed by user

These discrepancies are reviewed by data management, who often works with
Pharmacovigilance/Safety, or other coding resources to resolve the discrepancies. These
discrepancies do appear on the eCRF but should be addressed ONLY by Data Management. The
eCRF cell icon and patient icon on the Activity List will display the appropriate discrepancy
color relative to a users’ role, i.e. these will be YELLOW to the CRA and site but RED to Data
Management.
If the terms cannot be resolved or coded against the dictionaries, data management can set the
query status to INV Review. If this occurs, the discrepancy would then be an active discrepancy,
appearing to the site as RED for their action.
2. DM Review Or DM Lab Review
These are discrepancies that are set for data management to review. Most commonly, TMS
queries would be set to DM REVIEW after someone from coding has reviewed the queries and
the terms are not able to be coded to any medical dictionary. Site users and CRAs will see these
discrepancies as YELLOW since they do not require their action. Sites and CRAs do not have
the option to change a discrepancy status to “DM Review”.
3. INV (Investigator) Review:
This is the status of a manually assigned discrepancy or a system generated discrepancy that has
been reviewed by the CRA and sent back to the site that requires site personnel review i.e.
coordinator or Investigator. When logged in as a CRA or other study team member, you will see
these discrepancies in yellow as “Other Discrepancy”. They will appear Red to the site as “Open
Discrepancy”.

INV (Investigator) Review
4. CRA Review
This is the status of a query that requires PPD review when you are logged in as a CRA. You
will see these in red as “Open Discrepancy.” They will appear Yellow to the site as “Other
Discrepancy”.
Note that if the discrepancy was raised as a manual discrepancy by another department e.g. by
Data Management or PVG and the site has responded to it and sent it back to PPD the status bar
will still read CRA review (there is no option for the site to send this query to DM for review or

to PVG for review). You should work with DM and PVG to determine whether the query can be
closed and by whom.
CRA Review

MedDra (medical dictionary for regulatory
activities terminology)
 Coding: coding is the process of converting data on CRF to standard terminology. In order
to the data that is collected during the clinical trials to be analyzed. It must be put into a
standardize format. For coding of clinical data various coding dictionaries are used.
 Why Do We Need Coding Conventions?
• Differences in medical aptitude of coders
• Consistency concerns (many more “choices” to manually code terms in MedDRA compared to
older terminologies)
• Even with an autoencoder, may still need manual coding
 Coding dictionaries:
A coding dictionary is a standardized tool for grouping the terms and phrases to allow for the
analysis. eg. MedDra.
1. Introduction
The Medical Dictionary for Regulatory Activities (MedDRA) Terminology is the international
medical terminology developed under the auspices of the International Conference on
Harmonisation (ICH) of Technical Requirements for Registration of Pharmaceuticals for Human
Use. This guide describes the development, scope, and structure of the terminology.
2. MedDRA Codes:
Each MedDRA term assigned an 8-digit numeric code
• The code is non-expressive
• Codes can fulfill a data field in various electronic submission types (e.g., E2B)

• Initially assigned alphabetically by term starting with 10000001
. New terms are assigned sequentially
• Supplemental terms are assigned codes
3. What Does MedDRA Offer?
• Size and specificity (“granularity”)
• Hierarchy/grouping terms
• “Support” SOCs widen data collection/ analysis options
• Up-to-date and medically rigorous
• User-responsive
• Standardization
4. Development of The Medical Dictionary For Regulatory Activities
A. (Meddra) Terminology
As noted above, the ICH terminology was developed from a pre-existing terminology. The
MEDDRA Working Party enhanced the United Kingdom MCA’s (Medicines Control Agency)
medical terminology to produce MEDDRA Version 1.0.
MedDRA Version 2.0 was signed off as the implementable version of the terminology at the
ICH-4 conference in July 1997. A change in name and modified acronym were agreed upon at
this meeting. Hence, MEDDRA is used for versions up to Version 1.5, while the implementable
version (Version 2.0) and future versions are known as the MedDRA terminology.
B. Implementation Of The Terminology
The success of the terminology depends on its long-term maintenance and its evolution in
response to medical/scientific advances and changes in the regulatory environment. This is why
the MedDRA Maintenance and Support Services Organization (MSSO) is a necessary element to
implementing the MedDRA terminology. The International Federation of Pharmaceutical
Manufacturers and Associations (IFPMA) appointed the MSSO through an open competitive

tender under the direction of the ICH. The Call for Tenders document defined the functions of
the MSSO in detail.
C. Scope Of The Terminology
The MedDRA terminology applies to all phases of drug development, excluding animal
toxicology. It also applies to the health effects and malfunction of devices (e.g., PT Device
related infection and PT Device failure). The categories of terms classified as “medical” for
these purposes are as follows:
 signs
 symptoms
 diseases
 diagnoses
 therapeutic indications – including signs, symptoms, diseases, diagnoses, diagnosis or
prophylaxis of disease, and modification of physiologic function
 names and qualitative results of investigations – e.g., increased, decreased, normal, abnormal,
present, absent, positive, and negative
 surgical and medical procedures
 medical/social/family history
D. Inclusion Criteria Of Terms From Established Terminologies
Numerical codes/rubrics associated with the terms and COSTART symbols are stored as
attributes in MedDRA.
The terminology was not developed as a metathesaurus, and the hierarchies of these other
terminologies are not subsets of it. Thus, data entry terms from other terminologies do not
necessarily have the same PT in MedDRA as they did in their “parent” terminology. The
hierarchies used for data retrieval and presentation are unique to MedDRA.
Inclusion of terms is restricted to those within the scope of the terminology as defined above.
Thus, when terms from a particular field (e.g., clinical pharmacology) are represented, only
terms relevant to regulatory affairs are included. The WHO-ART codes included in MedDRA

distribution ASCII files are based on the 3rd Quarter 1998 release of WHO-ART. These codes
have changed in WHO-ART and should no longer be used.
E. EXCLUSION CRITERIA
The exclusion criteria used in the development of the terminology do not necessarily limit the
terminology’s expansion scope. Since this is a medical terminology, the following terms used in
regulatory affairs are out of scope:
Drug/product terminology (Note: The generic names of some commonly used products, such as
digoxin, that are included with their associated adverse events)
 Equipment/device/diagnostic product terminology
 Study design
 Demographics (including patient sex, age, race, and religion).As its focus is on health effects
in individual patients, the following are excluded:
 Qualifiers that refer to populations rather than individual patients (e.g., rare, frequent)
 Numerical values associated with laboratory parameters are not included (e.g., serum sodium
141 mEq/L)
 Descriptors of severity are not included in the terminology. Descriptors such as “severe” and
“mild” are used only when pertinent to the specificity of the term (e.g., severe vs. mild
mental retardation).
F. STANDARDISED Meddra QUERY (SMQ)
Standardised MedDRA Queries (SMQs) are groupings of MedDRA terms, ordinarily at the
Preferred Term (PT) level that relate to a defined medical condition or area of interest. SMQs are
intended to aid in the identification and retrieval of potentially relevant individual case safety
reports. The included terms may relate to signs, symptoms, diagnoses, syndromes, physical
findings, laboratory and other physiologic test data, etc. The only Lowest Level Terms (LLTs)
represented in an SMQ are those that link to a PT used in the SMQ; all others are excluded.

For detailed information about the SMQs, please refer to the SMQ Introductory Guide, which is
a separate document. It can be found along with the other supporting documentations with this
release.
G. Rules And Conventions Adopted In The Terminology
Each rule holds true in the majority of cases, but many rules will have exceptions. Some of those
exceptions are listed within each rule; however, it is not possible to notate all exceptions.
MedDRA is a medical terminology not taxonomy and medically must be balanced, pragmatic,
reflect actual medical practice, and have consideration for how different cultures interpret
specific terms.
MedDRA has some rules on:
o SPELLING
o ABBREVIATIONS
o CAPITALIZATION
o PUNCTUATION
o SINGLE WORD VS. MULTIPLE WORD TERMS
o WORD ORDER
o MedDRA CODES
o BODY SITE CONSIDERATIONS IN MedDRA
o NUMERICAL VALUES ASSOCIATED WITH PARAMETERS
o AGGRAVATION OF UNDERLYING CONDITIONS
o NOS AND NEC TERMS
o GENDER SPECIFIC TERMS
5. Term Selection Points in MedDRA:
• Diagnoses and provisional diagnoses with or without signs and symptoms
• Death and other patient outcomes
• Suicide and self-harm
• Conflicting/ambiguous/vague information
• Combination terms

• Age vs. Event specificity
• Body site vs. Event specificity
• Location vs. Infectious agent
• Pre-existing medical conditions
• Exposure during pregnancy and breast feeding
• Congenital terms
• Neoplasms
• Medical/surgical procedures
• Investigations
• Medication/administration errors and accidental exposures
• Transmission via medicinal product of infectious agent
• Overdose/Toxicity/Poisonings
• Device terms
• Drug interactions
• No adverse effect
• Unexpected therapeutic effect
• Modification of effect
• Social circumstances
• Medical and/or social history
• Indication for product use
• Off label use
6. System Organ Classes of MedDRA:
• Blood and lymphatic system disorders
• Cardiac disorders
• Congenital, familial and genetic disorders
• Ear and labyrinth disorders
• Endocrine disorders
• Eye disorders
• Gastrointestinal disorders

• General disorders and administration site conditions
• Hepatobiliary disorders
• Immune system disorders
• Infections and infestations
• Injury, poisoning and procedural complications
• Investigations
• Metabolism and nutrition disorders
• Musculoskeletal and connective tissue disorders
• Neoplasms benign, malignant and unspecified (incl cysts and polyps)
• Nervous system disorders
• Pregnancy, puerperium and perinatal
• Psychiatric disorders
• Renal and urinary disorders
• Reproductive system and breast disorders
• Respiratory, thoracic and mediastinal disorders
• Skin and subcutaneous tissue disorders
• Social circumstances
• Surgical and medical procedures
• Vascular disorders
7. The MedDRA coding process:
The process of coding into medDRA requires several stages they are as:
1. MedDRA Dictionary Creation: The first step is just to create MedDRA dictionary SAS
dataset from the downloaded flat files from MSSO. This step is only done once for each version
of the MedDRA dictionary.
2. Dataset to Code: The coding system can be configured to code against any dataset. But there
is one requirement. The dataset must have a verbatim variable to be coded. In the diagram,
Adverse Event dataset (AE) as an example. Its verbatim term variable is AETERM.

The FDA requires the Preferred Term (PT) and System Organ Class (SOC) to be reported along
with the verbatim terms. However, in order to find the correct Preferred Term, we need to find
the Lowest Level Term (LLT) first. Once LLT is found, PT and SOC will be found automatically
from the MedDRA Dictionary.
3. Auto Coding against MedDRA Dictionary: Auto coding means the coding system will find
the matching LLT for a verbatim term automatically. No human intervention is required. The
auto coding process consists of two parts. The first part is the coding system will try to match a
verbatim term to the LLT in the MedDRA dictionary. If a match is found, this verbatim term is
coded.
4. Auto Coding against MedDRA Synonym Dictionary: If the verbatim term does not match
to any of the LLT in the MedDRA dictionary, it will try to match the modified verbatim term
(VTMODIFY) in the MedDRA Synonym dictionary. If a match is found, this verbatim term is
coded. This is part two of the auto coding process.
5. Auto Coded: If auto coding is successful, the verbatim term is coded. So no further action is
needed. Please note
one LLT may have more than one path to a SOC. But there is only one primary path which the
auto coding will select.
In some rare occasions, if non-primary path is preferred, manual coding is required.
6. Transaction File: If a verbatim term cannot be coded during the auto coding process, it will
be written to the MedDRA Transaction file where manual coding is required.
7. Manual Coding: For a verbatim term that does not match to any of the LLT in the MedDRA
coding dictionary, a coder can assign a proper LLT term to it directly, or the coder can modify
the verbatim term and then assign a proper LLT to it. This process is called manual coding.

MedDRA Coding Process
8. Queries: a query is created to send to the investigator’s site to update the verbatim term.

9. Dataset Coded: By doing both auto-coding and manual coding repeatedly, all the verbatim
terms in the original dataset will be eventually all coded. All terms in the Transaction File will
also be coded.
10. Updation of MedDRA Synonym Dictionary

Electronic Data Capture
1. ELECTRONIC DATA CAPTURE (EDC):
Electronic data capture (EDC) is a system using central server for collecting the central data.
EDC helps to enter the data directly in electronic format instead of data in paper format. This
reduces time required for trial completion with increased efficiency of data management.
2. History:
Historically, clinical data has been first recorded on paper by the medical professional, and then
computerized for analysis. This process was quite lengthy, cumbersome, and prone to error that
required substantial human intervention to complete. This clinical data capture process has
evolved over time in the industry. In the late 1990s, it was believed that the introduction of web-
based technology provided an opportunity to greatly improve the efficiency and accuracy of
clinical data capture. Electronic data capture (EDC) systems became available in the marketplace
with the expectation that efficiencies gained in other web-based markets would now be brought
to clinical data capture. To date, many would agree that such efficiencies are still not apparent,
mainly due to the continued use of processes involving paper-based data collection. A main
hindrance in moving to more electronic source data is the belief that electronic data cannot be
validated which is a requirement of the FDA
3. Evolution of clinical data capture
In the early 1980s, personal computers (PCs) were introduced and soon became commonly used
tools for business and personal tasks. By the mid-1980s, PCs were introduced to clinical trial use
for clinical data capture. Use of PCs for this purpose led to a major transformation in the way
clinical data was captured. Before PC use for clinical data capture, site professionals captured
data on paper case report forms (CRF) and sent the forms to a sponsor centralized facility where
data computerization took place. This method of data capture was called decentralized because
the data was computerized in a single facility by professional data entry personnel. The

investigator’s main responsibility was the original completion of the paper CRFs, and then
responding to queries that arose from the sponsor after reviewing the computerized data. A major
change was that the staff member would now also computerize the clinical data. The reasoning
was that the centralized system led to long times from original data capture to computerization to
data validation. Common errors were of data fields not completed, or completed in error, or
using illegible writing. Then, in the late 1990s, web-based approaches to clinical data capture
were introduced. It was believed that efficiencies would be gained as had been achieved and
documented in other industries moving processes to the Internet.
4. CRITERIA FOR IDENTIFYING AN EDC:
No study is better than the quality of its data. A successful clinical trial should have a well-
developed scheme for monitoring the quality of data and for auditing data .Remember, “No data
– no trial”.
A. Basic Criteria:
The EDC system should provide automated support for data collection, data extraction, data
query, data validation, data manipulation, data sharing, reporting, and the ability to flag source
document verification, to export data and create PDF reports. A web-based system must be
HIPPA compliant.
B. Additional Advanced Requirements:
 Simple installation and study set up
 User friendly interface
 Flexible to meet variable research needs
 Electronic Patient Reported Outcomes (ePRO)
 Easy data exportation and database maintenance
 Hybrid capability to fit in paper sourced data

 Fast and satisfactory technical support and System upgrades responsive to clients’ needs
 Cost-effectiveness
5. REGULATORY GUIDELINE ON EDC:
1. Qualification of central laboratories
 The sponsor must conduct the system audit and/or assessment for the central laboratories in
order to ensure that there are no problems with their data reliability and quality management
systems.
 The central laboratories must establish Standard Operating Procedures for all processes
related to the collection and processing of measured data.
 CSV (Computer System Validation) must be conducted in a planned manner.
2. Verification of transfer and conversion processes of electronic data
 The sponsor must test its transfer and conversion processes of electronic data, and ensure
that there are no problems with the operating procedures and data identicalness before and
after the transfer or conversion of data.
 Specifications for electronic data capture should be established.
 Specifications on compatible software and hardware used for electronic data capture should
be defined.
 For testing purpose, the sponsor should receive and check the electronic data of test results
from the central laboratories.
 The sponsor should confirm the procedures to correct the test results at the central
laboratories, and check the process for obtaining revised data

3. Verification of data by direct access
It is also required to verify the consistency of patient IDs, dates, and other information between
test reports and other source documents by direct access, in order to ensure authenticity of the
data of each subject.
4. Confirmation of received data
The sponsor should implement the processes to confirm that electronic measurement data
obtained from the central laboratories do not contain missing or redundant data. The scope of
confirmation should include the data transmission logs from the central laboratories to the
sponsor.
6. Requirements of the GCP for EDC:
 The sponsor must fulfill the requirements provided in Article 26 (Record Keeping), and the
site must meet the requirements provided in Article 41 (Record Keeping).
 Article 26, Paragraph 1-3 of the GCP Enforcement Notification specifies requirements for
data handling using an electronic data processing systems
 When an electronic data processing system (including remote electronic data systems) is
used to handle clinical trial data, the sponsor shall conduct the following:
1) Ensure and document that the electronic data processing systems fulfill the sponsor’s
established requirements for completeness, accuracy, reliability and consistent intended
performance (i.e. validation).
2) Maintain the operating procedures for using these system.
3) Ensure that the systems are so designed as to permit data correction in such a way that the data
correction are documented and that all records of correction of entered data remain undeleted as
logs distinguishable to the inputter as well as to the corrector (i.e. to maintain audit trail, input
trail, and edit trail).
4) Maintain a security system for the data.
5) Maintain the adequate backup of the data.
6) Prepare and maintain a list of the individuals who are authorized to make data correction.

7) keep the blinding in case of a blinded clinical trial.
 If data are converted during the processing, the sponsor should ensure that it is always
possible to compare the original data with the processed data.
 Article 41 of the GCP lays down the requirements for record keeping at the site, including
the source documents.
7. EDC issues
The greatest process inefficiency in EDC revolves around the paper-based source documents
commonly used in most industry clinical trials. Whereas most other industries have achieved
efficiency gains through web-based systems, the gains have usually been achieved by also
changing their processes from paper-based to electronic. Two notable examples are the banking
and airline industries. The banking industry regularly moves large amounts of money
electronically around the world in a secure and timely manner. The airline industry manages
millions of passenger reservations globally electronically in a secure, safe, and reliable manner.
In both industries, paper copies of transactions are available as requested but not required. Yet
the clinical trials industry has been reluctant to make this important and essential process change
to improve the clinical trials conduct. There are at least three reasons for this lack of motivation
to change:
(1) FDA,
(2) Lack of portable hardware, and
(3) Attitude of monitors.
The FDA requires validation of all clinical data from each trial and provides guidance
requirements for electronic systems capturing clinical data .Although these guidelines are
developed and discussed for the use of electronic systems, much confusion has existed over these
guidelines due to the use of paper-based source documents being used in most clinical trials. The
confusion has led to the FDA reexamining those guidelines with a plan to provide an updated
interpretation.
A second issue hindering progress in electronic research data is the lack of portable hardware for
data gathering. Until recently, investigators had to use PCs hard wired to walls and telephone

modems that often were too slow and inaccessible for efficient electronic data collection.
A third issue impacting progress is the attitude of monitors whose job involves the validation of
the collected clinical data. The manual validation processes that have been in place since the
centralized data computerization through RDE and now EDC are so deeply ingrained that it is
difficult for many monitors to consider any process that does not include paper. Monitors need to
realize that validation will still be required for electronic source data, but their processes will also
change, allowing them to become more efficient in their processes as well.
8. Validation of electronic source data:
Clinical data comes from three main sources:
(1) Medical record,
(2) Directly from the subject, and
(3) Lab tests.
Laboratory data capture has been routinely conducted in an electronic process and source data is
considered to be the electronic data files provided by the lab to the sponsor. Hence, there is
certainly a precedent for electronic source data in the clinical trial arena.
Once data entry is completed then data is ready to be reviewed and validated. Data validation is
the cleaning of trial data after entering into a computer database in order to ensure that they
attained a reasonable quality level. Data validation ensures that all queries are addressed as well
resolved and that database is finally clean and ready to be locked. Data validation and quality
control are performed to make sure that entered data is;
 Complete
 Legible
 Consistent
 Logical

A. Validating direct data capture from the subject:
(a) A two-step approach first recording the information onto a paper CRF and then
computerizing from the paper source document as is most common today, or
(b) A single-step approach of direct entry onto an electronic CRF producing an electronic source
document.
B. Validating data capture from a subject medical record:
A common misconception is that research data taken from a patient medical record is
automatically paper-source as it already exists on the paper medical record. Whether copied onto
a paper CRF first or directly computerized from the medical record, many clinical trial
professionals believe the medical record becomes the source document, and computerized data
must be compared to the medical record. Instead, if the same system is used for capturing
research information from a medical record as described above for the data captured directly
from the subject, the research data entered electronically from the paper medical record and
validated immediately by the medical professional would constitute electronic source research
data that was already validated.

Future of Data Management/ Next Generation
Clinical Trial Data
In recent years the FDA and other government organizations working with clinical data have
seen the critical need for more robust data standards which, in the long run, will lead to better
and more efficient science. However, in order for this to be realized people have to adopt
standards, use standards, and continue to evolve to make the standards better. The iterative
process of changing can be very painful but innovation does not usually come without pain.
 MOVE TO A THREE DIMENSIONAL WORLD
As mentioned earlier, there are limitations in defining data standards in a two dimensional world.
The data and metadata must better define the complex interdependent relationships between
clinical research data which cannot completely be captured in the existing data standards.
The FDA has indicated the need to move to a more robust XML standard such as HL7 that
supposedly would provide the ability to define these complex relationships across data and
metadata. However, the current HL7 model is designed to handle a single point in time and does
not support either the relationships between different clinical trial domains within a patient as
well as the need to capture the traceability of derived data. Recently, there has been a push to
move in this direction with a deadline of 2013 for the adoption of an HL7 message and the
elimination of the SAS transport file. However, because of the backlash from industry the FDA
has backed off this message and has indicated there is no timeline for this implementation. They
will take their time and develop an alternative that works and can be easily adopted by industry.
Even though the short term seems to support use of the standards as they exist today, the industry
cannot deny the need to move to a three dimensional standard if they expect to realize rapid
efficiencies. This leads to many challenges in the future as to how data standards will evolve to
meet the needs of both clinical research and regulatory agencies.

 CONTINUED ADOPTION OF STANDARDS
While the current standards have limitations the industry must continue to work towards
adopting the standards in their process even if it doesn‟t lead to immediate efficiencies in the
short term. By jumping full throttle into the standards we can learn where the gaps are and work
harder to close those gaps. This is easy to recommend in theory but leads to challenges as
companies are under more pressure every day to get drugs submitted fast.
In the future, standards can be adopted more smoothly if the industry works harder at
incorporating them earlier in the process. As CDASH matures we can work on collecting the
data in a standard and thus make everything else downstream much easier since the standards are
aligned. The standards can even go back further to the development of the protocol with the
CDISC release of the Protocol Representation 1.0 Model which not only provides a standard for
collecting metadata about a Protocol but was also developed with a three dimensional world in
mind.
The challenges to investigate clinical product candidate efficacy and safety efficiently and to
adhere to regulatory requirements create the strong impression that widespread adoption of EDC
technology is inevitable. Indeed, EDC and e-clinical systems have attributes attractive to the
majority of biopharmaceutical firms and CROs in a competitive clinical trial industry. FDA has
brought forward a critical path initiative in pushing SDTM adoption to enable electronic
regulatory submissions for sponsors of human drug clinical trials. SDTM was initiated and
developed by CDISC. The increasing usage of SDTM, the operational data model, analysis data
model, case report tabulations data definition specification define.xml, the laboratory model, and
maturing standards, such as CDASH and FDA protocols, has created an end-to-end solution for
the industry to focus on moving data from the point of capture to regulatory submission,
therefore boosting the adoption rate of EDC and e-clinical systems by biopharmaceutical firms.
However, the apparent certainty of growing EDC adoption needs to be constantly re-examined
due to considerations of a number of challenging issues.

Software packages for CDM
After completion of data management activity, it is necessary to keep all records and all
documentation report data available in a database format with the help of software.
Some softwares used in clinical data management are:
1. Oracle
2. SAS
3. Office software
4. UW Catalyst data collection (University of Washington)
5. REDCAP (Research electronic data capture)
6. OPENCLINICA
7. STUDY TRAX
8. Aris Global software solution for life science
9. Symetric science
10. Progeny clinical
11. Informed

Basic procedure for data entry and evaluation required for these softwares is:
1. Login
2. Filter Patients
3. Enter data

Filter patient:

List of studies:
Site List:

Data Forms:
Data Evaluation:

Screening:

Edit Checks or Updates:

Vital Signs Form:
List of Sponsors:

Study details or Data collected:
Authors:
Pathan Azher Khan
Mail:
pathanazherkhan@gmail.com

CDM

More Related Content

What's hot

Viewers also liked

Similar to CDM

More from Pristyn Research Solutions

Recently uploaded

CDM