User Requirements Specifications (URS) in Pharmacovigilance

A User Requirements Specification translates the intended use of a computerised system into a controlled set of capabilities that users need the system to provide. In pharmacovigilance, that may include reliable case intake, MedDRA coding, regulatory reporting, audit trails, user access control, signal-management support and preservation of safety data.

Purpose and Regulatory Context

EU pharmacovigilance legislation does not prescribe a universal document called a URS. The regulatory objective is that computerised systems supporting pharmacovigilance are fit for purpose, appropriately controlled and supported by adequate validation evidence.

GVP Module II — Pharmacovigilance system master file (Rev. 2) requires the PSMF to describe relevant computerised systems and databases, their functionality, operational responsibility and fitness for purpose. It also expects a summary of validation status for key functionality, change control, testing, back-up arrangements and important repositories.

A URS is therefore best understood as one implementation technique for defining intended use and creating a stable basis for risk assessment, configuration, verification and change control.

Intended Use Comes First

Before requirements are written, the regulated process should be understood. For a safety database, intended use may include:

• intake and maintenance of ICSR information;
• medical and dictionary coding;
• duplicate management;
• workflow and status control;
• E2B(R3) message generation and transmission;
• audit trails and user-access controls;
• data extraction for aggregate reporting or signal evaluation; and
• preservation and retrieval of regulated records.

The requirement set should reflect the actual use of the system. It should not be copied mechanically from a supplier specification or an older implementation.

What a User Requirement Should Express

A good user requirement describes what capability is needed and why it matters, without unnecessarily fixing the technical design.

For example:

The system shall enable authorised users to generate the electronic ICSR message required for the applicable reporting route and retain evidence of transmission status.

This describes a regulated business capability. By contrast, specifying a particular database engine or software architecture usually belongs in technical or design documentation unless that technology itself is genuinely part of the business requirement.

Requirement Quality

Useful requirements are normally:

• clear enough to have one reasonable interpretation;
• necessary for intended use;
• verifiable through objective evidence;
• traceable through the lifecycle;
• proportionate to regulatory and patient-safety risk; and
• stable enough to remain meaningful through upgrades and change control.

Requirements such as “the system shall be user-friendly” are difficult to verify unless the intended outcome is defined more precisely.

Business, Functional and Control Requirements

Organisations may group requirements differently. Common categories include business capabilities, functional behaviour, interfaces, data integrity, security, reporting, continuity, retention and administration.

The categories are organisational aids rather than regulatory classifications. What matters is that important regulated capabilities are not omitted merely because they do not fit a chosen template.

Relationship With Risk Assessment

Requirements and risk assessment should inform one another. The requirement defines the capability; risk assessment helps determine how much assurance that capability requires.

A function that controls whether a serious ICSR is transmitted to a competent authority has a different consequence of failure from a preference concerning screen layout. The validation approach should recognise that difference.

Risk may be considered in terms of:

• patient-safety consequence;
• regulatory reporting consequence;
• data integrity;
• confidentiality;
• detectability of failure;
• complexity and customisation;
• reliance on interfaces; and
• dependence on supplier controls.

Risk-based validation does not mean that lower-risk requirements disappear. It means that assurance depth is proportionate.

Relationship With Specifications and Configuration

Once user requirements are approved, the organisation should be able to explain how they are satisfied by the implemented system. Depending on the development model, this may involve functional specifications, design specifications, configuration records, supplier documentation or combinations of these.

There is no universal regulatory requirement that every PV system must contain a separate URS, functional specification and design specification. The documentation model should provide enough controlled information to understand what was required, how it was implemented and how it was verified.

Relationship With Testing

A requirement becomes useful for validation when objective evidence can demonstrate whether it has been met. High-impact requirements may need several forms of evidence—for example interface tests, negative tests, role-based access testing and end-to-end business-process testing.

Conversely, a single end-to-end scenario may verify several related requirements. The purpose is meaningful assurance, not a mechanically one-to-one mapping between requirements and test scripts.

The companion articles [[validation-testing-in-pharmacovigilance]] and [[traceability-matrix-in-computerised-system-validation]] examine these relationships in more detail.

Supplier Products and Configured Systems

Commercial off-the-shelf systems complicate the traditional idea that the user writes every requirement before any solution is known. In practice, organisations often evaluate supplier capability, then define which configured functions and controls are necessary for intended use.

Supplier documentation may support assurance, but the regulated organisation should understand:

• which requirements are satisfied by standard product functionality;
• which depend on configuration;
• which rely on interfaces or local procedures;
• what supplier testing is being relied upon; and
• what additional verification is needed in the production-relevant environment.

Supplier evidence can reduce unnecessary duplicate testing, but it does not transfer responsibility for fitness for intended use.

Requirements for Interfaces

Interfaces deserve particular attention because they can fail silently while individual systems continue to appear functional.

A requirement should define the business outcome—for example, that specified safety data are transferred completely and accurately and that transmission failures are detectable. Technical mapping, protocol and middleware details can then be documented at the appropriate design level.

Relevant verification may address field mapping, rejected transactions, duplicate transmission, reconciliation and recovery after interruption.

Requirements for Data Integrity and Access

Safety data must remain reliable and attributable throughout their lifecycle. Depending on intended use, requirements may therefore address:

• authorised access;
• segregation of duties where needed;
• audit trails;
• controlled modification;
• record retention;
• backup and recovery;
• data migration;
• time and date controls; and
• preservation of metadata.

The exact controls should reflect applicable regulation, system risk and architecture rather than a generic checklist.

Requirements Through the System Lifecycle

Requirements are not merely implementation-project artefacts. They provide a reference for upgrades, migrations, regulatory changes and retirement.

When a major change occurs, the organisation should ask whether intended use has changed, whether requirements need revision, whether existing evidence remains applicable and which regression or new testing is justified.

A requirement history should therefore preserve the relationship between current intended use and earlier validated states rather than silently overwriting the past.

Practical Implementation

A proportionate requirements process can follow this sequence:

1. define the regulated business process and system intended use;
2. identify important users, interfaces and data flows;
3. translate necessary capabilities into clear requirements;
4. distinguish business need from technical implementation;
5. assess the consequence of requirement failure;
6. identify how each important requirement will be assured;
7. maintain traceability to configuration, testing and deviations; and
8. reassess requirements when intended use or regulation changes.

This is recommended operational practice rather than an EMA-prescribed URS workflow.

Illustrative Pharmacovigilance Example

Consider a system supporting expedited ICSR reporting.

A weak requirement might state:

The system shall support EudraVigilance.

A more useful requirement would identify the business outcome:

The system shall enable authorised users to generate and transmit the applicable E2B(R3) ICSR message and retain sufficient status information to identify successful submission or transmission failure.

That requirement can then be linked to applicable regulatory reporting rules, interface configuration, message mapping, access controls, positive and negative tests, acknowledgement handling and any deviations.

The example does not imply that every organisation must use this wording or documentation structure.

Potential Failure Modes

The following are illustrative failure modes rather than reported inspection findings.

Inspection Considerations

For a pharmacovigilance system, an inspector may ask how the organisation established that the system is fit for purpose. Requirements may help demonstrate:

• what the system is intended to do;
• which functions are important to patient safety or compliance;
• how regulated needs were translated into configuration;
• how critical requirements were tested;
• how supplier evidence was used;
• what changed after an upgrade; and
• whether the current production state remains aligned with approved intended use.

A polished URS cannot compensate for missing regulated capabilities or inadequate verification. Equally, an effective assurance model does not become deficient merely because the organisation uses a different document structure from a traditional URS template.

Practical URS Review Checklist

The following is recommended operational practice.

1. Is intended use defined before detailed requirements?
2. Does every important requirement support a genuine business or regulatory need?
3. Is each requirement clear enough to verify objectively?
4. Are implementation details kept at the appropriate documentation level?
5. Are interfaces and data flows covered where they affect regulated outcomes?
6. Are data-integrity, security, retention and recovery needs addressed proportionately?
7. Is risk used to determine assurance depth?
8. Can critical requirements be traced to implementation and verification evidence?
9. Is supplier evidence assessed for applicability?
10. Are deviations linked to affected requirements?
11. Does change control consider whether intended use or requirements have changed?
12. Is the requirements set maintainable through the operational lifecycle?

Key Takeaways

A URS is a practical requirements-management tool, not a universally mandated EU pharmacovigilance deliverable.

Its value is to define what a computerised system must achieve for its intended regulated use and to provide a stable basis for risk assessment, implementation, testing and change control.

Requirements should be clear, necessary, verifiable and proportionate to risk. They should describe business outcomes rather than prematurely prescribe technical design.

Supplier products can provide substantial existing evidence, but the organisation remains responsible for understanding whether the configured system is fit for its intended pharmacovigilance use.

The strongest requirements model remains useful after go-live because it supports traceability, upgrades, impact assessment and preservation of the validated state.

References

1. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module II — Pharmacovigilance system master file (Rev. 2). EMA/816573/2011 Rev. 2.
2. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module I — Pharmacovigilance systems and their quality systems. EMA/541760/2011.
3. European Union. Commission Implementing Regulation (EU) No 520/2012, as amended.
4. European Commission. EudraLex Volume 4, Annex 11 — Computerised Systems. Revision January 2011. GMP-scoped reference.
5. European Commission. Stakeholders' consultation on revision of EudraLex Volume 4 Chapter 4, Annex 11 and new Annex 22. Consultation closed 7 October 2025.
6. ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. Industry guidance; not legislation.

Regulatory Note

EU pharmacovigilance legislation and GVP require controlled, fit-for-purpose pharmacovigilance systems and appropriate evidence of validation, but they do not prescribe a universal URS template or mandatory V-model document hierarchy. As of 8 September 2026, GVP Module II Rev. 2 remains the published EMA module. EU GMP Annex 11 remains the January 2011 adopted revision; a revised Annex 11 underwent stakeholder consultation in 2025 and should not be treated as adopted law unless and until finalised.