Personal data in ICSRs: compliance is a matter of system architecture

The management of personal data in Individual Case Safety Reports (ICSRs) is today one of the most delicate aspects of pharmacovigilance governance, as it requires increasingly structured technical control. Guidance on the international transfer of pharmacovigilance cases, the GVP Module VI Addendum II and the principles of the GDPR all require strict control over outbound data flows. In this article we examine what these regulatory developments have in common and why compliance must be embedded in the architecture of the safety database.

In the context of European pharmacovigilance, pharmaceutical companies act as the data controllers for the processing of personal data contained in ICSRs and therefore remain responsible for their use and transmission. This responsibility persists even when the data are pseudonymised: under the GDPR framework, pseudonymisation does not equate to anonymisation.

A combination of quasi-identifiers within a case may still make an individual indirectly identifiable, keeping the information within the scope of personal data.

The GDPR introduces the principle of data minimisation and, above all, the concept of data protection by design. In the pharmacovigilance context, this means that ICSR flows should contain only the personal data strictly necessary for regulatory purposes, avoiding the dissemination of non-essential identifying elements.

In the case of ICSRs, the most critical moment is not the recording of the case in the safety database, but the generation of the regulatory output: XML E2B(R2/R3), CIOMS forms, and transfers to authorities in third countries. It is at this stage that internal data become a structured regulatory flow.

You may also be interested in: ICSR transfers outside the EU: how to comply with GDPR

The Addendum II to GVP Module VI introduces precise instructions for ICH E2B(R3) data elements, distinguishing between fields that must always be masked—such as reporter identifiers or medical record numbers—fields that must be left blank, and fields that may contain personal data but must still be transmitted because they are necessary for signal detection, duplicate detection and ICSR processing.

These instructions are not merely formal requirements. They imply that the system must be capable of consistently applying masking and exclusion rules defined by the regulation without altering the data necessary for regulatory purposes.

You may also be interested in: GVP Module VI Addendum II: how to comply with the new EMA rules for ICSR submission

ICSRs inevitably contain personal data, even when pseudonymised. Regulatory developments have clarified that the responsibility of the data controller does not end with data collection, but extends to its transmission.

At this point the logical link becomes clear: the GDPR introduces the principle of data protection by design, the Addendum II specifies which fields must be masked or left blank, and EMA guidance on transfers outside the EU emphasises the minimisation of transmitted data. All these provisions converge on a single operational point: the export stage.

It is here that compliance ceases to be a purely procedural matter and becomes a question of system architecture.

A safety database retains the full dataset for pharmacovigilance purposes, audits and inspections. However, not all information that is legitimately stored can be transmitted.

This is where a fundamental principle emerges: the separation between internal data and transmissible data.

An advanced system must be able to retain the full case for safety purposes while also applying selective filtering rules during export, generating XML R2/R3 and CIOMS outputs compliant with regulatory requirements, and adjusting the level of masking depending on the recipient. If this distinction is not implemented at system level, control shifts to manual procedures, increasing operational risk.

Within this context lies the design approach adopted in SafetyDrugs. The GDPR module introduces a dedicated mode called “Under data protection”, which acts as a control layer applied to outbound data flows.

The configuration allows users to define a list of data elements subject to protection and apply automatic substitution rules, such as the use of the nullFlavor “MSK”, blank fields, replacement of the country code with “EU” or “NONEU”, and—where required for transfers outside the EU according to EMA guidance—the replacement of the medicinal product name with the active substance in order to avoid indirect identification of the country of origin.

It is also possible to intervene in narrative sections through parameterised text or redaction, manage recipients by setting the “Under data protection” transmission mode, and automatically generate XML R2/R3 and CIOMS outputs compliant with regulatory requirements, with optional exclusion of attachments.

The “Under data protection” configuration does not modify the internal data stored in the database, but is applied exclusively during the export phase. In this way, the system preserves the informational integrity required for pharmacovigilance activities while ensuring the level of data minimisation required for regulatory flows.

Compliance therefore becomes an intrinsic logic of the system, rather than an external procedural control.

To learn more about the GDPR module and evaluate how to integrate structured outbound flow control into your pharmacovigilance system, you can contact our team.