Italian-Speaking

CDISC User Group 2008

Implementation of SDTM
in a pharma company with
complete outsourcing strategy

Annamaria Muraro
Helsinn Healthcare
Lugano, Switzerland

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
2

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
3

What needs to be standard?

STANDARD
ECG

CRF

Lab

Other

CDMS

Paper
CRF

STANDARD

STANDARD

STANDARD

SAS
Analysis
Datasets

SAS
Raw Data

Statistical
Analysis &
Data Listings

STANDARD
Study
Report

Protocol

STANDARD

Helsinn
Clinical
Storage
Area

Submission

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

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
6

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 for
pilot studies
7

MAPPING

Mapping: pilot studies

Jan 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

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
10

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

11

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 each

parameter

PK Dictionary: short and long name for each

parameter
12

13

Variable metadata

LENGTH
(not required by FDA)

LIST OF TERMS

COMMENTS
AND NOTES

According to
the CRF

ADDITIONAL NOT
CDISC VARIABLES

14

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 define
lab 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)
15

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
16

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

17

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

18

Study specific issues

Cancer history mapping
MH.MHCAT

MH.MHTERM
MH.MHSTDTC

SUPPMH.QVAL
where QNAM=EXTENT
SUPPMH.QVAL
where QNAM=SITE1

19

IMPLEMENTATION

20

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: process
traceability

21

CRF, SDTM
and Annotated CRF

22

Mapping CRFs to CDISC SDTM

April 2006-August 2006

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
23

Annotated CRF

Due to the variety in CRF Annotation, specifications

about Annotated CRF included in the Helsinn Standard
Library
24

Demography
Assigned value
DS.DSTERM="INFORMED CONSENT OBTAINED" (DS.DSCAT=PROTOCOL MILESTONE)

INFORMED CONSENT
DS.DSSTDTC
Informed Consent Signature Date

dd

mmm

yyyy

Dataset

Variable name

DEMOGRAPHY
Gender

Male

Female

DM.SEX

DM.BRTHDTC
Date of Birth
dd

mmm

yyyy

DM.RACE
Race

1
2
3
4
9

White
Black
Hispanic
Asian
Other

Where condition

SC.SCORRES (SC.SCTESTCD="RACEOTH")
Specify

________________________________

25

Medical History
MEDICAL HISTORY

MH.MHCAT="MEDICAL HISTORY"

Does the subject have any significant medical history?

Yes

No

If Yes, complete this section

MH.MHOCCUR
Disease
(prior and/or concomitant)
1.

MH.MHTERM

Ongoing
Date of Diagnosis

MH.MHSTDTC
mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

mmm

yyyy

Yes

No

(1)

(2)

MH.MHENRF

2.

3.

4.

5.

6.

7.

8.

9.
10.

26

Adverse Event
ADVERSE EVENT

AE.AEOCCUR

Has the subject experienced any adverse events?

If Yes complete this section

Yes

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

Serious

1 single episode
2 intermittent

1 Yes (*)
2 No

Intensity

Relation to
study drug

1 Mild
2 Moderate
3 Severe

1 Not related
2 Unlikely
3 Possible
4 Probable
5 Definite
6 Unassessable

AE.AESER

AE.AEREL

Action taken

Outcome

(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

1 Recovered
2 Recovering
3 Recovered with
sequelae
4 Not recovered
5 Death
9 Unknown

1.
Start

AE.AESTDTC
dd

AE.AETERM
Stop

mmm

yyyy

AE.AEENDTC
dd

mmm

yyyy

dd

mmm

yyyy

AE.AEPATT
AE.AESEV

AE.AEOUT

2.
Start
Stop
dd

mmm

yyyy

dd

mmm

yyyy

dd

mmm

yyyy

3.
Start
Stop

1, 2, 3, 4 4 AE.AEACN
2
5 5 AE.AECONTR
3
6 6 AE.AEHOSP
1

If the Event is serious, fill in a Serious Adverse Event Report

27

QC Process
Evaluate if the structure is CDISC complaint and Helsinn
SDTM 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

28

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
29

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 subsequent
implementation
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
30

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

31

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
32

Thank you!

Annamaria Muraro
Helsinn Healthcare,
Lugano Switzerland
amu@helsinn.com

33