Rule AD0129 - AD0130, AD0149 - AD0150

Posted Thu, 03/03/2011 - 04:57 by nsteigerwald

Hi *,

I have a question regarding the rules AD0129 - AD0130, AD0149 - AD0150. I got some errors, for e.g. ADLB, where the numerical value is not the same as the character value within the parameter. But for some parameters from e.g. URINALYSIS, numerical values are not possible.

It is stated in the guideline on page 27:

Character analysis value described by PARAM. AVALC can be a character string mapping to AVAL, but if so there must be a one-to-one map between AVAL and AVALC within a given PARAM. AVALC should not be used to categorize the values of AVAL.

 

See also example 3 on page 78, where 'Y'  is not coded and even for numerical values AVALC is missing. Is it possible to change the rule.

One option would be to check if AVALC and AVAL are presented, they must be the same.

Similar for the BASE and BASEC variable.

‹ Rule AD0124 Rule AD0138 ›
mdigian's picture

Rule AD0129 - AD0130, AD0149 - AD0150 - answer

by mdigian - 03/03/2011 - 15:37

short answer:

You are correct that only one of AVAL or AVALC are required by ADaM.   Yes, I believe we need to only run the rule when AVAL is not null in 149 and AVALC is not null in 150.  (same applies to BASE and BASEC) and possibly 109/110 (AVISIT & AVISITN within PARAMCD).  Thanks for discovering this.

 

Long answer , sample data and quick fix (for those wanting more....)

 

Here's the abbreviated version of how the rule is implemented in OpenCDISC.  The code in red can be applied to your config to fix the issue until it's released in next version

ID When GroupBy Variable (to validate) Description
AD0129 PARAMCD != '' @and BASEC != '' PARAMCD,BASEC BASE For a given BASEC value, all BASE values should be the same within a PARAMCD
AD0130 PARAMCD != '' @and BASE != '' PARAMCD,BASE BASEC For a given BASE value, all BASEC values should be the same within a PARAMCD
AD0149 PARAMCD != '' @and AVAL  != '' PARAMCD,AVAL AVALC For a given AVAL value, all AVALC values should be the same within a PARAMCD
AD0150 PARAMCD != '' @and AVALC  != '' PARAMCD,AVALC AVAL For a given AVALC value, all AVAL values should be the same within a PARAMCD

* note that This rule is not to ensure that AVAL = AVALC for each distinct PARAM.   

  1. In AD0149, The idea is that only for a given combo of PARAMCD + AVAL, … AVALC must be mapped consistently. 
  2.  Here you can see that record 6 will fail because the validator already associated {MIGRAINE,1} with Mild Pain in record 3.  
  3. So in record 6, {MIGRAINE,1} with BAD Pain will trip the rule and throw an error.  
  4. The issue you are facing deals with nulls.  
  5. By only running the rule when the params you group by are NOT NULL, this should solve your issue and records 11,12,14,15 should not fail anymore
rec_id STUDYID USUBJID PARAMCD AVAL AVALC result Desc
1 123 10001 MIGRAINE 3 Severe Pain pass  
2 123 10001 MIGRAINE 2 Moderate Pain pass  
3 123 10001 MIGRAINE 1 Mild Pain pass  
4 123 20001 MIGRAINE 3 Severe Pain pass  
5 123 20001 MIGRAINE 2 Moderate Pain pass  
6 123 20001 MIGRAINE 1 BAD Pain fail for MIGRAINE, you can't map "BAD Pain" and "Mild Pain" to AVAL=1
7 123 30001 EARPAIN 3 Severe Pain pass  
8 123 30001 EARPAIN 2 Moderate Pain pass  
9 123 30001 EARPAIN 1 GOOD Pain pass You can map GOOD Pain to AVAL = 1, since this is for EARPAIN
10 123 30001 BACKPAIN 3   pass (BACKPAIN, NULL: mapped to 3)
11 123 30001 BACKPAIN 2   fail (BACKPAIN, NULL: mapped to 2)
12 123 30001 BACKPAIN 1   fail (BACKPAIN, NULL: mapped to 1)
13 123 30001 BACKPAIN   Severe Pain pass (BACKPAIN, NULL: mapped to Severe Pain)
14 123 30001 BACKPAIN   Moderate Pain fail (BACKPAIN, NULL: mapped to Moderate Pain)
15 123 30001 BACKPAIN   Mild Pain fail (BACKPAIN, NULL: mapped to Mild Pain)

 

Sincerely

Mike DiGiantomasso

Pinnacle 21

Rule AD0129 - AD0130, AD0149 - AD0150 - answer

by nsteigerwald - 03/04/2011 - 08:47

Hi Mike,

that sounds great. However, no changes on AVISIT and AVISITN is needed. See guideline 'there is a one-to-one mapping between AVISITN and AVISIT '

 

Regards,

Natalie

mdigian's picture

AVISITN and AVISIT within PARAMCD

by mdigian - 03/02/2012 - 01:22

Hi Natalie, just to let you know, i'm working on fixing all these issues and implementing the CDISC ADaM Validation Checks 1.1.   We plan to release them this march with our 1.3 version of the validator engine

As part of the 1.1
release, CDISC issued a text change for 109 to clarify that AVISITN and AVISIT
should be the same for a given PARAMCD.  
However the same thing was not asserted in rule 110.  In general i believe it was stated correctly in 1.0 such that PARAMCD should be ignored.   I have alerted this to the CDISC ADaM validation team.

mdigian's picture

SHIFTy and SHIFTyN

by mdigian - 03/02/2012 - 01:52

ADaM 1.1 checks also specify that SHIFTy and SHFITyN should only be consistent ONLY within a PARAMCD.  This seems to make sense.   Do you agree ?

SHIFTy and SHIFTyN

by nsteigerwald - 03/02/2012 - 03:35

HI,

yes that makes also sense to me.

Thanks for providing an update.

Kind regards,

Natalie

Rule AD0129 - AD0130, AD0149 - AD0150

by nsteigerwald - 08/22/2011 - 06:12

Hi Mike,

now we are using the validation checks, version 1.2.1, and the above rules are not incorporated. My understanding was, that it would be corrected/implemented in the new version. We wouldn't like to do such changes to the program by ourselves, as every new version would produce the same warnings/errors, which would need to be updated every time.

Do you think, the rules above will be incorporated in the next version by the OpenCDISC team.

 

Thanks,

Natalie 

mdigian's picture

ADaM versions

by mdigian - 08/29/2011 - 16:26

Hi Natalie

Sorry for the confusion and delay.    At this time, OpenCDISC Validator software engine is at v1.2.1 released in April 2011.   This ships with multiple configuration files, all having their own version.    We can actually release just a new version of the ADaM checks, but to date, all rule changes have always been coupled with an actual software release.  

 

config-adam-1.0.xml   (still at Version 1)

config-define-1.0.xml

config-sdtm-3.1.1.xml

config-sdtm-3.1.2.xml

 

Currently, the CDISC ADaM Compliance subteam (led by Chris Decker for which I participate on) is working on the ADaM Validation Rules v1.2.    I anticipate that once those rules are finalized, we release a new version of the ADaM rules which incorporates all these changes.  I completely understand that you don't want to update the changes each time.    The good news is that this concept of "centrally managing the rules" is being addressed by OpenCDISC enterprise version which should be available by the end of the year.

I'll keep you posted once the revised ADaM 1.0 checks are available.

(and keep in mind 1.0 is the version of the ADaM IG... :)