What did the CDISC Standards Change?

Sometime in the spring of 2008, when I first heard about Clinical Data Interchange Standards Consortium (CDISC), my head started swirling with all the jargon. With much introspection, I realized very soon all the world’s pharmaceutical companies would have almost the same structure for their datasets for standard safety reporting. The novice SDTM learner within me thought, oh boy, if this concept is realized in all its fullness, then they surely won’t need a department full of programmers; I may lose my job and may have to consider an alternate career. It has been nearly nine years since that thought and today I realized there was absolutely no assurance that if the programming of analysis dataset for demographics in trial X took five days, then trial Y would also need five days to program the same demographics analysis dataset. CDISC has not only standardized the entire process of analyzing clinical trials, but it has also lifted the great distress that my previous thought were just fears.  My career certainly had not taken any downhill turn as I had feared.

What I did not realize that was that back then, much of a clinical programmer’s energy was being wasted in going back and forth to produce a standard safety dataset such as AE, DM, VS, LB, etc. There was quite some time spent on correcting the manual CRFs and an equal amount of energy to annotate them.. Due to the clinical programmer having sorted out these rudimentary processes, every trial of the same sponsor had a variety of datasets of the same kind. Finally, the clinical programmers could focus on analysis.. Today, submitting your datasets to the FDA in SDTM format has not just become a guideline, but it’s also become a mandate, and ADAM guidelines may fall in this category soon as well. CDISC standards have managed to relieve the stress of working on pooled analysis and exploratory analysis and overall have sped up creating analysis datasets and subsequently, the tables, figures, and listings. And exactly how are we using this great amount of time that we have saved by implementing CDISC Standards?

Exploratory analysis: Sponsors are increasingly engaging in various exploratory analysis for their trials that have been completed. This is primarily as an input to their medical affairs teams, to discover new indications for the new drug, or just to monitor ongoing safety and efficacy.

Site monitoring analytics: Traditionally, clinical trials were monitored and/or conducted through the various sites that were decided by the sponsor to conduct a trial, using a mix of paper and computerized monitoring system. Recently it has been discovered that maintaining these sites can result in an overhead cost, especially if the patient recruitments are lower than expected. Several algorithms (in machine learning and predictive analytics) have been used to enable real time decision making, opening a new avenue of site monitoring analytics to those programmers working in the domain for clinical trials. Site monitoring analytics aims to save costs, conduct trials efficiently and overall, improve the quality of data collected from a trial.

Data anonymization:

Several trials have gone into the EudraCT database that must be a part of a public database, after the Clinical Trials Regulations having been passed by the EU in 2014. Before the trial datasets are submitted on this public database, these databases must be anonymized. This is a new challenge for a clinical programmer.

Pharmacovigilance Analytics:  This would involve analyzing the trends of adverse events (AE) that are reported to the pharmacovigilance team, predicting the occurrence of AE, and calculating the time and efficiency in reporting an AE.

Health Economics and Patient Outcomes: This can be easily called big data for clinical space. Increasingly, many pharmaceutical companies are investing in Health Economics and Patient Outcomes for better healthcare decisions. The data is typically big data from the patient registries, compelling the clinical programmer to write smart codes and to use better tools to navigate and analyze data.

Standardization: This is a blanket term under which many activities are currently taking place, and these are opening fresh avenues for a clinical programmer viz: 1) Creating a macro library to map SDTM datasets (preferably at a project level). 2) Creating a macro library to generate standard tables figures and listings (preferably at a project level). 3) Creating edit checks for data managers that would make SDTMs compliant to the implementation guide followed. 4) Automating Open CDISC checks for the correctness of the SDTM dataset.

The above list is not exhaustive, and challenging days are here to stay. Life did not stop when SDTM and the other CDISC standards were introduced, but it has become more challenging, informative, and wholesome.  It has challenged us clinical programmers to look beyond the traditional table/figures and listings rigmarole. Fortunately, many of us have taken this challenge head-on and have upskilled ourselves. There are more analytics to be done, more standardizations to be achieved, and likely more regulations to follow.  The future is bright, and exciting times are waiting ahead for us.  I challenge us all to keep learning and growing to become the best clinical programmers we can be.

 

Written by Lovita Fernandes, Principal Programmer at GCE Solutions