Every few months someone publishes a piece describing how automation will transform periodic safety update report preparation. The vision is appealing: software ingests your cumulative ICSR data, runs your signal analysis, populates your report template, and your QPPV reviews a near-complete document rather than a blank structure that needs to be filled from scratch.
Some of that vision is real. Some of it misunderstands what regulatory agencies actually require from a PSUR, and selling the complete-automation story to a regulatory affairs team or a QPPV creates expectations that technology cannot currently meet — and arguably shouldn't meet, because the parts that can't be automated are the parts that carry the most regulatory accountability.
This piece is a frank account of the automation boundary as it currently stands. I'll describe what is genuinely automatable in PSUR preparation, what is partially automatable with human oversight, and what requires expert scientific judgment that automation should not attempt to substitute for.
The PSUR Structure as a Framework for Thinking About Automation
The ICH E2C(R2) guideline defines the PSUR structure. Working through the major sections — Regulatory Background and Completion of a List of Requirements, World Market Authorization Status, Actions Taken for Safety Reasons, Changes to Reference Safety Information, Estimated Exposure and Use Patterns, Data in Summary Tabulations, Summaries of Significant Findings, Signal and Risk Evaluation, Benefit-Risk Evaluation — you can roughly classify each section by its automation potential.
Some sections are predominantly factual data compilation. Some require epidemiological interpretation. Some require the QPPV or qualified medical reviewer to make a documented judgment about what the data means for the benefit-risk profile. That last category is not a candidate for automation now or in the foreseeable future, and being explicit about why matters for setting realistic expectations.
What Is Genuinely Automatable
World Market Authorization Status
This section requires a table of countries where the product is authorized, the indication and date of authorization in each, and any variations affecting the product. This is a data compilation task. A product lifecycle management database or regulatory information management system with current records can populate this section programmatically with high reliability. The primary risk is data quality in the source system — garbage in, garbage out — but the compilation step itself does not require scientific judgment.
Cumulative ICSR Summary Tabulations
The line listing and summary tabulations — cases by seriousness, by reporting source, by system organ class, cumulative serious case counts by preferred term — are mechanically generated from the safety database. Every validated safety database system produces these outputs. The automation here is not a new capability; it's the baseline expectation for compliant safety data management. What's less consistently automated is the comparison tables across review periods and across regulatory regions when a product has different data lock points for different PSUR submissions. Getting those comparison tables right programmatically, consistently, across a multi-product portfolio, is where many teams still spend manual effort.
Exposure Data Assembly
Estimated patient exposure — typically expressed as patient-years, treatment episodes, or units sold depending on the product type — can be compiled from commercial data sources, clinical trial enrollment records, and market data. The compilation is automatable; the epidemiological conversion from units sold to patient-years requires defined assumptions (average duration of therapy, adherence estimates) that should be documented by a scientist but don't change frequently once established for a given product.
Signal Status Tracking
Section 16 of the PSUR (Signal and Risk Evaluation) requires a tabular summary of all signals that were evaluated during the reporting period, including their current status. If your signal management system maintains structured records of signal detection, validation, assessment conclusions, and status changes with complete timestamps, that table can be auto-populated. The caveat is that the signal assessment conclusions themselves — what the data means, whether the risk-benefit balance changed — cannot be populated by automation. The status table is a navigation aid; the assessment content behind it is the substance.
What Is Partially Automatable
Benefit-Risk Summary Population
The benefit-risk section requires a narrative summary of established benefits (from pivotal trial data, approved indication), the identified and potential risks, and a conclusion about whether the benefit-risk balance remains positive in the context of cumulative post-marketing safety information. The benefit side of this equation is relatively stable — unless there's new clinical trial data changing the efficacy picture, the benefit summary changes little between PSURs. A template with prior-period language that is reviewed and confirmed (rather than generated from scratch) is a reasonable partial automation. The risk side and the integrative benefit-risk judgment are scientific conclusions that require human authorship.
Literature Search Compilation
Systematic literature surveillance for PSUR periods follows defined search strategies across PubMed, Embase, and other databases. The search execution, abstract retrieval, and initial relevance screen based on structured criteria can be substantially automated. The judgment about whether a paper contains new safety-relevant information that should be reflected in the reference safety information or cited in the signal section requires a scientist to read and interpret the paper. Automating the assembly of search results so that scientists are reviewing a pre-filtered set rather than raw search output is a meaningful efficiency gain; automating the scientific interpretation is not appropriate.
What Cannot Be Automated: The Lines That Matter
I want to be direct here. Regulatory agencies review PSURs with an understanding that a responsible person — the QPPV in EU contexts, the appropriate qualified physician in FDA contexts — has applied scientific judgment to the conclusions in the report. The expectation is not that a system generated these conclusions and a human rubber-stamped them. The expectation is that a qualified scientist evaluated the data and reached a documented conclusion.
Integrated Benefit-Risk Conclusion
The concluding benefit-risk statement in a PSUR is a regulatory-significant medical judgment. If the benefit-risk balance is unchanged, that statement commits the marketing authorization holder to the position that the cumulative safety data — including new signals, updated exposure data, and any literature findings — does not materially alter the product's risk profile. If that position turns out to be incorrect and a safety issue emerges that was visible in the data at the time of the PSUR, the benefit-risk section becomes relevant to any subsequent regulatory inquiry.
No automation system should generate this conclusion. The QPPV or designated medical reviewer writes it, with full awareness of the data, the signals, the company's regulatory obligations, and the product's clinical context. That is the purpose of having a QPPV. Automation that generates a proposed benefit-risk conclusion for human approval substitutes a machine's statistical summary for expert medical reasoning, and creates an ambiguous accountability chain when the conclusion is wrong.
Interpretation of New or Emerging Signals
When a new signal appears during a PSUR review period that was not present in prior submissions, the PSUR must address it. The characterization of the signal — the evidence base, the clinical plausibility, the proposed mechanism, the assessment of whether existing risk minimization is adequate — requires a pharmacologist or clinically trained pharmacovigilance scientist to write it. Signal detection can be algorithmically assisted; signal interpretation cannot be.
Reference Safety Information Update Decisions
The Company Core Safety Information (CCSI) is the reference against which expectedness is assessed across the product's global safety database. When cumulative ICSR data, new clinical information, or a signal assessment suggests that a new adverse reaction should be added to the CCSI, that is a consequential regulatory and medical decision. It changes the expectedness classification of future cases, affects aggregate reporting obligations, and may trigger label update negotiations with regulatory authorities. This is a medical and regulatory judgment call that requires expert human decision-making.
The Practical Implication for PSUR Timelines
A realistic expectation for automation in PSUR preparation is roughly this: the data assembly and tabulation work that currently occupies 30-40% of PSUR preparation time can be reduced to a verification and quality check rather than a generation task. That's a meaningful reduction in calendar time and scientist-hours. The narrative writing, signal interpretation, and benefit-risk conclusion remain human work and should remain human work.
The teams we've seen benefit most from automation in aggregate reporting are those that have invested in structured data practices upstream — clean MedDRA coding, consistent signal management documentation, well-maintained exposure databases. Automation at the PSUR assembly stage is only as good as the data it assembles from. Teams that try to automate PSUR preparation without first cleaning up the upstream data quality issues find that the time saved in assembly is consumed by validation and correction of auto-populated content.
The goal should be a PSUR preparation process where scientists spend their time on scientific reasoning — evaluating what the cumulative data means, writing interpretive narrative, making defensible regulatory judgments — rather than on data extraction, table formatting, and section population. That goal is achievable with current technology. A fully automated PSUR is not achievable, nor should it be.