2013 OHSUG - Facilitating Pharmacovigilance Globalization with Process Reengi...
Considerations for an SDTM Compliant Study Definition
1. 2009 Annual Conference
New Orleans, LA
Considerations for an SDTM
Compliant Study Definition
Steven Rifkin
Sr. Director of Consulting
BioPharm Systems
2. Topics
• History of the SDTM
• Horizontal Collection vs. Vertical Reporting
• Variable Names
• Date Formats
Oracle Clinical and the SDTM
3. CDISC Organization
• Clinical Data Interchange Standards
Consortium
– CDISC started in 1999
– Is a non-profit organization
– Data models are created by industry volunteers
– Mission: to develop & support global, platform-
independent data standards that enable
information system interoperability to improve
medical research & related areas of healthcare
http://www.cdisc.org
Oracle Clinical and the SDTM
4. CDISC Models
Acronym Title Use
Clinical Data Acquisition Data
B CDASH
Standards Harmonization Collection
R
Study Data Tabulation Model Content
I SDTM
D
Analysis Dataset Model Content
G ADaM
/ Case Report Tabulation Data Metadata
H Define.xml
CRT-DDS Definition Specification
L
7* ODM Operational Data Model Format
LAB Clinical Laboratory Model Content
PRG* Protocol Representation Content
* under development Group
Oracle Clinical and the SDTM
5. SDTM
• Study Data Tabulation Model
• Goal:
– Define a global standard for study data
tabulations
– Standardize regulatory submissions
– Currently, de facto standard between the CROs
and sponsors
• Focus on study data tabulation content
• Requested by FDA for all submissions
http://www.cdisc.org/models/sds/v3.1/index.html
Oracle Clinical and the SDTM
6. SDTM IG 3.1.2
http://www.cdisc.org/standards/index.html
Oracle Clinical and the SDTM
7. SDTM Model History
• 2001: Submission Data Domain Models Version 1.0
• 2002: Submission Data Domain Models Version 2.0
– Well received by industry
– Major shortcomings (focus on safety domains only)
• 2003: Submission Data Domain Models Version 3.0
– Standard for all clinical trial data
– Based on data modeling (e.g. events, interventions and findings)
• 2004: SDTM 1.0 - SDTM IG 3.1
– First version intended for implementation
• 2005: SDTM 1.1 - SDTM IG 3.1.1
– Enhancements resulting from FDA/industry pilot testing
• 2009: SDTM 1.2 - SDTM IG 3.1.2
– Major enhancements, expanded model
Oracle Clinical and the SDTM
8. Horizontal Collection vs
Vertical Reporting
• SDTM Domains are modeled (and reported)
in a vertical manner
– In many cases, this structure can be easily
modeled using OC Repeating Question groups
• CM, AE and PE domains are examples
– In other cases, this vertical reporting structure
leads to difficulties if OC repeating Question
groups are used
• VS Domain is an example to be discussed here
Oracle Clinical and the SDTM
9. VS Domain in the SDTM
USUBJID VSTESTCD VSPOS VSORRES VSORRESU
100 SYSBP STANDING 120 mmHg
100 DIASBP STANDING 80 mmHg
100 PULSE 55 BEATS/MIN
100 HEIGHT 210 LB
100 WEIGHT 69 IN
• Simplified VS Domain Structure
• Indicates individual records for each VS finding
even though two findings may be related
Oracle Clinical and the SDTM
10. Modeling the VS Domain in OC
• Could create a “vertical” structure in OC
– Questions for VSTESTCD, VSPOS, VSORRES etc
– Put these questions in a Question Group
– Make the Question Group repeat
• Supply repeating defaults
• Similar to LPARM, LVALUE model for normalized lab
data
• Default extract view mimics the way the SDTM
reports
So what’s the problem?
Oracle Clinical and the SDTM
11. Vertical OC as Model for SDTM
VS Domain: Difficulties
• Awkward Data Entry
– Physicians used to entering 120/80 as one measurement
not two
• Can be somewhat minimized in RDC Graphic Data Entry and
training DE for Paper Studies
• Limit utility of OC Univariate Discrepancies
– The univariate checks can not vary with each repeat – e.g.
different high/low limits for sysbp and diasbp
• May be able to write a complex multivariate to accomplish
this however
• Validation checks between repeats are more
difficult to create
Oracle Clinical and the SDTM
12. Solutions
• Model Horizontal and reformat in extract
view definitions
• Model Horizontal and post-process in SAS
• Create a Collection QG (horizontal) and a
Reporting QG (vertical) for the vital signs
– Entry into the Collection QG all normal univariate
checks and “easy” multivariate
– Use a derivation routine to derive data from the
collection QG to the reporting QG
– Place both in a single DCM
Oracle Clinical and the SDTM
13. Two Question Groups for Vital Signs
• Horizontal
– Typical non-repeating QG with Normal OC
functionality and layouts
• Vertical
– Create a repeating question group with the
SDTM questions like VSTESTCD, VSORRES, etc.
– Use protected repeating defaults for VSTESTCD
and VSTEST (cannot make these fields not
displayed)
– Make other questions in this question group
“non-displayed”
Oracle Clinical and the SDTM
14. Collection to Reporting Derivation
Procedure
• Could create a procedure for a standard VS
domain
– Assumes the names of the fields in the collection
DCM and the repeat number into which this field
will be derived
• Could create a more general routine with a
database package and assumptions
– E.g. assumptions like collection question name
will be the same as the TESTCD in the reporting
QG, names of subsidiary questions in HELP text
Oracle Clinical and the SDTM
15. Extract Views for Two QG Solution
• Will get two default extract views
– The non-repeating “collection” view can be
dropped or ignored
– The repeating “reporting” view can be used for
the submission
Oracle Clinical and the SDTM
16. SAS Names …
• Many SDTM Variables have an 8 character length
• OC supports using 8 characters, but, usually, it is
not recommended to use 8
– Extended attributes could add one character at end and
multiple occurrences of a question will add another
– If name is 8 (or at eight because of additional extended
attribute character) will not be able to create multiple
occurrences
• SDTM uses multiple occurrences only in the CO
Domain, so not usually a problem
• Extended Attributes could cause problems
Oracle Clinical and the SDTM
17. SAS Names …
• The Extended attributes are created when
the Global Library Question is created.
– If length of SAS Name is 8, the last character of
the name is truncated and the extended
attribute character is added to name the
extended attribute
• Problems occur when the extended attribute
character added is the same as the last
character removed
• Problem doesn’t appear until the views are
actually generated
Oracle Clinical and the SDTM
18. SAS Names:
Solutions
• Make sure the extended attributes are not
part of the view definition
– Usually not part of the SDTM submission
anyway, although may be useful for analysis
• Change the name of the extended attribute
in the view definition
– Can run a SQL statement to indicate where there
are duplicate column names and change just
these names
• Change the Extended Attribute names in the
GLib
Oracle Clinical and the SDTM
19. Date Formats …
• Oracle Clinical stores and reports dates in
the YYYYMMDD format
– Time is collected as separate variable in
HHMMSS format (Military)
– Partial dates and times are possible
• SDTM requires dates in the ISO 8601
format YYYY-MM-DDThh:mm:ss and
reported as __DTC variables in the domains
• Differences in how “missing significant” data
is recorded
– Unknown year is possible in SDTM but not in OC
Oracle Clinical and the SDTM
20. Date Formats: Solution
• Use a database package to convert from 2
OC fields to a single __DTC field for the
SDTM
• Package can include use of a third input
AM/PM so that military time need not be
used in OC
Oracle Clinical and the SDTM
21. Some good things
• Copy Groups
– Make its easy to create all Domain objects in a
single group and copy “standard” to target study
• RDC
– Might make some entry considerations for
Horizontal vs Vertical easier to handle
Oracle Clinical and the SDTM
22. Summary
• SDTM and other CDISC Standards are
evolving
• Modeling a completely compliant submission
in OC can be problematic
• Workarounds exist for some of the common
problems to reduce amount of post
processing
Oracle Clinical and the SDTM
23. Acknowledgements
Prof. Dr. Jerry Welkenhuysen-Gybels
jerry.welkenhuysen@businessdecision.com
Nico De Leeuw
nico.deleeuw@businessdecision.com
Oracle Clinical and the SDTM
24. Contact Information
Steve Rifkin
Biopharm Systems
908 822 0553
srifkin@biopharm.com
Oracle Clinical and the SDTM
26. Steve Rifkin has almost 14 years of experience working with the
OLS Product Suite. As an Functional Consultant, and then as a
Practice Manager with Oracle Consulting in the Oracle Clinical
Group, Steve has assisted over 60 companies with implementation
of Oracle Clinical, RDC and TMS. He has led the implementation
process and has provided training and performed custom coding.
Since joining Biopharm Systems in 2000, Steve has been
responsible for developing Oracle Clinical training courses, and
providing training and implementation services for Biopharm
clients.
Oracle Clinical and the SDTM