Variable label mismatch between dataset and ADaM standard - AD0018

December 10, 2015


I am using new Pinnacle 21 2.1.0 and am getting following errors in my validator report, which I didnt have in previous versions.

Message: Variable label mismatch between dataset and ADaM standard

Pinnacle 21 ID: AD0018

Values: TRTSDT, Date of First Exposure to Treatment

           TRTSDTM, Datetime of First Exposure to Treatment

   TRTEDT, Date of Last Exposure to Treatment

But according to ADAM IG, labels are fine for these variables.

Can you please look into this.





Those do look right.  Are you sure you don't have any hiddent trailing characters in the labels ?   Also, can you send me your file so i can test with it?  You can remove all the data, just leave 1 row.

TRTSDT Date of First Exposure to Treatment
TRTSDTM Datetime of First Exposure to Treatment
TRTEDT Date of Last Exposure to Treatment
TRTEDTM Datetime of Last Exposure to Treatment

In reply to by Michael

You can send to   I will look at it promptly

In 2.1.0, the ADaM 1.0 IG Placeholder variables were accidentally reintroduced into the document which is used for validation.   The problem sometimes comes down to process and process change in general.  In the past, labels were called labels.  Now they are callled Description/TranslatedText.   Since we maintain a faithful representation of the standards that are merged with validation logic, these labels were accidetnally put back in which makes sense for the IG, but not when trying to validate.   Remove them in th ADaM IG 10.xml and you will not have these issues anymore.

            <ItemDef OID="IT.BDS.*DTM" Name="*DTM" DataType="integer">


                    <TranslatedText xml:lang="en">Date/Time of ...</TranslatedText>



ItemDef OID

Description/TranslatedText (label)


Date of ...


Time of ...


Date/Time of ...


Relative Day of ...


Date Imputation Qual of ...


Time Imputation Flag of ...


Start Date of ...


Start Time of ...


Start Date/Time of ...


Relative Start Day of ...


Start Date Imputation Flag of ...


Start Time Imputation Qual of ...


End Date of ...


End Time of ...


End Date/Time of ...


Relative End Day of ...


End Date Imputation Flag of ...


End Time Imputation Flag of ...

I noticed in the XML for the affected <ItemDef> elements that some had <CodeListRef> elements.  For example:

  <ItemDef OID="IT.BDS.*EDTF" Name="*EDTF" DataType="text">


          <TranslatedText xml:lang="en">End Date Imputation Flag of ...</TranslatedText>


      <CodeListRef CodeListOID="CL.C81223.DATEFL"/> 


Should we always remove the entire <ItemDef> element, or if it contains a <CodeListRef> element should that remain? For example:  <ItemDef OID="IT.BDS.*EDTF" Name="*EDTF" DataType="text">

      <CodeListRef CodeListOID="CL.C81223.DATEFL"/> 



Hi Mike,

After applying the changes, we are also getting some issues for the following variables:

TRTSEQP - Planned Sequence of Treatments

TRTSEQPN - Planned Sequence of Treatments (N)

TRTSEQA - Actual Sequence of Treatments

TRTSEQAN - Actual Sequence of Treatments (N)

I checked the labels and they seem fine. I even went as far as cutting and pasting the exact text from the configuration file and I still get the same results however I don't get this issue if I run against v2.0.2.

Is this a known problem and are we able to amend the configuration to suppress?



Your dataset AD0018.xpt is recognized as BDS.
The 4 variables below are reserved ADSL variables names.  
They are compared against BDS variables of form TRTxxP(N) and TRTxxA(N).
The validator says, “the stuff in between TRT and P, "SEQ", is not IN  [01,...99].   Therefore fail.”  

Immediate easy work around which is true to the open source community model.   

1.  open your components\config\ADaM 1.0.xml
2. Seach for any variable that exists in ADSL, that you want in BDS (if not already there) as in: <ItemRef
 ItemOID="IT.ADSL.TRTSEQP" OrderNumber="35" Mandatory="No" Role="Treatment" val:Core="Conditional"/>
Copy the line above and paste it as the last ItemRef in BDS.  Optionally change the orderNumber, but it probably doesn’t matter.  Rerun and watch your AD0018 go away !


Long term solution (for Pinnacle)

explicity assign every ADSL variable in BDS - can be immediately done with metadata
2.) inspect ADSL variables when validating BDS variable metadata.  Requires software change

ADSL variabled Copied to BDS
explicity exists in BDS config as of 2.1.0)

ADSL variabled Copied to BDS
does not exist in BDS config)



Planned Treatment for Period $1


TRTSEQP,  Planned Sequence of Treatments



Planned Treatment for Period $1 (N)


TRTSEQPN, Planned Sequence of Treatments (N)



Actual Treatment for Period $1


TRTSEQA,   Actual Sequence of Treatments



Actual Treatment for Period $1 (N)


TRTSEQAN,  Actual Sequence of Treatments (N)

In 2.0.2 we did not include these variables in BDS.  This is why you did not get the error when including ADSL.TRTSEQA into your BDS.    Since 2.1.0 has the TRTxxA(N) and P(N) variables are in BDS there was a conflict with the TRTSEQA and TRTSEQP

Why did we include TRTxxA(N) and P(N) into BDS in versions in 2.1.0 ?  

  1. the ADaM IG 1.0 TTE explicity includes them as time to event variables.  
  2. ADaM IG 1.0 says "for BDS that TRTxxP (copied from ADSL) may also be needed for some analysis purposes, and may be useful for traceability and to provide context"
  3. The ADaM IG 1.0 p20 says that any ADSL variable may be copied to BDS.  
Most false positives deal with labels in data.   And these issues are specific to
  1. sas technology .xpt, .sas7bdat
  2. ADaM placeholders fragments (xx, y, zz)  
We as an industry should reconsider (but not eliminate) the effort of validating labels in data against labels in metadata to such an extent, especially when they are not used by automated analysis tools.  They are their to serve manual human review.

Thanks for your patience and support



The check AD0018 incorrectly reports an error. We use corresponding numerical code variables for the CRITy variables, called CRITyN with label “Analysis Criterion y (N)”. This corresponding numerical variable concept is compliant with the ADaM rules and therefore no issue should be reported.


CRIT1=”Decrease of >= 20% from baseline”

Could you update this check to allow corresponding numerical variables which using “* (N)” as Label?


We are getting Variable label mismatch errors for ANL01FL, ANL02FL variables. The label is as per IG. I assume it is the same problem as described above?