Embed Size (px)
Citation preview
Italian-Speaking CDISC User Group 2008
Implementation of SDTM in a pharma company with complete outsourcing strategy
Annamaria MuraroHelsinn Healthcare Lugano, Switzerland
2
Background
• Full outsourcing service: from Study Protocol to Clinical Study Report
• Several third parties involved:– Central Lab– Central ECG– Bioanalytical data provider– CRO sub-contractors– Consultants
• Studies conducted worldwide
• No detailed CRF and database specification
• Each CRO applies its own SOPs
• Paper/Hybrid submission to FDA
3
What drives the changes?(2005)
• Increasing number of molecules under development
• New CROs and third parties involved
• Extraordinary variability in the content of CRF forms and in the data structure
• Need to create efficiencies in the data management process and statistical analyses
• Need to pool data (ISS to be performed)
• To be ready for electronic submissions
4
What needs to be standard?
PaperCRF
CDMS
ECG Lab Other
SAS Raw Data
SASAnalysisDatasets
StudyReport
CRF
Protocol
StatisticalAnalysis &
Data Listings
Submission
STANDARD
STANDARD
STANDARD
HelsinnClinicalStorage
Area
STANDARD
STANDARD
STANDARD
5
First steps(Jan 2006)
• Define the project scope and timelines• Present the project to Top Management• Assemble a multidisciplinary team
– Project Leader– Statisticians and Data Managers– Clinicians (Phase I-III and Phase IV)– Quality Assurance– Drug Safety– Regulatory, (IT)
• Core-teams– CRF standardization– Datasets standardization– Data conversion (old studies) and ISS
6
Choosing CDISC
• No standards available at Helsinn• Comply with FDA guidelines• Use standards already known by CROs• Simplify interchange of data with providers/partners
• CDISC SDTM used as guide for CRF form (no CDASH yet)• CDISC SDTM Version 3.1.1 (+ PK domains, ver. 0.92)• CDISC ADAM Version 2.0 (and specific guidelines)• CDISC Controlled Terminology
7
Study Data Tabulation Model (SDTM): getting started
• Improve internal CDISC know-how– Guideline review, IG version 3.1.1
• Are the guidelines clear enough?• Ambiguity, individual opinions and interpretations
– Official training– Understand the experience of others: European meeting
interchange– CDISC Website, public forum, webseminars
• Knowledge about FDA requirements
• CRO and CDISC know-how: choose the right partner forpilot studies
8
MAPPING
9
Mapping: pilot studiesJan 2006 / July 2006
• SDTM was applied to 2 phase III and one PK study (ongoing studies, ‘old’ CRF)– First Helsinn and CRO experience– Different Guidelines interpretation– No place in the SDTM for variables collected in the CRF: a lot of
SUPPQUAL datasets– Variables collected but not needed/mapped
A lot of mapping effort High quality, clear understanding of the
structure, purpose and attributes of each dataset/variable
10
SDTM Specifications
• CRF Library• CRF design guideline• Complete set of CRF templates
• Database Library • General specifications• Admitted deviations from CDISC• Analysis Datasets: general specification, list of
analysis datasets• SDTM metadata:
– Dataset metadata– Variable metadata– Value-level metadata/Lab, PK dictionary
• Annotated CRF
11
SDTM specifications
• CDISC general assumptions 100% implemented
• Select CDISC SDTM variables– Required: all– Expected: all– Permissible (as needed)
• If no place for a variable à SUPPQUAL dataset
• Very few derived variables included in the SDTM
• Full compliant with FDA requirements (define.pdf/xml)
• Excel based, very easy
12
SDTM specifications
• Datasets Metadata: dataset name, description, structure, purpose, key variables
• Variables Metadata: variable name and variables attributes (label, length, controlled term, origin)
• Value-level Metadata: define attributes and list of terms by test code (example: list of terms for EGTESTCD, DSDECOD)
• Lab Dictionary: short and long name for eachparameter
• PK Dictionary: short and long name for eachparameter
13
14
Variable metadata
ADDITIONAL NOT CDISC VARIABLES
LIST OF TERMS
LENGTH (not required by FDA)
COMMENTS AND NOTES
According to the CRF
15
Terminology
• CDISC Controlled Terminology: few list of terms, applied when available
• Based on terminology already used within the Company
• Code list for Lab: Laboratory Dictionary to definelab parameter name (LBCAT, LBTEST and LBTESTCD)
• Code list for ECG: ECG code of terms (EGTEST and EGTESTCD)
• PK parameters code of terms (PPTEST and PPTESTCD)
16
Mapping challenges/1
• Understand SDTM guidelines and establish conventions– How should the ‘Reference start date’ in the DM domain be populated?– Where ‘Code broken’ information may be mapped?– How diary data may be mapped?– PK datasets: how relationship between PC and PP datasets should be
set?– Trial datasets: Implementation for studies based on cycles, cross-over
studies
• Inclusion/Exclusion dataset– SDTM IG: “The intent of the domain model is to ONLY collect those
criteria that cause the subject to be in violation of incl/excl”– We decided to include in the dataset a response to each criterion– TI (Trial inclusion) dataset prepared
• Deviation dataset (DV)– A lot of discussion– Statistician need to be involved
17
Mapping challenges/2
• Variables not present in the SDTM standards– Where does ATC code go? – Extra coding information: MedDRA hierachy added in the AE dataset– Data from external provider: additional information: comment, alert flags– SUPPCM: to collect ATC codes/terms, Planned dose– SUPPEG: to collect Comment, Alert flag– SUPPLB: to collect Comments from central lab– SUPPMH: to collect Sites of Metastases
18
Mapping challenges/3
• Derived variables– --BLFL “Baseline Flag”: Expected SDTM variable but to be
populated according to SAP
• Population Flag – “Attributions used to classify study populations for analysis (ITT,
SAFETY, PP), should be placed in the SUPPDM datasets”– Not included in the SDTM, present only in the analysis datasets
• Variables used with a different meaning– Does the subject have significant medical history? How can we capture this
question? à MHOCCUR– SDTM IG “The --OCCUR variable can be used in Interventions and Events
general-observation-class domains to indicate that a solicited/prelisted Intervention or Event did not occur, but the key here is "solicited/prelisted."
19
Study specific issuesCancer history mapping
MH.MHCAT
MH.MHTERM
MH.MHSTDTC
SUPPMH.QVAL where QNAM=‘EXTENT’
SUPPMH.QVAL where QNAM=‘SITE1’
20
IMPLEMENTATION
21
SDTM implementation
• CRO may decide where to implement SDTM– CDMS (Oracle Clinical, Clintrial, EDC solutions, etc.)– SAS environment– Hybrid solutions
• Linear method to be applied for generation of SDTM and analysis datasets: processtraceability
22
CRF, SDTM and Annotated CRF
23
Mapping CRFs to CDISC SDTM
• Design the CRF having in mind the final SDTM structure– Limit collection to required and necessary data (avoid ‘not
mapped’ fields)– Groups related fields in the CRF consistent with the SDTM
domain – Use fields name, list of codes in the CRF consistently with
variable labels, CT as much as possible
• Allow efficient database setup• Easy mapping with SDTM database (traceability)• Reduce effort to create SDTM complaint datasets
• Focus on both on content and layout
• CRF Library provided to CRO with SDTM mapping
April 2006-August 2006
24
Annotated CRF
• Due to the variety in CRF Annotation, specifications about Annotated CRF included in the Helsinn Standard Library
25
Demography
INFORMED CONSENT
Informed Consent Signature Date
dd mmm yyyy
DEMOGRAPHY
Gender 1 Male 2 Female
Date of Birth dd mmm yyyy
Race 1 White
2 Black 3 Hispanic 4 Asian 9 Other
Specify ________________________________
DM.SEX
DM.BRTHDTC
DM.RACE
SC.SCORRES (SC.SCTESTCD="RACEOTH")
DS.DSTERM="INFORMED CONSENT OBTAINED" (DS.DSCAT=”PROTOCOL MILESTONE”)
DS.DSSTDTC
Dataset Variable name
Where condition
Assigned value
26
Medical History MEDICAL HISTORY
Does the subject have any significant medical history? 1 Yes 2 No
If ‘Yes’, complete this section
Ongoing Disease (prior and/or concomitant) Date of Diagnosis Yes
(1) No (2)
1.
mmm yyyy
2.
mmm yyyy
3.
mmm yyyy
4.
mmm yyyy
5.
mmm yyyy
6.
mmm yyyy
7.
mmm yyyy
8.
mmm yyyy
9.
mmm yyyy
10.
mmm yyyy
MH.MHTERM MH.MHENRF
MH.MHCAT="MEDICAL HISTORY"
MH.MHSTDTC
MH.MHOCCUR
27
Adverse EventADVERSE EVENT
Has the subject experienced any adverse events? If ‘Yes’ complete this section
1 Yes 2 No
§ Adverse Event from XXX up to YYY days from the last study drug administration < as defined in the protocol > § Adverse events ongoing at the end of the study must be followed until XXX < as defined in the protocol > § Serious adverse event must be followed until the outcome is resolved or a stable condition is reached
Adverse Event
Start and Stop Date
Occurrence 1 single episode 2 intermittent
Serious 1 Yes (*) 2 No
Intensity 1 Mild 2 Moderate 3 Severe
Relation to study drug 1 Not related 2 Unlikely 3 Possible 4 Probable 5 Definite 6 Unassessable
Action taken (tick all that applies)
1 None 2 Study drug interrupted and restarted 3 Dose reduced 4 Study drug discontinued 5 Specific Therapy/Medication 6 (Prolonged) Hospitalization
Outcome 1 Recovered 2 Recovering 3 Recovered with sequelae 4 Not recovered 5 Death 9 Unknown
1. Start Stop
dd mmm yyyy
dd mmm yyyy
1
2
3
4
5
6
2. Start Stop
dd mmm yyyy
dd mmm yyyy
1
2
3
4
5
6
3. Start Stop
dd mmm yyyy
dd mmm yyyy
1
2
3
4
5
6
If the Event is serious, fill in a Serious Adverse Event Report
AE.AESTDTCAE.AETERM
AE.AEENDTC
AE.AEPATT
AE.AEOUT
AE.AESER
AE.AEREL
AE.AESEV
1, 2, 3, 4 → AE.AEACN5 → AE.AECONTR6 → AE.AEHOSP
AE.AEOCCUR
28
QC Process
• Evaluate if the structure is CDISC complaint and HelsinnSDTM requirements are fullfilled– SAS programming: PROC IMPORT of Excel datasets
specifications, PROC CONTENTS of SDTM, compare, report of inconsistencies (variable name, label, length)
– PROC CDISC: SDTM version 3.1 (but we are using 3.1.1!)
• Manual review of documentation/algorithm, FDA requirements, Annotated CRF
29
Benefit
• Facilitate electronic submissions preparation: – No need to reformatting data– ISS easily performed (but integration of old studies very
demanding)– Define.pdf document created quickly and easily– No question from FDA about data
• Efficient CRF design • Process of dealing with CROs simplified by supplying
clear data specification• Clear documentation of the data process: from CRF to
analysis• High level of quality• Efficient data review • Increase SAS programming re-use within the company
30
Lessons learned• Feasibility: standardization is easier for a small company• Timelines: needed additional time for setting SDTM for
the first studies but efficiency in the subsequentimplementation
• Standardization is an ongoing process• Solid internal know-how is key of success: keep up to
date about CDISC enhancement• Flexibility may be applied for Phase I studies• New processes implemented and new SOPs are needed• Improve efficiency throughout standardization is a
company process: work with Clinicians and Regulatory Department
31
Lessons learned: interacting with CROs
• Provide detailed CDISC mapping specifications
• CDISC CRO know-how: select provider able to deliver data on SDTM compliant sturcture– Low level may have a large impact in the activity– Investigate CDISC know-how from first CRO contact– High level: good and proactive collaboration and efficient process
• Clear definitions of expectations and sponsor/CRO involvment
• Frequent interaction with CRO during mapping/implementation: – Clarifications needed, exceptions to be discussed– Interim data transfer to verify data structure– Establish a rigorous QC process
• Leave CROs free to decide where to implement the CDISC models
32
Next Steps• Focus on ADaM implementation
• Be ready for eCTD– Expertise in XML– Preparation of Define.xlm– Tools to QC the submission package
• Standards for non-clinical data– FDA requirements for submission of non-clinical data– CDISC SEND: evaluate feasibility
• Create new standard CRF forms / datasets– Evaluate impact of new SDTM version, CDASH project and Controlled
Terminology
• What else may be standardized?– Third parties (Central Lab, ECG providers) data transfer – SAS programs/macros to check the data quality before db lock – Definition of Standard Logical Checks (Data Validation Plan) – Standardize TLF formats
