DISCUSSION: SDTM UPDATES MARCH 2013. Public comments Comments were requested from CDISC for the new and updated domains for SDTM v3.1.4 Batch 1 : RD -

Slides:



Advertisements
Similar presentations
Monika Kawohl Principal Statistical Programmer Accovion
Advertisements

Dimitri Kutsenko (Entimo AG)
ADaM Implementation Guide: It’s Almost Here. Are You Ready?
Testing Relational Database
Communicating with Standards Keeping it Simple Pamela Ryley Vertex Pharmaceuticals, Inc. September 29, 2006.
CHAPTER OBJECTIVE: NORMALIZATION THE SNOWFLAKE SCHEMA.
To change this title, go to Notes Master
Experience and process for collaborating with an outsource company to create the define file. Ganesh Sankaran TAKE Solutions.
Copyright © 2013 Quintiles FA vs. SUPPQUAL Facilitator: Riekert Henning, 11 April 2013.
SEND Standard for the Exchange of Nonclinical Data
Enhancing Data Quality of Distributive Trade Statistics Workshop for African countries on the Implementation of International Recommendations for Distributive.
Private Insurance and NEW CPT (Current Procedural Terminology) Codes: Terminology Review contracting with insurance Review old and new CPT’s Summarize.
The ICH E5 Question and Answer Document Status and Content Robert T. O’Neill, Ph.D. Director, Office of Biostatistics, CDER, FDA Presented at the 4th Kitasato-Harvard.
Database Design Concepts Info 1408 Lecture 2 An Introduction to Data Storage.
Database Design Concepts Info 1408 Lecture 2 An Introduction to Data Storage.
Create a Web Site with Frames
Life Sciences Accelerated R&D Services The Science of Getting Products to Patients Faster Study Data Standardization Plan Use Case Experience Dave Izard.
4-1 Compiled by Darren Paproski - Adapted from the University of Technology Sydney Writing Guide Case Studies Module Overview Why use case studies Learning.
Frequently Asked Questions (FAQ) prepared by some members of the ICH Q9 EWG for example only; not an official policy/guidance July 2006, slide 1 ICH Q9.
XP Tutorial 5New Perspectives on HTML, XHTML, and DHTML, Comprehensive 1 Designing a Web Site with Frames Using Frames to Display Multiple Web Pages Tutorial.
Gregory Steffens Novartis Associate Director, Programming NJ CDISC Users’ Group 17 April 2014 Supplemental Qualifiers.
Microsoft Office Word 2013 Expert Microsoft Office Word 2013 Expert Courseware # 3251 Lesson 4: Working with Forms.
Logical Database Design Nazife Dimililer. II - Logical Database Design Two stages –Building and validating local logical model –Building and validating.
23 August 2015Michael Knoessl1 PhUSE 2008 Manchester / Michael Knoessl Implementing CDISC at Boehringer Ingelheim.
Dominic, age 8, living with epilepsy SDTM Implementation Guide : Clear as Mud Strategies for Developing Consistent Company Standards PhUSE 2011 – CD02.
CBER CDISC Test Submission Dieter Boß CSL Behring, Marburg 20-Mar-2012.
© 2011 Octagon Research Solutions, Inc. All Rights Reserved. The contents of this document are confidential and proprietary to Octagon Research Solutions,
PhUSE SDE, 28-May A SAS based Solution for define.xml Monika Kawohl Statistical Programming Accovion.
Remapping of Codes (and of course Decodes) in Analysis Data Sets for Electronic Submissions Joerg Guettner, Lead Statistical Analyst Bayer Pharma, Wuppertal,
No, Thanks, I’ll Use a Spreadsheet
What is Sure BDCs? BDC stands for Batch Data Communication and is also known as Batch Input. It is a technique for mass input of data into SAP by simulating.
Implementation of a harmonized, report-friendly SDTM and ADaM Data Flow General by Marie-Rose Peltier Experience by Marie Fournier Groupe Utilisateurs.
Antje Rossmanith, Roche 14th German CDISC User Group, 25-Sep-2012
1CDISC 2002 RCRIM – Standard Domains Agenda NCI Presentation Standard Domains Working Group Goals Introduction to FDA Information Model (FIM) Discussion:
Overview and feed-back from CDISC European Interchange 2008 (From April 21 st to 25 th, COPENHAGEN) Groupe des Utilisateurs Francophones de CDISC Bagneux.
Confidential - Property of Navitas Accelerate define.xml using defineReady - Saravanan June 17, 2015.
Update on SDTMIG v and SDTM v. 1.2 Bay Area User Group Meeting May 2008 Fred Wood Octagon Research Solutions.
Event Management & ITIL V3
SDTM Validation Delaware Valley CDISC user network Ketan Durve Johnson and Johnson Pharmaceutical Reasearch and Development May 11 th 2009.
Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Chapter - 2 Basics of Sound Structure Author: Graeme C. Simsion and Graham C. Witt.
Research based, people driven CDISC ADaM Datasets - from SDTM to submission CDISC Experience Exchange and ADaM Workshop 15 Dec 2008 Zoë Williams, LEO Pharma.
WG4: Standards Implementation Issues with CDISC Data Models Data Guide Subteam Summary of Review of Proposed Templates and Next Steps July 23, 2012.
WG4: Data Guide/Data Description Work Group Meeting August 29, 2012.
1. © CDISC 2014 SDS ELT Rules Team Update Stetson Line 08 Dec
Understanding Allocations Brian Chizever Cognos Corporation.
Recruit, Train, and Educate Airmen to Deliver Airpower for America How Focus Groups Can Help Your Unit 1.
Preventing Wide and Heavy ADs Dirk Van Krunckelsven Phuse 2011, Brighton ADaM on a Diet.
Peter Granda Archival Assistant Director / Data Archives and Data Producers: A Cooperative Partnership.
Methods and Techniques for Integration of Small Datasets September 13-14, 2005 St. Louis, Missouri Sponsored by the U.S. Department of Housing and Urban.
Updates on CDISC Activities
Collaborating With Your Health Plan 03/07/05 To paraphrase A. Einstein: We cannot solve today’s problems with the same level of thinking that created them.
How good is your SEND data? Timothy Kropp FDA/CDER/OCS 1.
This was written with the assumption that workbooks would be added. Even if these are not introduced until later, the same basic ideas apply Hopefully.
How Good is Your SDTM Data? Perspectives from JumpStart Mary Doi, M.D., M.S. Office of Computational Science Office of Translational Sciences Center for.
Product & Process Working Group February 26, 2002.
CDISC SDS Oncology Domains: An Orientation to Aid Review & Feedback Barrie Nelson CDISC SDS Oncology Sub Team Lead
Validation Gary Gensinger Deputy Director Office of Business Process Support Center for Drug Evaluation and Research.
VAdata Tools VAdata: Virginia’s Sexual and Domestic Violence Data Collection System.
A need for prescriptive define.xml
Validation of CDISC data sets, current practice and future
Accelerate define.xml using defineReady - Saravanan June 17, 2015.
MAKE SDTM EASIER START WITH CDASH !
Traceability between SDTM and ADaM converted analysis datasets
To change this title, go to Notes Master
Fabienne NOEL CDISC – 2013, December 18th
To change this title, go to Notes Master
WG4: Data Guide/Data Description Work Group Meeting
SDTM and ADaM Implementation FAQ
PhUSE: Pooling WHODrug B3 Format
Presentation transcript:

DISCUSSION: SDTM UPDATES MARCH 2013

Public comments Comments were requested from CDISC for the new and updated domains for SDTM v3.1.4 Batch 1 : RD - Reproduction Details / RP – Reproductive System Findings IS - Immunogenicity Specimen Assessment SR - Skin Response EX - Exposure EC - Exposure as Collected Overview of the comments: Most comments were about : Label inconsistencies, Incorrect Type, CORE and Controlled Term/Codelist/Format information Spelling errors Controlled Terminology updates Questions Suggestions

Public comments Update : EX / EC domain IG v 3.1.4, batch 1 Comments (EXOCCUR/EXREASND): EX domain is an Interventions domain and therefore --PRESP, --OCCUR, --STAT and --REASND are already available, they were only excluded from EX because according to the current Implementation Guide page 85: ‘EX should contain only medications received’ - as this concept is now changed, it's making sense to allow these variables in EX and fill them as in all other domains.

Public comments IG v 3.1.4, batch 1 Also the SDTMIG V3.1.2 section should be updated to document the use of a --REASND in combination with an --OCCUR=N. The table listed in this section is used by many electronic compliance checking tools as the set of allowed situations. It should be clearly stated that for EX/EC an exception is to be made. (Please note I refered to the SDTMIG V3.1.2 as there is not yet an updated version of this part of the IG available) Update : EX / EC domain Comments (EXOCCUR/EXREASND):

EXSTAT/EXREASND - In every other SDTM domain, REASND is used for the reason that an observation was not made. In findings domains, this is the reason a test was not done. In events domains, this is the reason that a question about a pre-specified event was not asked. In other interventions domains, this is the reason that a question about a pre-specified intervention was not asked. REASND is populated when STAT=NOT DONE. In this proposal, REASND would be populated when OCCUR = N. If it is desired to record the reason why a dose was not given, then a new variable for "reason not given" (or some such) should be created, instead of overloading the existing variable REASND. Even if we don't foresee using REASND for its original purpose in EX, this proposal would create a domain-specific exception to the general mapping of REASND to BRIDG, complicating the process of mapping future BRIDG-based SHARE content to SDTM. Public comments IG v 3.1.4, batch 1 Update : EX / EC domain Comments (EXOCCUR/EXREASND):

Public comments IG v 3.1.4, batch 1 Update : EX / EC domain It's also good to have the CRF collected dose/units and the protocol specified ones, but in my opinion it would be a lot easier to introduce something like Standard Dose and Standard Units like in the Finding domains, and there the dosage and units as specified in the protocol. The original collected dosage and unit can be kept in EXDOSE and EXDOSU. That would be more clear than making two very similar domains and linking them via RELREC. Comments (EC Domain):

Public comments IG v 3.1.4, batch 1 Update : EX / EC domain Another argument for the EC/EX solution was that the values from EC can be summarized in EX to support analysis. In my opinion this should not be part of SDTM - as SDTM is usually not preparing tables for analysis but should reflect the CRF data as entered, sure some values are derived as well but to put one whole domain which is only derived and summarizing/pooling treatment data is maybe not what SDTM was intended for, for me that sounds more like ADaM. IG v 3.1.4, batch 1 Update : EX / EC domain It is indicated that EXVAMT will be deprecated, but it is not clear to me what replaces it. There are no examples showing collected doses based on a preparation step such as an infusion where study drug is diluted to a certain concentration in a vehicle such as saline. Comments (EC Domain):

Public comments IG v 3.1.4, batch 1 Update : RD domain In the NCI Terminology Codelists there is a RP (Reproductive System Findings) domain assigned, why did it change to RD ? Comments : The Response: It was decided by CDISC that this domain will be renamed to RP (Reproductive System Findings) as per CDISC controlled terminology. The Response: It was decided by CDISC that this domain will be renamed to RP (Reproductive System Findings) as per CDISC controlled terminology.

Public comments IG v 3.1.4, batch 1 Update : RD domain “Why RDSTDTC is not spelled out in the list of variables, given that one might want to know when a particular ‘finding’ occurred. What's being collected is RDDTC, the collection date. For some ‘tests’, like PREGNT, it is important to know when a pregnancy began, not simply the collection date. Reconsider this as a findings class.” Comments : The Response: RDDTC is the date of the reproductive finding and should not be confused with the collection date relative to when it was recorded on a CRF. The Response: RDDTC is the date of the reproductive finding and should not be confused with the collection date relative to when it was recorded on a CRF.

Public comments IG v 3.1.4, batch 1 Update : RD domain Control Terminology Suggestions: RDTESTCD – PREGSTAT / RDTEST- Pregnancy Status RDTESTCD - EARLYTRM / RDTEST - Early Termination RDTESTCD – LIVEBRTH / RDTEST- Live Birth PREGSTAT -PREGNANCY ONGOING, LIVE BIRTH, STILLBIRTH, EARLY TERMINATION EARLYTRM - SPONTANEOUS ABORTION, THERAPEUTIC ABORTION, ELECTIVE ABORTION, OTHER LIVEBRTH - NORMAL, BIRTH DEFECT, OTHER The Response: Suggestions for controlled terminology should be send to the NCI EVS for consideration upon the release of the domain in provisional status. The Response: Suggestions for controlled terminology should be send to the NCI EVS for consideration upon the release of the domain in provisional status.

Public comments IG v 3.1.4, batch 1 Update : IS and SR domains

Public comments IG v 3.1.4, batch 1 Update : IS and SR domains Comments: IS needs controlled terminology. Many of the tests used as examples are existing LBTESTCD codes - either existing terminology e.g. HCAB or extensible e.g. as in Example 3. Will they be copied from LBTESTCD terms? Will they then be removed from LBTESTCD terminology? Will ALL Serology and Immunology tests now reside in this domain rather than LAB? How about VIROLOGY? Can you provide a list of tests which will move? I think this needs clear guidance as the definition of serology/immunology in relation to specific testing can be rather vague. Defining the CAT for each LBTESTCD/ISTEST would be helpful. Please explain why you don't have an upper limit of quantitation. We have serology data that requires this.

Public comments IG v 3.1.4, batch 1 Update : IS and SR domains Comments: I am concerned about moving categories of data out of LAB into their own domain. Generally all the categories fit well within the existing LAB domain and may only need a few extra variables. My preference would have been to keep serology and immunology and viral within LAB but add extra optional variables to LAB e.g. ISLLOQ & ASSAYV with examples of how to use them. Dividing the data up too much leads to problems when people have different opinions as to whether this data is immunology or virology or biomark. We end up having the same data in different dataset domains due to study team preference. Does LAB just end up being haem, chem and urine? ISTEST : Immunoglobulin E is given as an example in the CDISC notes and HCAB in example 1. These are already a lab test codes. Will ISTESTCD/ISTEST share same codelist as LB? If so, how will users know whether to report results in LB vs IS? Does purpose of test determine domain to use? Any specific reason why the data from IS can't be included in LB, differentiated by LBCAT ?

Public comments Summary of comments on v3.1.4 batch 1: For the EX/EC/IS domains a lot more thought should go in there so that there is no duplication of information and a review of the quality of work to be reviewed by users should be done.

Non-standard variables

IG v 3.1.4, batch 2 Update : Non-standard variables Biggest Concerns: Dataset Size Validation Cost Impact

NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables Permitting NSVs in parent domain will likely produce datasets that are very wide and sparse in the NSV columns. While SAS v5 XPORT files remain as the transport mechanism, sparse datasets will result in big files, which the US FDA openly complains Reviewing wide datasets is very unlikely to improve review efficiency as mentioned in section 3. There is also the issue of additional file size that is sure to occur from the NSVs being included in the datasets, which flies in the face of often repeated comments from CDER that we should not have dataset files that area "too big". Most of the records will likely not even have data for many of these NSVs, yet they will have the variables and the character spacing for them. The increase of the file size (for all files with Supplemental Variables) should be carefully weighed against the benefit of the "ease of use" by only some reviewers. SuppQual increases the overall complexity of SDTM. SDTM isn’t easy to understand and explain. Jettisoning the SuppQual would make it a lot more appealing. Separating data that belongs together in two datasets is confusing. Given that SuppQual is transposed it is even more confusing Data transparency would be increased if extra variables were allowed. "Please develop this. This would make the SDTM datasets more operationally useful, which is likley to lead to better transparency. More information is needed. Varied examples in the IG would be helpful."

No. While this may address some challenges, it will create others, and we think that therapeutic area development is an overriding priority. NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables The compliance-checking is a particularly worrisome prospect. How can a dataset be standard if it isn't? If CDISC flips their fundamental constructs around as they did when moving from v2 to v3, especially when this is purely a matter of preference, I, and others, will throw up my hands in disgust and question the validity of the CDISC "standard". Compiling NSVs into SUPPXX domain structure requires complex programming and subsequent QC algorithms. Working on studies, when reviewing data and confirming NSV's, it was found best to have them linked to the parent domain. Programming and data review is more cumbersome and time consuming in SUPPXX structure. Much time is spent by sponsors programming teams removing NSV data from the original source parent domain where it is collected and moving it to the SUPPXX domain. Then again for internal data review sponsors must put the data back to the parent domain where it logically should be reviewed from.

At GSK we have invested millions of dollars and several years into developing an SDTM-compliant submission data development system. The creation of SUPP datasets are embedded into this system and are an integral part of the what defines the standard. Everyone knows that SUPP datasets can be transposed and merged for operational purposes. The existence of a standard is supposed to protect sponsors from having to adapt to various user preferences. To change SDTM to make it "optional" to include NSV in the main domain dataset will mean that reviewers will request it, so GSK would by necessity be forced to redesign our data creation and compliance- checking systems at great expense. NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables The SuppQual paradigm favours larger companies that can provide the infrastructure and staff to handle the increased complexity associate with SuppQual operations Companies with existing SuppQual infrastructure or companies that derive revenue by managing SuppQual for other companies will be advocating to keep the SuppQual paradigm. The current SuppQual convention ignores the fact that not all data is ultimately submitted to the FDA so the SuppQual costs are incurred without benefit. Given the rate of failure in pharmaceutical development this doesn’t seem optimal.

NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables For organizations that have already invested significant resources into developing a system to handle raw data at the operational level and then create SDTM compliant data, there would be an obvious negative impact. These organizations have already found a way to collect and clean the data, then separate the non-standard data into SUPPQUAL sets. If this proposal eliminates the SUPPQUAL, the investment of resources is lost. This is not however the only potential cost. Dependent upon how the proposal is developed, for all organizations the potential exists that adding NSV data to the standardized domains will require study level custom programming to draw these in the ADaM data. (As SDTM stands, NSV data is 100% predictable – values always appear as QVAL, transposed varnames are always in QNAM, etc.) Creating standardized programming to build analysis datasets is easier in the current model. Dropping the use of SuppQuals in favour of using NSVs is a very good idea for the following reasons: Maintaining the infrastructure to transpose and merge SuppQual variables for operational, non-submission business use case is substantial. With the current standard extra costs are incurred not matter which paradigm a pharmaceutical company chooses. The cost of converting operational, wide data sets to strict SDTM with SuppQual is expensive. The cost of converting strict SDTM with SuppQual to operational, wide data sets is expensive.

We are not in favour of the proposed change. We do think that there would be a heavy cost impact because of the work that would need to be undertaken to change existing standards as implemented by industry. We feel that the change is not backwards compatible with existing work. The impact to validation via OpenCDISC or other tools should also be considered. The possibility that this will open the door to the inclusion of more derived variables in SDTM data is also a concern NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables

No. Roche's "operational" SDTM datasets include NSVs. Roche has a standard procedure to separate the operational datasets into parent and supplemental qualifier domains and create study metadata (define.xml). As SDTM exists today, the SUPPQUAL supports collection of standardized data. Using the SUPP- - to extend the standard requires additional effort. Sponsors are incentivized to look for existing variables that meet each purpose or to find related datasets (e.g., FA) to contain data. Should a sponsor find no other way to meet the standards, sponsors are more likely to create a review process to justify the deviation from accepted industry standards. (To properly build a SUPP- - domain for submission requires planning, programming resources, QC effort, etc.) By simplifying the ability to add non-standard data, this proposal increases the temptation to work outside the established standards and possibly negate the gains provided. NSVs in standard domains IG v 3.1.4, batch 2 Update : Non-standard variables Yes. Roche has queried members of TBI and the consensus support this proposal. Roche would like to see this proposal prioritized and expediently pushed through the SDS development process. Given the resource requirements of the TA standards development, Roche encourages CDISC to explore alternate resourcing methods. For example, could this proposal be formalized as part of an FDA/PhUSE project? This will also be much easier to use the variables in ADaM. Consequently, we at BI support this proposal of keeping NSVs in the parent domain with clear rules such as standard variable prefixes (ie) SP_NSV. This would help streamline SDTM dataset creation and subsequent data review.

Any Comments ?