ADaM for Medical Devices: Extending the Current ADaM Structures

Similar documents
Introduction to ADaM and What s new in ADaM

PharmaSUG2014 Paper DS09

Traceability in the ADaM Standard Ed Lombardi, SynteractHCR, Inc., Carlsbad, CA

Deriving Rows in CDISC ADaM BDS Datasets

Applying ADaM Principles in Developing a Response Analysis Dataset

ADaM Compliance Starts with ADaM Specifications

Working with Composite Endpoints: Constructing Analysis Data Pushpa Saranadasa, Merck & Co., Inc., Upper Gwynedd, PA

Hands-On ADaM ADAE Development Sandra Minjoe, Accenture Life Sciences, Wayne, Pennsylvania

Introduction to ADaM standards

Hands-On ADaM ADAE Development Sandra Minjoe, Accenture Life Sciences, Wayne, Pennsylvania Kim Minkalis, Accenture Life Sciences, Wayne, Pennsylvania

How to write ADaM specifications like a ninja.

An Efficient Solution to Efficacy ADaM Design and Implementation

Metadata and ADaM.

ADaM IG v1.1 & ADaM OCCDS v1.0. Dr. Silke Hochstaedter

Creating an ADaM Data Set for Correlation Analyses

Riepilogo e Spazio Q&A

Xiangchen (Bob) Cui, Tathabbai Pakalapati, Qunming Dong Vertex Pharmaceuticals, Cambridge, MA

Dealing with changing versions of SDTM and Controlled Terminology (CT)

ADaM and traceability: Chiesi experience

Traceability: Some Thoughts and Examples for ADaM Needs

It s All About Getting the Source and Codelist Implementation Right for ADaM Define.xml v2.0

Sandra Minjoe, Accenture Life Sciences John Brega, PharmaStat. PharmaSUG Single Day Event San Francisco Bay Area

Improving Metadata Compliance and Assessing Quality Metrics with a Standards Library

A Taste of SDTM in Real Time

Use of Traceability Chains in Study Data and Metadata for Regulatory Electronic Submission

What is the ADAM OTHER Class of Datasets, and When Should it be Used? John Troxell, Data Standards Consulting

Harmonizing CDISC Data Standards across Companies: A Practical Overview with Examples

Material covered in the Dec 2014 FDA Binding Guidances

Traceability Look for the source of your analysis results

PharmaSUG Paper PO22

Yes! The basic principles of ADaM are also best practice for our industry Yes! ADaM a standard with enforceable rules and recognized structures Yes!

PharmaSUG Paper DS06 Designing and Tuning ADaM Datasets. Songhui ZHU, K&L Consulting Services, Fort Washington, PA

The Benefits of Traceability Beyond Just From SDTM to ADaM in CDISC Standards Maggie Ci Jiang, Teva Pharmaceuticals, Great Valley, PA

Optimization of the traceability when applying an ADaM Parallel Conversion Method

ADaM Implementation Guide Status Update

ADaM Implementation Guide Prepared by the CDISC ADaM Team

Codelists Here, Versions There, Controlled Terminology Everywhere Shelley Dunn, Regulus Therapeutics, San Diego, California

CDASH MODEL 1.0 AND CDASHIG 2.0. Kathleen Mellars Special Thanks to the CDASH Model and CDASHIG Teams

DCDISC Users Group. Nate Freimark Omnicare Clinical Research Presented on

Implementing CDISC Using SAS. Full book available for purchase here.

CDASH Standards and EDC CRF Library. Guang-liang Wang September 18, Q3 DCDISC Meeting

PharmaSUG Paper DS24

How to handle different versions of SDTM & DEFINE generation in a Single Study?

Analysis Data Model Implementation Guide Version 1.1 (Draft) Prepared by the CDISC Analysis Data Model Team

Submission-Ready Define.xml Files Using SAS Clinical Data Integration Melissa R. Martinez, SAS Institute, Cary, NC USA

Edwin Ponraj Thangarajan, PRA Health Sciences, Chennai, India Giri Balasubramanian, PRA Health Sciences, Chennai, India

ADaM Reviewer s Guide Interpretation and Implementation

AUTOMATED CREATION OF SUBMISSION-READY ARTIFACTS SILAS MCKEE

Clarifications About ADaM Implementation Provided in ADaMIG Version 1.1

The Implementation of Display Auto-Generation with Analysis Results Metadata Driven Method

DIA 11234: CDER Data Standards Common Issues Document webinar questions

Leveraging ADaM Principles to Make Analysis Database and Table Programming More Efficient Andrew L Hulme, PPD, Kansas City, MO

NCI/CDISC or User Specified CT

PharmaSUG DS05

Analysis Data Model (ADaM) Data Structure for Adverse Event Analysis

From SAP to BDS: The Nuts and Bolts Nancy Brucken, i3 Statprobe, Ann Arbor, MI Paul Slagle, United BioSource Corp., Ann Arbor, MI

Doctor's Prescription to Re-engineer Process of Pinnacle 21 Community Version Friendly ADaM Development

PharmaSUG Paper DS-24. Family of PARAM***: PARAM, PARAMCD, PARAMN, PARCATy(N), PARAMTYP

Beyond OpenCDISC: Using Define.xml Metadata to Ensure End-to-End Submission Integrity. John Brega Linda Collins PharmaStat LLC

Optimization of the traceability when applying an ADaM Parallel Conversion Method

PharmaSUG Paper PO21

From Implementing CDISC Using SAS. Full book available for purchase here. About This Book... xi About The Authors... xvii Acknowledgments...

Automated Creation of Submission-Ready Artifacts Silas McKee, Accenture, Pennsylvania, USA Lourdes Devenney, Accenture, Pennsylvania, USA

SAS as a Tool to Manage Growing SDTM+ Repository for Medical Device Studies Julia Yang, Medtronic Inc. Mounds View, MN

Clinical Metadata Metadata management with a CDISC mindset

Programming checks: Reviewing the overall quality of the deliverables without parallel programming

PharmaSUG 2014 PO16. Category CDASH SDTM ADaM. Submission in standardized tabular form. Structure Flexible Rigid Flexible * No Yes Yes

Automate Analysis Results Metadata in the Define-XML v2.0. Hong Qi, Majdoub Haloui, Larry Wu, Gregory T Golm Merck & Co., Inc.

Avoiding Sinkholes: Common Mistakes During ADaM Data Set Implementation

Study Data Reviewer s Guide Completion Guideline

Some Considerations When Designing ADaM Datasets

TS04. Running OpenCDISC from SAS. Mark Crangle

Tips on Creating a Strategy for a CDISC Submission Rajkumar Sharma, Nektar Therapeutics, San Francisco, CA

Now let s take a look

Making a List, Checking it Twice (Part 1): Techniques for Specifying and Validating Analysis Datasets

CDISC SDTM and ADaM Real World Issues

How a Metadata Repository enables dynamism and automation in SDTM-like dataset generation

An Introduction to Visit Window Challenges and Solutions

STUDY DATA TECHNICAL CONFORMANCE GUIDE

Automation of SDTM Programming in Oncology Disease Response Domain Yiwen Wang, Yu Cheng, Ju Chen Eli Lilly and Company, China

Creating Define-XML version 2 including Analysis Results Metadata with the SAS Clinical Standards Toolkit

Planning to Pool SDTM by Creating and Maintaining a Sponsor-Specific Controlled Terminology Database

CDISC Library. Sam Hume, Anthony Chow, Mike Hamidi Data Science, CDISC 21-Feb-2019

Interpreting CDISC ADaM IG through Users Interpretation

Standardising The Standards The Benefits of Consistency

Semantic Technologies and CDISC Standards. Frederik Malfait, Information Architect, IMOS Consulting Scott Bahlavooni, Independent

Updates on CDISC Standards Validation

Preparing the Office of Scientific Investigations (OSI) Requests for Submissions to FDA

CDISC Standards End-to-End: Enabling QbD in Data Management Sam Hume

Detecting Treatment Emergent Adverse Events (TEAEs)

%check_codelist: A SAS macro to check SDTM domains against controlled terminology

Robust approach to create Define.xml v2.0. Vineet Jain

Define.xml 2.0: More Functional, More Challenging

Interactive Programming Using Task in SAS Studio

Conversion of CDISC specifications to CDISC data specifications driven SAS programming for CDISC data mapping

Why organizations need MDR system to manage clinical metadata?

Customer oriented CDISC implementation

Study Data Technical Conformance Guide (TCG)

Lex Jansen Octagon Research Solutions, Inc.

Automate Clinical Trial Data Issue Checking and Tracking

Transcription:

PharmaSUG 2018 - Paper MD-02 ADaM for Medical s: Extending the Current ADaM Structures Sandra Minjoe, PRA Health Sciences; Julia Yang, Medtronic PLC; Priya Gopal, TESARO, Inc. ABSTRACT The current ADaM structures were designed and developed for common drug and biologic studies, which are focused on the subject (USUBJID). In fact, variable USUBJID is a requirement in all standard ADaM dataset structures. Additionally, the ADSL structure of one-record-per-subject is a requirement for submission of drug and biologic studies. Within medical device studies, subject may or may not be of interest, and USUBJID may not even be collected. Instead, the unique device identifier (SPDEVID) is the primary identifier of interest. This means that the current ADaM structures are usually not a good fit for the analysis needs of medical device studies. This presentation will highlight how ADaM can be extended to work with medical devices data. It focuses on content in an ADaM document, in development at the time of this writing, that is designed specifically to address medical device analysis needs. INTRODUCTION This paper describes analysis dataset structures that, at the time of this writing, are in development by the CDISC ADaM team to address the analysis of medical device studies. These structures are: ADDL: A -Level Analysis Modified BDS: Similar in structure to ADaM BDS, but with different requirements for identifiers Modified OCCDS: Similar in structure to ADaM OCCDS, but with different requirements for identifiers Within this paper, the important variables from each of these proposed medical device standard structures are described, and the proposed structures are compared to existing ADaM standard structures for human drug and biologic clinical studies. These proposed structures are needed to support analyses that differ from those in studies of drugs and biologics. Some unique medical device analyses include: Analysis of s Analysis of Subjects within each Analysis of Adverse Events Time-to--Event Analysis To fully understand this paper, you are expected to have some knowledge of medical device studies and analysis needs. Additionally, you need to know a little about CDISC, especially ADaM and SDTM. See the Recommended Reading section at the end of this paper for a list of CDISC standards documents most pertinent to this paper. Any CDISC standard document can be downloaded for free from the either the CDISC website https://www.cdisc.org/ or wiki page https://wiki.cdisc.org/. SUBJECT-LEVEL ANALYSIS DATASET (ADSL) In human clinical studies of drugs and biologics, ADSL is a required dataset. It is used directly to produce subject-level analyses, such as demographic summaries, plus provides denominator counts for other tables, such as those summarizing subject data over different timepoints. 1

ADaM for Medical s: Extending the Current ADaM Structures, continued When subject data is collected in a medical device study, there would be these same needs for an ADSL dataset. When subject-level data is not collected, ADSL would not make sense to include. Therefore, in a medical device study, ADSL is a conditionally-required dataset. DEVICE-LEVEL ANALYSIS DATASET (ADDL) ADDL is being developed to serve a similar purpose in medical device study analysis as the ADSL structure in human drug and biologic clinical studies. It can be used directly to produce device-level analyses, such as device demographic summaries. It also can easily provide denominator counts for other tables, such as those that summarize device data over different timepoints. ADDL STRUCTURE In the proposed ADDL, the unique device identifier (SPDEVID) must be included. Depending on the analysis need, the unique subject identifier (USUBJID) may also be included. This means that SPDEVID is a required variable, while USUBJID is conditionally required. The variable USUBJID can be included for two different reasons. The first is when multiple devices are used on the same subject, perhaps to study how a subject performs with each device. USUBJID can also be included when multiple subjects use the same device, such as a device to measure subject lab results. Note that ADaM has no rules around variable order within a dataset, or sort order of rows. How you arrange variables and sort rows in ADDL dataset may or may not be related to whether subjects had multiple devices, or devices were used by multiple subjects. To help visualize, consider dataset metadata for each of the possible scenarios. First the case where there is no subject identifier: Name ADDL Description -Level Analysis Location addl.xpt Structure one record per device Key Variables of SPDEVID Figure 1: ADDL for s (no Subjects) Next, when sorting by device, then subject: Name ADDL Description -Level Analysis Location addl.xpt Structure one record per device per subject Key Variables of SPDEVID, USUBJID Figure 2: ADDL Sorted by and Subject And finally,when sorting by subject, then device: Name ADDL Description -Level Analysis Location addl.xpt Structure one record per subject per device Key Variables of USUBJID, SPDEVID Figure 3: ADDL Sorted by Subject and The choice of ADDL structure is dependent on the study. If subject information is not collected, then use the first scenario. If subject level is collected, then determine the sort order of devices and subjects that best suits your study s analysis needs. 2

ADaM for Medical s: Extending the Current ADaM Structures, continued Similar to ADSL in human clinical studies, ADDL was designed so that its data can be combined with other device datasets, such as ADaM and SDTM, by using the appropriate merge or join key(s). With ADSL, the merge or join key is simply USUBJID. With ADDL, the merge or join key is at least SPDEVID, plus conditionally USUBJID, when USUBJID is included in ADDL. ADDL VARIABLES The most important identifiers for the proposed ADDL standard structure, SPDEVID and USUBJID, were mentioned in the above section: SPDEVID is required, and USUBJID is conditionally required. One other identifier, SITEID, is also required in the proposed ADDL, even if it is the same value across all rows in the dataset. All of these identifiers exist in SDTM, and would be copied unchanged into ADDL. In the proposed ADDL structure, the start and end date variables (DEVSDT and DEVEDT) are required, however the definitions of DEVSDT and DEVEDT will depend on the study. For example, DEVSDT could be the date a device with implanted and DEVEDT the date explanted, or DEVSDT could be the date the device was turned on and DEVEDT the date turned off. Other dates may be included in addition to, but not instead of, DEVSDT and DEVEDT; this allows you to count on the pair of variables DEVSDT and DEVEDT to define the start and end of device use, regardless of study. In long-term studies of subjects with multiple devices, it might be useful, especially when subject age could affect efficacy, to capture the age of the subject at the start of each device exposure. AGEDST is the proposed name for the age of the subject at the start of the device, and this is a permissible variable. Most of the source data needed for ADDL can be found in SDTM domains DI ( Identifiers), DR (-Subject Relationships), PR (Procedures), and DX ( Exposure). ADDL EXAMPLE The following example shows a few rows of an ADDL with multiple devices per subject: Row USUBJID SPDEVID MODEL MODELG1 MODELG1N TYPEGR1 BRTHDT AGEDST Unique Subject Identifier Sponsor Identifier Model Model Group 1 Model Group 1 (N) Type Group 1 of Birth 1 1001 G003 Model 1 Model A 1 GENERATOR 1940-01-01 59 2 1001 G2002 Model 2 Model A 1 GENERATOR 1940-01-01 71 3 1001 W0101 Model 123 Model B 2 WIRE 1940-01-01 59 Subject Age at First Exposure to Row DEVSDT DEVEDT DEVIPDT DEVXPDT DEVONDT DEVOFDT DEVRPDT DEVMDDT of First Exposure to of Last Exposure to Implanted Explanted Turned On Turned Off Repositioned Modified 1 1999-12-01 2011-06-06 1999-12-01 2011-06-06 1999-12-15 2011-03-03 2008-04-01 2 2011-06-06 2011-06-06 2011-06-06 3 1999-12-01 1999-12-01 1999-12-15 2014-05-05 Figure 4: Example ADDL Additional variables, not shown above, could include flags that denote whether a device was implanted, explanted, etc., which would enable counting for summary tables. 3

ADaM for Medical s: Extending the Current ADaM Structures, continued OCCURRENCE DATA STRUCTURE (OCCDS) FOR MEDICAL DEVICES The proposed Medical version of OCCDS is very similar to the current ADaM OCCDS structure. The only differences have to do with the identifier requirements. OCCDS STRUCTURE AND VARIABLES The current ADaM OCCDS structure requires USUBJID, which as explained above may not be collected in medical device studies. In the proposed Medical version of OCCDS, the variable SPDEVID is required, and the USUBJD requirement has been changed to conditionally required. There is only one other variable in the proposed Medical s OCCDS that is different from the current ADaM OCCDS: ASEQ. The CDISC Notes in the current ADaM OCCDS structure explain that this assigned sequence number ASEQ must be unique within a subject (USUBJID). In the proposed Medical OCCDS, sequence number uniqueness is instead required within SPDEVID. Because of these changes to the dataset identifiers, dataset meta is affected. In the proposed Medical OCCDS, SPDEVID is a key variable. OCCDS EXAMPLE The following example shows a few rows of a Medical OCCDS dataset containing device events: Row USUBJID SPDEVID DEVSDT DEVEDT DETERM DESTDTC ASTDT 1 1001 G003 1999-12-01 2011-06-06 POWER CONDITIONING ISSUE 2009-12-28 2009-12-28 2 1001 W0101 1999-12-01 BENT 2013-08-08 2013-08-08 Figure 5: Example OCCDS for Events Analysis Note that: 1. Variables USUBJID and SPDEVID are keys that would be used to merge or join input datasets ADDL and SDTM DE. 2. Variables DEVSDT and DEVEDT would be copied from ADDL. 3. Variables DETERM and DESTDTC would be copied from SDTM DE. 4. Variable ASTDT is a numeric date, derived from the character DESTDTC. 5. This example dataset contains just device events from SDTM domain DE. Other adverse events, not associated with a device, would be found in SDTM AE, and analysed without SPDEVID. This type of dataset could be used to produce a summary table of device events. BASIC DATA STRUCTURE (BDS) FOR MEDICAL DEVICES The proposed Medical version of BDS is very similar to the current ADaM BDS structure. The only differences have to do with the identifier requirements. BDS STRUCTURE AND VARIABLES The current ADaM BDS structure requires USUBJID, which as explained above may not be collected in medical device studies. In the proposed Medical version of BDS, the variable SPDEVID is required, and the USUBJD requirement has been changed conditionally required. There is only one other variable in the proposed Medical s BDS that is different from the current ADaM BDS: ASEQ. The CDISC Notes in the current ADaM BDS structure explain that this assigned sequence number ASEQ must be unique within a subject (USUBJID). A similar requirement is needed for device studies, so in the proposed Medical BDS, sequence number uniqueness is required within SPDEVID. 4

ADaM for Medical s: Extending the Current ADaM Structures, continued Because of these changes to the dataset identifiers, dataset meta is affected. In the current BDS structure, the dataset is structed as one or more records per subject, per analysis parameter, per analysis timepoint, where timepoint is optional. The proposed structure for the Medical version of BDS is one or more records per device, per subject, per analysis parameter, per analysis timepoint, where subject and timepoint are optional. BDS EXAMPLE The following example shows a few rows of a Medical BDS dataset for time-to-device-event analysis: Row USUBJID SPDEVID PARAM PARAMCD STARTDT ADT AVAL CNSR 1 1001 G003 2 1001 G2002 3 1001 W0101 TIME TO FIRST DEVICE EVENT (MONTHS) TIME TO FIRST DEVICE EVENT (MONTHS) TIME TO FIRST DEVICE EVENT (MONTHS) TTFDE 1999-12-01 2011-06-06 138 0 TTFDE 2011-06-06 2016-08-10 62 1 TTFDE 1999-12-01 2013-08-08 164 0 Row EVENTDESC SRCDOM SRCVAR SRCSEQ 1 DEVICE REPOSITIONED ADDATES ADT 2 2 END OF STUDY ADDATES ADT 10 3 DEVICE BENT ADDATES ADT 8 Figure 6: Example BDS for Time-to--Event Analysis Notes: 1. This time-to-device-event dataset looks very similar to a typical time-to-event dataset found in drug and biologic studies. The only difference here is the inclusion of SPDEVID. 2. SRCDOM for all rows is ADDATES. This idea of using an intermediate dataset called ADDATES to collect all the dates that could be used as events or censoring was first published in the Prostate Cancer Therapeutic Area User Guide (Provisional, April 2017). The example ADDATES for the above time-to-device-event dataset is: Row USUBJID SPDEVID ASEQ ADT ADTDESC ADTDESCD SRCDOM SRCVAR SRCSEQ 1 1001 G003 1 1999-12-01 of First Exposure to DEVSDT ADDL DEVSDT 1 2 1001 G003 2 2008-04-01 Repositioned DEVRPDT ADDL DEVRPDT 1 3 1001 G003 3 2009-12-28 of Event ASTDT ADDE ASTDT 1 4 1001 G003 4 2011-03-03 Turned Off DEVOFDT ADDL DEVOFDT 1 5 1001 G003 5 2011-06-06 Explanted DEVXPDT ADDL DEVXPDT 1 6 1001 G2002 6 2011-06-06 of First Exposure to DEVSDT ADDL DEVSDT 2 7 1001 W0101 7 1999-12-01 of First Exposure to DEVSDT ADDL DEVSDT 3 8 1001 W0101 8 2013-08-08 of Event ASTDT ADDE ASTDT 2 9 1001 W0101 9 2014-05-05 of Modified DEVMDDT ADDL DEVMDDT 3 10 1001 10 2016-08-10 End of Study EOSDT ADSL EOSDT. Figure 7: Example ADDATES Intermediate 5

ADaM for Medical s: Extending the Current ADaM Structures, continued Note that: 1. All rows are specific to a single device, other than row 10 which is the end of study date (used for censoring) 2. Variable ASEQ is created within this intermediate dataset for the sole purpose of being used as a reference in the time-to-device-event dataset. Notice that row 1 in Figure 6 points to ADDATES sequence number 2, which is the row the describes the device repositioning. Whenever one ADaM dataset is used as input to another ADaM dataset, the variable ASEQ in the predecessor dataset is used to provide traceability. 3. While many BDS variables are used in ADDATES, some required BDS variables are not included, such as PARAM, PARAMCD, and either AVAL or AVALC. As an intermediate dataset not being used directly for analysis, these standard and required BDS variables are not needed. CONTROLLED TERMINOLOGY FOR CLASS Define-XML uses controlled terminology for CLASS to describe the structure of every ADaM dataset. At the time of this writing, only 4 choices exist for ADaM dataset class: 1. SUBJECT-LEVEL ANALYSIS DATASET 2. BASIC DATA STRUCTURE 3. OCCURRENCE DATA STRUCTURE 4. ADAM OTHER Items 1-3 are ADaM structures used in human clinical studies. ADaM datasets that do not fit into one of the first three classes listed are of class ADAM OTHER. It is the intention to add a class of DEVICE-LEVEL ANALYSIS DATASET, but until that happens the only choice for an ADDL dataset as described in this document would be ADAM OTHER. For the modified BDS and OCCDS structures described, you could either refer to them as class ADAM OTHER, or use BASIC DATA STRUCTURE and OCCURRENCE DATA STRUCTURE. An issue with using ADAM OTHER is that it isn t very informative, and these datasets as described mostly follow the existing BDS and OCCDS structures. An issue with using the BASIC DATA STRUCTURE and OCCURRENCE DATA STRUCTURE is that when compliance checks are run based on the current structure requirements, many failures will need an explanation, such as in the conformance section of the Analysis Data Reviewer s Guide. Until there are changes in the controlled terminology, you will need to decide what class values make the most sense for your needs. CONCLUSION This paper walked through some of the material being developed for a document tentatively titled ADaM Implementation Guide for Medical s (ADaMIG-MD). It described a new structure, ADDL, and changes to both BDS and OCCDS to include the device identifier instead of, or in addition to, the unique subject identifier. It also discussed options for handling dataset class until controlled terminology is updated. Be aware that the dataset structures, variable names, and the examples shown in this paper may change during development or after public review. However, with no current standard that addresses these medical device needs, we hope that the content in this paper can be of help as a starting point. REFERENCES All CDISC documents referenced in this paper can be downloaded from https://www.cdisc.org/ or https://wiki.cdisc.org/. 6

ADaM for Medical s: Extending the Current ADaM Structures, continued RECOMMENDED READING Analysis Data Model Implementation Guide version 1.1 Study Data Tabulation Model Implementation Guide for Medical s (SDTMIG-MD) - Provisional Prostate Cancer Therapeutic Area User Guide CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the authors at: Sandra Minjoe PRA Health Sciences MinjoeSandra@prahs.com Julia Yang Medtronic PLC Julia.Yang@medtronic.com Priya Gopal TESARO, Inc. pgopal@tesarobio.com 7