2009 Ohsug Considerations for an Sdtm Compliant Study Definition

8/22/2019 2009 Ohsug Considerations for an Sdtm Compliant Study Definition

http://slidepdf.com/reader/full/2009-ohsug-considerations-for-an-sdtm-compliant-study-definition 1/26

2009 Annual ConferenceNew Orleans, LA

Considerations for an SDTMCompliant Study Definition

Steven Rifkin

Sr. Director of ConsultingBioPharm Systems



Oracle Clinical and the SDTM

Topics

• History of the SDTM

• Horizontal Collection vs. Vertical Reporting• Variable Names

• Date Formats




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 improvemedical research & related areas of healthcare

http://www.cdisc.org




CDISC Models

Acronym Title Use

Clinical Data Acquisit ion

Standards Harmonization

Data

CollectionStudy Data Tabulation Model Content

Analysis Dataset Model Content

Case Report Tabulation Data

Definition Specification

Metadata

ODM Operational Data Model Format

LAB Clinical Laboratory Model Content

PRG* Protocol Representation

Group

Content

BR

I

D

G/

H

L

7*

SDTM

ADaMDefine.xmlCRT-DDS

CDASH

* under development




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


http://slidepdf.com/reader/full/2009-ohsug-considerations-for-an-sdtm-compliant-study-definition 6/26Oracle Clinical and the SDTM

SDTM IG 3.1.2

http://www.cdisc.org/standards/index.html



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

H t C t



Horzonta Co ecton vsVertical Reporting

• SDTM Domains are modeled (and reported)

in a vertical manner– In many cases, this structure can be easilymodeled using OC Repeating Question groups

• CM, AE and PE domains are examples

– In other cases, this vertical reporting structureleads to difficulties if OC repeating Questiongroups are used

• VS Domain is an example to be discussed here



VS Domain in the SDTM

USUBJ ID VSTESTCD VSPOS VSORRES VSORRESU

100 SYSBP STANDING 120 mmHg

100 DIASBP STANDING 80 mmHg100 PULSE 55 BEATS/MIN100 HEIGHT 210 LB100 WEIGHT 69 IN

• Simplified VS Domain Structure

• Indicates individual records for each VS finding

even though two findings may be related



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 labdata

• Default extract view mimics the way the SDTM

reports

So what’s the problem?

V t OC M SDTM



Vertca OC as Mo e or SDTMVS 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 moredifficult to create



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 thecollection QG to the reporting QG

– Place both in a single DCM



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”

C t t R t D t



Co ecton to Reportng DervatonProcedure

• Could create a procedure for a standard VSdomain

– Assumes the names of the fields in the collectionDCM and the repeat number into which this fieldwill be derived

• Could create a more general routine with adatabase package and assumptions

– E.g. assumptions like collection question namewill be the same as the TESTCD in the reportingQG, names of subsidiary questions in HELP text



Extract Views for Two QG Solution

• Will get two default extract views

– The non-repeating “collection” view can bedropped or ignored

– The repeating “reporting” view can be used forthe submission



SAS Names …

• Many SDTM Variables have an 8 character length

• OC supports using 8 characters, but, usually, it isnot recommended to use 8

– Extended attributes could add one character at end andmultiple occurrences of a question will add another

– If name is 8 (or at eight because of additional extendedattribute character) will not be able to create multipleoccurrences

• SDTM uses multiple occurrences only in the CODomain, so not usually a problem

• Extended Attributes could cause problems



SAS Names …

• The Extended attributes are created whenthe Global Library Question is created.– If length of SAS Name is 8, the last character of

the name is truncated and the extendedattribute 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

SAS N




SAS Names:Solutions

• Make sure the extended attributes are notpart 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




Date Formats …

• Oracle Clinical stores and reports dates inthe YYYYMMDD format– Time is collected as separate variable in

HHMMSS format (Military)

– Partial dates and times are possible

• SDTM requires dates in the ISO 8601format YYYY-MM-DDThh:mm:ss andreported as __DTC variables in the domains

• Differences in how “missing significant” datais recorded– Unknown year is possible in SDTM but not in OC




Date Formats: Solution

• Use a database package to convert from 2OC fields to a single __DTC field for theSDTM

• Package can include use of a third input

AM/PM so that military time need not beused in OC




Some good things

• Copy Groups

– Make its easy to create all Domain objects in asingle group and copy “standard” to target study

• RDC

– Might make some entry considerations forHorizontal vs Vertical easier to handle




Summary

• SDTM and other CDISC Standards areevolving

• Modeling a completely compliant submissionin OC can be problematic

• Workarounds exist for some of the commonproblems to reduce amount of postprocessing




Acknowledgements

Prof. Dr. Jerry Welkenhuysen-Gybels

[email protected]

Nico De Leeuw

[email protected]




Contact Information

Steve Rifkin

Biopharm Systems908 822 [email protected]

mailto:[email protected]

mailto:[email protected]




?



O l Cli i l d th SDTM

Steve Rifkin has almost 14 years of experience working with theOLS Product Suite. As an Functional Consultant, and then as a

Practice Manager with Oracle Consulting in the Oracle ClinicalGroup, Steve has assisted over 60 companies with implementationof Oracle Clinical, RDC and TMS. He has led the implementationprocess and has provided training and performed custom coding.

Since joining Biopharm Systems in 2000, Steve has beenresponsible for developing Oracle Clinical training courses, andproviding training and implementation services for Biopharmclients.

Documents

2009 Ohsug Considerations for an Sdtm Compliant Study Definition