Is this the future of TFL programming?

This is the story of Steve, a Statistical Programmer tasked with programming the Tables, Figures and Listings (TFLs) for the CSR of a large clinical study.

All 278 of them.

He pulls in his chair for the day’s work, switches on his laptop, and reviews the team’s progress so far:

ADaM datasets — check, ready.

TFL Shells — check, ready.

All that’s left now is writing 278 programs to generate the outputs (well, maybe less if there are some repeat tables). Steve smiles. He thinks back on previous studies, when he would have buckled in for weeks, maybe months, of hard work with his team to produce the programs. They would mostly duplicate similar methods and concepts to generate similar summary statistics, frequency counts, and comparative statistics for different variables and datasets. They would meticulously adjust millimetres on the final RTF outputs to make everything fit and proceed to QC these results and layouts on a detailed level. Once they did this, they would finally have static RTFs or PDFs with static, non-machine-readable results to submit to regulatory authorities.

Steve used to stress about creating so many TFL programmes.

But today, Steve has a reason to smile. He and his team have adopted the CDISC Analysis Results Standard (ARS) and prospectively defined the metadata for the TFLs when they designed the Shells. Using a modern web-based software solution called TFL Designer, they added Population Sets (like SAFFL = “Y”), data subsets (like TRTEMFL = “Y”), Treatment Groups, and all relevant metadata pieces with a point-and-click UI to the shells they were designing. They even added general macro-like code snippets to their metadata setup, which will be re-used to produce the desired results. It took a bit of time and coordination, but not nearly the same amount as writing out the full programs. Today, Steve is ready to use this ARS metadata to automate his team’s TFL generation. He opens TFL Designer , fills in his login details, selects his study, and clicks “export”. He selects “ARS Metadata”, and gets his populated JSON metadata file: Check out the video he made of these steps so far:

[embed]

Steve finds it easy to export CDISC ARS metadata for his Shells.

Easy enough. Next, Steve is ready to pass this ARS metadata to the “*siera*” R package. He knows that the latest version of “siera” is on CRAN, and has been updated with the following features:

• Siera is able to ingest either JSON or xlsx formats of ARS metadata
• It facilitates running dynamic user-provided R code from the “cards” and “cardx” R packages, which handle the Analysis Method operations as specified by the ARS model
• Can produce well-structured R scripts (one for each output), which can be run as-is to produce an Analysis Results Dataset (ARD) for the output

Check out his video where he does this:

[embed]

Steve is very pleased. He has ready-to-run R scripts that will generate the results in ARD format for most of the 278 TFLs. As he gets up for his 10am coffee break, he thinks about the upcoming submission to regulatory authorities. He knows that he can rest assured that he has a reproducible process with R scripts showing how ADaM datasets were transformed into results (ARDs). He also thinks about the upcoming QC process. With machine-readable results in a standardized format like this, it would be a much simpler process to compare results, rather than having to compare potentially unneeded layouts as well. In addition to this, he can only imagine how useful these ARDs would be in upcoming meta-analysis study, with data already in a standardized format, machine-readable, and easily convertible into multiple data formats (like JSON).

Steve is pleased about the new improved TFL Generation process, and enjoys his coffee.

He walks back to his desk, coffee in hand. Now that he has the ARDs, he’s ready to transform them into actual tables, with the correct layout. He smiles again as he ponders the wonder of Open-Source solutions. His next step would be to use existing R packages, specifically developed for transforming ARDs into submission-ready tables. He navigates to the pharmaverse.org website, and searches two reputable R packages for this purpose:

1. gtsummary
2. tfrmt

He also finds a really nice PHUSE presentation on the topic as a starting point.

It’s two weeks later in the afternoon. Steve and his team have QC’d the results and produced submission-ready TFLs in record time. The client is overjoyed, and Steve knows that this improved process would translate into eventual savings on the finished product, helping to improve the lives of more people. Steve closes his computer for the day and reflects on the vast improvement to TFL generation processes since he started his career as a Statistical Programmer. The advent of the CDISC Analysis Results Standard, Open-Source solutions, TFL Designer and GenAI has changed it all. What used to take Steve and his team weeks or months is now something he’s able to do in days. As Steve leaves for the day, he hears about the AI Code Generator module in TFL Designer — which can generate R or SAS code, being prompted with a structured set of JSON metadata specific to the Shell. He can’t wait to test it out first thing in the morning — but that’s a story for another time.