Very few adverse event reports arrive complete. The initial report establishes that a case exists; the information that follows is what makes it assessable. Follow-up is therefore not an administrative tidy-up at the end of processing — it is a core part of the case lifecycle, with its own reporting consequences and its own audit expectations.
The technical decision underneath it is versioning. If a follow-up edits the case in place, you have improved your current data and destroyed your history. If it creates a new version, you keep both. That distinction determines whether you can answer the question every inspector eventually asks: what did you know, and what did you report, at the time?
Scope of this guide
This describes general industry practice to help you design a process and specify a system. It is not regulatory advice — your obligations come from applicable legislation, your agreements, and your own qualified PV personnel.
Follow-up has three distinct purposes, and they justify different levels of effort. Treating all follow-up as one undifferentiated task is why many teams chase low-value detail on non-serious cases while a serious case waits.
Make the case valid
Where one of the four ICH E2D criteria is missing, follow-up is what turns a non-case into a case. This is the highest-priority follow-up because a valid case may carry an expedited obligation.
Make the case assessable
Causality, expectedness and seriousness cannot be assessed properly without dates, dose, outcome, concomitant medication, medical history and de-challenge or re-challenge information.
Complete the regulatory dataset
Fields the receiving authority expects in an E2B submission, and the data your periodic reports and signal detection will later rely on.
A generic "please send any further information" request produces very little. Targeted follow-up — asking specific questions driven by what the case is missing and what the event requires — produces materially better response rates and better data.
| Case type | Approach | Typical effort |
|---|---|---|
| Serious, incomplete | Targeted, event-specific questionnaire; multiple attempts across channels | Highest — pursue actively, document every attempt |
| Serious, complete | Targeted only for outcome updates (e.g. resolution, sequelae, death) | Moderate — outcome follow-up until resolved or stabilised |
| Non-serious, missing validity criterion | Targeted at the missing criterion specifically | Moderate — a valid case may still carry obligations |
| Non-serious, complete enough | General or none, per SOP | Lowest — do not consume capacity here while serious cases wait |
| Fatal | Targeted, including cause of death, autopsy findings where available, and medical history | Highest — and typically on the shortest clock |
Document the attempts, not just the outcome
Auditors routinely test whether follow-up was actually attempted on incomplete serious cases. "No further information received" is acceptable only if you can show what was asked, of whom, when, through which channel, and how many times. An SOP should define the number of attempts and the interval, and the record should show they happened.
This is the single most consequential concept in follow-up handling. Not all new information is equal: some of it is administrative detail, and some of it materially changes the case — and material change generally creates a fresh expedited reporting obligation with its own clock, starting from the date the significant information was received.
| Generally significant | Generally not significant alone |
|---|---|
| A non-serious case becomes serious (e.g. hospitalisation reported) | A corrected spelling or reformatted date |
| A change in the reported outcome, particularly death | Additional concomitant medication with no bearing on the event |
| A change in causality assessment | Administrative reporter contact details |
| A change in expectedness or listedness | Clarification that does not alter the medical picture |
| A new adverse event added to the case | A duplicate reference number from a partner |
| New dechallenge or rechallenge information | Internal workflow or queue changes |
The trap
Teams often treat the follow-up clock as a continuation of the original one. It generally is not. If significant new information arrives on day 40 of a case already submitted, you typically have a fresh expedited obligation counted from receipt of that information — not zero days because the original was submitted on time. Whether a given item is significant is a regulated judgement and should be recorded as such.
The rule is simple and the consequences of breaking it are wide-ranging: a follow-up should create a new version of the case, preserving the prior version intact. Four things depend on that.
- Submission defensibility — you can show what was reported to which authority, and that it matched what was known at that time
- Aggregate reporting — periodic reports are built from the case versions in force at the data lock point, so regenerating a report must yield the same numbers
- Reconciliation — comparing your case population with a partner's requires a stable view of each case at a point in time
- Inspection — reconstructing the decision chain requires the assessment as it stood, not the assessment as it stands now
Alongside versioning, the audit trail should capture the field-level change: who changed what, when, and from which value to which value. Versioning tells you the case had five states; the audit trail tells you what moved between state three and state four, and who moved it.
Two mechanisms exist for correcting a submitted report, and they are not interchangeable.
| Mechanism | Use when | Effect |
|---|---|---|
| Follow-up / amendment report | The case is genuine and information has changed or been added | A new version is submitted, superseding the previous one in the authority's database |
| Nullification | The case should not exist — a confirmed duplicate that was submitted, or a report that was never a valid case | The report is withdrawn from the authority's database, with a stated reason |
Nullification is visible and reason-coded
A nullification carries a reason and is recorded by the receiving authority. A pattern of nullifications for duplicate submission is a direct signal that your duplicate detection is not working — which is why the first gate and the versioning discipline are the same problem viewed from two ends. See ICSR triage and duplicate detection.
Follow-up is administratively heavy and judgement-light in most of its steps, which makes it a good automation target — with two clear exceptions.
| Step | Automate | Human |
|---|---|---|
| Identifying incomplete cases | Yes — rules on missing mandatory and assessment-critical fields, by case type | Deciding effort level where an SOP allows discretion |
| Matching inbound follow-up to the right case | Yes — the same matching logic as duplicate detection, surfaced as a candidate | Confirm the match; never auto-attach on a weak score |
| Extracting the new data from the follow-up document | Yes — confidence-scored per field | Verify low-confidence fields against the source |
| Creating a new version | Yes — automatic on accepted change, with the prior version preserved | None |
| Follow-up request generation and tracking | Yes — templated targeted questionnaires, attempt counters, due reminders | Content of non-standard clinical queries |
| Deciding whether new information is significant | Flag candidates only (e.g. seriousness or outcome changed) | The determination itself — it creates a reporting obligation |
| Re-derived reporting obligations and new clock | Yes — the rules engine recalculates destinations and deadlines on the new version | Review where the significance call was borderline |
In PVgenix, each follow-up creates a new case version rather than editing in place, inbound follow-up is matched against the existing case population for reviewer confirmation, and the reporting rules engine re-resolves obligations and deadlines on the new version. Aggregate reporting uses the case versions in force at the data lock point, which is what makes a regenerated periodic report reproduce the same figures. See case processing and assessment, regulatory submission and aggregate reporting.
Where the judgement stays
AI assists intake and data entry. Qualified personnel review, edit, and approve AI-generated content before a case proceeds; regulated judgments remain with the client's PV personnel.
| Metric | What a problem looks like |
|---|---|
| Follow-up cycle time | Long cycles on serious incomplete cases mean assessments are being made on thin data |
| Follow-up response rate | A low rate often means requests are general rather than targeted, or going to the wrong channel |
| Cases closed as incomplete | A rising share suggests follow-up attempts are being abandoned early — check the attempt records |
| Versions per case | An unusually high average can indicate follow-up fragmentation or matching failures creating churn |
| Follow-up submissions late | Usually the significant-information clock being treated as a continuation of the original |
| Nullification count and reason mix | Duplicate-reason nullifications point back at the first gate |
- Follow-up edits applied in place, leaving no record of the earlier state of the case
- No evidence that follow-up was attempted on incomplete serious cases
- Significant new information treated as administrative, so no new expedited report was submitted
- Follow-up entered as a new case, inflating case counts and splitting the history of one event across two records
- Aggregate reports that cannot be reproduced because the underlying cases have moved on since the data lock point
- Nullifications used to fix data errors that should have been amendments
The short version
Target your follow-up rather than sending generic requests, document every attempt, and treat the significance determination as the regulated judgement it is — because it usually starts a new clock. Never overwrite a case: version it, and keep field-level audit history alongside. Everything downstream, from submission defensibility to reproducible periodic reports, depends on that one discipline.
Also in this cluster: ICSR triage and duplicate detection and medical review versus quality review. For how the case record holds all of this, see ICSR management software.
Frequently asked questions
Common questions
Information that materially changes the case rather than tidying it up. Typical examples are a non-serious case becoming serious, a change in outcome (particularly death), a change in causality or expectedness, a new adverse event added to the case, or new dechallenge or rechallenge information. Corrected spellings, reformatted dates, administrative reporter details and irrelevant concomitant medication are generally not significant on their own. The determination is a regulated judgement and should be recorded, because significance usually creates a fresh reporting obligation.
Where the new information is significant, it generally creates a fresh expedited reporting obligation counted from the date that information was received — not a continuation of the original clock. A common and costly misunderstanding is to assume that because the initial report was submitted on time, a follow-up carries no new deadline. Confirm the specific requirement against the applicable legislation and your agreements with your qualified PV personnel.
Because four things depend on being able to reconstruct the case as it stood at an earlier point: showing that what you submitted matched what you knew at the time; reproducing aggregate reports built from the case versions in force at a data lock point; reconciling your case population with a partner's at a point in time; and reconstructing the decision chain during an inspection. Editing in place improves the current record and destroys all four capabilities.
An amendment or follow-up report is used when the case is genuine and information has changed or been added — a new version supersedes the previous one in the authority's database. Nullification is used when the report should not exist at all, such as a confirmed duplicate that was submitted or a report that was never a valid case; it withdraws the report with a stated reason. They are not interchangeable, and using nullification to fix ordinary data errors is a common error.
There is no single universal number — it should be defined in your SOP, scaled to case seriousness and completeness, and then evidenced. What auditors test is not whether you hit a particular count but whether the record shows what was asked, of whom, through which channel, when, and how many times. "No further information received" is acceptable only when the attempts behind it are documented.
Most of the administrative load: identifying incomplete cases by rule, matching inbound follow-up to the correct existing case, extracting the new data with per-field confidence scoring, creating the new version automatically while preserving the prior one, generating targeted follow-up requests with attempt tracking and reminders, and re-deriving reporting obligations and deadlines on the new version. The significance determination — and therefore whether a new expedited obligation exists — should remain a recorded human judgement.