1. 9th German CDISC User Group Meeting
Kendle Implementation of Clinical Data Acquisition Standards Harmonization
Dr Elke Sennewald
Kendle
Berlin, 28 September 2010

2. Outline Formation of CDASH Team
Theoretical Development of Kendle’s CDASH Standard
Practical Implementation
Mapping to SDTM and Data Validation Plan
Progress to Date and Future Plans
Repeating the Rewards

3. CDASH Draft Published
April 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
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

4. 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….
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

5. CDASH Form Specification Template (1)
CDISC
Domain
Form Label
(to be
Displayed)
Order
Kendle Question Prompt
Instructions to be Printed on CRF
CDASH CRF Label / Question
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

6. CDASH Form Specification Template (2)
Kendle Database Variable Name
CDASH Variable Name
CDASH Core
Conditional Rule
Data Type
Kendle Codelist Name
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.

7. CDASH Form Specification Template (3)
CDISC
SDTM
Codelist
Name
Min
Precision
Max
Length
Display
Question
within table?
Table
Details
Heading
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.

8. CDASH Form Specification Template (4)
Dictionary Name/
Version
Loaded Electroni-cally?
Question Hidden?
Data Derived?
Derivation Description
Comment
Mapping Specification
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.

9. 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
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: integer
Float:
.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.

10. 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
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.

11. 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
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 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 (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 , VSTEST rows , LBTEST rows , and EGTEST rows ). 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 , VSTEST rows , LBTEST rows and EGTEST rows
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

12. 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. 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
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.

14. 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
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

15. 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
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 (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 This will be the final major release of terminology for SDTM IG Any future additions to the 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 (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 , VSTEST rows , LBTEST rows , and EGTEST rows ). 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 , VSTEST rows , LBTEST rows and EGTEST rows
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

16. 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. 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. 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
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.

19. 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”

20. Questions? Please contact Elke Sennewald: sennewald.elke@kendle.com
+49 (0)

21. Real people. Real results.®
Final slide