Almost every discussion of ICSR processing starts at data entry. That skips the two steps that decide how much data entry you end up doing at all. Triage determines whether a report is a valid case, how urgent it is, and where it goes. Duplicate detection determines whether you are about to process something you already hold. Both happen in the first hours of a case's life, and both are cheap to do well and expensive to do late.
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.
Triage is often described vaguely as "initial review". In practice it resolves four separate questions, and conflating them is where processes go wrong. Each has a different consequence if answered incorrectly.
| Decision | Question | What it drives |
|---|---|---|
| Validity | Does this meet the four ICH E2D minimum criteria — identifiable patient, identifiable reporter, suspect product, adverse event? | Whether a case exists at all. Invalid reports are logged but do not become ICSRs |
| Seriousness | Does it meet any ICH seriousness criterion — death, life-threatening, hospitalisation, disability, congenital anomaly, other medically important? | Expedited versus routine handling, and the length of the reporting clock |
| Duplicate status | Have we seen this event, for this patient, on this product, before? | Whether this is a new case, a follow-up to an existing one, or nothing at all |
| Priority and routing | Who works this, and in what order relative to everything else in the queue? | Cycle time, and whether the expedited cases actually get done first |
The clock is already running
Day 0 is generally the date the first party in your organisation received the minimum information constituting a valid case — not the date triage got to it. Every day a report sits in an unmonitored mailbox is a day removed from a 15-day or 7-day obligation. This is why intake routing and triage latency are compliance controls, not administrative conveniences.
The four ICH E2D criteria sound mechanical until you apply them to real inbound reports. The judgement calls cluster in predictable places.
Identifiable, not identified
You do not need a name. Age, age group, sex, or any characteristic allowing the patient to be distinguished can suffice. "A patient" with no attributes at all generally does not.
Contactable in principle
An identifiable reporter — HCP, patient, consumer, or literature author. Fully anonymous reports with no attributable source are the common failure here.
Suspect, not just concomitant
A suspect medicinal product must be identified. A report naming only concomitant medications with no suspect drug does not constitute a valid case for you.
An adverse event or reaction
A stated adverse experience. Product quality complaints with no adverse event, and enquiries with no event, are logged separately rather than as ICSRs.
Two practical points. First, invalid reports still need to be recorded and retained — an inspector may well ask how many reports you rejected as invalid and why, and "we deleted them" is not an answer. Second, a report can become valid later: a follow-up that supplies the missing criterion turns a non-case into a case, and Day 0 is then generally the date the fourth criterion was received.
Duplicates are not primarily a discipline problem. They are the predictable output of having multiple legitimate inbound routes for the same underlying event.
- Multi-channel intake — the same patient reports by phone to a call centre and by email to a medical information mailbox
- Partner and licensee exchange — a partner forwards a case you also received directly, under your safety data exchange agreement
- Literature — a published case report describes an event you already hold as a spontaneous case
- Regulator or database feeds — a case received back from an authority or a shared database that originated with you
- Clinical and safety databases — an adverse event recorded in the trial database that also arrived as a safety report
- Follow-up mistaken as new — the most common internal cause: additional information on an existing case entered as a fresh report because the match was not made
Two failure directions, both costly
A missed duplicate means the same event is processed, assessed and submitted twice — visible to the authority in their database and awkward to explain. A false duplicate means genuinely new information is merged into an existing case and effectively lost, which is the more dangerous of the two because nobody notices. A detection process tuned only against the first failure will produce the second.
Matching runs on a set of key fields, and the practical difficulty is that in real reports most of those fields are partially missing, inconsistently formatted, or free text. Systems therefore combine deterministic and probabilistic approaches.
| Match key | Reliability | Why it fails |
|---|---|---|
| Patient identifiers (initials, DOB, sex) | High when present | Frequently partial or absent, especially in consumer reports |
| Suspect product | Moderate | Brand versus active substance, different strengths, and free-text spelling variants |
| Event term | Moderate | The same event described in entirely different words before coding; coding happens later |
| Event onset date | High when present | Often approximate ("last month"), or the reported date differs between sources |
| Reporter details | Low to moderate | The same case reported by different people, or by the patient and separately their physician |
| Case reference from partner | Very high when present | Only exists where an exchange agreement assigns one |
Because no single key is dependable, matching is normally scored across several. Deterministic rules catch exact and near-exact matches; probabilistic or fuzzy matching catches the rest by weighting partial agreement across fields. Both should produce a *candidate* with a score, not a decision.
Do not auto-merge
Automatic merging of suspected duplicates is the single most consequential shortcut in this part of the process. Merging is effectively irreversible from a data-integrity standpoint and can silently discard new information. Surface suspected duplicates to a reviewer with the evidence side by side, record the confirm-or-reject decision and who made it, and keep that on the audit trail.
This is the point at which the process becomes a technology question. Triage and duplicate detection split cleanly into work that should be automated and judgement that should not be.
| Step | Automate | Human |
|---|---|---|
| Channel routing | Yes — the inbound route should determine the tenant, product family and queue, not a person choosing afterwards | Exception handling only |
| Field extraction from the report | Yes — extract patient, product, event, reporter and dates from PDFs, emails and forms, with confidence per field | Verify low-confidence fields against the source |
| Duplicate candidate identification | Yes — score against the existing case population and surface candidates | Confirm or reject each candidate; never auto-merge |
| Validity screening | Partly — flag which of the four criteria appear present or missing | The validity determination itself, particularly borderline patient or reporter identifiability |
| Seriousness flagging | Partly — auto-flag terms and outcomes meeting ICH criteria | Confirmation and sign-off, which is a regulated judgement |
| Prioritisation and queue order | Yes — rules-based on seriousness, clock remaining, and agreement timelines | Override where operational context requires it |
| Day 0 determination | Yes — derived from receipt date per reporter region by a rules engine | Review where receipt is ambiguous across parties |
In PVgenix, duplicate detection runs at intake before a case enters a processing queue, and suspected duplicates are presented for reviewer confirmation rather than merged silently. Extraction is confidence-scored per field so uncertain values are routed to a person, and Day 0 plus the applicable expedited timeline are derived automatically. See AI case intake for the extraction and review console, and case processing and assessment for the stages that follow.
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.
Most teams measure case processing cycle time and stop there. These are the measures that tell you specifically whether triage and duplicate detection are working.
| Metric | What a problem looks like |
|---|---|
| Triage latency (receipt to triage complete) | Rising latency is clock you no longer have. Measure from receipt, not from when the case was opened |
| Duplicate detection rate | A rate near zero usually means detection is not working, not that you have no duplicates |
| False-duplicate rate (rejected candidates) | A very low rejection rate suggests matching is too loose and reviewers are rubber-stamping |
| Duplicates found downstream | Any duplicate discovered after data entry, or worse after submission, is a first-gate escape — root-cause each one |
| Invalid-report rate | A sudden change usually means an intake channel or form has changed, not that reporting behaviour has |
| Seriousness upgrade rate at review | Cases upgraded to serious after triage indicate the flagging logic or triage training needs work — and each one may have eaten clock |
- Unmonitored intake routes — a mailbox or form nobody owns, with cases sitting in it past their deadline
- Day 0 taken from case creation rather than from first receipt anywhere in the organisation, including affiliates and partners
- No documented rationale for rejecting reports as invalid, or invalid reports not retained at all
- Duplicates merged automatically with no reviewer decision recorded
- Follow-up information entered as a new case, producing an inflated case count and a fragmented history
- No reconciliation with partners, so cases that never arrived are never detected
- Triage performed by staff whose training records do not cover the current SOP version
The short version
Automate the routing, the extraction, the candidate matching, the prioritisation and the clock. Keep the validity call, the seriousness sign-off and the duplicate confirm-or-reject decision with a qualified person, and record every one of those decisions. Then measure triage latency from first receipt — because that is the number the regulatory clock is actually counting.
Next in this cluster: ICSR follow-up and case versioning for what happens when more information arrives, and medical review versus quality review for the two gates at the other end of the workflow. If you want to see the first gate running, ICSR management software is the place to start.
Frequently asked questions
Common questions
Under ICH E2D a valid individual case safety report requires four elements: an identifiable patient, an identifiable reporter, a suspect medicinal product, and an adverse event or reaction. "Identifiable" does not mean named — any characteristic allowing the patient or reporter to be distinguished can suffice. If a report is missing one of the four it is generally not a valid case, though it should still be recorded and retained, and it can become valid if follow-up supplies the missing element.
Day 0 is generally the date on which the first party within your organisation received the minimum information constituting a valid case — which includes affiliates, distributors, and in many arrangements partners under a safety data exchange agreement. It is not the date the case was opened in the safety database or the date triage was completed. This is why unmonitored intake routes are a compliance risk: clock is consumed before anyone is aware a case exists.
Structurally, because there are several legitimate routes for the same event to reach you: multi-channel intake (the same patient phoning and emailing), partner and licensee exchange, published literature describing a case you already hold, feeds back from authorities or shared databases, and the clinical database alongside the safety database. The most common internal cause is follow-up information being entered as a new case because the match to the existing case was not made.
Typically patient identifiers (initials, date of birth or age, sex), the suspect product, the event term, the event onset date, reporter details, and any partner case reference. No single field is dependable in real reports — patient details are often partial, products appear as brand or active substance with spelling variants, and the same event is described in different words before coding. Matching is therefore scored across several fields, combining deterministic rules for near-exact matches with probabilistic matching for the rest.
No. Automatic merging is effectively irreversible from a data-integrity standpoint and can silently discard genuinely new information — the more dangerous of the two failure directions, because nobody notices it. Suspected duplicates should be surfaced to a qualified reviewer with the evidence presented side by side, and the confirm-or-reject decision, with attribution, should be recorded on the audit trail.
Channel routing, field extraction from source documents, duplicate candidate scoring, queue prioritisation, and Day 0 and deadline derivation can all be automated. Validity screening and seriousness flagging can be partly automated — a system can indicate which criteria appear present or which terms meet seriousness criteria — but the validity determination, the seriousness sign-off, and the duplicate confirm-or-reject decision are regulated judgements that should remain with qualified personnel and be recorded.