a brief history of cdisc implementation stephen harrisonportal.cdisc.org/cdisc user...
Post on 28-Feb-2018
234 Views
Preview:
TRANSCRIPT
AZ CDISC Implementation
A brief history of CDISC implementation
Stephen Harrison
2
Overview
� Background
� CDISC Implementation Strategy
� First steps
� Business as usual
� ADaM or RDB?
� Lessons learned
� Summary
3
Background
� Seven R&D sites all operating
in their own environments
� Creating and maintaining
similar tools across the R&D
sites
� Continuous duplication of effort
across regions
4
A&RT Initiative
� Project initiation – April 2003
� Objective: Harmonise the A&R
process and environment across ALL R&D sites within AZ
� Multiple workstreams looking at
technology, process and standards
� Reporting Database (RDB) w/stream
� Deliver standardized reusable code or macros to automate production of analysis and report ready datasets
5
Data Flow Process
� Previous data flow process was a simple route from existing CRFsto Clinical Study Reports/Higher Level Document outputs
� Reporting Database is created directly from the Module Package
� Remit of project was to use existing internal data standards
� Opportunity to implement CDISC standards
Analysis
Datasets/
RDB
Module
Package
RAW
Data
CSR/
HLD
Output
CRFs
6
CDISC Implementation Strategy
� RDB completely described in terms of SDTM source – good for reviewer
� No need to construct SDTM at the end of the process
Analysis
Datasets/
RDB
Module
Package
RAW
Data
CRFs
CSR/
HLD
Output
SDTM
7
CDISC Implementation Strategy
Analysis
Datasets/
RDB
Module
Package
RAW
Data
CRFs
CSR/
HLD
Output
SDTM
� RDB completely described in terms of SDTM source – good for reviewer
� No need to construct SDTM at the end of the process
� Linear process fulfils the requirement of traceability
8
Longer term strategy
Analysis
Datasets/
RDB
Module
Package
RAW
Data
CRFs
CSR/
HLD
Output
SDTM
New
CRFs/
CDASH
Modified CRFs
� Underlying RAW data standards are SDTM friendly
� Transformation process is simplified
� CDASH - Clinical Data Acquisition Standards Harmonization
9
Longer term strategy
Analysis
Datasets/
RDB
Module
Package
RAW
Data
CRFs
CSR/
HLD
Output
SDTM
New
CRFs/
CDASH
ADaM
� Adopt ADaM model, replacing internal data standards
� Utilise industry standard transformation and derivation processes
ADaM
10
First steps
� Global team set up August 2005 to specify AZ business rules
� Application of SDTM Implementation Guide v3.1.1 from an AZ point of view
� Two team members also part of CDISC SDS team
� Inside track to SDTM
� Scope - all corporate and TA standard modules (>200)
� Mapping exercise took nearly 18 months to complete!
11
Manual mapping document
12
Business as usual
� Web Interface developed
� Metadata driven process
� RAW to SDTM and SDTM to RDB mapping function
� Inherit Corporate data standards and maps down to project or study
level
� Metadata used by “code builder” to create executable code
13
Windows
PMPL
Data Standards
A&RTApplication
Database
Datasets Variables
RAW Data Metadata
Study
Project Import
A&RT Web Interface
Variables
Dataset
Variables
Dataset
CSV file
14
Standards and Reuse of Code
Corporate
Therapy Area
Project
Study
• Data standards
• Mappings
• Data standards
• Mappings
• Data standards
• Mappings
• Data standards
• Mappings
•Locked dataset definitions
•Locked Corporate map
•Locked dataset definitions
•Locked TA map
•Locked dataset definitions
•Locked Project map
15
Inheritance – SDTM
RAW Metadata
Study 2Study 1
TA (Respiratory)
Corporate
RESPHIS
DEM
AELOGDEM DEM
AELOG
Project
RESPHISDEM
HISM
RESPHIS
AELOG
PULM
PULMAELOG
SDTM Metadata
Corporate
DM AE MH
PF CF
mapping
Project
DM AE MHPF CF
PULM
Study 1
DM AE
Study 2
DM AE
MHPF CF
16
Example RAW – SDTM map
17
Define Simple Mapping
18
Define Macro Mapping
19
Transposition Groups
20
A&RT Application DatabaseWeb
Interface
(Oracle)
UNIX
(SAS)
SDTMDatabase
RAWDatabase
ReportingDatabase
Program Builder
Execute job
SAS code
Execute job
SAS code
Load
RAW
Data
Import
RAW
Data
Metadata
Create Mapping Metadata
SDTM � RDB
Create Mapping Metadata
RAW � SDTM
A&RT Mapping Process
21
ADaM or RDB?
� Well established reporting requirements
� AZ Reporting Database standards defined and in use before CDISC considered
� Perception that ADaM model still quite unstable and subject to significant change
� Unlike SDTM, no regulatory pressure to implement ADaM
22
Reporting Database
RAWModulePackageDatasets
Etc…
WBDC LAB
GRand
AMOS
CROSDTMData
Domains
SupplementalQualifiers
UnalteredSource
Datain SDTMformat
Su
pp
lem
en
tal
Qu
alifi
ers
Ke
y I
D V
ari
ab
les
DerivedVariables
DerivedObservations
Study Database
(RAW Data) Mapping toSDTM
Reporting Database
Deri
ved
Vari
ab
les
Superset New Dataset
+
R_AE
R_DM
R_VS
Etc.
RD_xx
RH_xx
Etc.
23
Reporting Datasets (R_)
� Datasets must remain fundamentally unchanged from the SDTM source data. An R_ dataset is a superset of the SDTM dataset
SDTM RDB
� Original SDTM dataset name retained, but prefixed with R_
� All information from SUPP-- datasets re-attached to parent RDB dataset
Observations
R_VS
(Superset)
VS VS
Su
pp
VS
SuppVS
Vari
ab
les
24
RDB General Conventions
� All reporting must take place directly from Reporting Database defined at study level
� All variables used for reporting must be created in relevant reporting dataset
� Subject datasets must have at least 1 observation per randomized subject
� All SDTM data must be present in Reporting Database
� Original SDTM data cannot be amended, but new variables or observations can be created as needed (e.g., imputing dates)
� All naming conventions defined by SDTM must be followed when generating additional variables
25
RDB Common Dataset Features
� Datasets taken from source database – name prefixed with R_ (e.g., DM becomes R_DM)
� New derived datasets – name prefixed with RD_(e.g., RD_SUBJ)
� Transposed datasets – name prefixed with RH_ (e.g., R_LB becomes RH_LB)
� Datasets must contain Key variables to uniquely identify every observation
� Duplication of variables across multiple datasets should be avoided (except for Key and Cross variables)
� Duplication of source (SDTM) variables should be avoided
� Variables defined at a higher level must not have attributes changed, except in the following circumstances:
� Length may be increased
� Algorithm may be project-specific
26
RDB Use of Codes and Decodes
� Historically, codes and decodes used widely
� Associated using SAS formats
� Loses all meaning outside of SAS
� SDTM does not use codes and decodes
� Variables defined using explicit text values to describe observations
� Clear, unambiguous and interpretable irrespective of the tools or software used
� RDB based on SDTM
� Codes and decodes not used in final reporting datasets
27
Transposed Datasets
� RAW datasets may be transposed to contain re-structured RAW data (e.g., RH_dataset = horizontal structure, RV_dataset = vertical)
� Normally only considered for Findings domains
� Original dataset must still exist as R_dataset
� May make reporting easier (e.g., lab parameters reported as columns)
28
Transposed Datasets
� Carefully consider whether transposed data is essential and/or appropriate
� Duplicates data
� Variable names driven by --TESTCD can be meaningless, e.g.,:
� Significant loss of information
� e.g., original results, units, reference ranges, analysis flags,etc.
� Contravenes CDISC SDTM convention to store units as a separate variable qualifier to the test result
Unique
subject
Identifier
Visit
name
Alanine
Aminotranferase
(ukat/L)
Albumin
(g/L)
Alkaline
Phosphotase
(ukat/L)
Aspartate
Aminotranferase
(ukat/L)
USUBJID VISIT L01101 L01118 L01104 L01102
29
Example SDTM to RDB map
30
Lessons learned
� Mapping takes a lot of effort!
� Ambiguity in guidance
� Individual opinions and interpretations
� Get your conventions right
� Often had to revisit decisions as experience grew
� Big differences between CRF and SDTM standards:
� Purpose: data collection vs. data storage
� Coding: codes vs. text(e.g., 1, 2, 3 vs. mild, moderate, severe)
� Structure: horizontal vs. vertical
� SDTM IG v3.1.2 a big improvement
� Introduction of Clinical Findings (CF) domain really helped with many difficult mappings
31
Changes for SDTM IG v3.1.2 – CF
General Observation ClassesSpecial Purpose
Datasets
Interventions Events Findings Demographics
Comments
Related
Records
Supplemental
Qualifiers
Trial Design
Clinical Findings (CF) Domain
� Findings about Events or Interventions that don’t fit
in SDTM domain variables for those classes
� CFOBJ (Object of Measurement): Event or
Intervention that is the subject of the test evaluation
� Mandatory, but won’t necessarily have a
parent record in another domain
32
MHTERM MHOCCUR MHPRESP
MHSTDTC
MHCAT
Changes for SDTM IG v3.1.2 – CF
33
CFOBJ
CFTESTCD = OCCUR
CFORRES = answer provided in checkbox
CFCAT
Changes for SDTM IG v3.1.2 – CF
34
CFOBJ
CFTEST
CFORRES
CFCAT
Changes for SDTM IG v3.1.2 – CF
35
ExampleRow USUBJID CFSEQ CFOBJ CFTEST CFTESTCD CFDTC
1 D06-608-123 1 HYPERTENSION OCCURRENCE OCCUR 2006-08-28
2 D06-608-123 2MYOCARDIAL
INFARCTIONOCCURRENCE OCCUR 2006-08-28
3 D06-608-123 3MYOCARDIAL
INFARCTION
DATE OF MOST
RECENT MIMY_LDAT 2006-06-20
4 D06-608-123 4MYOCARDIAL
INFARCTIONNUMBER OF MI MYNO 2006-08-28
Row USUBJID VISITNUM CFORRES CFSTRESC CFCAT
1 D06-608-123 1 CURRENT CURRENTSPECIFIC CV MEDICAL AND
SURGICAL HISTORY
2 D06-608-123 1 PAST PASTSPECIFIC CV MEDICAL AND
SURGICAL HISTORY
3 D06-608-123 1 2006-06-20 2006-06-20SPECIFIC CV MEDICAL AND
SURGICAL HISTORY
4 D06-608-123 1 2 2SPECIFIC CV MEDICAL AND
SURGICAL HISTORY
(continued)
Changes for SDTM IG v3.1.2 – CF
36
Summary
� CDISC Implementation is a huge
task
� AZ strategy allows for step-wise
implementation
� CDASH
� ADaM
� Mapping tool really assists process
� Easy inheritance
� Reuse of standards and code
� SDTM IG v3.1.2 big improvement
37
Questions and Answers
38Thank You
top related