Exploring Common CDISC ADaM Conformance Findings

The relationship of PARAM to PARCATy cannot be one-to-many; it must be many-to-one.

• PARCATy is not a qualifier for PARAM; it is a categorization of PARAM within a dataset.
• PARCATy must be a “unique match” to PARAM. That is, any given PARAM may be associated with at most one level of PARCATy (e.g., one level of PARCAT1 and one level of PARCAT2).
• If this relationship is violated, you will see an inconsistent value warning for PARCATy (AD0124: Inconsistent value for PARCATy within a unique PARAMCD).

The CT for the RACE codelist (C74457) is not extensible by values of MULTIPLE and OTHER. However, the SDTM-IG describes these additional use cases as valid. Therefore, we consider the codelist extensible and urge customers to write an Explanation for the affected records in their ADRG.

Records with RACE=OTHER will trigger a Warning per Validation Rule CT2002: “Variable value not found in extensible codelist.” Health agencies view this as a Warning, not an Error. It is common and found in over 60% of data packages.

Here is a sample Explanation for your ADRG: “Subjects selected ‘Other, specify’ on the CRF. Per the SDTM-IG, DM.RACE=’OTHER’ and details of race can be found in SUPPDM.”

This is a known misalignment between the CT for RACE and the SDTM-IG. However, we do not know if or when CDISC will address it.

If a European study does not allow RACE for privacy reasons, you can still meet the ADaM-IG requirements to include it. Simply include the RACE variable without populating it with the protected information.

RACE is Core=Exp in SDTM. Meaning, the variable must be present, but it can contain null/missing values. If your CRF has values of “NOT REPORTED” or “UNKNOWN,” you can set RACE to those values. If your CRF does not have those values, you can leave them missing.

The value of DTYPE describes the derivation technique used to populate an analysis value (AVAL or AVALC). It’s often used when you populate a missing observed analysis value with an imputed value.

Find a standard value from the DTYPE codelist that is appropriate for your derivation technique (e.g., WOCF for Worst Observed Value Carried Forward). If you can’t find one, set DTYPE to a short descriptive value that describes your technique. The DTYPE codelist is extensible.

Further describe your technique in your ADRG and Define.xml. You don’t need to describe this in your dataset with an additional variable alongside DTYPE. Examples of how to set DTYPE for imputed analysis values can be seen in ADaM-IG v1.2 Section 4.2.1.3.

You don’t need to use DTYPE for derived parameters. That is, if you derive an entirely new parameter using an existing parameter in the dataset, you don’t need to set DTYPE; instead, describe the derivation technique in your ADRG and metadata.

Earlier versions of the ADaM-IG allowed the PARAMTYP variable to show that a parameter is derived. However, PARAMTYP is retired as of AdaM-IG 1.2. Examples of how to handle creating new parameters can be seen in ADaM-IG v1.2 Section 4.2.1.5.

Multiple records for the same subject and parameter may require imputation. In this example, Baseline is defined as the maximum observed value between the Screening and Run-In visits. Endpoint is defined as the worst observation carried forward, which happens to also be the newly derived Baseline analysis result (i.e., 101).

Note that DTYPE is set to a short descriptive value on each record with the imputation.

Regulatory Expectations

These Data Standards Catalogs from the FDA and PMDA show the valid ADaM-IG versions for your submission’s date.

Using the Data Standards Catalog is easy. Navigate to the Submission Data Exchange Standards worksheet pictured below and look for the rows that are applicable to CDISC ADaM. Note: the dates in these columns are “Study start date.”

You need to use the ADRG to document and explain these items. P21 Enterprise includes recommended “Fix Tips” and examples of common issue explanations.

False positives – cases where you receive Vendor data you cannot change

For data with wrong variable labels due to different IG versions, for example your study was started using ADaM-IG v1.0 variable labels, so the rule fired for variable label mismatch, we recommend using the latest versions of Controlled Terminology (CT). Otherwise, you’ll need more explanations.

E.g., SDTM’s 2018-06-29 CT does not have “Unknown” in the RACE codelist. You’d be forced to explain: “’Unknown’ was added by the sponsor to the extensible CDISC codelist ‘RACE.’”

The P21 Issues Report spreadsheet is not a required part of the submission package for the FDA or PMDA but is helpful to include. ADRG Section 6 is sufficient to meet the requirement.

P21 Validation Engine Improvements

The P21 Validation Engines are consistently updated and improved upon with insights from our Subject Matter Experts, consultations with regulatory agencies, and findings submitted by our users. For example:

• AD0047 was producing problems for some variables but has already been fixed and patched.

Note: Our Validation Engines support analysis for a single study but do not yet fully support analysis for integrated studies, which may present added challenges for the ADRG.

IG, Software & Engine Versions

P21 validation rules are based on the version of the IG that you configured on the Data Package in P21 Enterprise or in the Validator screen in P21 Community. Visit the Validation Rules page to see rules sortable by standard, regulatory agency, and Engine version.

If AD0047 “Required variable is not present” fires for datasets such as ADCE, ADCM, ADMH, you must explain it in the ADRG.

This result may be due to you using an outdated version of P21 Community. Upgrade to newest version of P21 Community for the most accurate validation results. Engines releases are independent of our main software releases, so you may be able to access a new Engine without needing to upgrade our main software.

Have you ever wondered how Pinnacle 21 implements rules for ADaM validation? Check out the answers to some commonly asked questions:

Does Pinnacle 21 implement the validation checks published by CDISC?

Yes, Pinnacle 21 rules are an implementation of CDISC validation checks. In fact, several Pinnacle 21 team members have served as CDISC ADaM Conformance Rules subteam leads or active members. This close collaboration between Pinnacle 21 developers, ADaM team core members, and representatives from across the industry is what makes it possible to continuously improve rule definitions and implementations.

Why do the message text and rule counts differ?

CDISC check definitions are designed to serve as requirements to machine implementation, “a programmable test, written such that an affirmative response represents a failure of the requirement. This text is intended for use as a requirement specification which could be implemented in a variety of programming languages”. P21’s rule messages and descriptions, on the other hand, are designed for the end user to help them quickly identify and fix the cause of validation issue.

Example:

CDISC: A variable with a prefix of TR, containing AG with a suffix of N is present and a variable with the same root without a suffix of N is not present

P21: TRxxAGyN is present but TRxxAGy is not present

When it comes to rule counts, Pinnacle 21 validation engine allows many CDISC checks to be implemented as one validation rule. This significantly improves consistency across related checks and reduces the development and testing effort. In some rare cases, a single CDISC check must be implemented as multiple Pinnacle 21 rules. Regardless of the rule count mismatch, when issues are created during validation, they will always map to a singular CDISC ADaM check.

Does Pinnacle 21 implement additional rules not published by CDISC?

Yes, Pinnacle 21 implements additional data quality checks for calculations, file validity, consistency between Define.xml and dataset metadata, and controlled terminology for SDTM sourced variables. There are also a few additional conformance checks found during implementation that are described in ADaM-IG but were missed in the checks specification. These are currently being reviewed by the CDISC ADaM Conformance subteam.

If you are interested in validation check development, it’s not too late to get involved – the CDISC ADaM Compliance subteam could use your help. Also, if you find any issues with the current rule implementations or have ideas on how we can improve Pinnacle 21 software, please let us know!

Want to find out more about CDISC ADaM?

Read our blog “3 Things You Should Know About ADaM Standards”.