As an Industrial Engineer working as Statistical Programmer in the CRO industry, I’ve often been asked the question (by others as well as myself), “How did you end up here?” The role of Statistical Programmer has the reputation of being defined by rigid rules and regulations, following strict industry guidelines to produce pre-defined dataset structures and Tables, Figures, and Listings (TFLs). Typically, there’s little room for innovation, apart from the odd macro to handle repetition. Hardly the place for Industrial Engineers who are always on the lookout for improving and automating processes! Or is it?

At a networking event during the 2023 CDISC EU Interchange in Copenhagen, I happened to sit at the same table as Bhavin Busa co-founder of Clymb Clinical. During the Interchange, while observing Clymb Clinical and their innovative work in TFL automation, I sensed that I’ve encountered a group of like-minded people, who dare to innovate and challenge the status quo of traditional Statistical Programming. To prove the point, I recently came across the notes I scribbled during the Interchange, and one of the first things I wrote down, was “Clymb Clinical”! It occurred to me that there could indeed be room in this industry for innovation – and for Industrial Engineers.

For those not familiar with Clymb Clinical, allow me to provide a quick overview: Clymb Clinical is a start-up in the CRO space, with a unique offering of providing not only Biostats and Statistical Programming services, but also TFL Designer – a web-based software that allows user-friendly design of TFL Shells, with added metadata. The shells can be exported with machine-readable metadata in various formats, including ARS metadata based the CDISC Foundational Analysis Results Standards . Among the many advantages of having a TFL creation tool, the metadata offers the capability to fully automate downstream generation of TFLs. “Automate… TFLs”? Now, this is the kind of stuff that could excite any Industrial Engineer…

So, what is the overlap between Industrial Engineering and innovation in Statistical Programming (specifically, TFL generation)? I will focus on three aspects: 1. Holistic View of Systems, 2. Optimal Resource Utilization, and 3. Scalability and Standardization.

1. Holistic View of Systems:

Generating TFLs is not a stand-alone process. It is interdependent on other processes, such as SDTM and ADaM generation, SAP and shells creation. Industrial Engineering aims to “see the bigger picture”, rather than focusing on one system only. If we see TFL generation in this light, could we “start with the end (finalised TFLs) in mind”, even when designing shells, ADaM specs and ADaMs? And if so, could we arrive at a design that allows for TFL automation?

2. Optimal Resource Utilization:

As it stands, there are typically many resources (especially Statisticians and Statistical Programmers) involved in the process of producing TFLs. This requires all resources working on a specific Reporting Event to gain in-depth knowledge of all aspects of the Statistical Analysis – understanding the SAP, ADaM specs and TFL Shells inside-out. This is complex and simply takes up a good amount of time. Is there perhaps a scenario where fewer resources (e.g. Statistician) could be experts in all aspects of the Reporting Event and capture all relevant information (Analysis Sets, Groupings, Data subsets, etc.) in one user-friendly system, which exports all this information as machine-readable metadata, which can be ingested by a tool that automates the downstream TFLs? If nothing else, it would be a big win to have to allocate less resources to each Reporting Event setup.

3. Scalability and Standardization:

Henry Ford would not have been able to produce 15 million Model T Fords, if it was not for Standardization in the production process. As with Model T Fords, so also with TFL production. If we want to be able to automate TFLs across the Clinical Research Industry - if we want to scale – we need to standardize. Since the Analysis Results Standards by CDISC were released, this has created an immense opportunity to scale TFL generation (not just in-house, but in a consistent way across the industry). We need to focus on developing tools that allow us to scale across Therapeutic Areas, projects, and even companies in the pharmaceutical industry. This is the strength of the TFL Designer tool, and its powerful connection to ARS metadata and TFL automation tools.

One example of a practical innovation I’m working on with Clymb Clinical, is creating an R package (“Siera”), that ingests ARS metadata (produced by the TFL Designer tool) and produces multiple R programs – one for each output to be produced. These R programs can be run as-is and will each produce an ARD for the applicable output. This meta-programming approach removes the “black box” notion, making the ARD-generating code inspectable and updateable (if needed). I’m excited to share that I will be presenting on this at the PHUSE 2025 US Connect in Orlando ! Watch this space...

I can barely think of a more exciting industry and role for an Industrial Engineer to be in, than Statistical Programming and TFL automation. And yes, I’ve yet to meet a fellow Industrial Engineer in such a role (if you’re out there, let me know!). While some may see this as a drawback, I see it as an immense opportunity – and I’m excited to take this opportunity on with Clymb Clinical!

Malan Bosman

Statistical Programmer