In-text safety tables from immutable outputs
Transferring numbers by hand from statistical output into a clinical study report's in-text safety tables is slow and prone to error. Immutable tables, read-only and append-only outputs linked into the report rather than retyped, are one proposed remedy, and their value depends on how they are built, who builds them, and what they cost in set-up, training and storage.
Where errors enter the in-text safety tables
Writers of clinical study reports have historically transferred data by hand from the tables, listings and figures that a statistical analysis system generates into in-text tables, a significant burden for the safety tables in particular because of the volume of data and the repetitiveness of the task. Dynamic Data Exchange, which shares data live between programs, and delimited files with Word macros have been tried with limited success, because output was slow and errors remained.
In current practice the writers receive outputs in a different format from each contract research organisation and edit and format the in-text and post-text tables themselves, which can generate errors. Modifications by the writing team or other departments, though usually made with good intentions, can inadvertently introduce errors and put the integrity of the data at risk, which is why thorough review and quality control are needed. Immutable tables are particularly needed for the safety section, because safety data are collected over long periods and change as more data become available.
Mutable data, immutable data and immutable tables
Most traditional databases store data in a mutable form, so data and tables can be modified or overwritten. Immutable data cannot be deleted or modified once in the database, and it keeps a trail of the events that led to the current tables, which identifies how the data evolved through the trial and the drug's development. Immutable tables are read-only tables that prevent unauthorised modification and accidental modification through human error; generated from immutable data, they are original statistical outputs that cannot be deleted or changed.
Traditional and immutable tables differ on seven points. Unauthorised changes by rogue or compromised insiders, and genuine errors, cannot be eliminated in traditional tables but are avoided in immutable ones. Creating or modifying a traditional table takes several steps, such as alignment, formatting and further processing, while generating formatted immutable tables is automated, with no additional resource time. A traditional table preserves no earlier output and cannot compare current data with historical data to show shifting outcome trends, and an immutable one does both. A mutable database is record-based, rewriting a cell when a new item arrives, and when a title or content changes the new data overwrite the previous entry, so the older title and content are lost for ever and only the current state is stored; an immutable database is log-based, creating a new log for every new piece of data, performs only inserts and never updates an existing field, and stores the history alongside the current state. And where each revision of a mutable table overwrites it, the immutable structure inserts every revision as a new row — revision number as the primary key, time stamp, table number, title and content — so information about every earlier edit is retained and can be retrieved at any time by time stamp or revision number.
Building the immutable tables
Building immutable safety tables produces tamper-proof, insert-only tables that keep strict retention rules and traceability. The statistics and programming teams are central to the work, and each step must be completed thoroughly before the next, to ensure the integrity and accuracy of the final report and keep the data in the database immutable.
First, conceptualisation: cross-functional teams work on the overall structure of the safety outputs, and statistics and programming together define the table schema, structure and data fields and create a standard safety template that can be used across all clinical studies. Second, creation: the table is created in structured query language with a create-table command that specifies it is immutable and append-only, so new records can be inserted but existing ones cannot be modified or deleted. Third, insertion: new data are added by insert statements, each row a record that stays unchanged once inserted, which protects integrity and prevents accidental loss. Fourth, retention: rules at table and row level, with a no-drop clause preventing the table from being dropped and a no-delete clause preventing rows from being deleted.
Fifth, peer review: experts from areas such as medical writing, safety, statistics, programming and clinical development check that the generated tables are correct, clear and consistent and not too complex for the reader, after which they are formally approved for insertion into the report. Sixth, security and auditability: every attempted change and every write is logged, giving a trail of what data were added and when. Seventh, archiving: older data no longer in active use may be archived for performance and storage while staying available for audit or analysis.
Statisticians and programmers should follow these practices while crafting the standard safety template for immutable tables: treat a table's title, body and footnotes as one block; put the title only at the top of the first page and the footnote only at the bottom of the last when a table runs over several; in a table over several pages, let a selection on the first page select the whole table, for easy copying and pasting; output in HTML, which allows interactive elements and is widely supported; and keep every output in landscape orientation to maximise horizontal space.
Linking the tables into the report
Inserting the tables runs through a restricted repository. The programmer creates a secure folder in SharePoint or another document repository to hold the list of safety outputs and their final versions, with write access for the statistical programming team only and read-only access for other team members. The process then runs in order: the statistics team finalises the analysis plan and mock shells; the programming team lists the outputs in Excel; the writers mark which are in-text tables; the outputs are quality-controlled and finalised; the programming team creates the folder and the tables are pasted into it; the programmers add a link to each output in the list; the writers are told the final outputs are available; and the writers paste the links into the report and replace them with the actual tables using the sponsor-developed toolbar, before team review.
That toolbar, an IT-developed Word toolbar called CSR Conversion, turns table links into read-only tables sourced directly from the repository. The tables it inserts are read-only, so their data stay unaltered throughout development. The safety section and the report are finalised when the writers activate all the safety and other immutable tables, which ensures every table is correctly linked, read-only and reflects the final data from the statistical programming team. A sample list pairs table titles such as the summary of treatment-emergent adverse events, subjects with events by system organ class and preferred term, drug-related events by system organ class and preferred term, serious drug-related events, and serious events by system organ class and preferred term, with the file links for outputs 14.3.1 to 14.3.5, and an example table generated with the tool tabulates adverse events, serious events, drug-related serious events, discontinuations due to adverse events and events of special interest by arm and in total.
Roles in the team
The team needs defined roles. The clinical lead is responsible for the content of the tables and the key parameters they must include, peer-reviews their final structure and gives expert opinions on stakeholders' queries and their responses; the clinical data manager ensures accurate collection and cleaning of safety data and coordinates its lock; the biostatistician defines the safety analysis datasets, such as adverse events and serious adverse events, and ensures the datasets behind tables and figures are immutable; the writer uses the immutable tables as the source for the report's results text and keeps narratives consistent with the tables; the regulatory affairs specialist validates the safety data structure against ICH E3 and FDA and EMA requirements where applicable; the safety physician or medical monitor reviews the tables for completeness and medical relevance and validates adverse event coding; the data standards specialist ensures conformity with SDTM and ADaM and maintains metadata and controlled terminology; the programmer writes programs that generate tables without overwriting raw data and enforces append-only processing; the quality assurance auditor ensures the handling meets GCP and ALCOA+ principles, checks audit trails for tampering or inconsistency and ensures audit readiness; the IT team builds the tool that generates the tables, maintains secure storage for the safety data and implements access control; and the project manager holds everyone to the timeline and confirms the safety data are final before the report is signed off.
Introducing the tables into the report process
Implementation follows five steps: select software that supports creating and managing immutable tables, which could be a specialised data management system or a general-purpose tool customised for it; train the regulatory writers and other relevant staff to create and use the tables, including what immutability means for data integrity and consistency; integrate the tables into the existing report process, which may change when and how tables are created and reviewed; put quality control in place to confirm the tables really are immutable, such as periodic checks or software that verifies this automatically; and regularly review and improve the process, for example by asking the writers for feedback and monitoring the effect on quality and efficiency.
Benefits and costs
The benefits are consistency, since presentation is uniform across sections and discrepancies between the statistical results and the reported results can be reduced; data integrity, since accidental alteration is eliminated; a faster review, because reviewers can trust the tables; better quality and efficiency overall; traceability, since every version is preserved; extension to other report domains as in-house expertise grows; and support for accelerated submissions, the reliability and traceability of an immutable infrastructure enabling timely or even early submission and participation in expedited pathways such as the FDA's Real-Time Oncology Review. Further advantages are faster insertion of tables as links without copying, pasting and formatting, shorter timelines for complex data sets such as integrated safety summaries and periodic safety surveillance reports, comparison with historical data, auditability, no need for manual quality control and no transcription errors, and data privacy, which building the tables with cross-functional teams including quality assurance helps maintain. Automating the in-text safety tables keeps the data accurate, reliable and easy to manage; given the well-laid-out structure of safety tables, the automation can be extended to multiple reports and into integrated safety summaries and reports as the drug progresses to authorisation, which fast-tracks the reports, limits review fatigue and assures the sponsor of faster delivery with less quality-control burden.
The costs are significant technical expertise and infrastructure, with initial investment in people, software or tools; time and resources to set up and integrate the tables, given the cross-functional reviews and quality assurance oversight; training for clinical and writing staff once it is set up; the difficulty of assuring that the tables really are immutable and accurate, which needs robust quality control; and growing storage and data management, since data can only be added, so that over longer periods retiring and archiving data, and summarising key datasets from what is retired for longer-term outcomes, have to be managed.
The approach can significantly improve the accuracy, consistency, quality and efficiency of report development while reducing errors, bridging a gap the writers face particularly under contracted timelines, and can benefit the presentation of efficacy, demographic and other data as well as safety data. Successful implementation requires thorough training of the writers and other team members, and getting the most from it needs careful planning, including understanding its challenges and defining each contributor's roles.