DSUR writing software: where it helps and where it should stay out

What a DSUR has to do

ICH E2F sets the format. The DSUR is an annual review of safety information for a drug under development, covering every trial running anywhere in the world, with a data lock point tied to the development international birth date. It is due within sixty days of that data lock point.

Its job is narrower than people sometimes treat it. It is not a summary of everything that happened. It is an assessment of whether the safety profile has changed, and whether the risk to trial participants is still acceptable. Everything in it should serve that question.

Where the time actually goes

Ask a safety writer and the answer is rarely the first draft. It is assembly and reconciliation.

The cumulative tables have to match the interval tables. The interval tables have to match the line listings. The narrative has to match all three. The exposure estimates have to be consistent with what the clinical team reported elsewhere. And the whole thing has to agree with last year's DSUR, except where it deliberately does not.

That is mechanical work that people do badly, not because they are careless but because it means holding hundreds of numbers in mind across a long document. It is also where findings come from. An inconsistency between a table and the text is the first thing a reviewer notices.

What software should draft, and what it should not

The descriptive sections are a fair target: the summary of ongoing and completed trials, exposure, the interval line listings, and the restatement of tables in prose. All of that exists in source data already. Drafting it is transcription with structure.

What software should not touch is the judgement. The overall safety assessment, the evaluation of new signals, the benefit-risk conclusion and any change to the reference safety information belong to a qualified person who signs them. A tool that drafts the descriptive sections and leaves those fields alone is doing its job. A tool that proposes a conclusion is doing something else, and should be judged as such.

The one feature that matters most

Every number and every factual statement in the draft should point back to where it came from. Not a footnote at the end. A link a reviewer can follow in place.

That changes the review. Without it, a reviewer reads for plausibility, and a fluent wrong number reads as well as a right one. With it, the reviewer checks against source, which is the only kind of review that holds up over a long document.

It also makes next year easier. When a dataset is corrected or a trial is re-analysed, the statements that depend on it can be found straight away, instead of someone re-reading the whole report. It is the property our clinical documentation work is built around.

Questions to ask a vendor

• Does every factual statement trace to a specific source, and can a reviewer see it without leaving the document?
• What does the tool refuse to draft? If the answer is nothing, that is a problem.
• How does it handle a dataset that changes after drafting has started?
• What happens to the audit trail, and does it meet 21 CFR Part 11 in practice rather than on a slide?
• Has the vendor validated its own AI, and can they show you the evaluation evidence?

The last question is the one most vendors struggle with. We cover it in more detail in what sponsors ask about AI in clinical writing.

Where to start

Not with the whole report. Start with the sections that are purely descriptive and high volume: trial status, exposure, interval listings. A writer can check those quickly, so you learn fast whether the tool is trustworthy.

Then move to consistency checking across the document, which is usually the biggest time saving and the safest one. Leave the safety assessment and conclusions with your qualified people, permanently.

TraceDraft is our product for this, backed by our pharmacovigilance practice. If you want to see it against one of your own reports, get in touch.