CDISC ‘standardized’ CRFs project dated back to 2006 Numerous people involved from Pharma/CROs/industry associations Kendle had been involved in the review of the various draft CDASH “packages” and provided feedback

We thought it would be easy to transfer the CDASH domain spec into our DB design spec – we just needed to define: Question prompt – defined in the CDASH specs Database variable name – defined in the CDASH specs Data type Any conditional rules Codelist name (if applicable – only for text values) Precision and length Should the variable be displayed in a table on the screen – and if so the table details

CDISC Domain: See CDASH document Form Label: This must match the "Form Label to be Displayed" as defined in the Forms tab. A selection list has been defined on the Forms tab - but some adjustment may be needed depending on number of forms. Order: Used to identify the order in which the questions will be placed on the eCRF CDASH CRF Label / Question: See CDASH document Clinical Database Variable Name (CDISC/CDASH): see CDASH document

Kendle Database Variable Name: Use Clinical Database Variable Name from CDASH document as often as possible CDASH Core: See CDASH document Conditional Rule: Details of condition to enable this question for entry on an eCRF. (e.g. for question prompt "If other race please specify", conditional rule could be "If 'Race' = 5 (other)") Data Type: Type of data: TEXT, DATE, INTEGER (whole numbers) or FLOAT (numbers with decimal places). Kendle Codelist Name: Name of code (pick) list associated with question where none appropriate exists within the CDISC Controlled Terminology list. Codelists that are a part of the CDISC Controlled Terminology list should be used wherever possible. Details of code lists that are not a part of the CDISC Controlled Terminology list should be authorised and documented within the CDASH team. This is only applicable for questions defined as TEXT.

CDISC SDTM Codelist Name: Name of CDISC Controlled Terminology codelist to be applied or name of CDISC Controlled Terminology codelist that is associated with the Kendle Codelist. This is only applicable for questions defined as TEXT Min Precision: Length of the minimum number of decimal places allowed (not including the decimal point). This is only applicable for questions defined as FLOAT. Length of the maximum number of decimal places allowed (not including the decimal point). This is only applicable for questions defined as FLOAT. Is the question to be displayed as a part of a repeating table within the form? This is used for form types that can have multiple records of values (e.g. AEs, Conmeds, etc.) Table Details: Differentiate table if more than one table on form (e.g "table a", "table b", etc) Table Heading: Table heading text to be displayed above table summary row once data has been entered. Applicable for ClinPhone eCRFS only.

Dictionary Name/Version: Name and version of coding dictionary the question response should be coded to, eg WHO-DDE and MedDRA dictionaries. Only applicable for questions defined as TEXT. Loaded Electronically?: Enter "yes" if data will be loaded electronically into this question. Question Hidden?: Is the question hidden in ClinPhone? (typically used for derivations). Derivation Description: Details of how the data will be derived. This is only applicable for questions where "Data Derived" = "Yes“ Comment: Insert any relevant comments or considerations, e.g. if a variable may be optional on the CRF page.

We started with the Vital Signs domain – we thought it would be relatively simple and easy to transfer from CDASH into our database spec. In retrospect, this was not an easy domain to start with – but it did highlight a lot of the issues we were going to find early on in our development which an advantage! For example: We needed to decide how to set up our eCRFs to reflect a CDASH domain that could apply once per study, once per visit or many times per visit – we ended up with two eCRF specs – one for collection at a single timepoint and one for multiple timepoints We had to decide on what actual variables we wanted to include on our “horizontally” structured eCRF, e.g. “weight”, “height”, etc. Could all the defined CDASH variables actually be collected at every timepoint on a mulit-timepoint version? We had to make a decision on whether to include the CDASH “Vitals Status” variable (used to indicate that a vital signs measurement was not done) for every variable we defined, a subset, or just once per eCRF We needed to add additional fields to our eCRF spec template: Kendle question prompt – this would be different for many fields, e.g. in vital signs there is just one CDASH field “Vital Sign Test Result” – we needed to define separate fields for all tests, such as “weight”, “height”, etc. Kendle database variable name – for the above reason again this would be different for fields such as “weight” and “height” where there is just one CDASH variable to cover all tests

CDASH Team Decisions .Standard CRF modules will be produced using InDesign .Kendle will set up code lists to mirror the entire list in the CDISC Controlled Terminology list - to be reduced down on a study-by-study basis .CRF Specification files will be created for each different version of a standard CRF module .Where dates need to be set up as three separate variables in the database in order to enter partial dates, this will be specified in the Form Specification by using different rows for each date constituent part with a further row for the derived full date. Partial dates will be derived using the standard of 1st of month for missing days and January for missing month - unless otherwise specified by the Sponsor. .Variable names will not include an underscore. .Missing codes will be: Dates: 1Jan00 Character: .A (includes times) Integers: -999 integer Float: -999.9 .In our Kendle terminology code list, we will use proper case in the dropdown and upper case in the DB. .No standard Kendle CRF/eCRF will be set up for the Comments (CO) domain since CDASH do not recommend including this form. .Full text values for variable responses will be used in both the display value and the stored data value. Where possible and practical, these will match.

We agreed we should include all Highly Recommended and Recommended/Conditional variables. We discussed each “optional” filed and made our decisions – in most cases including them all since, as a CRO, it is difficult to develop our own company standards since our clients may well have made their own decisions with respect to each CDASH optional variable. In most cases we decided it would be more efficient in the long term to remove unwanted fields rather than have to create additional CDASH fields to satisfy sponsor requirements. In a few cases, we did decide to omit optional fields from our eCRF standards as we felt they would rarely be used. For example, time of birth. This would only be used in pediatric trials, and it makes sense to add when needed (rarely) versus remove when you don't need (assuming we added it as a standard variable), which would be most of the time. Other time variables were excluded for the same reason.

Example of one of the problems we found: The SDTM codelist “Unit” contains over 300 terms, ranging from such terms as “cm” to “mg/kg/min” to “log10 TCID 50/dose”! Whilst of course all these terms are valid and useful, site staff need to be encouraged to use any EDC system by being presented with easy to complete eCRFs. They do not want to trawl through a list of 300 terms to find one of “cm” or “m”! The controlled terminology in this spreadsheet supports Study Data Tabulation Model (SDTM) Implementation Guide Version 3.1.1 and represents all SDTM controlled terminology developed and in production to date including - SDTM Package 1, SDTM Package 2A and Labtest Package 1. Addtional SDTM Terminology is in various stages of development and will be moved into production in the coming months. A change request mechanism will be implemented on the CDISC website by early February. Once activated, terminology change requests will be assessed with terminology version releases planned twice annually. Column Description Code (Column A) Unique numeric code randomly generated by NCIt and assigned to individual CDISC controlled terms Codelist Code (Column B) Unique numeric code assigned to the SDTM parent codelist names. This number is repeated for each controlled term (aka permissible value) belonging to a codelist. **NOTE - light blue highlighting is used to identify the beginning of a new SDTM codelist and its applicable term set. Codelist Extensible (Yes/No) (Column C) Defines if controlled terms may be added to the codelist. New terms may be added to existing codelist values as long as they are not duplicates or synonyms of existing terms. The expectation is that sponsors will use the published controlled terminology as a standard baseline and codelists defined as “extensible” (or "Yes") may have terms added by the sponsor internally. Codelist Name (Column D) Contains the descriptive name of the codelist which is also referred to as the codelist label in the SDTM IG. As with the Codelist Code, the Codelist Name is repeated for each controlled term belonging to a codelist. CDISC Submission Value (Column E) IMPORTANT COLUMN: Currently (as per SDTMIG 3.1.1) this is the specific value expected for submissions. Each value corresponds to an SDTM Codelist Name as indicated by light blue shading.

**NOTE - when a Submission Value in Column E is shaded yellow, this indicates when a particular value differs from the CDISC Preferred Term in Column F. This is either due to: (a) an existing external reference noted in the SDTMIG 3.1.1 (e.g. see rows 63-67, 524, 645 and 721); or (b) where Test names are identified and repeated following a list of corresponding Test Codes (e.g. see TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004, and EGTEST rows 1222-1267). In many cases the discrepencies between the Submission Value and Preferred Term will be rectified in a future version release. CDISC Preferred Term (Column F) This is the CDISC preferred name for a term as identified in the NCI Thesaurus (NCIt) environment and to which numeric codes (Column A) are assigned. In most cases, the Preferred Term or PT is redundant with the "CDISC Submission Value" in Column E. CDISC Synonym(s) (Column G) This identifies the applicable synonyms for a CDISC Preferred Term in Column F. **NOTE - this is especially important in instances where a Test name or Parameter Test name contains a corresponding Test Code or Parameter Test Code. Examples include: TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004 and EGTEST rows 1222-1267 CDISC Definition (Column H) This identifies the CDISC definition for a particular term. In many cases an existing NCI definition has been used. The source for a definiton is noted in parentheses (e.g. NCI, CDISC glossary, FDA) NCI Preferred Term (Column I) This is the NCI preferred name for a term as identified in NCIt Pre-release / Production (Column J) This indicates the workflow status for a particular term. **NOTE - all terms in this spreadsheet are currently in "Production" Notes (Reference for CDISC PT) (Column K) Contains additional reference information for a particular term as identified in SDTMIG 3.1.1

Once we started building our eCRFs for real, we realised that our EDC system, as with any, has its limitations that we needed to work around. For example, in our DB system, times are recorded as text fields. This resulted in extensive discussions on how to require a time to be entered. The CDASH guidelines state that “Times are collected in a user-friendly format and then converted to the ISO 8601 format for submission.” – but what is a “user-friendly format”?! Does it require a colon between the hours and minutes, a period (full stop), or nothing at all between the two. Deciding which might be the most “user-friendly format” took some considerable discussion! I think we decided to use HHMM without the colon, but Gill will have to confirm. If I remember correctly, it was a toss up and felt it was 1 less thing to remember to DE and would likely be less mistakes. But, I may be completely wrong.

However, our system also has functionality that we needed to utilise to best advantage, for example, we are able to mark a whole page or single item as “not answered”. In several cases, CDASH defines a variable to collect this information. We needed to decide if we should use the CDASH variable or utilise our system functionality and export to the equivalent SDTM variable. This decision was compounded when considering a single eCRF containing multiple timepoints with multiple (Kendle) variables, created during the conversion from the CDASH vertical structure to our Kendle eCRF horizontal format! We created "Kendle variables" and include "mapping specs" to indicate which SDTM variable the kendle variable should be mapped to (e.g. all VS tests in SDTM is VSORRES for the results. However, you can't have the same variable name for more than 1 field, so we names our temperate VSORT (or something similiar), or systolic BP, VSORSBP, etc. with instructions that VSORT is to be mapped to VSTEST="Temperature", VSORRES). And for the "not answered functionality, we decided after a lot of discussion (I think - Robin can you confirm?) that we would use the ClinPhone "not answered" functionality for all scenarios. The decision centred around the suggestion that, for the multiple timepoint version, we could have used the CDASH "Status" field to indicate a whole timepoint not done, to save the site entering "not answered" for each variable at that timepoint, (For a single time point, they can use mark not answered for each field or mark not collected for the whole page.) In the end though, we went for consistency and used the ClinPhone "Not answered" for all variations.

Once we started our UAT we felt we were making real progress – our standard eCRFs were almost ready to put into production use! Our early but thorough decision making process paid off as we were able to pass most eCRFs through UAT with minimal findings and re-work being needed. Reviews by the various groups focussed as follows: CDM review ensured that the eCRF functioned as specified and complied with the (newly published) CDASH specifications Clinical Development review ensured that the eCRF was user friendly and followed standard clinical practice Coding review ensured that our additions and sub-setting of the SDTM controlled terminology was required and consistent Programming review ensured that the data collected on the eCRF would be able to be mapped to SDTM Statistics review ensured that the data being collected would be able to be analysed in an appropriate manner

Originally we had (naively) hoped that mapping data collected following CDASH standards to SDTM would almost be automatic. It soon became apparent that this would not be the case and we needed an expert on SDTM to join our team to assist with the mapping specs. We added an additional field to our eCRF specification document which provides details of how to map our “CDASH compliant” variable to SDTM. In some cases, this process also identified further required changes to the way in which we had decided to collect data to ensure that it most easily facilitated the transition to SDTM. The controlled terminology in this spreadsheet supports Study Data Tabulation Model (SDTM) Implementation Guide Version 3.1.1 (IG 3.1.1). It represents all SDTM controlled terminology developed and in production to date, comprising SDTM Packages 1, 2A & 2B and Labtest Packages 1 & 2. Additional SDTM Terminology is in development (SDTM Package 3, Labtest Package 3) and will be moved into production in the fall of 2008. This will be the final major release of terminology for SDTM IG 3.1.1. Any future additions to the 3.1.1 terminology set will be handled via a terminology maintenance process to be implemented later this year. Column Description Code (Column A) Unique numeric code randomly generated by NCIt and assigned to individual CDISC controlled terms Codelist Code (Column B) Unique numeric code assigned to the SDTM parent codelist names. This code is repeated for each controlled term (aka permissible value) belonging to a codelist. As of 9/22/2008, this code was dropped for parent codelist entries, where it created confusion. **NOTE - light blue highlighting is used to identify the beginning of a new SDTM codelist and its applicable term set. Codelist Extensible (Yes/No) (Column C) Defines if controlled terms may be added to the codelist. New terms may be added to existing codelist values as long as they are not duplicates or synonyms of existing terms. The expectation is that sponsors will use the published controlled terminology as a standard baseline and codelists defined as “extensible” (or "Yes") may have terms added by the sponsor internally. Codelist Name (Column D) Contains the descriptive name of the codelist which is also referred to as the codelist label in the SDTM IG. As with the Codelist Code, the Codelist Name is repeated for each controlled term belonging to a codelist. CDISC Submission Value (Column E) IMPORTANT COLUMN: Currently (as per SDTMIG 3.1.1) this is the specific value expected for submissions. Each value corresponds to an SDTM Codelist Name as indicated by light blue shading.

**NOTE - when a Submission Value in Column E is shaded yellow, this indicates when a particular value differs from the CDISC Preferred Term in Column F. This is either due to: (a) an existing external reference noted in the SDTMIG 3.1.1 (e.g. see rows 63-67, 524, 645 and 721); or (b) where Test names are identified and repeated following a list of corresponding Test Codes (e.g. see TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004, and EGTEST rows 1222-1267). In many cases the discrepancies between the Submission Value and Preferred Term will be rectified in a future version release. CDISC Preferred Term (Column F) This is the CDISC preferred name for a term as identified in the NCI Thesaurus (NCIt) environment and to which numeric codes (Column A) are assigned. In most cases, the Preferred Term or PT is redundant with the "CDISC Submission Value" in Column E. CDISC Synonym(s) (Column G) This identifies the applicable synonyms for a CDISC Preferred Term in Column F. **NOTE - this is especially important in instances where a Test name or Parameter Test name contains a corresponding Test Code or Parameter Test Code. Examples include: TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004 and EGTEST rows 1222-1267 CDISC Definition (Column H) This identifies the CDISC definition for a particular term. In many cases an existing NCI definition has been used. The source for a definition is noted in parentheses (e.g. NCI, CDISC glossary, FDA) NCI Preferred Term (Column I) This is the NCI preferred name for a term as identified in NCIt Pre-release / Production (Column J) This indicates the workflow status for a particular term. **NOTE - all terms in this spreadsheet are currently in "Production" Notes (Reference for CDISC PT) (Column K) Contains additional reference information for a particular term as identified in SDTMIG 3.1.1

The controlled terminology in this spreadsheet supports Study Data Tabulation Model (SDTM) Implementation Guide Version 3.1.1 (IG 3.1.1). It represents all SDTM controlled terminology developed and in production to date, comprising SDTM Packages 1, 2A & 2B and Labtest Packages 1 & 2. Additional SDTM Terminology is in development (SDTM Package 3, Labtest Package 3) and will be moved into production in the fall of 2008. This will be the final major release of terminology for SDTM IG 3.1.1. Any future additions to the 3.1.1 terminology set will be handled via a terminology maintenance process to be implemented later this year. Column Description Code (Column A) Unique numeric code randomly generated by NCIt and assigned to individual CDISC controlled terms Codelist Code (Column B) Unique numeric code assigned to the SDTM parent codelist names. This code is repeated for each controlled term (aka permissible value) belonging to a codelist. As of 9/22/2008, this code was dropped for parent codelist entries, where it created confusion. **NOTE - light blue highlighting is used to identify the beginning of a new SDTM codelist and its applicable term set. Codelist Extensible (Yes/No) (Column C) Defines if controlled terms may be added to the codelist. New terms may be added to existing codelist values as long as they are not duplicates or synonyms of existing terms. The expectation is that sponsors will use the published controlled terminology as a standard baseline and codelists defined as “extensible” (or "Yes") may have terms added by the sponsor internally. Codelist Name (Column D) Contains the descriptive name of the codelist which is also referred to as the codelist label in the SDTM IG. As with the Codelist Code, the Codelist Name is repeated for each controlled term belonging to a codelist. CDISC Submission Value (Column E) IMPORTANT COLUMN: Currently (as per SDTMIG 3.1.1) this is the specific value expected for submissions. Each value corresponds to an SDTM Codelist Name as indicated by light blue shading.

**NOTE - when a Submission Value in Column E is shaded yellow, this indicates when a particular value differs from the CDISC Preferred Term in Column F. This is either due to: (a) an existing external reference noted in the SDTMIG 3.1.1 (e.g. see rows 63-67, 524, 645 and 721); or (b) where Test names are identified and repeated following a list of corresponding Test Codes (e.g. see TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004, and EGTEST rows 1222-1267). In many cases the discrepancies between the Submission Value and Preferred Term will be rectified in a future version release. CDISC Preferred Term (Column F) This is the CDISC preferred name for a term as identified in the NCI Thesaurus (NCIt) environment and to which numeric codes (Column A) are assigned. In most cases, the Preferred Term or PT is redundant with the "CDISC Submission Value" in Column E. CDISC Synonym(s) (Column G) This identifies the applicable synonyms for a CDISC Preferred Term in Column F. **NOTE - this is especially important in instances where a Test name or Parameter Test name contains a corresponding Test Code or Parameter Test Code. Examples include: TSPARM rows 746-767, VSTEST rows 807-819, LBTEST rows 916-1004 and EGTEST rows 1222-1267 CDISC Definition (Column H) This identifies the CDISC definition for a particular term. In many cases an existing NCI definition has been used. The source for a definition is noted in parentheses (e.g. NCI, CDISC glossary, FDA) NCI Preferred Term (Column I) This is the NCI preferred name for a term as identified in NCIt Pre-release / Production (Column J) This indicates the workflow status for a particular term. **NOTE - all terms in this spreadsheet are currently in "Production" Notes (Reference for CDISC PT) (Column K) Contains additional reference information for a particular term as identified in SDTMIG 3.1.1

Having embarked initially on the development of standard CDASH compliant eCRFs, the development of paper CRF modules is greatly facilitated by many of the decisions already made. Likewise, we hope that the development of accompanying database modules will be much simpler second time around. Currently we are developing data validation routines on a study-by-study basis. However, we hope that we will be able to utilise some of the programs that we have developed for specific studies which have a database set up following the CDASH standards to become generic data validation routines that can be utilised across studies.

3.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a3
CDASH Draft Published
• April 2008 - CDISC put the draft of the CDASH (clinical data acquisition
standards harmonization) documents out for public review
• Draft consisted of:
– Introduction
– List of CDASH domains with recommendations on variables to be collected, why
and how
• Primary goal was “the development of ‘content standards’ for a basic set of
global data collection variables that will support clinical research studies“
• Kendle decided to take the risk that this draft was near final and commence
design of eCRF modules compliant with CDASH

4.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a4
Kendle’s CDASH Team Formation
• June 2008 – Kendle’s CDASH team was formed with members from around
the world representing CDM, Biostatistics, Programming and Clinical
Development
• Each team member took on responsibility for one or more CDASH domains
with the objective to:
– review and understand the intention of CDASH re the domain
– transfer the CDASH specs into Kendle’s Study Definition Specification spreadsheet
– cross reference as necessary to the CDISC SDTM controlled terminology list
• We thought this would be easy….

9.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a9
First CDASH Considerations
• July 2008 – we found it was not so easy….
• CDASH, although reflecting the needs of SDTM, is not necessarily conducive
to a database design
– some domains can be collected once per study, once per visit or many times per
visit
– several domains have a very “vertical” structure – which is not immediately
transferable to a database specification
• We discovered that we needed to supplement CDASH standards with our
own Kendle standards
• Clinical input at this stage was vital – in order to define what were the most
likely real-life scenarios we would encounter in the use of our standard
eCRFs

10.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a10
Selection of Standard Variables
• July 2008 – the CDASH document identifies the level of requirement to
include each variable:
– Highly Recommended = A data collection field that should be on the CRF
– Recommended/Conditional = A data collection field that should be collected on the
CRF for specific cases
– Optional = A data collection variable that is available for use if need
• We needed to decide which level of variable we would always collect and, if
not all variables at every level, which we would omit

11.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a11
Codelists and CDASH
• August 2008 – we started to investigate the SDTM terminology list
• We needed to utilise this list to create “pick-lists” for categorical questions on
the eCRF
• Whilst on the one hand the SDTM list is extremely useful…
– it does did not cover all CDASH variables we needed to code
– codelists for some CDASH variables are more than extensive and do not facilitate
an eCRF pick-list
• We created our own “Kendle Codelists” as needed – either:
– New codelists where none existed within the SDTM terminology lists or
– Subsets of a codelist that does exist in SDTM terminology to make the list more
manageable and appropriate as an eCRF pick-list
• Future version control will be vital as revised SDTM terminology lists are
released

12.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a12
Helptext
• August 2008 – the CDASH document also includes “Instructions to Clinical
Site” for each variable
• We realised we could use this text to formulate our eCRF Helptext for each
variable

13.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a13
Building and Testing the Draft eCRFs
• September 2008 – we had now started to build our first eCRFs, but not
without resolving a few more issues along the way, for example:
– Our EDC system has its own limitations – which in some cases we needed to work
around
– It also has functionality which we needed to utilise to best advantage
• Testing the eCRFs began with peer review by another database programmer
and a feedback/review cycle until the peer review passed to the next level

14.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a14
User Acceptance Testing (UAT)
• October 2008 – once peer review of our draft eCRFS was completed, we
commenced a full UAT process, undertaken by worldwide Kendle associates
representing:
– Clinical Data Management
– Clinical Development
– Coding
– Programming
– Statistics
• We needed to ensure our standard eCRFS covered the requirements of all
departments who would directly use them whilst at the same time still
adhered to the CDASH standards and so would map easily to SDTM
• CDASH version 1.0 was now published – we needed to ensure we
incorporated any changes from the draft version

15.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a15
Mapping to SDTM
• October 2008 – at the same time as UAT was undertaken, our programming
representatives added a new field to our eCRF specification document –
“Mapping Specification”
• This field defines the precise details of how each listed variable maps to
SDTM
• Undertaking this further step also highlighted that in some cases it would not
be easy to map to SDTM – and resulted in further changes to the way in
which we had decided to collect some data items

16.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a16
Data Validation Plan (DVP)
• November 2008 – we now commenced defining DVP modules to match our
standard eCRFs
• This was a relatively easy process given the fact that we already had some
standard DVP modules in place that just needed to be adapted to the new
standard eCRFs
• Draft DVPs were created by a Data Manager and reviewed by:
– Clinical Data Management (peer review)
– Clinical Development
– Programming
– Statistics
• DVPs were finalised and now accompany each standard eCRF

17.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a17
Progress to End of 2008
• December 2008 – by the end of 2008 we had:
– Defined, programmed and tested standard eCRFS which comply with the CDASH
domains
– Created “Kendle” coding lists to accompany and supplement SDTM controlled
terminology
– Defined the mapping process from our standard eCRFs to SDTM
– Created Data Validation Plan modules to accompany our standard eCRFs

18.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a18
Focus in 2009
• 2009 – whilst we decided to focus initially on developing CDASH compliant
eCRFs, like most companies we still process a lot of paper CRFs
• Therefore our focus was shifting to developing CDASH standards for a paper
CRF process, including:
– Development of CRF modules compliant with CDASH
– Development of corresponding database modules within the database
management system we use for processing paper CRFs
– Development of corresponding mapping specifications to SDTM
– Development of corresponding Data Validation Plan modules
• Finally, we developed program code which corresponds to our DVP
specifications for both our EDC and paper CRF systems

19.
N o r t h A m e r i c a • E u r o p e • A s i a / P a c i f i c • L a t i n A m e r i c a • A f r i c a19
Reaping the Rewards
• Here and now – we are already finding the set up of our EDC study
databases much simpler and quicker:
– Data Managers are using and adapting our CDASH Study Design Specifications to
define study specific database designs
– Database Programmers are able to pull our eCRF modules and utilise for study
specific database builds
– Data Managers are using and adapting the standard DVP modules to develop
study specific DVPs
– Statistical Programmers are able to use the mapping specifications in our CDASH
Study Design Specifications to write mapping programs more effectively
• The overall result to date is quicker and more cost effective study database
builds with a reduction in the time from final protocol to database “go-live”