Some Considerations When Designing ADa M Datasets Italian

  • Slides: 28
Download presentation
Some Considerations When Designing ADa. M Datasets Italian CDISC UN Day - Milan 27

Some Considerations When Designing ADa. M Datasets Italian CDISC UN Day - Milan 27 th October 2017 Antonio Valenti Principal Statistical Programmer CROS NT - Verona

Content Disclaimer All content included in this presentation is for informational purposes only. These

Content Disclaimer All content included in this presentation is for informational purposes only. These are from personal notes taken during the attendance of the webinar in reference. Please refer to the original presentation and to the latest published standards documents for the most authoritative implementation information.

Reference CDISC Members Only Mini-Training Series Some Considerations When Designing ADa. M Datasets Nate

Reference CDISC Members Only Mini-Training Series Some Considerations When Designing ADa. M Datasets Nate Freimark, Vice President -Clinical Programming and Date Standards, The Griesser Group CDISC Webinar 09 MAR 2017

Overview General concepts ADSL related tips &FAQ BDS related tips &FAQ OCCDS related tips

Overview General concepts ADSL related tips &FAQ BDS related tips &FAQ OCCDS related tips &FAQ

General #1 Variables selection Just because a variable is defined in the ADa. MIG

General #1 Variables selection Just because a variable is defined in the ADa. MIG does not mean it has to be created in an/all ADa. M datasets: SITEID/SUBJID in all BDS datasets TM and DTM variables when time is missing Numeric variables not used in analysis (i. e. ARMN) Null variables (i. e. AVISIT/AVISITN) Variables from ADSL can be copied to other ADa. M datasets without renaming to a new variable (i. e. AX 01 SDT in BDS = ADSL. TR 01 SDT) Variables coming from SDTM should be copied without changes, but bad SDTM should not necessarily translate to bad ADa. M (i. e. TPT containing VISIT)

General #2 Date/time variables Respect suffix conventions (DT, TM, DTF, TMF, DY) Date/time variables

General #2 Date/time variables Respect suffix conventions (DT, TM, DTF, TMF, DY) Date/time variables should have associated study day variables. When date/time imputation are needed it is a good idea to keep the SDTM variable that contains the partial value Creating the DT, TM, and DTM triplicate just because it can be done is not necessary For a given SDTM DTC variable, if only hh and mm are collected, and ss are imputed in *DTM as 00, then it is not necessary to set *TMF to “S”. However if collected but are missing should be qualified in *TMF.

General #2 (example) Date/time Example 1 SDTM ADAM --DTC --DT --TM 2014 -02 -24

General #2 (example) Date/time Example 1 SDTM ADAM --DTC --DT --TM 2014 -02 -24 T 12: 00 2014 -02 -24 12: 00 1 2014 -03 -10 T 10: 30 2014 -03 -10 10: 30: 00 16 --DY Date/time Example 2 SDTM --DTC ADAM --DT --TMF --DY 2014 -02 -24 T 12: 00 2014 -02 -24 12: 00 S 1 2014 -03 -10 T 10: 31: 50 2014 -03 -10 10: 31: 50 16

General #3 Visit/Time Point Variables AVISIT/AVISITN/ATPT/ATPN should be the timing variables that are in

General #3 Visit/Time Point Variables AVISIT/AVISITN/ATPT/ATPN should be the timing variables that are in datasets –VISIT/VISITNUM/--TPTNUM should also be kept if the values/algorithms differ VISIT/VISITNUM have to come from SDTM and cannot be derived/changed in ADa. M but bad SDTM should not necessarily translate to bad ADa. M (TPT containing VISIT values) AVISIT –last value within a window is not an ENDPOINT value unless you are outputting an extra record –if true then DTYPE has to be present. If not then ANLzz. FLshould be used AVISIT –RESCREEN/UNSCHEDULED are not generally valid AVISIT values unless they are summarized on the table or defined in the SAP – if not they should be null (or windowed)

General #3 (example) Visit/time point bad implementation AVISIT ATPT Day 1 – 12 h

General #3 (example) Visit/time point bad implementation AVISIT ATPT Day 1 – 12 h Baseline PARAM Heart rate (bpm) – Day 1 – 12 h Baseline DIASTOLIC BLOOD PRESSURE Visit/time point good implementation AVISIT ATPT PARAM Day 1 12 h Heart rate (bpm) Baseline uses XXSTRESU value Diastolic Blood Pressure (mm. Hg)*

ADSL #1 Population Flags ITTFL do not created it, if is same as RANDFL

ADSL #1 Population Flags ITTFL do not created it, if is same as RANDFL and not defined in protocol/SAP RANDFL – why is it tied to being dosed? DISCFL this appears to be the inverse of COMPLFL (only one) NOMEDFL what is the purpose of a combination flag? (use the available flags) Some population flags in the efficacy analysis are too complicated. Can we generate these population flags by referring to each other? Circular logic is always a concern

ADSL #2 Treatment Variables ARM/ARMCD are not analysis variables do not have to be

ADSL #2 Treatment Variables ARM/ARMCD are not analysis variables do not have to be included in every dataset – Use (TRTSEQP) There is no variable ARMGR 1 in ADa. M ARMN is not necessary ARM is required per the ADa. MIG v 1. 1 for traceability, ACTARM is perm TRT 01 A –do you check whether Actual differs from Planned or do you always create? Check order TRT 01 P vs TRT 02 P (TR 01 SDT/TR 01 EDT vs TR 02 SDT/TR 02 EDT). Check also TRTSEQP (order is reversed? )

ADSL #3 Treatment duration Duration AEXDURN –I don’t see why this is prefixed with

ADSL #3 Treatment duration Duration AEXDURN –I don’t see why this is prefixed with A/Analysis – EXDURN is sufficient xxx. DUR– DUR in SDTM is ISO 8601. Use ADa. MIG v 1. 1 defined variables and xxx. DURC (if needed) ADSL –do you have any subjects with missing disposition records? it should be null in that case and not “discontinued” –make sure metadata covers all scenarios

ADSL #4 Date Variables APxx. SDT/APxx. EDT are paired variables –both or neither should

ADSL #4 Date Variables APxx. SDT/APxx. EDT are paired variables –both or neither should be present There should not be more APxx variables then there are TRTxx. P ADSL. TRTSDT/TRTEDT –required ADSL. TR 01 SDT/TR 01 EDT –not needed in a single period trial TRTSDT/TRTEDT based on RFX not RF (start of trt not the study) LSTVST (based on Last SV record in spec)? SV has no “order” unless VISITNUM is in the correct order VISITNUM (i. e. 99 for Unscheduled) Is there a reason you format dates as DATE 9 instead of YYMMDD 10? No right or wrong but you should be consistent across datasets

ADSL #5 Other Variables SEX per SDTM is M/F –you cannot change any SDTM

ADSL #5 Other Variables SEX per SDTM is M/F –you cannot change any SDTM variable value in ADa. M DEATHFL –why not use SDTM variable DTHFL? DSTERM/DSDECOD may be one of several DS records –renaming to useful concept is helpful HEIGHT should be HEIGHTBL or BLHEIGHT to indicate it is a baseline value (similar to label) Baseline variables should start or end with BL and not just B AGEU is required

BDS #1 Population flags all BDS have to have at least one population flag

BDS #1 Population flags all BDS have to have at least one population flag variable –however not all ADSL population variables have to included in every ADa. M dataset Can we add free text to the label of ANLzz. FL or any variable with y, zz, xx? e. g: added text “Analysis Flag zz–Last for Dup. Records”. Yes for y and zz but not for xx ADxx-xxxxx. FL–values of 1 -4 are not allowed for an FL variable ADLB -no ANLzz. FL variables are needed for analysis? (this is possible if there are no multiple nominal visit values and unscheduled values are not summarized) Is –BLFL=Y always the value where ABLFL=Y?

BDS #2 Incorrect/Iffy Variables/Values AVALU is not a valid ADa. M variable –if unit

BDS #2 Incorrect/Iffy Variables/Values AVALU is not a valid ADa. M variable –if unit is relevant it should be included in PARAM if not then just keep ORRESU/STRESU ADxx-AVALC is not left-justified for numeric values (nor does AVALC have to be populated for numeric parameters) ADDV -AVALC – are these values actually analyzed/summarized? Is there a protocol deviation summary –why was this ADa. M created? Shouldn’t ADDV be OCCDS in any case? ADPE -Summary is by AVISIT –why are ABLFL/BASEC needed?

BDS #3 PARAM/PARAMCD/LBCAT ADLB -LBTEST/LBTESTCD generally are not sufficient for PARAM/PARAMCD in labs since

BDS #3 PARAM/PARAMCD/LBCAT ADLB -LBTEST/LBTESTCD generally are not sufficient for PARAM/PARAMCD in labs since there are the same –TEST in CHEMISTRY and URINALYSISPARAM/PARAMCD have to uniquely identify -using PARCAT 1 is not allowed –GLUC cannot have two different PARCAT 1 values Is it your standard or the sponsor’s standard to capture LBCAT in PARAM instead of only the ones that are common in more than one LBCAT? Any value added in capturing on all PARAMCD? Only add U to the ones that are in more than one LBCAT can be enough

BDS #3 (Example) PARAM/PARAMCD/LBCAT Wrong definition PARAMCD PARAM PARCAT 1 CA Urine Calcium URINALYSIS

BDS #3 (Example) PARAM/PARAMCD/LBCAT Wrong definition PARAMCD PARAM PARCAT 1 CA Urine Calcium URINALYSIS CA Blood Calcium CHEMISTRY RBC Blood Erythrocytes HAEMATOLOGY CAU Urine Calcium URINALYSIS CA Calcium CHEMISTRY RBC Erythrocytes HAEMATOLOGY Correct definition

BDS #4 Incorrect/Iffy Variables/Values (continue) ADLB -A lot of the PARAM appear to be

BDS #4 Incorrect/Iffy Variables/Values (continue) ADLB -A lot of the PARAM appear to be CRIT values and should not be added parameters (e. g. ALKGR 15) -for the ones that look at multiple PARAM it makes sense but not so much for the ones that are within PARAM

BDS #4 (Example) PARAM/PARAMCD/LBCAT Bad definition PARAMCD AVAL ALK 20 ALKGR 15 20 AVALC

BDS #4 (Example) PARAM/PARAMCD/LBCAT Bad definition PARAMCD AVAL ALK 20 ALKGR 15 20 AVALC Y Good definition PARAMCD AVAL CRIT 1 FL ALK 20 ALK > 15 Y

BDS #5 BASE/BASETYPE ADLB -BASETYPE is not populated for all records within a PARAM

BDS #5 BASE/BASETYPE ADLB -BASETYPE is not populated for all records within a PARAM ADLB/ADVS -Having BASE and not CHG seems odd –what is the purpose? BASE should reference ABLFL and not AVISITN ADa. MIG -BASE contains the value of AVAL copied from a record within the parameter on which ABLFL = “Y” (and BNRIND=ANRIND where ABLFL=‘Y’) AVALCATy/CRITy ADxx. AVALCAT 1/AVALCAT 2 -these can only be categorizations of AVAL –only CRITy/MCRITy can be based on “any” variable CRITy has to be a constant value within PARAM – if it varies then use AVALCATy (or MCRITy. ML)

BDS #5 (Example) AVALCATy/CRITy Bad definition AVALC CHG AVALCAT 1* 90 High 20 GT

BDS #5 (Example) AVALCATy/CRITy Bad definition AVALC CHG AVALCAT 1* 90 High 20 GT 90 and CHG > 20 95 High 10 Good definition AVALC CHG AVALCAT 1 CRIT 1* CRIT 1 FL* 90 20 High Y 95 10 High GT 90 and CHG > 20

BDS #6 Timing Variables ENDPOINT BASELINE is not a correct AVISIT value –this should

BDS #6 Timing Variables ENDPOINT BASELINE is not a correct AVISIT value –this should be AVISIT=BASELINE with DTYPE=AVERAGE. Why are there AVISIT=ENDPOINT xxxx in any case –it does not have that on the tables What does ATPT=ENDPOINT 0. 5 H POST-DOSE mean? If these are supposed to identify the average value then DBTYPE should be used and not a changed ATPT value –it is not a different visit/timepoint ADTC – often included this. Value added?

BDS #7 DTYPE=SUM or COMBINED is incorrect –DTYPE is for records within a parameter

BDS #7 DTYPE=SUM or COMBINED is incorrect –DTYPE is for records within a parameter and not totally derived parameters DTYPE=MAXIMUM (used to identify a maximum record) -this is incorrect usage of DTYPE -there is no indication that there is an added row with AVISIT="Maximum" -this should be identified with an ANLzz. FL DTYPE=EOT is not correct –it does not describe the derivation method (it could be LOV Last Observed Value) ADLB -LBMAXFL/LBMINFL/POSTHIFL/POSTLOFL (and all the rest of the flags) –these should all be ANLzz. FL (or AVISIT added rows) –see section 4. 5. 3. 1 of the ADa. MIG

BDS #7 (Example) Wrong AVISIT PARAMCD AVAL Week 1 DBP 80 Week 2 DBP

BDS #7 (Example) Wrong AVISIT PARAMCD AVAL Week 1 DBP 80 Week 2 DBP 120 Use ANLxx. FL Add AVISIT and Use DBTYPE POSTHIFL MAXIMUM Y AVISIT PARAMCD AVAL Week 1 DBP 80 Week 2 DBP 120 ANL 01 FL Y AVISIT PARAMCD AVAL DBTYPE Week 1 DBP 80 Week 2 DBP 120 Post-Baseline Maximum DBP 120 MAXIMUM

OCCDS #1 ADAE -Creating records with ANYAE=N and populating AETERM with None for subjects

OCCDS #1 ADAE -Creating records with ANYAE=N and populating AETERM with None for subjects with no AEs is not allowed AEDUR is an SDTM variable that is character and ISO 8601 –it cannot be changed to numeric in ADa. M. Use ADURN (derived) Do not change SDTM variables as AEOUTR (SDTM. AEOUT), AESEV should be SDTM. AESEV TRTEMFL -derivation may not be correct if time is imputed –use caution in defining TRTEMFL ASTDT should be included even if ASTDTM is present. No a requirement –just a suggestion

OCCDS #2 ADCM /ADMH ADCM -CMDOSU/CMDOSFRQ/CMROUTE changed from SDTM values –this is not allowed

OCCDS #2 ADCM /ADMH ADCM -CMDOSU/CMDOSFRQ/CMROUTE changed from SDTM values –this is not allowed ADMH –ASTDT/AENDT –do these add value? These appear to be mostly partial dates

Conclusion Thanks for your attention Questions?

Conclusion Thanks for your attention Questions?