GVP Module VI Addendum II: Masking Personal Data in Individual Case Safety Reports

Introduction

Individual case safety reports can contain information relating to patients, reporters and other individuals. Pharmacovigilance systems must therefore protect personal data while retaining enough information to allow the case to be clinically understood, assessed and managed.

This creates a practical tension:

Protect personal data
        ↕
Preserve pharmacovigilance value

Masking should not be understood as indiscriminate removal of information. The objective is to protect personal data while maintaining the integrity and usefulness of the safety report within the applicable regulatory framework.

1. Why Masking Matters

ICSRs can contain direct identifiers as well as combinations of information that could identify an individual indirectly.

Potentially identifying information may include:

• names;
• addresses;
• telephone numbers;
• email addresses;
• exact dates associated with an identifiable person;
• patient numbers;
• healthcare-professional identifiers;
• and other information capable of identifying an individual in context.

The appropriate treatment depends on the applicable regulatory requirements, reporting environment and purpose for which the information is being processed.

2. Masking Is Not the Same as Deleting the Case

The purpose of masking is to protect personal information, not to remove the clinical substance of the case.

A report should continue to communicate the information needed to understand:

• the patient;
• the exposure;
• the suspected reaction;
• relevant clinical circumstances;
• outcome;
• and the source of the report.

The organisation should therefore distinguish between information that is identifying and information that is clinically necessary.

3. Direct and Indirect Identification

Personal-data protection requires consideration of both direct and indirect identification.

A person's name is an obvious direct identifier.

However, a combination such as a rare occupation, unusual disease, very specific location and exact event date could potentially identify an individual even if the name has been removed.

The context therefore matters.

4. Patient Information

Patient information is often necessary for clinical assessment, but the report does not necessarily require the patient's full name.

Relevant clinical characteristics can often be retained in a form that supports pharmacovigilance without unnecessarily exposing direct identifiers.

Depending on the applicable rules, useful information can include:

• age or age group;
• sex;
• relevant medical history;
• treatment dates where necessary;
• event chronology;
• investigations;
• and clinical outcome.

The principle is to preserve pharmacovigilance utility while applying the applicable privacy controls.

5. Reporter Information

Reporter information also requires appropriate protection.

The identity and qualifications of a reporter can be relevant to assessing the quality and clinical significance of a report.

However, unnecessary personal contact information should not automatically be exposed in every downstream reporting context.

The organisation should distinguish information required for legitimate pharmacovigilance purposes from information that is unnecessarily identifying.

6. Why Over-Masking Can Be a Problem

Excessive masking can reduce the clinical value of an ICSR.

For example, removing all dates from a case could make it impossible to understand the relationship between exposure, reaction and outcome.

Similarly, removing relevant clinical characteristics could make duplicate detection, follow-up or medical assessment more difficult.

The objective is therefore appropriate masking, not maximum masking.

7. Why Under-Masking Can Be a Problem

The opposite failure is also possible.

An organisation may transfer unnecessary identifying information because it has always been included in the source report.

This can increase privacy risk without improving pharmacovigilance value.

Processes should therefore identify the information that genuinely needs to be transmitted and protect other personal information appropriately.

8. Masking and Source Traceability

Masking should not destroy the organisation's ability to trace the report internally to its source.

A mature system separates:

Protected source information
          ↓
Controlled internal record
          ↓
Appropriately masked regulatory report

The internal system may need to retain information that should not be included in an external transmission.

Access to that information should itself be appropriately controlled.

9. Masking and Case Processing

Masking should be integrated into the ICSR lifecycle rather than performed as an isolated activity at the end.

Relevant controls may exist during:

• case intake;
• database entry;
• narrative preparation;
• quality control;
• electronic message generation;
• transmission;
• and downstream data exchange.

The organisation should know where personal data can enter the workflow and where masking controls operate.

10. The Narrative Requires Particular Attention

ICSR narratives can contain more identifying information than structured fields.

Processors should therefore consider the narrative carefully when preparing information for transmission.

A narrative should retain information necessary to understand the clinical case while avoiding unnecessary identifying details.

The next chunk will address practical masking decisions, dates, identifiers, special situations, EudraVigilance transmission and inspection controls.

11. Masking Dates

Dates can be clinically important because they establish chronology.

Relevant dates may show:

• when exposure began;
• when the reaction occurred;
• when treatment was stopped;
• when the patient was hospitalised;
• and when the outcome occurred.

The appropriate approach is therefore not to remove dates automatically. The organisation should apply the applicable masking rules while preserving dates or date representations needed for pharmacovigilance.

12. Exact Dates and Identifiability

An exact date can sometimes contribute to identification when combined with other information.

For example, an unusual event occurring on a precise date at a small institution may be highly identifying even without a person's name.

The organisation should therefore consider the complete context rather than treating every individual field independently.

13. Patient Identifiers

Patient identifiers should be assessed carefully.

A patient number generated by a hospital or healthcare organisation may be useful for source traceability but may not be appropriate for unrestricted external transmission.

The organisation should distinguish between identifiers necessary for controlled pharmacovigilance activities and identifiers that should be masked in the applicable reporting environment.

14. Reporter Contact Details

Reporter contact information can facilitate follow-up, but it can also contain unnecessary personal information.

A pharmacovigilance system should maintain the information required to support legitimate follow-up and case assessment while applying appropriate controls to information that does not need to be disclosed in a particular transmission.

15. Names in Narratives

A narrative may contain a patient's or reporter's name because the source report included it.

The presence of a name in the source does not mean that the name must automatically be reproduced in a downstream safety report.

Processors should review narratives for unnecessary direct identifiers and apply the applicable masking requirements.

16. Rare Diseases and Small Populations

Rare diseases and unusual clinical circumstances require particular care because apparently harmless details may become identifying when combined.

For example, a rare disease, a specific hospital, a narrow age range and an exact date may collectively identify an individual.

Privacy assessment should therefore consider the risk of re-identification in context.

17. Healthcare Professionals

Healthcare professionals are also individuals whose personal data may require protection.

At the same time, information about professional qualifications or source type may have legitimate pharmacovigilance value.

The appropriate balance depends on the reporting purpose and applicable requirements.

The process should avoid unnecessary disclosure while preserving information needed to evaluate the credibility and nature of the report.

18. Masking and Follow-Up

Masking should not make legitimate follow-up impossible.

The internal pharmacovigilance system may need to retain appropriate contact information under controlled access so that follow-up can be performed when justified.

This reinforces the distinction between:

Internal source record
        ≠
External regulatory representation

The two may contain different levels of identifying information while remaining linked through controlled traceability.

19. Masking and Duplicate Detection

Some information used to identify duplicates can also be personal data.

This creates an important interface between privacy and data quality.

The organisation should maintain sufficient information within its controlled environment to perform legitimate duplicate detection while ensuring that personal data are handled appropriately.

The solution is controlled access and appropriate data handling, not elimination of all potentially useful information.

20. Masking and EudraVigilance

Electronic transmission to EudraVigilance requires compliance with the applicable data standards and reporting requirements.

The organisation should ensure that the data transmitted through the electronic ICSR message are appropriate for the reporting context and do not contain unnecessary personal information.

Technical validation alone does not guarantee appropriate privacy protection. A message can be technically valid while still containing information that should have been masked.

21. Quality Control of Masking

Masking should be included in appropriate quality-control activities.

QC may assess:

• direct identifiers;
• narrative content;
• contact details;
• dates;
• unusual combinations of information;
• and consistency between source and transmitted information.

The purpose is not simply to check whether a processor followed a checklist. QC should determine whether the resulting report appropriately balances privacy and pharmacovigilance value.

22. System Controls

Where possible, systems should support appropriate privacy controls.

Possible controls include:

• role-based access;
• restricted fields;
• controlled exports;
• audit trails;
• masking rules;
• workflow permissions;
• and validation checks.

System controls should complement, rather than replace, appropriate human assessment.

23. Training

Personnel who process ICSRs should understand why personal-data protection matters and how it applies to their specific activities.

Training should address practical examples rather than relying solely on general privacy terminology.

Processors should know when to escalate an uncertain masking decision.

24. Common Masking Failures

Copying source reports verbatim

The processor transfers all source information into a downstream report without considering whether every identifier is necessary.

Removing too much information

Important clinical chronology is removed, reducing the value of the case.

Ignoring narratives

Structured fields are reviewed, but identifying information remains in free text.

Assuming technical validation is sufficient

The electronic message passes technical validation, so privacy review is assumed to be complete.

Inconsistent affiliate practices

Different affiliates apply different masking approaches, creating inconsistent reporting quality.

25. Practical Example: Unnecessary Direct Identifier

A spontaneous report contains the patient's full name and telephone number.

The internal case record may need to retain the source information under controlled access for legitimate pharmacovigilance purposes.

However, if those identifiers are not required in the relevant external ICSR transmission, they should not simply be copied into the transmitted narrative.

The clinical information should remain intact.

26. Practical Example: Clinically Necessary Date

A serious reaction occurs two days after treatment initiation and resolves after treatment discontinuation.

Removing all dates would eliminate important information about the temporal relationship between exposure, reaction and dechallenge.

The appropriate approach is therefore to apply the relevant masking requirements while preserving the chronology needed for clinical assessment.

27. Practical Example: Rare Clinical Event

A report describes a very rare disease in a small geographic area and includes the exact date of a hospital admission.

Even without the patient's name, the combination could potentially increase identifiability.

The organisation should assess the context and apply the applicable privacy and reporting requirements rather than treating each field independently.

28. Inspection Considerations

An inspector may ask:

• How do you identify personal data in an ICSR?
• Where are masking rules defined?
• Who is responsible for applying them?
• How are narratives reviewed?
• How are affiliates trained?
• How is masking verified before submission?
• How do you protect source information internally?
• How do you balance privacy with duplicate detection and follow-up?

The organisation should be able to demonstrate both documented procedures and evidence that the controls work in practice.

29. Audit Considerations

A pharmacovigilance audit may examine:

• procedures;
• training;
• system configuration;
• sample ICSRs;
• source-to-submission traceability;
• quality-control results;
• privacy incidents;
• deviations;
• and CAPA.

The audit should consider whether the masking process is consistently implemented across the organisation and its vendors.

The final chunk will cover governance, data-protection interfaces, practical inspection scenarios, final principles, References and the Regulatory Note.

30. Governance of Masking

Masking should have clear ownership within the pharmacovigilance quality system.

Responsibilities should be defined for:

• procedure ownership;
• case-processing activities;
• quality control;
• system configuration;
• training;
• privacy escalation;
• vendor oversight;
• and deviation management.

The organisation should be able to demonstrate that masking is a controlled process rather than an informal judgement made differently by individual processors.

31. Vendors and Affiliates

Where affiliates or service providers process ICSRs, the organisation should ensure that the applicable masking expectations are understood and consistently implemented.

Oversight can include:

• procedures and work instructions;
• training records;
• quality metrics;
• sample review;
• audit findings;
• deviations;
• and CAPA.

Contractual language alone is insufficient evidence of effective implementation.

32. Privacy Incidents

If inappropriate personal information is transmitted or otherwise disclosed, the event should be managed through the organisation's applicable quality and data-protection processes.

The response should determine:

• what information was disclosed;
• who received it;
• whether the information was actually accessible;
• whether regulatory or other notification obligations apply;
• the immediate containment actions;
• and whether systemic corrective action is required.

Pharmacovigilance and data-protection functions may need to work together depending on the circumstances.

33. Masking and Data Protection Governance

Pharmacovigilance requirements and data-protection requirements should be considered together.

The existence of a pharmacovigilance obligation does not mean that every piece of personal information should be transferred without restriction.

Conversely, privacy controls should not be implemented in a way that prevents legitimate pharmacovigilance activities or destroys necessary safety information.

The practical objective is controlled, lawful and proportionate processing.

34. Practical Example: Narrative Review

A source report states:

Patient: [full name]
Hospital: [named hospital]
Reaction: severe reaction requiring admission

The internal case may retain the source information under appropriate controls.

When preparing an external ICSR, the processor should assess whether the patient's name and other direct identifiers are necessary in the relevant reporting context.

The clinical facts should remain understandable after appropriate masking.

35. Practical Example: Reporter Contact Details

A healthcare professional provides a private mobile telephone number in the source report.

The number may be necessary internally to facilitate follow-up, but that does not automatically mean it should appear in a transmitted narrative.

The organisation should distinguish operational contact information from the information required in the applicable external safety report.

36. Practical Example: Re-identification Risk

A case concerns an extremely rare event in a small community. The source contains the patient's age, exact admission date, occupation and hospital.

Removing the patient's name may not eliminate the possibility of identification.

The organisation should therefore consider the combination of information and apply the applicable rules rather than relying on removal of a single direct identifier.

37. Inspection Questions

An inspector may ask:

1. What procedures govern ICSR masking?
2. How do you determine what personal information may be transmitted?
3. How are narratives reviewed?
4. How are affiliates and vendors controlled?
5. How is the process validated or tested?
6. What happens when inappropriate personal information is identified?
7. How do you preserve source traceability?
8. How do privacy controls interact with duplicate detection and follow-up?

A mature system should be able to answer these questions with documented procedures and operational evidence.

38. Audit Questions

An audit can assess whether masking controls operate consistently by sampling:

• source documents;
• internal cases;
• transmitted ICSRs;
• narratives;
• quality-control records;
• system configurations;
• training;
• and deviations.

The audit should compare what the procedure says with what actually happens.

39. What Good Looks Like

A mature masking process has:

• clearly defined requirements;
• controlled procedures;
• trained personnel;
• appropriate system controls;
• narrative review;
• proportionate treatment of direct and indirect identifiers;
• preservation of clinically important information;
• secure internal source records;
• vendor and affiliate oversight;
• quality control;
• and documented handling of privacy incidents.

The result should be a safety report that remains clinically useful without unnecessary disclosure of personal information.

40. Final Principles

1. Personal-data protection is an integral part of ICSR management.
2. Masking should protect personal data without unnecessarily reducing pharmacovigilance value.
3. Direct and indirect identification should both be considered.
4. Names and contact details should not automatically be copied into external reports.
5. Clinically important chronology should be preserved where required.
6. Narratives require particular attention because they can contain identifiers that are absent from structured fields.
7. Internal source traceability should be maintained under appropriate access controls.
8. Masking should support, rather than obstruct, legitimate follow-up and duplicate management.
9. Technical message validation does not by itself demonstrate appropriate privacy protection.
10. Affiliates and vendors should operate under consistent controlled requirements.
11. Privacy incidents should be assessed through appropriate quality and data-protection processes.
12. The process should be periodically monitored and audited.

Key Takeaways

• GVP Module VI Addendum II addresses masking of personal data in ICSRs.
• The objective is appropriate protection, not indiscriminate removal of information.
• Personal-data assessment must consider context and potential re-identification.
• Patient and reporter identifiers require careful handling.
• Narratives can contain significant identifying information and require review.
• Internal source records and external regulatory reports may appropriately contain different levels of identifying information.
• Privacy controls must coexist with legitimate follow-up, duplicate detection and clinical assessment.
• Effective masking requires procedures, systems, training, QC and oversight.

References

1. European Medicines Agency. Good Pharmacovigilance Practices (GVP), Module VI — Collection, management and submission of reports of suspected adverse reactions to medicinal products. Current version should be consulted for the overarching ICSR framework.
2. European Medicines Agency. GVP Module VI — Addendum II: ICSR masking of personal data. Primary EU pharmacovigilance guidance for the masking subject addressed by this article.
3. European Medicines Agency. EudraVigilance guidance and electronic reporting requirements. Relevant to the electronic transmission environment in which ICSRs are exchanged.
4. European Parliament and Council. Regulation (EU) 2016/679 (General Data Protection Regulation), as applicable. Relevant to the broader data-protection framework for processing personal data.
5. European Parliament and Council. Directive 2001/83/EC, as amended. EU legal framework for medicinal products for human use and pharmacovigilance.
6. European Parliament and Council. Regulation (EC) No 726/2004, as amended. Union framework for authorisation and supervision of medicinal products and relevant pharmacovigilance obligations.

Regulatory Note

This article is an educational and practical explanation of personal-data masking in EU pharmacovigilance ICSRs. It does not replace the current GVP Module VI guidance, Addendum II, EudraVigilance technical requirements, applicable data-protection law or organisation-specific procedures.

Data-protection obligations depend on the circumstances of the processing and the applicable legal framework. Before making a live decision about transmission or disclosure of personal data, the current regulatory and privacy requirements should be verified and, where appropriate, the organisation's data-protection function consulted.

The examples in this article are illustrative and are not descriptions of specific regulatory inspection cases unless an authoritative source is explicitly identified.