Addressing 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 this recommendation in 2004, pharmaceutical and biotechnology companies have focused on complying with these standards, while maintaining trial efficiency. Pinnacle 21 has developed an industry-accepted, open-source software package to check CDISC compliance. The Pinnacle 21 tool checks SDTM/ADaM datasets and metadata against CDISC rules and generates a findings report. Regulatory bodies generally expect these to be 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 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 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 Pinnacle 21 validator tool provides a concise summary of violations; however, it is up to the data programmer to understand these messages, investigate the data issues, and give an acceptable explanation. This can present a challenge.

We asked Alira Health’s in-house statistical programming experts to share some examples of common SDTM/ADaM issues and 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 the end of the study). As shown in the example below, 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), this should be explained in the SDRG with these specific details.

Coded variables value not found in the 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 table 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 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 reason (2) applies, 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. 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 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 usually due to a different numerical precision representation between SAS and the Pinnacle21 application. Check that the calculation is in fact correct first, then document 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 and warning messages provided by tools such as Pinnacle21 can be difficult to interpret and explain, and may also involve deep investigations into the data.

How can Alira Health support you?

Our dedicated CDISC specialists have combined experience in SDTM, ADaM, and associated documentation to provide comprehensive support for both standardization and analysis. Our specialists work across all CDISC standards and support many clients with submission efforts to regulatory authorities.

Our services include:

• Data mapping, standardization, 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 CDISC expert and team support
• CDISC strategy for trials and customized solutions
• Contribution to the Study Data Standardization 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

• Study Data Tabulation Model, Study Data Tabulation Model Implementation Guide, Analysis Data Model, and Analysis Data Model Implementation Guide. Available at https://www.cdisc.org/standards/foundational/.
• Pinnacle 21 Community. Available at http://www.pinnacle21.net/downloadnet/download.
• SAS® Viya® Programming Documentation. Available at https://documentation.sas.com/doc/en/pgmsascdc/v_011/lepg/p0dv87zb3bnse6n1mqo360be70qr.htm