m Matthias
on

 

Hello,
The rule AD1008 checks for null values in required variables. Many ERRORS are printed due to missing values in TRTP where visit is SCREENING. At this time point I can't assign a planned treatment. Also in the documentation (CDISC ADaM Implementation Guide Version 1.0, page 51) an example displays missing values.
Please update this check.
Best regards,
Matthias

Forums: ADaM

m Michael
on February 4, 2011

Thanks Matthias.   Good catch.   I see what you are referring to on page 51 (Table 4.2.1.8, Creation of Endpoint Rows to Facilitate Analysis of a Crossover Design )

AD1008 wasn't an explicity published rule by the ADaM team.   We applied the same logic from SDTM checks to extend any CORE REQUIRED variable that must be present in the dataset to also be POPULATED/not null.  I will take the feedback to the OpenCDISC community for revision.   We will also bubble up the feedback to the ADaM team.

Any suggestions on how to make this check more practical ?   Is there any other variable we can check to run it conditionally, like "when AVISIT not like 'screen', then TRTP must not be null ?   Or perhaps when APERIOD is not null ??

m Matthias
on February 4, 2011

A possibility would be to check only visit(num)s which can be found in ex.

Best regards,
Matthias

i Iain
on March 7, 2011

Hi,

We have approached this issue for Screening in another way. When we have periods or visits defined as screening/washout/follow-up etc we explicitly set TRTP to be "NO_TRT" so it is clear that there is no planned treatment since we had also interpreted the Req variables as following similar rules to SDTM meaning that TRTP couldn't be null.

Though looking at table of 4.2.1.8 a possibility to handle crossovers would be apply the rule as TRTP or TRTSEQP must not be null?

 Iain

m Matthias
on March 7, 2011

This is a possibility to avoid check AD1008 but the rule should not end in an ERROR. The ADaM rule of required variables is: "Req = Required. The variable must be included in the dataset.", so null values are allowed. The check AD1008 should be deleted in the openCDISC Validator.

Best regards,
Matthias

m Michael
on March 7, 2011

If you delete AD1008, then all these variables will allow nulls.  Would it be better if the ADaM team and OpenCDISC community allowed just a select few to be null, if any ?

Data set role variable label Core
ADSL Identifier STUDYID Study Identifier Req
ADSL Identifier USUBJID Unique Subject Identifier Req
ADSL Identifier SUBJID Subject Identifier for the Study Req
ADSL Identifier SITEID Study Site Identifier Req
ADSL Demographics AGE Age Req
ADSL Demographics AGEU Age Units Req
ADSL Demographics SEX Sex Req
ADSL Demographics RACE Race Req
ADSL Treatment ARM Description of Planned Arm Req
ADSL Treatment TRT01P Planned Treatment for Period 01 Req
BDS Identifier STUDYID Study Identifier Req
BDS Identifier USUBJID Unique Subject Identifier Req
BDS Treatment TRTP Planned Treatment Req
BDS Analysis Parameter PARAM Parameter Req
BDS Analysis Parameter PARAMCD Parameter Code Req
i Iain
on March 7, 2011

Most of these are defined as "must be identical to the the SDTM". So should match the restrictions in SDTM and can be split in two - where the variable is Req in SDTM e.g. SEX then the rule can remain as SEX should not be null, however, where the variable is Exp in SDTM e.g AGE then this rule should be removed as AGE is allowed to be null in SDTM and should also be allowed to be null in ADaM.

Excluding those leaves just the 4:

ADSL.TRT01P, BDS.TRTP, BDS.PARAM and BDS.PARAMCD.

I had thought these should all be non null but this isn't what is explicitly written in the implementation guide as pointed out by Matthias.

 

m Matthias
on March 7, 2011

Don't forget that copied variables must follow the same rules and must have the same contents as the original variable. So the check is okay for required SDTM variables. Only the variables TRT01P, TRTP, PARAM and PARAMCD can have null values. From my point of view this is okay.

Best regards,
Matthias

m Michael
on March 7, 2011

thank you Iain and Matthias.   I will add these notes to list of potential changes for next release. 

Data set variable not null Data set variable not null
ADSL STUDYID x   BDS STUDYID x
ADSL USUBJID x   BDS USUBJID x
ADSL SEX x   BDS PARAM x
ADSL SITEID x   BDS PARAMCD x
ADSL ARM x   BDS TRTP  
ADSL SUBJID          
ADSL AGE          
ADSL AGEU          
ADSL RACE          
ADSL TRT01P          
m Michael
on April 15, 2013

For the next release of OpenCDISC ADaM 1.0 rules (v1.3), which will implement as many of the ADaM Validation Checks v1.2 as possible, this rule will be downgraded to a Warning and its message will reflect the new severity.  

m Matthias
on April 16, 2013

Many thanks for this update.

 

n Natalie
on April 16, 2013

HI,

it is unclear to me how/why PARAMCD and PARAM could have Null values? Why are the records then available in the datasets, if PARAMCD is Null?

Thanks,

Natalie

m Michael
on April 16, 2013

Ok i take that back :)

The original rule AD1008 was implemented to ensure all required variables (except TRTP and TRTxxP) were populated.   

The ADaM Validation Checks v1.2 now recognize officially that PARAM and PARAMCD should be populated.  I think it makes sense now to keep AD1008 as an error, but change the attributes to be 

 

  • VARIABLE = %Variables[!TRTP;!TRT##P;!AGE;!AGEU;!RACE;!SUBJID].Core:Required%
  • MESSAGE = Null value not allowed for this required variable
  • DESCRIPTION = Some required variables should not be null (ADaM rules 196 and 197 minimally affirm that PARAM and PARAMCD must be populated.)

 

I wanted to keep just one rule that can cover multiple variable, but exclude an required variables that can be null.  

What do you think ?   

j Joan
on April 29, 2013

Note, AGE and AGEU can have null values (they are Expected variables in SDTM, due to privacy issues).  RACE is also expected, not required, for all values to be nonnull. 

Therefore, these cannot be mandated to be nonnull in ADaM in all records when they are not mandated that way in SDTM.  Variables with identical names to SDTM must be populated identically across the ADAM and SDTM databases.

So it seems AGE and RACE would need different handling from the PARAM/ PARAMCD strict requirement for presence in all records.

Thank you,

Joan

g Guillaume
on October 9, 2013

I couldn't help but notice that a semantic distinction is missing here: maybe it could be interesting to have, in the implementation guide and also in the OpenCDISC checks, the distinction between variables which presence in the domain is required (aka 'required' variables), and variables that are non nullables (aka "mandatory" variables).

Maybe in our context where the word "required" is already used, "mandatory" wouldn't be a good choice. But specifying "nullable" or "non-nullable" for all variables could help.

Don't you think?

On my side, I'm thinking about using the integrity constraints of PROC SQL (available since SAS 9.3) to create my domains with such variable-level constraints.

Want a demo?

Let’s Talk.

We're eager to share and ready to listen.

Cookie Policy

Pinnacle 21 uses cookies to make our site easier for you to use. By continuing to use this website, you agree to our use of cookies. For more info visit our Privacy Policy.