Reporting complex safety data in the report and the summary of clinical safety
A study or submission can produce more safety output than a health authority reviewer can readily digest, so the writer of the clinical study report and the Module 2.7.4 summary of clinical safety makes the important findings easy to find rather than reporting everything. Doing so involves navigating the outputs, turning adverse event tables into narrative while leaving causality to physicians, applying lean writing without cutting too much, and settling the level of detail at the kick-off meeting.
The volume and layout of safety outputs
As clinical studies and development programmes grow more complex, clear and informative reporting of safety data matters more than ever, and the writer has a key role in guiding the team on the best way to communicate the key safety findings. Innovative designs generate large volumes of safety data, and hundreds of tables, listings and figures may be produced for each study and submission, a sea of information that a health authority reviewer cannot readily digest. A document packed with irrelevant detail risks obscuring the key data. By shaping the document, the writer guides the reviewer and eases the assessment of safety data that will help answer one of the key questions of a submission: whether the product's safety profile is acceptable. Guidance for the report and for Module 2.7.4 is well established, and the writer should be familiar with it. To craft a clear story, however, the writer needs to deliver insight, not just report data.
Writers making sense of safety data may meet some common challenges, however unique each study or submission is. One is being handed a list of safety outputs with little explanation or orientation from the team. Standard tables usually sit in the same place in the list whatever the data set, but outputs specific to the study or submission are not always in the most obvious or logical place. It pays to read the table of contents of the outputs carefully and to annotate the working document with the output numbers relevant to each section, marking which outputs are likely to be important to discuss and which need only a cross-reference. In a clinical study report, this also ensures that every output is referred to in the document.
Another early challenge is that the layout of individual outputs can sometimes be unhelpful. With multiple arms, or data from multiple studies in a submission, there may be too many columns to fit a page, and each row can then split across several pages, which lengthens the output considerably and can make it hard to keep track of one's place. In some cases adverse event listings may be organised by MedDRA system organ class and preferred term, which makes it hard to populate in-text tables ordered by the frequency of preferred terms alone. It may be possible to request extra programmed outputs to avoid populating tables by hand, but this is not always feasible or desirable for reasons of cost and timelines. Ideally the writer should be involved early in developing the outputs and review the shells or dry-run outputs to identify such problems. Often that does not happen, particularly when the writer is external to the sponsor and joins only when authoring is due to start, and it is then up to the writer, with the team's support, to direct the reviewer to the most pertinent information.
Turning adverse event tables into narrative
Tables, listings and figures (TLFs, also called tables, listings and graphs, or TLGs) are the raw material the writer is given to build regulatory documents. The writer synthesises hundreds of tables such as adverse event tables into narrative summaries, going through them to try to pull out the most relevant information. A standard adverse event table shows the percentage of patients with each event in the placebo and treatment groups, by system organ class and preferred term. System organ classes such as blood and lymphatic system disorders, gastrointestinal disorders and hepatobiliary disorders head the rows, and the preferred terms beneath them, such as anaemia, thrombocytopenia, nausea, vomiting and diarrhoea, name the individual events.
In one illustrative table for an unnamed drug, 78% of placebo recipients and 82% of those taking the drug had any adverse event, figures that could be argued to be statistically similar. Anaemia occurred in 15% of the placebo group and 42% of the treated group. The narrative written from the table reports nausea, vomiting and diarrhoea as the most commonly observed events, above 30% in both groups, and anaemia and thrombocytopenia as observed more frequently with the drug than with placebo. It concludes that participants in both groups had similar numbers of adverse events and that investigators can determine that anaemia and thrombocytopenia were more common in those treated with the drug.
Determining whether an event is related to the drug requires a physician, and the writer presents the data for that determination without making it.
Reporting what matters
The reviewer has access to all the source data submitted, so the report and the summary can concentrate on the most important safety findings. Discussing every piece of data collected is neither necessary nor recommended. An everything-but-the-kitchen-sink approach is not helpful, and regulators will not appreciate having to work hard to understand the most important points. Regulators want value, not volume. A submission is less likely to be approved if the reviewer cannot locate the most relevant data.
So the writer should encourage the team to draft key messages early, ideally before writing begins, which helps the team decide which data are most important to present and how. Rather than large in-text tables, which are often overwhelming, shorter tables with appropriate frequency cut-offs improve understanding of frequently reported adverse events. A high-level summary statement can present the key message, followed by supporting detail or, where relevant, cross-references to the source data to give the full picture. Prompts in the draft can help a team think about how much is needed, for instance by asking whether a section of hard-to-interpret subgroup analyses should become a high-level summary with a cross-reference to the source outputs. Some teams insist on including as much information as possible, and it is advisable to remind them of the drawbacks of too much detail.
Lean writing and the level of detail
The level of detail is one of the most difficult judgements in reporting safety data. Lean writing avoids wordiness and redundancy, but reporting too little information is unhelpful too, and consideration should be given to when to apply it. The writer should ask how much detail is enough to tell the story, and should weigh the following to avoid reporting too little:
- Study phase. Pivotal phase 3 studies demand more in-depth reporting than supportive studies.
- Clinical importance. Reviewers are more interested in adverse events that may have a lasting or significant impact on patients' quality of life. Trivial events commonly managed through routine care without lasting impact may not need reporting in as much detail. For laboratory tests and vital signs without significant or relevant findings, a single high-level statement and a cross-reference to the outputs may suffice.
- Important or unexpected findings. Adverse events of special interest, adverse events of potential interest, serious adverse events and unexpected findings warrant more detail.
- Timing. Some detailed analyses might be left to regulatory defence, the stage of responding to the health authority's questions.
The kick-off meeting
Many of the challenges of reporting safety data can be avoided with a well-planned, strategic kick-off meeting, which should discuss the overall content requirements, the expectations for in-text tables and figures against appendices, and preliminary decisions on the level of detail. Knowing the product, the study design and the key risks beforehand can help focus the meeting on the most relevant data. The writer should feel confident persuading the team to report only what matters, working with the clinical and safety teams to establish what is important for the submission.
If the kick-off meeting has not settled the team's expectation on the level of detail, the writer should gauge it from shell or early drafts. Early on it may be more helpful to err towards more detail and to flag sections or items for discussion and revision, which ensures nothing important is missed and invites the team's input on what is essential. An overly lean early draft may need more substantial revision later, and it is much easier for a team to decide that information is no longer needed than to notice that something that needs to be reported is missing.
Expectations on timelines and data accuracy also need to be set. Dry-run data can be useful for prototyping, but shell in-text tables should not be populated until the final outputs arrive. Checking all the data in the document against the final outputs later to see what has changed is impractical unless considerable time is allowed for a full quality control check. A team is likely to have a preferred way of working that the writer, particularly an external one, may not know. Approaches such as these are adaptable and can often be integrated into the team's existing practices. The approach should be agreed at the kick-off meeting to help the project run smoothly, and the writer should emphasise that making key decisions and reviewing thoroughly early in document development reduces the chance of extra delays and costs from substantial late changes. The temptation to include every detail may be strong, but by working transparently with the team and setting expectations early the writer can maximise impact and minimise unnecessary detail.