SDTM FILE SIZE ISSUE (SAS LENGTH)

CJUG LISaS Learning Industry Standard around SDTM

14th September 2012

Version 1.0

1

はじめに

• 本スライドはSDTM IG v3.1.3で新たに追加された“4.1.2.9 - VARIABLE LENGTHS”の記述について、背景理解と解釈・今後の対策などについてまとめたものです。なお、2012年8月末時点での情報を元に検討しており、9月以降は変わっている

可能性があります。また、内容についての保証はないことにご注意ください。

• Some of the views and opinions expressed in this presentation are those of the individual discussion member and should not be attributed to the organization by which the member is employed.

2

背景

3

SDTMにおけるSAS Lengthの規定

• SDTMで変数のLengthは規定されていない

• XPTファイルの要件上、最大値は200

• しかしながら、一部の変数のみ制約が示されている • ARMCD, ACTARMCD: max 20

• Y/N flags (例：--FL, AESER, IEORRES): 1

• --TESTCD, ETCD, --PARMCD, QNAM , IDVAR: max 8

• --TEST, --PARM, QLABEL: max 40

（これらはXPTの変数およびLabelの上限と一致している、転置を想定）

VSTESTCD VSTEST VSORRES

SYSBP Systolic Blood

Pressure 150

DIABP Diastolic Blood

Pressure 45

SYSBP DIABP

150 45

Variable Label=“Diastolic Blood Pressure”

eDC Raw data

SDTM

4

事の発端

• SDTM Column Resizing: Background and Industry Testing Results; Electronic Data (eData) Team, CDER FDA, October 13, 2011

• 2010年1月～2011年2月に扱った565試験のうち20試験を抽出、432データセットを使って調査

• SDTM（SAS V5.xpt）の各変数のLengthを、「データの中身に合わせた最大長」で作り直したところ、平均70%、最大で90%ファイルサイズが減った

• SAS V5.xpt形式のSDTMは、ファイルサイズが大きすぎる！ということが分かった

Ref: http://www.cdisc.org/stuff/contentmgr/files/0/4f05d8426369051905a247002c87e38e/files/dhananjay_chhatre__session_9.pdf

5

データの中身に合わせた最大長？

① RACEにおいて、CRFに以下の5カテゴリがあるとする • BLACK OR AFRICAN AMERICAN (25byte)

• AMERICAN INDIAN OR ALASKA NATIVE (32byte)

• ASIAN (5byte)

• NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER (41byte)

• WHITE (5byte)

② 結果的に白人しか組入れされなかった場合、データの中には”WHITE”しか存在しない

③ 変数RACEのSAS-XPTのLengthは”5”となる

• CRFにSetされた最大長41ではない

• SDTM, XPTの最大長200ではない

• 社内標準で規定された最大長 xxxではない

6

試行 • SDTM IG v3.1.2+Amendment / Permissible variablesのうち7割を使用（CDISC Controlled Terminology フル使用） • Pattern 1: ARMCDやFlagなど規定されている文字変数以外は全て$200

• Pattern 2: 社内標準やデータ上取りうる最大値を確保（例：日時変数は$20、CRFでSetされたCDISC Controlled Terminologyの最大）

• Pattern 3: データの最大長のLengthを使用

Domain Subject *

Test * Visit Record Pattern 1 Pattern 2 Pattern 3

DM 30 30 129KB 19KB 11KB

DM 200 200 832KB 98KB 47KB

LB 30*25*2 10000 28.7MB 5.98MB 2.44MB

LB 500*25*8 100000 287MB 59.7MB 22.0MB

Note: FDAはZIP等によるXPTファイルの圧縮を許容していない（Study data Specifications v2.0） また、SASのCOMPRESSオプションは、XPTファイルでは使用できない

7

続いて • FDA CDER Common Data Standards Issues Document (Version 1.1/December 2011) • Quote:

"Column Length/Size; For both CDISC and non-CDISC datasets, in order to significantly reduce dataset file sizes, the allotted character variable length/size for each column in a dataset should be the maximum length used. Lengths/Sizes of columns should not arbitrarily be set to 200, For example, if your USUBJID column has a maximum length of 18 being used throughout the dataset, the USUBJID’s column size should be set to 18, not to 200. Alternative solutions to this problem that involve some inclusion of a small amount of padding to column width may be acceptable as long as they don’t result in significant increases in file size due to the padding.”

“Dataset Splitting; If datasets are greater than 1 gb in size, please split the datasets into smaller datasets no larger than 1 gb in size“

• ファイルサイズの上限は”1GB”

• ファイルサイズを減らすために、使った分だけのLengthがよい • ただし、サイズの増加に顕著な影響を及ぼさない場合は＋αが許されるとも

Ref: http://www.fda.gov/downloads/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/UCM254113.pdf

CDISC標準を考慮した、データ構造に特化したBest Practice

(2011～)

8

SDTM IG v3.1.3 / 15 July 2012

• Quote: “4.1.2.9 - VARIABLE LENGTHS”; Very large transport files have become an issue for FDA to process. One of the main contributors to the large file sizes has been sponsors using the maximum length of 200 for character variables. To help rectify this situation:

The maximum SAS Version 5 character variable length of 200 characters should not be used unless necessary.

Sponsors should consider the nature of the data, and apply reasonable, appropriate lengths to variables. For example:

The length of flags will always be 1 --TESTCD and IDVAR will never be more than 8, so length can always be set to 8 The length for variables which use controlled terminology can be set to the length of the longest term.

• ファイルサイズ増大の原因の1つは200バイトのLength

• 必要でないとき以外は使わない

• 適切な処置をとること、例：フラグは1, --TESTCDとIDVARは8, その他Controlled terminologyを使うものはその最大値

9

SDTM IGの解釈

• SDTM v3.1.3に記載のある“The length for variables which use controlled terminology can be set to the length of the longest term.”

をどのように解釈し、Lengthを決めればよいか？ どのような影響があるか？

A) 社内標準で用意されているもの or SDTM IGで推奨されている最大値（例：ARMCD=20）

B) CRFにSetされたもの

C) 実際に得られたデータ

• ファイルサイズは C) ≦ B) ≦ A) となる

• 他に検討すべき要因はないか？

10

FDA Study Data Specifications v2.0 18 July 2012

• Quote: “2.4 Sizing of Columns; For all datasets, in order to significantly reduce dataset file sizes, the allotted character column length/size for each column should be the maximum length used. Lengths/sizes of columns should not arbitrarily be set to 200. For example, if USUBJID has a maximum length of 18, the USUBJID’s column size should be set to 18, not 200. An inclusion of a small amount of padding to column width may be acceptable as long as this doesn’t result in significant increases in file size. “

• CDER Common Data Standards Issues Document

(Version 1.1/December 2011) からの引用に近い • しかしながら、文書の性質上、強制力は上がったといえる

Ref: http://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM312964.pdf

CDISC標準かどうかに限定しない、データを提出する際の総則 (2004～), Annotated CRFやフォルダ構造含む

11

Submissionを通じてLengthは一致していないといけない? • CDER Common Data Standards Issues Document

• Quote: “Datasets should be resized to the maximum length used prior to splitting. This will ensure split datasets have matching variable lengths for future merges.

• LB Domain (Laboratory); The size of the LB domain is often quite large and can exceed the reviewers’ ability to open the file using standard-issue computers. This size issue can be addressed by splitting the large LB dataset into smaller data sets according to LBCAT and LBSCAT, using LBCAT for initial splitting.”

• FDAの公式的な見解では、Split datasets（例; Hematology LB + Chemistry LB + Urinalysis LBなど、--CATなどで分割することを意味する）においては、Lengthは一致していないとならない

• SASやJReview/WebSDMで結合した際には、1つ目にロードしたデータセットの変数のlengthに、2つ目以降が依存してしまう（データが欠落する恐れがある）という問題がある

• 拡大解釈により、潜在的にはDomain間のデータも含まれる（例：USUBJID）

• しかし、Submission内の複数試験で一致させる必要があるとの記述はない

12

SDTM IG (v3.1.2 & v3.1.3)では

• 4.1.1.7 SPLITTING DOMAINS • Quote: “Sponsors may choose to split a domain of topically related information

into physically separate datasets.

（中略）

• 5) Variables of the same name in separate datasets should have the same SAS Length attribute to avoid any difficulties if the sponsor or FDA should decide to append datasets together.”

• SDTM IGに記載されている”SPLITTING DOMAIN”の章は、ファイルサイズが原因で分割することは意図していない

• FAやQSなど、複数のソースデータ（例：SF-36, ADAS, HAM-Dなど）が1つのDomainに包括される場合に、使いにくいなどの理由でスポンサーが分割することを意味する

• 結果的には前述の” Split datasets”と同じになるため、同一Domainに該当するデータの変数のLengthは、一致していないといけない

13

OpenCDISCの対応

• OpenCDISC Enterprise（有料版）では、試験間のLengthの差をチェックしてくれている • Quote: “FDA encourages you to

1. not use unreasonably long variable length (e.g., 200 chars for baseline flag (--BLFL))

2. have consistently in variables' lengths across a whole submission (to avoid potential truncation problems during data pooling/manipulation across domains and studies)

It’s quite challenging to check this for all data variables in the OpenCDISC Validator Community version (it’s done in OC Enterprise version, which performs cross-standards and cross-studies validation).”

• 試験間でLengthが一致しているべき、ということについての出典の記載はない

• SASやJReview/WebSDMで結合した際の潜在的な問題が考慮されている

Ref: http://www.opencdisc.org/forum/non-recommended-variable-length

14

Split datasetに関する見解

• CDER Common Data Standards Issues Document (Version 1.1/December 2011) • Quote: “LB Domain (Laboratory); Sponsors should submit these smaller files

in addition to the larger non-split standard LB domain file.”

• CDERには分割したデータと、分割していないデータ両方を提出する

• DIA 11234: CDER Data Standards Common Issues Document webinar questions (July 28, 2011 webinar) • Quote: “For CBER do NOT send both split and non-split datasets in your

submission. CBER prefers that non-split data sets are submitted, when this is not possible split the datasets using __CAT and document in the reviewers guide and/or the define.xml”

• CBERの見解は、CDERとは異なる（両方は欲しくない）

Ref: http://www.cdisc.org/stuff/contentmgr/files/0/cafc9ec064e98791f925a575d4aafa44/misc/cdisc_fda_webinar_july2011_q_a.pdf

15

事例に合わせた検討

16

さてここで疑問

• SASのLengthをCutするなんて簡単

• Manual or Auto by programming

• PharmaSUG 2012でも報告あり • CC17. Efficiently Trim Character Variable Lengths to Fit Data,

Reduce Dataset Size, Wayne Zhong, Octagon Research Solutions Inc., Wayne, PA

•他に何か問題があるか？

• パターン分けして考えてみる

1. In-house Standard、もしくは、開発において初めから終わりまでSDTMをCSR作成に用いる場合

2. Legacy DataでCSRを作成して、Submission時に（後付けで）SDTMを作成する場合

17

1. SDTMをCSR作成に用いる場合の例

• DB固定直前にLengthが確定する

• データが入らないと決まらない、特にVerbatim text=AETERM etc.

• LengthをCutするのは、試験実施時か、Submission前か

• ARMCDなどはCutするより固定のほうがいいのではないか

• ただし、OpenCDISCではLengthがIGで記載されたLimit未満の場合には、Warningが出るようになっている

Variable Data Length

AETERM 36 36

ARMCD 20 20

Variable Data Length

AETERM 120 120

ARMCD 5 5

Variable Data Length

AETERM 76 76

ARMCD 12 12

18

もし、Lengthを複数の試験で一致させるとしたら（※そのような明確な規制はないが）

Variable Data Length

AETERM 36 36

ARMCD 20 20

Variable Length

AETERM 120

ARMCD 20

Variable Length

AETERM 120

ARMCD 20

Variable Length

AETERM 120

ARMCD 20

Submissionの際

Variable Data Length

AETERM 120 120

ARMCD 5 5

Variable Data Length

AETERM 76 76

ARMCD 12 12

19

Metadataも含めて検討してみると…

• RACEにおいて、CRFに以下の5カテゴリがあるとする • BLACK OR AFRICAN AMERICAN (25byte)

• AMERICAN INDIAN OR ALASKA NATIVE (32byte)

• ASIAN (5byte)

• NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER (41byte)

• WHITE (5byte)

• もしデータに「NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER」が存在しないならば、RACEのLengthを、41ではなく、最大長の32にCutすることになる • Metadataは32になるが、 aCRF/Codelistには残ったまま • 同様に、解析結果においては、データにないTerminologyもCRFのカテゴリに合わせて表示されている

• この差を「Inconsistency/Gap＝矛盾」とみるのかどうか

20

FDAの非公式な見解の一つ（伝聞）

• CDISC International Interchange 2011における質疑応答 • Quote; "After the presentation, there was a follow-up question

on what the lengths in the define.xml should be. The response was that they should be *exactly* the lengths in the compressed datasets that are submitted. “Greater/equal” is not what they are looking for – they want an accurate description of the actual properties of the datasets that are actually submitted.“

• 提出されたデータ（XPT）とdefine file（.pdf/.xml）の内容は、完全に一致している必要がある、ということ

• LengthをCutした場合Metadataの変更は必須、Controlled terminologyとのInconsistencyについては不明

Ref: http://bbs.cdisc.org/bbs/forums/thread-view.asp?tid=3513&posts=22&start=1

21

2. Legacy Data Conversionの場合

• Lengthは変換の過程（CDISC Controlled TerminologyへのMappingなど）で変更する

• Metadataも通常、イチから作成する

•実作業にひと手間加わるだけ

• 「LengthのCut」という作業に焦点が当たるわけではなく、単にSDTM作成作業の一つとして発生

• XPTとMetadata/define fileの不整合は起こらない

• Inconsistencyの懸念のみが残る

22

まとめ

23

今は…Lengthを短くするしかない

• ファイルサイズはレコード数・文字変数の数などで左右

• ファイルサイズを減らしたいという意図で考えた場合、一部のDomain（例：DM）においては、 「データの中身に合わせた最大長」 に切り詰めたとしても、あまりファイルサイズは減らない（Page 7参照）

• Findings domainではかなりのインパクトがある

• % file size reductionが小さいのは、SVやTAである

• （繰り返しになるが）Inconsistencyの懸念が残る

24

要件が曖昧な中での、想定される動き

• LengthはCut、Metadataは整合させる、複数試験での一致はPending

• いつもどおり、細かいことはpre-NDA meeting等での相談が推奨される？

• XPTを破棄し、XMLでのData Submissionの推奨

• SDTMの規則で、個々のデータにLengthの概念が追加される

• 例1：データに合わせてCutする必要があるかどうか、Length Extensible =Yes/Noのイメージ

• 例2：USUBJIDやARMCDのみCutする必要はない、など

• 分割データの結合時の問題は、将来的にはVendor側の対応で解決されるかもしれない（FDAによりRequest済） • つまり、Split dataset/複数試験でLengthを一致させる必要はなくなる

• （もし必要があれば）OpenCDISC Enterpriseなどでチェック

25

まとめ 問題の焦点 電子ファイルのサイズを小さくする

解決方法 1. XPTのまま、ファイルサイズを縮小する工夫をする 2. 別のフォーマットを使う、例えばXMLファイル（現在は不可）

サイズを縮小する工夫

XPTをZIP等で圧縮 -> Study Data Specificationsで禁止 テキスト変数のLengthをCut -> 注意してやればOK

テキスト変数のLength Cut

原則論： 最低限必要な長さに設定する。闇雲に200 byteにするのはよくな

い。データ長が規定されている変数には、そのルールを適用する（例： --FLG, --TEST, --TESTCD, IDVAR, ARMCDなど）。変数のデータ長はMetadataに正しく記載する 実際の作業： （上限1GBの範囲内で）実データ or Terminologyの最大長を利用、ただし、サイズの増加に顕著な影響を及ぼさない場合は＋αが許される（＋αについてはSDTM IG v3.1.3の記載を遵守すればよい）

ファイルの分割は本質ではない

サイズを無視してデータセットを作成 -> 1GBを超えた -> 分割が必要！…というロジックで考える。CDERは分割前のデータも提出す

ることを要求しているため、最初からバラバラに作るのではない。ただし、QSやFA Domainでは、ファイルサイズとは独立して考え、その内容から分割するかもしれない。

26

参考文献・リンク 1) SDTM Column Resizing: Background and Industry Testing Results; Electronic Data

(eData) Team, CDER FDA, October 13, 2011

http://www.cdisc.org/stuff/contentmgr/files/0/4f05d8426369051905a247002c87e38e/files/dhananja

y_chhatre__session_9.pdf

2) CDER Common Data Standards Issues Document v1.1, December 2011

http://www.fda.gov/downloads/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequireme

nts/ElectronicSubmissions/UCM254113.pdf

3) CDISC Public Discussion Forums; "Editor for SAS XPT files?"

http://bbs.cdisc.org/bbs/forums/thread-view.asp?tid=3513&posts=22&start=1

4) Study Data Specifications v2.0, July 18, 2012

http://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM312964.pdf

5) OpenCDISC Forum; "Non-recommended variable length"

http://www.opencdisc.org/forum/non-recommended-variable-length

6) DIA 11234: CDER Data Standards Common Issues Document webinar questions,

July 28, 2011

http://www.cdisc.org/stuff/contentmgr/files/0/cafc9ec064e98791f925a575d4aafa44/misc/cdisc_fda

_webinar_july2011_q_a.pdf

27

補足：FDAの組織について

• 医薬品評価研究センター Center for Drug Evaluation and Research (CDER)

• すべての処方箋薬とOTC薬

• 生物学的製剤評価研究センター Center for Biologics Evaluation and Research (CBER)

• ワクチン、細胞置換療法(輸血)や動物由来組織片移植などの生物学的製剤

• 医療機器・放射線保健センター Center for Devices and Radiological Health (CDRH)

• 医療機器

Ref: http://www.fda.gov/AboutFDA/CentersOffices/OrganizationCharts/default.htm http://www.mhlw.go.jp/shingi/2009/03/s0318-8.html

28

SDTM FILE SIZE ISSUE

(SAS LENGTH) UPDATE

CJUG LISaS Learning Industry Standard around SDTM

12th April 2013

Version 1.0

1

Disclaimers

• Some of the views and opinions expressed in this

presentation are those of the individual

discussion member and should not be attributed

to the organization by which the member is

employed.

2

Background

• The “SDTM File size issue (SAS Length)” topic was

discussed at the CJUG meeting on Sep. 14, 2012.

This slide deck is focused on the update based on

the following 2 topics.

• FDA public meeting entitled “Regulatory New Drug

Review: Solutions for Study Data Exchange Standards”

on November 5, 2012

• SDTM-IG v3.1.4 Batch 2 Review Package - SDS Proposal

for Alternate Handling of Supplemental Qualifiers

3

SAS Length Definition in SDTM

• Length definition in SDTM IG;

• IG v3.1.3 - The length for variables which use

controlled terminology can be set to the length of

the longest term.

• Restrictions or Recommendations

• SAS XPT file requirement: 200

• ARMCD, ACTARMCD: max 20

• Y/N flags (e.g., --FL, AESER, IEORRES): 1

• --TESTCD, ETCD, --PARMCD, QNAM , IDVAR: max 8

• --TEST, --PARM, QLABEL: max 40

4

CDISC INTERCHANGE PRESENTATION

• SDTM Column Resizing: Background and Industry

Testing Results; Electronic Data (eData) Team,

CDER FDA, October 13, 2011

• 20 randomly selected studies from 565 unique studies tabulated by

the eData Team (OBI/CDER) between 2010-2011.

• Maximum length required (used) vs. Pre-defined limit (e.g., $200)

• An average reduction in file size of 70% among all 20 studies.

• Quote; CDISC standardized datasets are

increasing file sizes of submissions using

transport v5.

5

FDA PUBLIC MEETING ENTITLED

“REGULATORY NEW DRUG REVIEW:

SOLUTIONS FOR STUDY DATA

EXCHANGE STANDARDS” ON

NOVEMBER 5, 2012

The purpose of this meeting was to solicit input from industry, technology vendors, and other members of the public regarding the advantages and disadvantages of current and emerging open, consensus-based standards for the exchange of regulated study data.

6

Meeting Summary : Study Data Exchange

Solutions - Quote; • There were five options presented for replacing

the current exchange format, SAS Transport v5:

1. SAS Transport v5 extensions

2. Clinical Data Interchange Standards Consortium

(CDISC) Operational Data Model (ODM)

3. Health Level Seven (HL7) v3 including Clinical

Document Architecture (CDA)

4. Semantic Web (Resource Description Framework

(RDF); Web Ontology Language (OWL))

5. Analytical Information Markup Language (AnIML)

7

Extended XPT (SAS Transport v5 extensions)

• Quote;

• As of 19-October-2012, organizations can download the new macros from support.sas.com, along with installation and use instructions. (http://support.sas.com/kb/46/944.html)

• The macros have been tested for all SAS releases dating back to SAS 8.2.

8

Reference: DATA DELIVERY STRATEGY FOR INDUSTRY AND FDA - TRANSITIONING TO CDISC VIA THE NEW SAS

TRANSPORT FILE EXTENSIONS, BILL GIBSON, SAS Institute.

Limitations

• Quote;

• Industry and FDA integrate these new macros into their

business processes.

• Other software products (JMP, JMP Clinical, jReview)

integrate these new macros.

• The following software products can NOT read

the extended XPT files as of April 2013.

• OpenCDISC

• SAS Universal Viewer

9

Reference: DATA DELIVERY STRATEGY FOR INDUSTRY AND FDA - TRANSITIONING TO CDISC VIA THE NEW SAS

TRANSPORT FILE EXTENSIONS, BILL GIBSON, SAS Institute.

SAS Program example

/* Use the %LOC2XPT macro to create a V9 transport file */

%loc2xpt(libref=test,

memlist=Thisisalongdatasetname,

filespec='c:¥trans.v9xpt‘

);

/* Use the %XPT2LOC to convert V9 transport file to a SAS data set. */

%xpt2loc(libref=work,

memlist=Thisisalongdatasetname,

filespec='c:¥temp¥trans.v9xpt‘

);

10

General Discussions on the meeting

• Quote;

• There was interest in exploring SAS v5

extensions as a short term solution for technical

limitations to the current format. It’s clear that it

would not solve the structural limitations and a

longer-term solution would also need to be

identified. Attendees discussed that this would

be a lower level of effort to assess as a short

term solution but more information is needed.

11

Summary

• “Using Extended XPT” could be a short term

solution for the following limitations;

• Field name size

• Field name characters

• Field label size

• Character value size

• However “Using Extended XPT” would not

decrease file sizes.

• XML could be a long term solution for the file size issue.

12

SDTM-IG V3.1.4 BATCH 2 REVIEW

PACKAGE - SDS PROPOSAL FOR

ALTERNATE HANDLING OF

SUPPLEMENTAL QUALIFIERS

13

SDS Proposal for Alternate Handling of

Supplemental Qualifiers - Quote;

• It is proposed that NSVs be permitted to be represented in the parent datasets. This would:

• Improve efficiency of FDA reviewers, allowing direct viewing of standard variables and NSVs from the same structure, eliminating the need for tools or the writing of programs to display the data together.

• Eliminate some current Supplemental Qualifier structural limitations by allowing:

• Numeric NSVs to be represented in a numeric data type

• Character NSVs to be defined with an appropriate length for each variable, rather than the typical default of $200 for QVAL

• Allow metadata for NSVs (including Controlled Terminology) to be applied at the variable level instead of the value-level.

14

When we can represent NSVs in parent

domains…

• Variable lengths for character NSVs should be set

to the appropriate length for that variable, as with

all standard character variables.

• It seems that these new, but still under review,

requirements of CDISC standardized datasets

decrease file sizes.

15

Examples • dm.xpt* : 109 KB

• To represent NSVs in DM domain; • QNAM->Variable Name, QLABEL->Variable Label, QORIG and

QEVAL are removed.

16

Type of SUPPDM* File Size Total File

Size ( + DM)

6 pop flags in QNAM

QVAL=$200

1,032 KB 1,141 KB

6 pop flags in QNAM

QVAL=$1

800 KB 909 KB

100 flags in QNAM

QVAL=$1

16,919KB 17,028 KB

DM +

NSVs

468 KB

111 KB

6,099 KB

*: Datasets of “Updated Version of Pilot Submission Package (2013)” are used.

Questions?

17

Reference

1) FDA public meeting entitled “Regulatory New Drug Review: Solutions for Study Data Exchange Standards” on November 5, 2012

http://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/

ElectronicSubmissions/ucm332003.htm

2) SDTM-IG v3.1.4 - Batch 2 Review Package –

http://www.cdisc.org/stuff/contentmgr/files/0/3fa5f30f40ce5ecc7b3f91e558b55f73/misc/sdt

m_ig_3.1.4_batch_2.zip

3) Usage Note 46944: New SAS transport format and tools available

http://support.sas.com/kb/46/944.html

4) SDTM File size issue (SAS Length), CJUG SDTM Team, September 14, 2012

18

SDTM FILE SIZE ISSUE (SAS LENGTH) UPDATE2CJUG LISaS Learning Industry Standard around SDTM21st May 2013

1

Introduction• The “SDTM File size issue (SAS Length)” topic was discussed at the CJUG SDTM meeting on Sep. 14, 2012 and Apr. 12, 2013.

• This slide deck is focused on the comparison of file size by two file format;A) SDTM-XPT files created by CJUG SDTM team (Study

data: HTT-55-MA2AC, 2012)Note that some datasets are re-sized by maximum length used, the others are not (=$200 used).

vs.B) SDTM-XML files (ODM v1.3) created by CDISC XML

team based on the A)

2

Result: Comparison of file size -1A) XPT v5 File size (byte) B) ODM v1.3 File size (byte) Compared to XPT

AE.xpt 19,840 AE.xml 25,477 128%CE.xpt 8,400 CE.xml 16,743 199%CM.xpt 12,400 CM.xml 17,041 137%CO.xpt 8,320 CO.xml 7,869 95%DA.xpt 10,400 DA.xml 27,946 269%DM.xpt 8,320 DM.xml 21,712 261%DS.xpt 26,480 DS.xml 36,664 138%DV.xpt 3,200 DV.xml 2,361 74%EG.xpt 572,960 EG.xml 227,523 40%EX.xpt 14,240 EX.xml 31,414 221%FA.xpt 18,960 FA.xml 14,813 78%IE.xpt 4,160 IE.xml 4,033 97%LB.xpt 178,800 LB.xml 331,540 185%MB.xpt 15,760 MB.xml 33,945 215%MH.xpt 38,000 MH.xml 43,219 114%MS.xpt 34,880 MS.xml 100,889 289%PC.xpt 34,800 PC.xml 114,925 330%PE.xpt 4,240 PE.xml 281 7%PP.xpt 6,880 PP.xml 13,161 191%

3

Result: Comparison of file size -2A) XPT v5 File size (byte) B) ODM v1.3 File size (byte) Compared to XPT

QS.xpt 58,160 QS.xml 114,843 197%RELREC.xpt 39,840 RELREC.xml 58,760 147%

SC.xpt 15,600 SC.xml 36,944 237%SE.xpt 7,360 SE.xml 23,750 323%SU.xpt 10,160 SU.xml 12,802 126%

SUPPEG.xpt 168,960 SUPPEG.xml 109,296 65%SUPPFA.xpt 8,160 SUPPFA.xml 10,474 128%SUPPVS.xpt 117,760 SUPPVS.xml 100,052 85%

SV.xpt 11,760 SV.xml 33,672 286%TA.xpt 2,960 TA.xml 2,180 74%TE.xpt 3,200 TE.xml 1,662 52%TI.xpt 6,080 TI.xml 3,495 57%TS.xpt 13,600 TS.xml 14,328 105%TV.xpt 2,880 TV.xml 2,401 83%VS.xpt 79,760 VS.xml 277,444 348%

Total XPT 1,567,280 Total XML 1,873,659 120%

4

• PE.xpt is ZERO record.• In other words, The file size of XPT is about 84% of XML file size.

Result: EG vs. VS domain -1 • VS.xpt=80KB -> VS.xml=277KB

• XML is larger than XPT because CJUG-VS.xpt is re-sized.

5

Variable Name Variable Label LengthVSGRPID Group ID 1VSSPID Sponsor-Defined Identifier 1VSTESTCD Vital Signs Test Short Name 8VSTEST Vital Signs Test Name 40VSCAT Category for Vital Signs 1VSSCAT Subcategory for Vital Signs 1VSPOS Vital Signs Position of Subject 8VSORRES Result or Finding in Original Units 14VSORRESU Original Units 4VSSTRESC Character Result/Finding in Std Format 14VSSTRESU Standard Units 14VSSTAT Completion Status 1VSREASND Reason Not Performed 1VSLOC Location of Vital Signs Measurement 14

Result: EG vs. VS domain -1 • EG.xpt=573KB -> EG.xml=228KB

• XML is smaller than XPT because CJUG-EG.xpt is NOT re-sized.

6

Variable Name Variable Label LengthEGGRPID Group ID 200EGSPID Sponsor-Defined Identifier 3EGTESTCD ECG Test or Examination Short Name 8EGTEST ECG Test or Examination Name 40EGCAT Category for ECG 200EGSCAT Subcategory for ECG 200EGPOS ECG Position of Subject 6EGORRES Result or Finding in Original Units 200EGORRESU Original Units 9EGSTRESC Character Result/Finding in Std Format 200EGSTRESU Standard Units 9EGSTAT Completion Status 8EGREASND Reason ECG Not Performed 200EGLOC Lead Location Used for Measurement 200

FDA Survey• SDTM Column Resizing: Background and Industry Testing Results; Electronic Data (eData) Team, CDER FDA, October 13, 2011• 20 randomly selected studies from 565 unique studies tabulated by

the eData Team (OBI/CDER) between 2010-2011.

• Comparison of file size for datasets from all 20 studies (432 datasets) by file format;• .xpt modified (Maximum length used) -> Mean=10MB• .xpt received -> Mean=50MB• .xml -> Mean=20MB

7

Note that there is no information about ODM version, maybe v1.2

Summary -1

8

.xpt modified (well-controlled, re-sized by maximum length used)

.xml.xpt received (non-

controlled, e.g., all variables = $200)＜ ＜

• According to the presentation by FDA;

0.5 : 1 : 2.5

• Study data: HTT-55-MA2AC, CJUG-SDTM, 2012;

0.84 : 1.xpt (Follow IG, but Some datasets are re-sized, the others are not re-sized)

.xml＜

Are you happy with the result?

Summary -2• Generally XML is smaller than received (non-controlled) XPT, and larger than modified (well-controlled) XPT because of the tags.• As of 2013, However key-variables should be controlled appropriately,

No maximum length used, for future merges (see the slide-deck on last Sep.).

• From another perspective, essentially File size is Unimportant. What matters is Quality of data review software or process at FDA.• Jozef Aerts, he is a member of CDISC XML team, is writing that

explains this point of view. Looking forward to his article.

9

1) SDTM Column Resizing: Background and Industry Testing Results; Electronic Data (eData) Team, CDER FDA, October 13, 2011http://www.cdisc.org/stuff/contentmgr/files/0/4f05d8426369051905a247002c87e38e/files/dhananjay_chhatre__session_9.pdf

2) SDTM File size issue (SAS Length), CJUG SDTM Team, September 14, 2012

3) SDTM File size issue (SAS Length) UPDATE, CJUG SDTM Team, April 12, 2013

10

Reference