By Diganta Bose, Statistical Programming Team Lead at Cytel
Editor's note: This blog is based on work presented at ConSPIC 2017
Innovation within CROs is critical to enhance efficiency, reduce costs, and increase productivity. Importantly, process innovation can also help limit errors, and reduce efforts required by a team to conduct a specific task, so freeing them up for other value-adding activities. The process and technology innovations developed by statistical programmers can make important contributions to improved productivity and aid the industry-wide drive to accelerate new products to market.
In a previous blog, we highlighted an innovative solution developed by Cytel’s Angelo Tinazzi and Dean Shultsto improve efficiency in the Data Monitoring DMC programming process. In this article, I will provide an overview of another programming innovation project, which aims to improve the efficiency of creating ADaM datasets.
As a Team Lead – Statistical Programming at Cytel, I work primarily as a SAS programmer and also lead end-to-end clinical trial study related statistical programming deliverables. These activities involve Analysis, Tabulation and Reporting Data generated across all phases of clinical trials.
During its day-to-day work, my programming team deals extensively with CDISC compliant datasets like SDTM and ADaM. With an urgent need to accelerate new medicines to market, it is critical to have tools available to create the required deliverables for electronic submissions in the minimum time, while maintaining the highest levels of quality.
With the above objective in mind, we set out to develop an in-house tool that could help ease the production of CDISC based electronic submissions and analysis results by automating key ADaM variable derivations. The tool, ( which we have named STAG) can be used effectively to derive a substantial percentage (we estimate around 60-70% ) of ADaM ADSL and BDS variables, provided of course that the SDTM datasets are available for a given study. The tool has been designed paying special attention to good programming practices and aims to ensure the delivery of high-quality outputs.
In developing the tool we acknowledge that ADaM is open to interpretation and related to the SAP. We don’t aim to generalize study specific interpretations but rather intend to make customizations based on user requirements.
At the front- end, there is a User Interface (UI) that requests certain fields to be completed to specify study-level analysis requirements in a simple and succinct manner. The backbone of the tool is a set of SAS Macros that play the functional role behind the front-end UI. These Macro utility programs have been developed using robust approaches that do not adhere to a fixed logic and are able to handle many common scenarios that may arise due to specific analysis requirements.
Once the user has completed their specifications at the front-end UI, these are then passed as parameters to the SAS Utility macros. The application runs, and the SAS Program files will be generated. The statistical programmer retains full control over the SAS program files through the UI Layer. The program files contain codes that can be utilized to create the most appropriate and important ADaM variables based on the entries in the UI or modified further (if specific additional variables are needed) and run to generate the final ADAM datasets.
I developed the SAS macros organically over time as specific key scopes of programming work relating to ADaM Variable derivations were identified. The front-end was developed more recently (by my team member Rashmi Pardeshi) using VBA Excel to help make the back-end codes more accessible to users.
The tool is currently undergoing internal testing and will then enter a pilot phase. It is particularly well suited for creating the ADSL (Subject-level analysis dataset) especially for common forms of study design with exposure. The tool is also able to handle Basic Data Structure (BDS) ADaMs that are derived out of “General Observation Class Findings” SDTM Domains. However, currently it is not able to handle more complex BDS ADaMs (sourced from multiple SDTM Datasets e.g. ADTTE or complex efficacy) in a straightforward way. STAG could save time by minimizing the data-driven programming steps that are written to derive common ADaM variables used in almost in any analysis.
In the future, we would like to evaluate more flexible options, and cater to a wider range of analysis requirements. We'd also like to cater for more complex requirements, although there are of course a wide range of analysis scenarios which makes this challenging. More imminently, we expect other ADaMs like ADAE to be soon available within the tool.
About the Author
Diganta Bose is Team Lead Statistical Programming at Cytel. He has worked with Cytel since August 2013, and started his career as a Statistical Programmer in 2010.
He holds a Bachelor of Engineering in Biotechnology from Visvesvaraya Technological University, and a Master of Science in Bioinformatics from The Georgia Institute of Technology, United States.
His hobbies include hiking, traveling to wildlife sanctuaries and hill stations and reading science fiction.