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 |
You can send to mike@opencdisc.org. I will look at it promptly
I have got the same message for AP01SDT.
| VARIABLE, LABEL | AP01SDT, Period 01 Start Date | AD0018 | Variable label mismatch between dataset and ADaM standard |
|---|
Thanks,
Rob
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.
Date/Time of …
ItemDef OID |
Description/TranslatedText (label) |
|---|---|
*DT |
Date of … |
*TM |
Time of … |
*DTM |
Date/Time of … |
*ADY |
Relative Day of … |
*DTF |
Date Imputation Qual of … |
*TMF |
Time Imputation Flag of … |
*SDT |
Start Date of … |
*STM |
Start Time of … |
*SDTM |
Start Date/Time of … |
*SDY |
Relative Start Day of … |
*SDTF |
Start Date Imputation Flag of … |
*STMF |
Start Time Imputation Qual of … |
*EDT |
End Date of … |
*ETM |
End Time of … |
*EDTM |
End Date/Time of … |
*EDY |
Relative End Day of … |
*EDTF |
End Date Imputation Flag of … |
*ETMF |
End Time Imputation Flag of … |
I noticed in the XML for the affected elements that some had elements. For example:
End Date Imputation Flag of …
Should we always remove the entire element, or if it contains a element should that remain? For example:
Thanks…
Change this
End Date Imputation Flag of …
to this
Next version of Pinnacle Community will fix this.
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?
Thanks
Steve
Can you send me your sas .xpt file with the bad labels. You can just include 1 row.
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.
Long term solution (for Pinnacle)
1.) 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 |
ADSL variabled Copied to BDS |
|||
|
BDS |
TRT__*__P |
Planned Treatment for Period $1 |
BDS |
TRTSEQP, Planned Sequence of Treatments |
|
BDS |
TRT__*__PN |
Planned Treatment for Period $1 (N) |
BDS |
TRTSEQPN, Planned Sequence of Treatments (N) |
|
BDS |
TRT__*__A |
Actual Treatment for Period $1 |
BDS |
TRTSEQA, Actual Sequence of Treatments |
|
BDS |
TRT__*__AN |
Actual Treatment for Period $1 (N) |
BDS |
TRTSEQAN, Actual Sequence of Treatments (N) |
Rob, for this one, you may also be experiencing the issue where it is comparing it to *SDT. Make sure you remove those labels and rerun. AP01SDT should only be in ADSL dataset.
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 ?
Most false positives deal with labels in data. And these issues are specific to
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
Mike.
Hi,
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.
Example:
CRIT1=”Decrease of >= 20% from baseline”
CRIT1N=3
CRIT1FL=”N”
CRIT1FN=0
Could you update this check to allow corresponding numerical variables which using “* (N)” as Label?
Hi,
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?
Thanks,
Rob
Hi Mike,
Is there a plan to be adding this to the BDS configuration? People are reporting to me they are getting the AD0018 error for these 4 labels.
Thanks,
Joan
Hi,
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.
Br,
Malathi