Your safety database was configured years ago? Someone mapped the ICH-E2B(R3) fields, set the export rules, and moved on? Since then, your team has been submitting ICSRs to EudraVigilance without revisiting whether those field-level settings still reflect current requirements? That is not unusual. Until July 2025, there was no agreed common masking standard across EU Member States to configure against.

The publication of GVP Module VI Addendum II (EMA/178902/2025) closed that gap. It introduces a common masking policy that applies to every organisation submitting ICSRs or SUSARs to EudraVigilance, with no exemptions based on company size, product type, or geographic location. This article sets out exactly what has changed, which ICH-E2B(R3) data elements are affected, and what a compliant submission process looks like. If your team is still working from the 2017 framework, or has not yet reconfigured your safety database to reflect the Addendum, now is the time to act.

Why EMA published the Addendum: the GDPR gap

GDPR came into force in May 2018. Yet despite the regulation applying directly to MAHs and Sponsors as data controllers, there was no agreed common masking policy among EU Member States until 2025. Individual organisations applied inconsistent interpretations of which ICSR fields constituted personal data and which did not.

GVP Module VI Addendum II closes that gap. It establishes a uniform pseudonymisation standard: field-level masking instructions that apply across all ICSR submissions to the EudraVigilance gateway, regardless of whether the report originates from a consumer, a healthcare professional, or a clinical trial investigator.

Critically, the Addendum does not change EV Business Rules or the electronic submission process for ICSRs. The change is at the data preparation stage — specifically how ICH-E2B(R3) fields are populated before submission. The EU Individual Case Safety Report Implementation Guide remains fully applicable and requires no changes.

Understanding the field-level masking split

The Addendum categorises all ICH-E2B(R3) data elements into four groups. Two require immediate action from PV teams.

Group 1: 13 fields to be masked with nullFlavour MSK

These 13 fields are not required for signal management, duplicate detection, or ICSR processing. Where the data is available to the sender, they must be submitted with the ICH-E2B(R3) nullFlavour MSK value. They must not be left populated with identifying information.

The 13 fields cover reporter and patient identifiers:

• Reporter’s Title, Given Name, Middle Name, and Family Name (C.2.r.1.1 to C.2.r.1.4)
• Reporter’s Organisation and Department (C.2.r.2.1 and C.2.r.2.2)
• Reporter’s Street, Postcode, and Telephone (C.2.r.2.3, C.2.r.2.6, and C.2.r.2.7)
• Patient Medical Record Numbers from GP, Specialist, and Hospital sources (D.1.1.1, D.1.1.2, and D.1.1.3)
• Parent Identification (D.10.1)

The MSK flag tells EudraVigilance that the data exists but has been intentionally withheld for data protection purposes. It is a pseudonymisation measure, not omission. If the field is populated in your source data, you must mask it. Leaving it blank is not an acceptable alternative to applying nullFlavour MSK.

Group 2: 11 fields to be left blank

A second group of 11 fields relates to the sender’s personal contact details (name, address, telephone, and fax). These must be left blank on submission. The ICH-E2B(R3) guideline does not support nullFlavour for these elements, so blank submission is the correct technical approach.

The 11 sender fields (C.3.3.2 to C.3.4.7) include title, given name, middle name, family name, street address, city, state or province, postcode, country code, telephone, and fax.

Groups 3 and 4: fields that must remain populated

The remaining data elements may contain personal identifiers or quasi-identifiers, but they are required for signal management, duplicate detection, and ICSR processing. These must not be masked or left blank when available to the sender.

Notable examples include patient name or initials (D.1), date of birth (D.2.1), sex (D.5), body weight (D.3), height (D.4), and age at time of onset (D.2.2a and D.2.2b). These fields must remain populated. Over-masking is itself a compliance failure, as it would impair EudraVigilance’s core pharmacovigilance function.

Does this conflict with the 2017 GVP VI guidance?

This is the most common question PV teams are asking. The short answer: where the 2021 EU ICSR Implementation Guide acknowledged that the MSK flag ‘can be appropriate’ for fields such as D.1 (patient name or initials) or D.2.1 (date of birth), GVP VI Add. II now makes masking mandatory for the 13 specified fields, and prohibits masking of the fields required for PV processing.

The 2025 Addendum explicitly supersedes the 2017 GVP Module VI and the March 2021 Implementation Guide. If there is any conflict, the Addendum prevails. Your SOPs, system configurations, and submission templates should reference the Addendum (EMA/178902/2025) as the primary authority for all EV submission masking decisions.

Implementation: what your team needs to do

Document your implementation plan. The Addendum states that instructions should be implemented as soon as possible and within a reasonable timeframe. Critically, that timeframe must be documented. If your EV submissions are audited, inspectors will expect to see evidence of when you identified the obligation and how you planned to meet it. This is not a future obligation to note and revisit. It is an active requirement with an audit trail component from the date of publication.

Review your safety database configuration. Most safety database platforms allow field-level mapping to ICH-E2B(R3) elements. You will need to:

• Identify which output fields correspond to the 13 MSK elements and the 11 blank elements
• Configure your E2B(R3) export to apply nullFlavour MSK to the Group 1 fields on all EV submissions
• Ensure the 11 sender fields are suppressed from the export file regardless of source data content
• Confirm that fields in Groups 3 and 4 are not masked, as masking these would be a separate compliance failure
• Validate your configuration against the field tables in the Addendum before submitting to EV

Update SOPs and training materials. Your ICSR processing SOPs, E2B submission procedures, and QA checklists should reference GVP VI Add. II as the governing document. Staff responsible for ICSR case entry and review need to understand the masking framework, particularly the distinction between fields that must be masked, fields that must be blank, and fields that must remain fully populated.

Scope your submissions correctly. The Addendum applies to all cases submitted to EudraVigilance: ICSRs including literature cases and non-EEA cases, and SUSARs. There is no carve-out based on case type or reporting pathway. If it goes to EV, the masking policy applies.

The GDPR foundation: why pseudonymisation matters beyond EV submissions

Under GDPR Article 4(5), pseudonymisation means processing personal data so it can no longer be attributed to a specific individual without the use of additional information held separately. Masked ICSR data (where the 13 identified fields carry the MSK flag) meets the GDPR definition of pseudonymised data.

This matters for two reasons. First, pseudonymised data is still personal data under GDPR. The masking policy does not remove your obligations as a data controller; it supports compliance with them. Second, pseudonymisation is the legal basis for the additional data protection measures the Addendum requires, and it underpins the international transfer framework addressed in Part 2 of this series.

What a compliant submission process looks like

A compliant EV submission workflow under GVP VI Add. II has these characteristics: