Rule AD1002

AD1002

I would agree.  Problem is that this varible is defined as core=expected and we have a general warning rule when any expected variable is not at least PRESENT (can be null) in the dataset.  

Solutions:

1. always include the variable and leave it null to escape the warning.  

2. Change your \config\config-adam-1.0.xml file and set the core attribute to permissible for all of these or just the ones your study does not expect

<ItemRef ItemOID="TRTSDT" val:Core="Permissible"/>

<ItemRef ItemOID="TRTSDTM" val:Core="Expected"/>

<ItemRef ItemOID="TRTEDT" val:Core="Permissible"/>

<ItemRef ItemOID="TRTEDTM" val:Core="Expected"/>  

3.) At the openCDISC level, we could make all these variables Permissible and then have a new validation (similar to AD0061 and AD1005) that ensures at least one of TRTSDT or TRTSDTM is present.

I'll have to talk it over with the CDISC ADaM Validation Compliance Subteam and the OpenCDISC development team.  Both are independent entities, but i participate in both.

thanks for you feedback.   And again, please feel free to edit your local file to make the warnings go away.  if it's for a submission, just include your explanation to the FDA.

Problem is with 'expected' terminology

Unfortunately this problem arises from a disconnect between the SDTM "core" terminology and the ADaM "core" terminology.

In the ADaM IG, TRTSDT is core="Conditional" which is a bit useless from a compliance-checking perspective. It is "conditional" on 2 things: first, it must be an interventional study (must have a treatment) and second, if #1 is satisfied, either TRTSDT or TRTSDTM must exist. Depending on the status of these conditions, the variable either does or does not need to be present.

So applying the SDTM "expected" algorithm (must be present, but may not be populated) to these variables isn't supported by the ADaM IG.

Randall Austin

Change Ticket exists for AD1002

I verified that a ticket exists in the issue tracking system to address the conditions for when AD1002 fires.  We hope to address this in either the next engine release or ADaM validation check release which should conincide with the official CDISC ADaM VC v1.2  

I agree with Natalie and Randall and appreciate the detailed feedback.   i believe that the latter part of this check will work like AD1005 (AVAL or AVALC must be present) once we determine that this is indeed an interventional study.   Randall, what metadata in the adam dataset can we programmatically use with 100% certaintly to check the "interventional study" condition ?  

I would also suggest to the ADaM team to include information in the validation checks document which can aid rule developers.   In essence, the sort of information that might be found in an IG.  Although i recognize creating a separte IG for the checks is unnecessary.   Finally, i understand AD1002 was not a check published by CDISC ADaM team, but rather OpenCDISC's interpretation of the "core" concept to be consistent with SDTM.   These checks might be worthwhile to publish as well.

Thanks.

Mike DiGiantomasso

OpenCDISC community developer

Interventional or not?

Re: "Randall, what metadata in the adam dataset can we programmatically use with 100% certaintly to check the "interventional study" condition?" That's the challenge --- we can easily detect whether some, but not all, of the variables exist for an interventional study (e.g., we have TRTA but not TRTSTDT) but there isn't a reliable way to know if it is interventional and everything related to treatment has been left out. That's why the ADaM Compliance Team didn't attempt to tackle that one.

Randall Austin

It seems that the condition for AD1002 has not been modified

Hi Mike,

Is OpenCDISC still planning to make changes to the conditions that trigger AD1002? Is there a way to bowse the issue database? I don't want to reopen an issue that had already been raised.

Thanks,

Jian