Common CDISC Compliance Findings for Regulatory Submission

The Clinical Data Interchange Standards Consortium (CDISC) recommends, and most regulatory authorities require, the use of the Study Data Tabulation Model (SDTM) and Analysis Data Model (ADaM) standards for submission of clinical study data. Since CDISC made the recommendation in 2004, pharmaceutical and biotechnology companies have been focused on complying with these standards, while also maintaining trial efficiency. Pinnacle 21 (P21) has developed a widely industry-accepted, open-source software package to check CDISC compliance. The P21 tool checks SDTM/ADaM datasets and metadata against CDISC rules and generates a findings report. Regulatory bodies generally expect that these findings are resolved prior to submission of data, and those that are not are appropriately justified.

The SDTM and ADaM standards have rules related to the structure and terminology contained within the datasets. Deviations from these rules are considered compliance findings and have different levels depending on the seriousness of the violation (e.g. Error is the most serious, followed by Warning, then Notice). Checking that datasets, as well as metadata, conform to the CDISC rules during the development process will prevent the accumulation of issues to fix at the end of the statistical analysis or while preparing the clinical study report for submission. Failure to conform to the CDISC models during submissions may result in the datasets being rejected, leading to delays for the drug approval.

Most regulatory bodies strongly suggest submitting a reviewer’s guide along with clinical data. Any unresolvable errors/warnings related to CDISC compliance need to be addressed in the Study Data Reviewer’s Guide (SDRG) for SDTM or Analysis Data Reviewer’s Guide (ADRG) for ADaM. The P21 validator tool provides a concise summary of violations; however, it is up to the programmer of the data to understand these messages, investigate the data issues, and give an acceptable explanation, which can be quite a challenge.

We have asked our Statistical Programming experts to share with us some examples of common SDTM/ADAM issues and suggestions of how to explain them to regulatory reviewers.

SDTM Compliance findings

AE start date is after the latest Disposition date

In an ongoing study, this issue should be queried by Data Management and corrected by the clinical site. However, if this issue remains after database lock, Data Management should be able to provide justification (e.g. subject lost to follow-up and cannot be contacted to correct the date).

Another possible explanation is related to study design (e.g. SAE should be reported up to X days on or after end of study). For example, if a subject left the study on a known date, but the information was not collected until after this termination date (also including an AE), as shown below, this should be explained in the SDRG with these specific details.

AE start date is after the latest Disposition date

 

AE start date is after the latest Disposition date - 2

Coded variables value not found in extensible code list

Controlled terminology is expected for certain CDISC variables, and the code lists for such variables are either extensible or non-extensible. Extensible code lists allow you to add new terms, however, you will still get this warning as a reminder to make sure that the values you have added are unique. If you can replace a collected value with a value from the controlled terminology, this is preferred (see examples). If a suitable match is not found in the code list then the collected value may be used and should be documented in the reviewer’s guide. Note that there are special code lists for certain domains that may have the unit you are looking for as well (e.g. VS or PC).

Example 1: FREQ (Frequency)

Example 1- FREQ (Frequency)

Example 2: VSRESU (Units for Vital Signs Results)

Example 2- VSRESU (Units for Vital Signs Results)

Duplicate records

CDISC rules expect that each domain has certain key variables that identify unique records. For example, Pinnacle21 checks the following for unique records in the AE domain:  USUBJID, AETERM, AEDECOD, AECAT, AESCAT, AESEV, AETOXGR. In some cases, it could be that there are true duplicates in the source data. The study sponsor or responsible party should decide if (1) the duplicate records should be removed, (2) the duplicate records should be kept as they are, or (3) the duplicates should be altered in such a way that they are no longer duplicates (e.g. One instance of a repeated visit can be changed to “unscheduled”). If (2) then a detailed explanation should be given in the reviewer’s guide, including the subject number and why the record is not a duplicate.

ADAM Compliance finding

Inconsistent value for AVALC

This message means that AVAL is not exactly equal to AVALC. For example, this can occur if there is a leading 0 in AVALC, which is not present when converting the value to numeric (AVAL). This should be addressed at SDTM level by removing leading 0’s, particularly in the xxSTRESC variable. If it is not corrected, then an explanation needs to be provided in the reviewer’s guide.

Another example is if the AVALC value is associated with >, <, + symbols, which should be displayed in listings as per the requirement of SAP, but the respective AVAL value does not have the symbol in order to use the value for analysis (e.g. tables). In the reviewer’s guide, you can note that the difference is intentional per the requirements of the SAP, noting the SAP text or section number.

Calculation issue: CHG != AVAL – BASE

This is typically due to mismatch in precision between SAS and the Pinnacle21 application. Pinnacle21 truncates values at a certain number of significant digits, which could explain the issue. Check that the calculation is in fact correct first, then note in the reviewer’s guide that this is a false positive message and that the value is calculated correctly, including an example.

*DTM does not have the ADaM required SAS Datetime format

Pinnacle21 expects that the variables ending in “DTM” are datetime variables (e.g. RANDTM = Randomization Time). It can be prevented with careful selection of variable names (e.g. change RANDTM to RANTM).

Conclusion

It can be quite a challenge to understand all the CDISC guidelines and data conformance rules published by regulatory bodies. The concise error/warning messages provided by tools such as Pinnacle21 can be difficult to interpret and explain and also may involve deep investigations into the data. We hope this article provides useful insight to guide your programming team in handling common issues that can appear in studies.

How can CROS NT support you?

We have a dedicated team of CDISC specialists with combined experience in SDTM, ADaM, and associated documentation so no need for separate teams for standardisation or analysis. Our specialists work across all CDISC standards and have supported many clients with submission efforts to regulatory authorities.

We offer such services as:

  • Data mapping, standardisation and implementation of the latest SDTM or ADaM standards
  • CDISC CDASH compliant database build
  • Documentation provision services including reviewer’s guides, specifications, annotated CRF, and Define.xml
  • Embedded experts and teams as required to support your CDISC needs
  • Consultancy and support in finding the right CDISC strategy for your trial including customised solutions
  • Contribution to the Study Data Standardisation Plan (for pre-IND and pre-NDA meetings)
  • ISS/ISE data mapping to CDISC including gap analysis for data pooling and submissions
  • Standalone GAP analysis to assess project requirements and budgets

References