Intro to ADaM Conformance

ADaM data are required by the FDA and PMDA, and accepted by China’s NMPA. Agencies often begin reviews with ADaM data validation, which helps them understand the analyses performed and reproduce results.

This is the first in a series of posts where we answer questions from our recent webinar, Exploring Common CDISC ADaM Conformance Findings. In this post, we focus on implementation recommendations.

Defining PARAM

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.

Rule CT2002 for RACE

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. So consider the codelist extensible and write an Explanation for the affected records in your ADRG.

• Records with RACE=OTHER will trigger a Warning per Validation Rule CT2002 (ADSL.RACE): “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 datasets.
• 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.

Rule CT2002 for DTYPE

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.

Intermediate Datasets

For very complex derivations, some developers make an intermediate analysis dataset: STDM dataset > intermediate analysis dataset > main ADaM dataset. To achieve traceability, include those intermediate datasets and their associated metadata in your submission package.

• We recommend considering the intermediate dataset to be a valid ADxx dataset that should conform to the core ADaM concepts and principles.
• We also recommend including it in your validation process to ensure conformance.
• Note: If a dataset such as ADaM “Other” conforms to the core ADaM concepts and principles, start its name with the "AD" prefix.

The ADaM standard variable ASEQ is useful for traceability if the dataset is used as input to another ADaM dataset.

• If the dataset isn’t being used as input to another ADaM dataset, then you likely don’t need it, even if you are required to have --SEQ in the OCCDS dataset.
• Similarly, it’s best in general to include in ADaM data only the records that will be analyzed. E.g., you don't need to carry NOT DONE records into ADaM if they aren't being used. 

More to Come

We hope these discussions assist you in your workflow. Please check back as we continue this series of posts!