–Written by Rabia Ahmad, Programming Leader at GSK Please note, this blog is the opinion of the author and does not represent PHUSE nor necessarily the opinion of the authors employer.

I have always imagined the programming team to be at “the end of the totem pole”. The idea is not entirely baseless; identifying and establishing a fully functional programming team is not really considered until study/project level protocol and, in many cases, Statistical Analysis Plan (SAP) and list of displays, are developed and approved. Although it is true that the main function of the clinical programming team is to develop analysis datasets and displays to support submissions and other deliverables, they are also extremely well placed to provide valuable programming-specific insights during protocol and the SAP development process.

Based on my experience of leading multiple study teams, I strongly believe that programming can bridge the gap between what the study/project team envisions from an analysis perspective and what is possible to develop given the time constraints and tools available to support that vision. At the same time, the experience empowers programmers to develop TA-specific expertise and knowledge, and become independent contributors and decision-makers within the study/project team. The sooner the gap is addressed, the faster the study team can leverage this resource (programming team) to develop efficiencies and cut back delivery timelines. Below are some key areas where programming can add value in a non-programming capacity.

1. Advice on Standards:

Programmers are the study team’s best resource to gain knowledge about existing (and, in many cases, future) industry and internal data and reporting standards. Programmers have in-depth knowledge of submission requirements and standards (CDISC, ADaM, etc.). Including them in the protocol and SAP review process will avoid many roadblocks during the TFL development and delivery process.

2. Data, Data, Data:

At the end of the day, it all comes down to the robustness and quality of clinical trial data. Even the best protocol is of no help if the entire data collection process is not designed well. Programmers don’t visualise data or imagine what the data will look like; they know data! They know how the eCRFs must be designed to collect the right data to support the analysis and narrative. Involving them early on in the process avoids changes to eCRFs after First Subject First Visit (FSFV) or, worse, realising that the collected data is insufficient or incapable to support the required reports.

3. Use of Standard Macros:

In clinical reporting, when we think efficiency, we think standard macros. Standard macros not only help produce consistent datasets and outputs, they also lessen QC time and chances of errors. Programmers are your resident experts to advise on how to best leverage the available standard macros. They are best placed to help the study team decide when a study-specific request can be handled using a standard approach and when nonstandard programming is inevitable. They are also your best resource to ensure that any study-specific requirements are addressed proactively.

4. Timing is Everything:

The sooner programmers are aware of the needs of the study (particularly study-specific ones), the quicker they can identify ways to address these needs. For example, if the study design/analysis requires a dozen non-standard displays, the programming team can proactively look into developing “standard” macros to address these needs, work with data standards groups to develop mock shells and ensure eCRFs are designed to capture the right data in the right format. The upfront effort results in smooth deliveries and reduces unnecessary stress that, in hindsight, could have been easily avoided.

5. Future Improvements & Growth:

I strongly believe that enabling future improvements and growth is the most crucial outcome of establishing fully functional programming teams at the very start of a study. Based on the learnings from their assigned studies, programmers can identify gaps, work to “standardise” the non-standard approaches (think project-specific rather than study-specific needs) and establish best programming practices to make future studies within the asset more time and resource efficient. This not only adds value at a study level but collectively streamlines, strengthens and standardises the entire asset or, even, the therapeutic area.

Author