Despite continuous development of, and the quarterly updates to, CDISC Controlled Terminology, there is still a need for study-specific extensions to standard codelists.

Often, extensions to standard terminology are incorrect. For example, some users falsely believe that any new terms can be added to an extensible codelist and related data validation is not needed if new terms are listed in the define.xml. In this webinar, Sergiy Sirichenko summarizes industry metrics across many studies and sponsors to produce an overall picture of CDISC Controlled Terminology utilization. He reviews common issues with implementation of controlled terminology and reinforces best practices for extending standard codelists.

Below are Q&A topics, including those for which there was not time to answer live. Thank you for participating!

Mapping Non-Standard Terms [1]

Units: It is not necessary to retain the original unit in SUPPLB when standardizing LBORRESU values, e.g., from ng/mL to ug/L.

• Operational data is not applicable to regulatory submission and is similar to other "raw" data from EDC and data collection vendors.
• Some fear that mapping original units present in the CRF to CT terms in --ORRESU will risk losing the audit trail between original and reported data. However, think of other raw data, such as subject Sex data in EDC presented as values of 0 and 1. You are unlikely to keep these values in SDTM in addition to standard F and M terms. This approach then also applies to original units present in the CRF. Map them to CT terms for --ORRESU without concern for losing the link between original and reported data.

Synonyms: Sometimes lab literature uses synonyms, but to be CDISC compliant, follow CDISC standards rather than literature. For example, using the synonym "mg/g" for the standard term "g/kg" in regulatory submission is an error. Standardization is assigned to original units' variables, not on the standard units' variable, as this is a formal requirement from CDISC and part of the SDTM mapping process.

RACE: The SDTM Implementation Guide has good examples of RACE values not present in the CT. In general, SDTM-IG recommends mapping collected race into standard terms with details like multiple race or additional granularity in the SUPPDM dataset. SDTM-IG and referenced guidelines are FDA-centric, so be aware of the requirements of other agencies for subject race information.

Alternatives & Addition Requests [2]

For non-standard terms in non-extensible codelists for a standard variable such as AEACN, try mapping the collected term to a standard term, such as "Restarted drug" mapped to "DRUG INTERRUPTED." If you see no suitable standard alternatives, submit your collected non-standard term with minor modifications, e.g., using upper case to match standard terms. (In general, science prevails over standards).

For future studies, consider adjusting the data collection design to be compliant, and/or contact CDISC to request addition of new terms to standard CT. During the lag time between when the industry submits a new term to CDISC and when CDISC adds that term to the CT:

• Ensure your company or study-specific extensions of CT are valid. Many requested new terms are rejected for various reasons, but feedback from CDISC may be helpful.
• Ensure your extensions are consistent within your submissions.

P21 Enterprise can help expedite reporting new CT to CDISC by providing you with company metrics, including for controlled terminology. P21E offers a new Analytics module for self-serve company-wide metrics (available now) and industry-wide benchmarks (coming later). Also, P21E lets you manage, deploy, and enforce your company-specific standards.

Validation Rules & Issue Explanations [3]

Some rules resist automation due to either rule logic or algorithm complexity. However, we plan to fine-tune CT2002, which now has a P21 Message Type of Warning. E.g., we could detect invalid extensions and report them as Errors instead of Warnings. O we could ignore valid terms such as OTHER, MULTIPLE, LBALL, which are formally not a part of standard CDISC CT.

For --TESTCD = --ALL, there are, in fact, specific rules in the SDTM IG v3.3 (section 4.5.1.2 Tests Not Done), so we may consider adding rules that correspond to this IG, such as:

• Exclude ALL terms from CT2002 check
• Result value should not be populated for such records
• STAT must be 'NOT DONE'
• VISIT value should not be 'Unplanned'

Generally, you should not have many CT2002 issues in your study if you use standardization best practices in the data collection process. However, here are two ways to address multiple Issues for the same Rule ID, such as CT2002, quickly and efficiently:

• In the xDRG, combine Explanations for the same Issue across domains. P21E offers an Issue Management platform with features such as Bulk Updates, Custom Default Explanations, and xDRG Generator for this.
• Introduce company-specific controlled terminology for validation in addition to CDISC CT. With P21E, you can filter out Validation Issues related to company-approved extensions of standard controlled terminology.

Multiple Studies in One Submission [4]

In a single submission, start dates may differ across multiple studies.

• The FDA does not formally require the same version of CT for all studies in the submission. However, they recommend they be the same version. P21 also highly recommends this. Consistency simplifies many tasks such as data integration.
• The PMDA formally requires the same version of CT, standards, and validation engine for all studies in the submission. This consistency requirement even applies to potential re-submission of your data during the review process.

If you have an older study using an older version of CT, decide whether to up-version per these best practices.

• For FDA submissions, create a Study Data Standardization Plan and discuss it in advance with your FDA reviewers. Keeping the original version(s) of CT may help ensure that reviewers can reproduce results consistent with your Clinical Study Reports. However, having the same recent version of CT across all studies will simplify data integration and meta-analysis.
• For PMDA submissions, all studies must use the same version of CT. (P21E supports all historical or legacy versions of CT that have been accepted by regulatory agencies, so that you can validated studies against the original CT that was available at that time).

PMDA Severity and non-PMDA Message Type [5]

Reports from P21 products now specify Severity (Error, Warning, Notice) only for PMDA validations. For non-PMDA validations (P21, FDA, NMPA), Severity is no longer specified. The FDA no longer uses or publishes Severity values for validation results, with the exception of FDA Reject Issues.

• Reject is a Rule attribute in regulatory processes. All Reject Issues must be fixed. The FDA started enforcing Reject Issues from 2021-09-15 for most studies started after 2016-12-17, per the FDA's Technical Rejection Criteria for Study Data (Revised March 2021). The PMDA also requests Issue Explanations for Error Issues too, which they will compare and reconciliation with their own validation results.
• P21E clients, there are additional categories such as P21 Message Type. P21 Message Types represents the probability of false-positive results, such as zero chance (Error: definitely a problem in your data), to potential chance (Warning: requires your manual review and judgement to confirm).

Pinnacle 21 and Certara [6]

With our M&A with Certara, P21 continues to execute its roadmaps for P21 Community and P21 Enterprise—both of which provide value for the industry in preparation of study data for regulatory submissions. New releases of P21C and P21E are coming soon. Roadmap previews are available to P21E customers. Also, existing contracts with our clients remain in full effect.

Max Kanevsky, a founder of Pinnacle 21, is now CTO at Certara. As at Pinnacle 21, he steers the product portfolio and leads R&D for Certara's software business unit, focusing on data and regulatory sciences. P21 is keeping the "Pinnacle 21" brand identity—similar to Alphabet's maintaining sub-brands for Google and Android. There is no impact to P21 contracts and licensing with our clients.

If we missed any burning questions or topics, check out the full webinar and slide deck to see if we covered it. If you still have other questions, please feel free to contact us!

Footnotes

[1] Inspired by questions such as:

Is there a need to retain the original unit in SUPPLB when we standardize the LBORRESU values, e.g., from ng/mL to ug/L?

If we map original units present in the CRF to CT terms in –ORRESU, don't we risk losing the link between original data and reported data (in the context of an inspection for instance)?

What would be the ideal way to handle RACE values which are not present in the CT?

What about synonyms such as "mg/g" for permitted "g/kg"? Sometimes lab literature uses the synonym, so should lab units allow more synonyms to conform to literature? E.g. albumin/creatinine.

[2] Inspired by questions such as:

For a standard variable, e.g. AEACN, we get from the CRF design an option for a non-standard term in a non-extensible codelist, e.g. "Restarted drug". Because this is not part of the codelist, should we leave AEACN blank or capture it and explain in the Reviewer's Guide that the Error reflects the situation in the source data?

[3] Inspired by questions such as:

For --TESTCD = --ALL, there are specific rules in the SDTM IG v3.3 (section 4.5.1.2 Tests Not Done). May the corresponding rules be added?

[4] Inspired by questions such as:

Did you mean FDA requires the same CT version for all studies in one submission or for one study in a submission? In one submission, the study start date is usually different for different studies.

[5] Inspired by questions such as:

Why does the P21 report developed using P21 Community not specify "Errors" and "Warnings" now?

[6] Inspired by questions such as:

How will P21’s M&A with Cetera impact existing client contracts with P21?