In many safety operations "case review" is treated as one step performed by whoever is available. In a well-designed workflow it is two steps that answer genuinely different questions, require different competence, and produce different records. When they are collapsed together, cases can pass through two sign-offs without either question being properly asked — which is exactly the pattern that surfaces in audit findings.
Quality review asks: is this an accurate and complete record of what was reported? Medical review asks: does this make clinical sense, and what does it mean?
Scope of this guide
This describes general industry practice to help you design a workflow and specify a system. It is not regulatory advice, and it does not define who is qualified to perform any given activity in your organisation — that is determined by applicable legislation, your SOPs, and your qualified PV personnel.
| Quality review (QC) | Medical review | |
|---|---|---|
| Core question | Is the case record accurate and complete against the source? | Is the case clinically coherent, and what is the assessment? |
| Typically performed by | Trained QC reviewer or senior case processor | Physician or appropriately qualified healthcare professional |
| Primary reference | The source documents and your data-entry conventions | Clinical judgement plus the reference safety information |
| Checks | Field-by-field accuracy, coding consistency, narrative-versus-data agreement, mandatory field completeness, regulatory dataset readiness | Seriousness, causality, expectedness, medical plausibility, narrative clinical sense, whether further follow-up is medically necessary |
| Typical failure mode | Transcription errors, inconsistent coding, narrative contradicting structured fields | Seriousness under-called, causality assessed mechanically, listedness assessed against the wrong datasheet version |
| Output | Case corrected and confirmed as an accurate record | Recorded assessment with rationale, and a decision on release |
Quality review is often described as "checking for errors", which understates it. A good QC step tests specific, enumerable things, and the checklist should be written down rather than held as tacit knowledge.
- Source fidelity — every structured field traceable to something in the source document, with nothing invented and nothing dropped
- Narrative-versus-data agreement — the single most productive check: the narrative says the patient was hospitalised while the seriousness field says non-serious
- Coding consistency — the coded term reflects the reported verbatim, at the correct level, against the correct dictionary version
- Date logic — onset after start of therapy, outcome date after onset, no impossible sequences
- Dose and product detail — correct product, strength, route, and distinction between suspect and concomitant medication
- Mandatory and conditionally mandatory fields — completeness against the regulatory dataset you will submit, not just against your internal form
- Duplicate check confirmation — that the duplicate decision was made and recorded, not skipped
- Follow-up status — that outstanding follow-up is recorded and requests were actually issued
The most valuable single QC check
Read the narrative, then read the structured fields, and confirm they describe the same case. Most consequential data-entry errors — wrong seriousness, wrong outcome, a missing event, the wrong suspect product — are visible as a contradiction between the two. Automated field validation cannot catch this; it is a comprehension check.
Medical review is not a second QC pass by someone more senior. It answers questions QC is not competent to answer, and it produces the regulated determinations the case is submitted on.
Seriousness confirmation
Whether an ICH seriousness criterion is genuinely met — including the "other medically important" criterion, which is a clinical judgement and cannot be automated away.
Causality assessment
Company causality using WHO-UMC or a company algorithm, considering temporal relationship, alternative explanations, dechallenge and rechallenge — kept distinct from the reporter's own assessment.
Expectedness / listedness
Whether the event is listed in the reference safety information version in force. This drives expedited reporting, so getting the datasheet version right matters as much as the clinical call.
Medical plausibility
Whether the case hangs together clinically, whether the coded terms represent the event a clinician would recognise, and whether a diagnosis should be coded rather than a list of symptoms.
Follow-up necessity
What additional information would materially change the assessment — which makes follow-up targeted rather than generic.
Signal awareness
Whether the case represents something new or unusual worth flagging outside the routine disproportionality cycle. Statistics lag; a reviewer's recognition does not.
These determinations do not belong to the software
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.
The conventional order is data entry, then quality review, then medical review, then release. The logic is that a physician's time should not be spent finding transcription errors — the case should be accurate before it reaches clinical judgement.
In practice the loop runs both ways, and the workflow should support that explicitly rather than forcing people into email. Medical review frequently sends a case back — a coded term does not represent the clinical event, a diagnosis should replace a symptom list, the narrative needs rewriting. Each return should be recorded, because the pattern of returns is one of the most useful quality signals you have.
| Decision | Owner | Can the other overrule? |
|---|---|---|
| Data accuracy against source | Quality review | Medical review can request correction, not silently change the source interpretation |
| Coded term selection | Quality review applies conventions; medical review determines clinical appropriateness | Medical review prevails on clinical appropriateness; the change and its rationale are recorded |
| Seriousness | Medical review | No — QC flags candidates only |
| Company causality | Medical review | No |
| Expectedness / listedness | Medical review, against the controlled datasheet version | No |
| Release to submission | Medical review or a defined approver per SOP | No |
A person should not approve their own work. That principle sits behind 21 CFR Part 11 expectations and GxP segregation of duties, and in a small team it is the control most often quietly broken — because the same two people do everything.
- The user who performed data entry should not be the user who completes quality review on the same case
- Roles should be assigned under least privilege, so the permission simply does not exist rather than relying on people to decline it
- Each review step should carry an electronic signature bound to the record it approves, with the meaning of the signature clear
- Where a small team makes full separation impossible, the compensating control and its rationale should be documented in advance — not explained during an audit
- Training records should show that the person performing each step was trained on the current SOP version
For the underlying record-keeping expectations, see 21 CFR Part 11 compliance in pharmacovigilance.
Reviewing every case at full depth is the safest position and, at volume, not always the most sensible allocation of clinical time. Risk-based QC is defensible — but only when the risk model is explicit, documented, and monitored.
| Case characteristics | Typical review depth |
|---|---|
| Serious, fatal, or expedited-reportable | 100% quality review and 100% medical review |
| Non-serious, listed, established product, high-confidence data | Sampled quality review per SOP; medical review per SOP, potentially sampled |
| Clinical trial cases, particularly potential SUSARs | 100% both — the expedited consequences and blinding considerations warrant it |
| Cases with low-confidence extracted fields | 100% quality review regardless of seriousness |
| New product, or product under additional monitoring | Higher depth than the established-product baseline |
| Processor in training, or first cases after an SOP change | Elevated sampling until the error rate stabilises |
Sampling requires evidence that it works
If you sample, you must monitor the error rate found in the sampled population and be able to show that it stays within an acceptable threshold — and that you escalate depth when it does not. Sampling without that feedback loop is not risk-based quality control; it is reduced quality control with a better name.
This is where the split between the two gates becomes practically useful: a large share of quality review is mechanically checkable, and almost none of medical review is.
| Check | Automate | Human |
|---|---|---|
| Mandatory and conditionally mandatory field completeness | Yes — validated against the target regulatory dataset before release | Resolve genuine unknowns |
| Date logic and internal consistency | Yes — rule-based | Adjudicate where source dates conflict |
| Coding against the correct dictionary version | Yes — auto-coding plus version enforcement | Clinical appropriateness of the term, and any override |
| Duplicate decision recorded | Yes — workflow gate | The decision itself |
| Low-confidence extracted fields routed for checking | Yes — per-field confidence scoring | Verification against source |
| Narrative-versus-data agreement | Partly — inconsistencies can be flagged as candidates | The comprehension check itself |
| Sampling selection and review assignment | Yes — rules-based, with segregation of duties enforced | Escalation decisions |
| Seriousness, causality, expectedness, release | No | Entirely — recorded with rationale and signature |
In PVgenix, quality and medical review are configurable workflow states with review gates and sign-off roles set per tenant, so the sequence can match your SOPs rather than a vendor default. Role-based access control under least privilege supports segregation of duties, electronic signatures are captured, and every return, override and approval is on the audit trail with attribution and before/after values. See case processing and assessment and quality management for how findings feed CAPA and deviation records.
| Metric | What a problem looks like |
|---|---|
| QC failure rate by processor and case type | A rate near zero usually means QC is not looking hard enough, not that entry is perfect |
| Medical review return rate to QC | A high rate points at coding conventions or narrative quality; a zero rate points at medical review not engaging |
| Seriousness upgrades at medical review | Frequent upgrades mean triage or entry is under-calling seriousness — and clock may already be lost |
| Causality changed from reporter assessment | Neither high nor low is inherently wrong, but the distribution should be explicable |
| Listedness assessed against a superseded datasheet | Any occurrence is a finding waiting to happen — this should be structurally impossible, not monitored |
| Segregation-of-duties exceptions | Any case where entry and approval share a user; should be zero and enforced by role, not counted afterwards |
| Review cycle time by depth | If medical review is the bottleneck, check how much of its time is spent on correctable QC issues |
- One combined "review" step with no distinction between data accuracy and clinical assessment, and no record of which was performed
- The same user performing entry and approval, with no documented compensating control
- Medical review sign-off present but no recorded rationale for causality or expectedness
- Listedness assessed against a datasheet version that was not in force on the assessment date
- Sampling in use with no monitored error rate and no escalation trigger
- Narrative contradicting structured fields in released cases — the check nobody owned
- Reviewers whose training records do not cover the current SOP version
The short version
Keep the two gates separate, in that order, and let the system enforce who may do which. Automate everything in quality review that is mechanically checkable so that clinical time is spent on clinical questions — and record the medical determinations with their rationale, because those are what the case is submitted on.
Also in this cluster: ICSR triage and duplicate detection and ICSR follow-up and case versioning. To see the review gates configured, see ICSR management software.
Frequently asked questions
Common questions
Quality review asks whether the case record is an accurate and complete representation of what was reported — field-by-field source fidelity, coding consistency, date logic, narrative-versus-data agreement, and completeness against the regulatory dataset. Medical review asks whether the case is clinically coherent and what the assessment is — seriousness confirmation, company causality, expectedness against the reference safety information, medical plausibility, and whether further follow-up is medically necessary. They test different things and require different competence.
Conventionally data entry, then quality review, then medical review, then release — so that clinical time is not spent finding transcription errors. In practice the loop runs both ways: medical review frequently returns a case because a coded term does not represent the clinical event or the narrative needs rewriting. The workflow should support that return explicitly and record it, because the pattern of returns is a useful quality signal.
Typically a physician or appropriately qualified healthcare professional, because the determinations involved — seriousness including the "other medically important" criterion, causality, expectedness, and medical plausibility — are clinical judgements. Exactly who is qualified in your organisation is determined by applicable legislation, your SOPs, and your qualified PV personnel, and their training records should cover the current SOP version.
They should not. A person approving their own work undermines the segregation of duties that sits behind 21 CFR Part 11 expectations and GxP practice. The control is strongest when the system enforces it through least-privilege roles, so the permission does not exist, rather than relying on individuals to decline it. Where a small team makes full separation genuinely impractical, document the compensating control and its rationale in advance.
It can be defensible, provided the risk model is explicit and documented and the outcome is monitored. Serious, fatal, expedited-reportable and clinical-trial cases are normally reviewed at full depth, along with any case containing low-confidence extracted data. If you sample the remainder, you need to track the error rate found in the sampled population, hold it within a defined threshold, and escalate depth when it drifts. Sampling without that feedback loop is simply reduced quality control.
Reading the narrative and the structured fields and confirming they describe the same case. Most consequential data-entry errors — wrong seriousness, wrong outcome, a missing event, the wrong suspect product — show up as a contradiction between the two. Automated field validation cannot catch it because it is a comprehension check rather than a rule check, which is precisely why it should be an explicit step owned by a person.