GVP Module VI: Case Intake, Triage and Initial Assessment

1. Introduction

The point at which pharmacovigilance information first reaches an organisation is one of the most important control points in the individual case safety report (ICSR) lifecycle.

A report cannot be processed correctly if it is not recognised, captured, dated and routed correctly at intake. Conversely, an intake process that creates large numbers of cases without appropriate triage can overload downstream processing and obscure genuinely urgent safety information.

GVP Module VI therefore needs to be understood as an end-to-end process rather than simply a database activity. The system must allow safety information to be acquired, recorded, assessed for validity and exchanged within the applicable regulatory timelines. EMA describes the collection system as needing to support reports that are authentic, legible, accurate, consistent, verifiable and as complete as possible for clinical assessment. citeturn0search16

This article focuses on the front end of the ICSR lifecycle: receipt, recognition, logging, Day 0 determination, triage, validation hand-off and initial assessment. It does not duplicate the dedicated articles on ICSR validity, source-specific cases, follow-up, duplicate management or data quality.

2. Where Intake Sits in Module VI

The practical lifecycle can be represented as:

Safety information received
          ↓
Recognition of PV relevance
          ↓
Initial capture / logging
          ↓
Awareness date established
          ↓
Triage and prioritisation
          ↓
Validation
          ↓
Case creation / processing
          ↓
Medical assessment
          ↓
Submission where required
          ↓
Follow-up and lifecycle management

The boundaries between these activities may differ between organisations and systems. The controls must nevertheless preserve the important regulatory facts: what information was received, when it became known to the relevant organisation, what decision was made and what happened next.

3. Collection Is Broader Than the Safety Database

A common misconception is that "intake" begins when a case processor creates a record in the safety database.

It does not.

Potential safety information may first appear in an email inbox, call-centre record, medical-information enquiry, affiliate system, vendor platform, literature-monitoring workflow, clinical or post-authorisation study process, patient-support programme, digital channel or other business process.

GVP Module VI requires systems capable of collecting reports from both unsolicited and solicited sources. citeturn0search16

The organisation therefore needs an intake architecture, not merely a case-entry screen.

4. Recognition of Pharmacovigilance Information

The first operational question is often not whether the information is a valid ICSR. It is whether the information contains a potential safety report that needs to enter the PV assessment process.

Examples include:

• a consumer reporting a rash after taking a medicine;
• a physician emailing a product complaint together with a patient's clinical event;
• a medical-information enquiry containing an unexpected adverse event;
• an affiliate forwarding a report received locally;
• a study team transmitting a suspected adverse reaction;
• or a literature-monitoring process identifying a possible case.

The person receiving the information does not necessarily need to decide the final regulatory classification. The critical control is that potentially relevant information is recognised and routed to the function responsible for the assessment.

5. Capture Before Classification

An organisation should avoid losing the original information while waiting for a complete classification.

Initial capture should preserve the source information and the relevant receipt metadata. Classification and medical assessment can then occur through controlled downstream steps.

This is particularly important when the initial information is incomplete. Incompleteness should not become a reason for suppressing or discarding a potentially relevant safety notification.

6. Authenticity, Legibility and Traceability

EMA specifically expects the collection system to support reports that are authentic, legible, accurate, consistent and verifiable. citeturn0search16

In practical terms, an intake process should preserve enough information to answer:

• What was received?
• From whom?
• Through which channel?
• When was it received?
• By which organisational unit?
• What product was involved?
• What event or suspected reaction was described?
• Was the original communication retained?
• When was it transferred to PV?
• Who or what system performed the initial assessment?

These controls create the evidence trail from the original communication to the final ICSR.

7. Day 0 Begins With Awareness, Not Database Creation

One of the most important intake controls is determination of the relevant Day 0.

The organisation must not assume that the date on which a case is entered into the safety database is automatically the date on which the reporting clock begins.

The relevant awareness date depends on the applicable regulatory framework and the facts of the information flow. An organisation may therefore need to reconstruct the pathway through an affiliate, vendor or other business function.

A one-day delay between receipt and database entry can become a regulatory delay if the organisation uses database creation as a substitute for determining awareness.

8. The Intake Clock

A controlled intake process should distinguish at least the following events where relevant:

Source sends information
        ↓
Organisation / affiliate receives information
        ↓
Relevant PV organisation becomes aware
        ↓
Information logged
        ↓
PV assessment begins
        ↓
Valid ICSR established
        ↓
Regulatory submission clock applied

Not every event will occur in a different system. What matters is that the organisation can reconstruct the relevant dates and responsibilities.

9. Triage Is Not Validation

Triage and validation answer different questions.

Triage asks:

How should this information enter and move through the PV process?

Validation asks:

Does the information satisfy the minimum criteria for a valid ICSR?

Triage may determine that a report requires urgent routing to PV, medical review, a specialist team or a particular source-specific workflow. Validation then determines whether the minimum criteria for reporting are present.

This distinction prevents the intake team from using a premature "valid/invalid" decision to determine whether information should be captured at all.

10. Triage Priorities

A practical triage system may consider:

• potential seriousness;
• fatal outcome;
• potential public-health significance;
• suspected product involvement;
• special situations;
• possible signal relevance;
• source type;
• imminent regulatory deadlines;
• duplicate indicators;
• and whether specialist medical assessment is required.

These criteria are operational controls. They should not be confused with the legal criteria for ICSR validity or seriousness.

11. What Triage Should Not Do

Triage should not become an informal mechanism for rejecting inconvenient or incomplete reports.

For example:

"The report only says the patient was hospitalised, so there is nothing to process."

is not an appropriate intake principle.

The organisation should capture and assess the information. Whether it ultimately represents a valid ICSR and what additional information is required are separate questions.

The dedicated G14 article addresses difficult validity scenarios in detail.

12. Initial Assessment

Initial assessment should establish enough information to route the report correctly and determine the next processing step.

Depending on the source and workflow, this may include preliminary assessment of:

• reporter identity and qualification;
• patient information;
• medicinal product;
• event or suspected reaction;
• source type;
• country;
• dates;
• seriousness indicators;
• and whether the information appears to represent an existing case.

The depth of initial assessment should be proportionate. The intake function should not duplicate the entire medical-review process unnecessarily.

13. Intake and Duplicate Detection

Duplicate awareness should begin at intake.

A new communication may relate to a case already present in the safety database. Useful identifiers may include:

• patient characteristics;
• reaction/event;
• medicinal product;
• reporter;
• dates;
• source;
• and distinctive clinical details.

The purpose of an early duplicate check is not to prevent legitimate follow-up information from reaching the existing case. It is to route information correctly and avoid unnecessary creation of parallel records.

GVP Module VI Addendum I provides dedicated guidance on duplicate management; the detailed duplicate methodology is addressed separately in this series.

14. Initial Data Preservation

Original source information should remain available for verification.

Transformation of an email or telephone report into structured database fields should not destroy the ability to reconstruct what the reporter actually communicated.

This is particularly important where later assessment raises questions about:

• Day 0;
• seriousness;
• causality;
• expectedness;
• patient or reporter identifiability;
• or whether a case was valid at the time of receipt.

15. Quality-System Ownership

The intake process crosses organisational boundaries.

Typical participants can include:

• PV operations;
• medical information;
• clinical development;
• regulatory affairs;
• quality;
• affiliates;
• call centres;
• digital teams;
• vendors;
• and business units receiving customer communications.

A robust system therefore defines ownership at the interfaces. It should be clear who recognises potential safety information, who forwards it, who determines the regulatory Day 0 and who owns escalation when information is delayed.

16. A Simple Control Model

The minimum practical control model is:

RECEIVE
   ↓
RECOGNISE
   ↓
RECORD
   ↓
DATE
   ↓
TRIAGE
   ↓
VALIDATE
   ↓
PROCESS / SUBMIT

Each arrow represents a potential control failure. The remainder of this article examines how those failures become inspection findings.

17. Intake Channels and Interface Controls

The number of intake channels should be treated as a risk factor.

A central mailbox may be straightforward to control. A global organisation with affiliates, vendors, medical information, patient-support programmes, studies, websites and local contact centres has a much larger interface population.

The key question is not whether every channel is operated by PV. It is whether the organisation has controls that reliably bring potential safety information into the PV system.

An effective channel inventory should identify, as appropriate:

• the business process;
• responsible owner;
• country or region;
• type of safety information expected;
• transfer mechanism;
• required transfer time;
• system of record;
• backup route;
• and escalation route.

18. Email Intake

Email remains a common source of safety information and a common source of control weaknesses.

Potential controls include:

• monitored mailboxes;
• defined ownership;
• access continuity during absence;
• controlled forwarding;
• automated acknowledgement where appropriate;
• timestamp preservation;
• and reconciliation of received messages with PV records.

A mailbox rule that forwards messages to PV is not sufficient if the organisation cannot demonstrate that messages were monitored and transferred reliably.

19. Telephone and Call-Centre Intake

Telephone reports create a different evidence problem because the original communication may not exist as a written document.

The organisation should therefore have controlled mechanisms for recording relevant information, including who received the report and when.

Where a call-centre agent is not a PV professional, training should focus on recognition and routing rather than requiring the agent to make complex regulatory determinations.

20. Affiliate Intake

Affiliate processes require particular attention to the distinction between local receipt and central PV awareness.

An affiliate may receive information first and transfer it later. The organisation should define the applicable awareness-date rule and controls for demonstrating timely transfer.

Potential controls include:

• local PV contact points;
• standard intake procedures;
• escalation of serious information;
• transfer-time monitoring;
• reconciliation;
• and periodic testing of the end-to-end process.

21. Vendor Intake

Where a vendor performs intake or case processing, the MAH should maintain appropriate oversight.

Oversight can include:

• contractual requirements;
• training;
• service levels;
• quality metrics;
• audit rights;
• deviation management;
• business continuity;
• and escalation of potential late reports.

A vendor's timestamp is useful evidence, but the organisation should understand what that timestamp represents and whether it corresponds to the regulatory concept of awareness.

22. Medical Information Interfaces

Medical-information functions can receive safety information in communications that initially appear to be product enquiries.

A robust process therefore includes recognition criteria for potential adverse-event or adverse-reaction information.

For example, a caller asking about the appropriate use of a medicine may also mention that a patient developed severe symptoms after taking it. The PV relevance should not be missed because the communication originated as a medical-information enquiry.

23. Product Complaints and Safety Information

Product-quality complaints can contain associated adverse events.

The intake process should therefore allow the quality and PV functions to exchange relevant information without creating competing or incomplete records.

The presence of a product complaint does not itself determine whether an ICSR exists. The clinical information must be assessed.

24. Special Situations at Intake

Certain situations require specialised routing, including:

• medication errors;
• overdose;
• misuse;
• abuse;
• off-label use;
• occupational exposure;
• pregnancy or breastfeeding exposure;
• lack of efficacy where relevant;
• and product exposure without an adverse reaction.

These categories should not be allowed to bypass the standard intake and validation controls. Instead, the relevant special-situation workflow should begin after the information has been captured and appropriately assessed.

25. Literature Intake

Literature has its own intake pathway because the organisation may become aware of information through a publication rather than a direct report.

EMA's Module VI requires MAHs to maintain awareness of relevant medical literature through systematic review and to assess publications for ICSRs. citeturn0search18turn0search3

The Day 0 and case-creation implications of literature are sufficiently specialised to warrant the dedicated G17 article. G4 should therefore focus on the intake-control principle: the literature-monitoring process must reliably transfer identified cases into the PV workflow.

26. Clinical Trial and PSP Interfaces

Clinical trials and patient-support programmes use structured data-collection mechanisms and therefore have source-specific processes.

The intake function should not automatically treat these cases as spontaneous reports. The source classification established at intake influences subsequent processing, causality assessment and reporting pathways.

The dedicated G15 and G16 articles address these systems in depth.

27. Intake During Business Continuity Events

A safety-intake process should remain operational during foreseeable disruptions.

Potential failure points include:

• mailbox outages;
• vendor outages;
• database downtime;
• staff shortages;
• cyber incidents;
• public holidays;
• and loss of a key local contact.

Business continuity should therefore identify alternative intake routes and define how information received through contingency channels is reconciled into the controlled PV system.

28. Triage of Potentially Serious Information

Initial information may suggest seriousness without providing enough detail for a final assessment.

The triage function should escalate potentially serious information promptly while preserving the distinction between:

potential seriousness

and

final seriousness classification.

For example, "patient was rushed to hospital" may warrant urgent assessment, but the final classification depends on the facts of the case and applicable criteria.

29. Triage of Fatal Reports

Reports mentioning death should receive appropriate attention, but intake personnel should avoid automatically converting "death" into an assumed cause of death or adverse reaction.

The organisation should preserve the information actually received and route the case for appropriate assessment and, where useful, follow-up.

This is particularly important because the outcome of death and the cause of death are distinct clinical concepts.

30. Triage of Incomplete Reports

Incomplete reports should be captured and assessed rather than discarded simply because information is missing.

The intake process should support a controlled transition from:

Initial information
      ↓
Validation assessment
      ↓
Missing information identified
      ↓
Follow-up decision
      ↓
Case processing

The fact that a report is incomplete does not by itself establish that it is invalid.

31. Triage and Priority Queues

Electronic workflows may use queues to prioritise information.

Useful categories might include:

• urgent medical review;
• suspected serious case;
• potential fatality;
• imminent reporting deadline;
• possible duplicate;
• routine validation;
• and specialist source review.

Queue logic should be validated and periodically reviewed. A workflow should not silently deprioritise cases because of an incorrect source classification or missing metadata.

32. Manual Versus Automated Triage

Automation can improve consistency but introduces its own risks.

Examples include rules that classify messages based on keywords such as "hospital", "death" or "rash".

Keyword rules may be useful screening tools but can produce both false positives and false negatives. A message describing a serious event may contain none of the expected keywords, while a non-serious historical mention may trigger an unnecessary urgent queue.

Automated triage should therefore be treated as a controlled support mechanism rather than an infallible clinical decision-maker.

33. Escalation Criteria

A mature intake procedure should define when the initial assessor must escalate.

Examples can include:

• possible fatality;
• potentially life-threatening reaction;
• uncertainty about whether the information is already a case;
• suspected product quality issue with clinical consequences;
• potential emerging safety issue;
• conflicting source information;
• uncertainty about Day 0;
• or a possible reporting deadline risk.

Escalation criteria should identify both the responsible function and the expected response.

34. Documentation of Initial Decisions

The record should make material intake decisions reconstructable.

For example, if a notification was initially considered non-reportable, the organisation should be able to determine:

• what information was available at the time;
• who made or approved the assessment;
• why the decision was made;
• whether additional information was sought;
• and whether later information changed the conclusion.

This becomes especially important when an inspection examines historical information that did not become an ICSR.

35. The Intake-to-Case Handoff

The transition from intake to case processing should have an explicit control point.

At handoff, the organisation should be able to establish:

• source;
• awareness date;
• product;
• patient information;
• reporter information;
• event information;
• preliminary seriousness indicators;
• existing-case or duplicate status;
• and any escalation already performed.

The handoff should not create a second, conflicting version of the source information.

36. What Happens When Information Changes?

Initial triage is necessarily based on information available at that moment.

Later information can change:

• validity;
• seriousness;
• causality;
• expectedness;
• outcome;
• source classification;
• or duplicate status.

The system should therefore support reassessment rather than treating the initial triage decision as permanent.

37. Intake Metrics

Useful intake metrics should test control effectiveness rather than merely volume.

Examples include:

• time from receipt to PV routing;
• percentage of channels with defined ownership;
• transfer-time compliance by affiliate or vendor;
• unidentified or orphan safety communications;
• cases discovered outside the expected intake route;
• late awareness-date corrections;
• and recurring intake deviations.

A particularly valuable metric is the number of potential safety reports discovered through reconciliation or inspection rather than through the intended intake process. A rising number may indicate that the primary intake controls are failing.

38. Inspection Evidence

An inspector may select a reported case and work backwards from the safety database to the original communication.

Alternatively, an inspector may select a communication from a non-PV system and ask what happened to it.

The second approach can be more revealing because it tests whether the organisation captures cases that never became database records.

The organisation should therefore test both directions:

SOURCE → PV DATABASE

and

PV DATABASE → ORIGINAL SOURCE

Both pathways should be traceable.

39. Common Intake Failure Modes

Recurring weaknesses can include:

• treating database creation as Day 0;
• relying on one central mailbox without channel reconciliation;
• inadequate affiliate transfer controls;
• unclear vendor ownership;
• failure to recognise PV information in medical-information contacts;
• loss of original source records;
• automated triage without adequate validation;
• incomplete escalation rules;
• treating incomplete information as automatically invalid;
• and failure to investigate communications that never reached the PV database.

The next chunk will examine difficult intake scenarios, inspection testing, control design, practical examples and the distinction between a documented intake procedure and an effective intake system.

40. Difficult Scenario: A Report Arrives in the Wrong Department

A consumer sends an email to a commercial contact rather than the PV mailbox and describes a suspected adverse reaction.

The key control question is not whether the commercial employee is qualified to validate an ICSR. It is whether the organisation has a reliable mechanism for recognising and transferring potential safety information.

The employee should follow the defined escalation route. The PV organisation should then establish the relevant awareness date from the actual information flow rather than assuming that the date of later database entry is the regulatory starting point.

41. Difficult Scenario: The Affiliate Receives the Report on Friday

An affiliate receives a potentially serious report shortly before a weekend or public holiday.

A mature process should not depend on normal office hours without a contingency mechanism. The organisation should have defined arrangements for urgent escalation and continuity.

The important control is not simply a target such as "forward within one business day". It is whether the process protects the applicable regulatory timeline and ensures that potentially serious information receives appropriate attention.

42. Difficult Scenario: The Vendor Receives the Report First

A call-centre vendor receives a consumer report and transfers it to the MAH later.

The organisation should be able to reconstruct when the vendor received the information, what the vendor did, when the MAH became aware and how the reporting timeline was managed.

A contractual service level does not redefine the regulatory awareness date.

43. Difficult Scenario: Hospitalisation Is Mentioned but Not Explained

The initial report states:

"Patient was admitted to hospital after taking Product X."

This information warrants assessment, but it does not by itself establish the clinical reason for admission, the adverse reaction, or causality.

The intake function should capture the information and route it for validation and clinical assessment. It should not simply code "hospitalisation" and close the question.

44. Difficult Scenario: Only Death Is Reported

The initial notification says:

"Patient died while taking Product X."

The intake process should preserve the report as received and escalate appropriately. It should not invent a cause of death or convert the outcome into an adverse reaction without supporting information.

G19 addresses the subsequent targeted follow-up process for such cases.

45. Difficult Scenario: The Report Looks Like a Product Complaint

A customer reports that a vial was defective and adds that the patient developed a severe reaction after administration.

The quality function may need to investigate the product complaint, while PV needs to assess the safety information.

The two processes should be connected without allowing one function to assume that the other has completed the regulatory assessment.

46. Difficult Scenario: The Same Patient Is Reported Twice

Two communications arrive through different channels on the same day.

One comes from a consumer and another from a healthcare professional. Both describe the same patient and reaction.

The intake system should recognise the possibility of a duplicate and route the information for duplicate assessment rather than treating the second communication as an unrelated new case automatically.

The second communication may contain valuable additional information and should not simply be discarded.

47. Difficult Scenario: An Incomplete Report Arrives

The initial report identifies the reporter, patient and product but provides only a brief description of an event.

The appropriate approach is to capture and validate the information according to the applicable criteria. If valid, it should enter the reporting process; if information is missing, follow-up can be considered.

The absence of a complete clinical narrative at intake is not itself evidence that the report can be ignored.

48. Difficult Scenario: Automated Triage Misses the Case

A text-classification rule is designed to identify terms such as "rash", "hospital" and "death". A report instead says:

"After the second dose the patient developed severe airway swelling and required emergency treatment."

The absence of a configured keyword should not cause the information to disappear from the PV process.

Automated screening should therefore have appropriate validation, monitoring and human oversight.

49. Difficult Scenario: The Case Is Found During an Inspection

An inspector identifies a safety communication in a medical-information system that never entered the PV database.

The immediate issue is the individual communication. The larger issue is whether the organisation should search the population of similar communications.

A mature response should include containment, impact assessment, root-cause analysis and consideration of whether other cases may have been missed.

50. Difficult Scenario: The Awareness Date Changes

During follow-up, the organisation discovers that an affiliate received the original report several days before it was forwarded to central PV.

The organisation should assess the effect of the corrected awareness date on the regulatory timeline and determine whether other cases from the same interface could have been affected.

This illustrates why Day 0 is an intake-control issue, not simply a database-field issue.

51. Difficult Scenario: Conflicting Initial Information

A consumer reports that a patient was hospitalised. A later healthcare-professional communication states that the patient was treated in an outpatient emergency department and was not admitted.

The initial triage decision should not be treated as immutable. The case should be reassessed using the available evidence, with the conflicting information preserved and appropriately resolved or documented.

52. Difficult Scenario: A Report Arrives Through a PSP

A patient-support programme systematically asks patients about adverse events and forwards a report to the MAH.

The intake process should preserve the programme as the source context. It should not automatically classify the report as spontaneous simply because a patient described the event.

The source-specific classification and reporting implications are addressed in G15.

53. Difficult Scenario: A Clinical-Trial Case Reaches Post-Authorisation PV

A clinical-trial team forwards a case to the post-authorisation PV organisation.

The receiving function should not erase the original study context. The source and reporting pathway must remain traceable so that the appropriate clinical-trial and PV obligations can be applied.

G16 provides the detailed study-specific framework.

54. Difficult Scenario: Literature Identifies a Possible Case

A literature-monitoring process identifies a publication containing a suspected adverse reaction.

The intake control is to transfer the identified information into the appropriate PV assessment pathway while retaining the publication as the source record.

The literature-specific Day 0, search, screening and case-origin questions are handled in G17.

55. What an Effective Intake System Demonstrates

A strong system can answer four questions for any selected communication:

1. Did we recognise it?
2. Did we capture it?
3. Did we route it correctly and on time?
4. Can we demonstrate what happened next?

The same questions can be reversed:

For every selected ICSR, can we identify the original information, source, awareness date and transfer pathway?

This two-directional traceability is a powerful inspection control.

56. Evidence of Effective Implementation

A written SOP is only the beginning.

Evidence of an effective intake system can include:

• channel inventories;
• training records;
• monitored mailbox controls;
• transfer logs;
• awareness-date records;
• reconciliation results;
• escalation records;
• deviation trends;
• vendor and affiliate performance data;
• business-continuity tests;
• sampling of non-PV communications;
• and evidence that missed or delayed information is investigated.

The strongest evidence is consistent performance demonstrated across the real operating population.

57. Intake Control Testing

A practical internal test can select records from outside the safety database.

For example:

Select 100 medical-information contacts
              ↓
Identify communications containing potential PV information
              ↓
Compare against PV database
              ↓
Investigate unmatched communications
              ↓
Assess Day 0 and transfer time
              ↓
Trend failures

The reverse test can start with safety cases and reconstruct the original source.

Together these tests examine both completeness of capture and traceability of processing.

58. Inspection Questions

An inspector may ask:

• What channels can receive adverse-event information?
• How do non-PV employees recognise potential safety information?
• How is Day 0 determined?
• How are affiliate transfers controlled?
• How are vendors monitored?
• What happens outside business hours?
• How do you know cases are not lost in medical-information or product-complaint systems?
• How is automated triage validated?
• How do you identify communications that never became cases?
• Can you reconstruct the complete pathway for this sampled case?
• What happens when an intake error is discovered?

59. Common Inspection Findings

Potential deficiency patterns include:

• inadequate awareness-date controls;
• delayed transfer from affiliates or vendors;
• unmonitored or poorly controlled intake channels;
• insufficient recognition training;
• missing reconciliation between source systems and PV;
• inadequate continuity arrangements;
• unsupported automated triage decisions;
• loss of original source information;
• inappropriate rejection of incomplete reports;
• and failure to investigate potential population impact after a missed case is discovered.

These are learning patterns, not assertions that every example represents a formally published regulatory finding.

60. Practical Intake Checklist

Before considering the intake process inspection-ready, ask:

• Have all potential intake channels been identified?
• Does every channel have an accountable owner?
• Are employees trained to recognise potential PV information?
• Is the original communication preserved?
• Is awareness date determined using a controlled rule?
• Are affiliates and vendors subject to appropriate transfer controls?
• Are urgent and potentially serious reports escalated appropriately?
• Is triage clearly distinguished from validation?
• Are incomplete reports captured rather than prematurely rejected?
• Are duplicate indicators considered at intake?
• Are automated rules validated and monitored?
• Are contingency routes available?
• Can source-to-case and case-to-source traceability both be demonstrated?
• Are intake deviations trended and investigated?
• Can the organisation demonstrate effective implementation rather than merely an SOP?

Key Takeaways

• Intake is an end-to-end control, not merely creation of a database record.
• Potential safety information can originate in many non-PV business processes.
• Collection systems should preserve information that is authentic, legible, accurate, consistent, verifiable and sufficiently complete for clinical assessment.
• Day 0 should not be assumed to equal database creation.
• Triage and validation are different activities.
• Incomplete information should be captured and assessed rather than automatically discarded.
• Seriousness, fatal outcome and other priority indicators should trigger appropriate escalation without replacing the formal clinical assessment.
• Automated triage can support screening but should not be treated as infallible.
• Affiliates and vendors require controlled interfaces and appropriate oversight.
• Effective intake requires both source-to-case and case-to-source traceability.
• The strongest inspection evidence demonstrates that the organisation can identify potential safety information outside the PV database as well as reconstruct the origin of existing cases.

References

1. European Medicines Agency. Good Pharmacovigilance Practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products, Rev. 2.
2. European Medicines Agency. GVP Module VI Addendum I — Duplicate management of suspected adverse reaction reports.
3. European Medicines Agency. GVP Module VI Addendum II — Masking of personal data in individual case safety reports submitted to EudraVigilance.
4. International Council for Harmonisation. ICH E2D(R1) — Post-Approval Safety Data: Definitions and Standards for Management and Reporting of Individual Case Safety Reports.
5. European Medicines Agency. EudraVigilance electronic reporting guidance.
6. European Medicines Agency. Pharmacovigilance inspection coordination and guidance material.
7. European Commission. Commission Implementing Regulation (EU) No 520/2012, as amended.
8. European Parliament and Council. Directive 2001/83/EC, as amended.

Regulatory Note

This article is an educational explanation of ICSR intake, triage and initial assessment within the EU pharmacovigilance framework. It does not replace current EU legislation, GVP Module VI, applicable addenda, ICH E2D(R1), EudraVigilance technical guidance, national requirements or an organisation's approved procedures.

Specific regulatory timelines and reporting requirements should be verified against the current applicable legislation and guidance. Operational controls described in this article are implementation approaches and should not be interpreted as additional legal requirements unless explicitly identified as such.

The scenarios and deficiency patterns are illustrative unless a specific authoritative source is cited. They are intended to demonstrate how an inspection-ready organisation can reason about intake controls and evidence.