Functional Specifications and Design Specifications in Pharmacovigilance

A pharmacovigilance requirement becomes useful only when it can be translated into system behaviour that users can rely on and technical implementation that can be controlled. Functional and design specifications are two common ways of making that translation explicit.

The distinction is easiest to understand as a sequence of questions:

What does the pharmacovigilance process need? → What must the system do? → How is that behaviour implemented? → How will we verify it?

A User Requirements Specification (URS) usually addresses the first question. A Functional Specification (FS) addresses the second. A Design Specification (DS), or equivalent technical documentation, addresses the third. Verification and validation evidence address the fourth.

This sequence is useful, but the document names themselves should not be mistaken for universal legal requirements. EU pharmacovigilance legislation and GVP require an effective quality system and appropriate validation or qualification of systems critical to pharmacovigilance. GVP Module II requires the PSMF to describe important computerised systems, their fitness for purpose and the validation status of key functionality. It does not prescribe that every pharmacovigilance system must have separate documents titled URS, FS and DS.

The correct objective is therefore not to produce a predefined stack of documents. It is to preserve a convincing evidence chain from regulated need to implemented and verified behaviour.

Purpose and Regulatory Context

Functional and design specifications support three connected objectives:

1. translation — turning business and regulatory requirements into implementable system behaviour;
2. traceability — showing how requirements are realised and verified; and
3. lifecycle control — providing a baseline against which changes can be assessed.

The direct EU pharmacovigilance basis comes primarily from Commission Implementing Regulation (EU) No 520/2012 and GVP Module I. GVP Module I states that facilities and equipment critical for the conduct of pharmacovigilance should undergo appropriate checks, qualification and/or validation activities to demonstrate suitability for intended purpose.

GVP Module II then requires the PSMF to describe computerised systems and databases used to receive, collate, record and report safety information, including an assessment of fitness for purpose and a summary of the validation status of key functionality, change control, testing, backup and important electronic repositories.

EMA's pharmacovigilance-inspection Q&A further clarifies that an MAH remains ultimately responsible for validation of pharmacovigilance processes supported by electronic systems. Supplier qualification evidence may be relied upon where its adequacy has been assessed, but additional qualification or validation may be required based on documented risk assessment.

These sources establish the need for controlled, demonstrable fitness for purpose. They do not prescribe a universal specification hierarchy.

Other frameworks

EU GMP Annex 11 and ISPE GAMP 5 contain mature concepts for requirements, configuration, supplier assessment and lifecycle control. They can be useful when designing a pharmacovigilance validation framework, but their regulatory status must remain clear: Annex 11 is a GMP document and GAMP 5 is industry guidance.

FDA's February 2026 Computer Software Assurance guidance also promotes risk-based assurance and efficient objective evidence, but its formal scope is medical-device production and quality-management-system software. It should not be described as a general FDA pharmacovigilance requirement.

The Translation Chain

For a configured safety database, a practical chain might look like this:

Regulatory/business need
Submit reportable ICSRs correctly and within applicable requirements.

User requirement
The system shall support electronic regulatory reporting of eligible ICSRs.

Functional behaviour
The system identifies reportable cases, applies configured reporting rules, generates an E2B(R3) message, queues the submission, receives an acknowledgement and records the outcome.

Technical design/configuration
Specific reporting-rule tables, gateway mappings, scheduler settings, message-generation components, interface configuration and acknowledgement-processing logic implement that behaviour.

Verification evidence
Test cases demonstrate correct positive, negative and exception scenarios, including due-date calculation, message generation, submission routing and rejection handling.

This example shows why traceability matters. If a regulatory requirement changes, the organisation can identify which functional rules and technical components are affected and target verification accordingly.

Functional Specification: What the System Must Do

A Functional Specification describes the behaviour needed to satisfy approved requirements. It is more detailed than a user requirement but should remain focused primarily on logical behaviour rather than low-level implementation.

Depending on the system, functional content may describe:

• workflow states and transitions;
• business rules and calculations;
• user interactions;
• notifications and exception handling;
• data-entry and validation behaviour;
• regulatory reporting rules;
• interface behaviour;
• role-based functional permissions;
• audit-trail behaviour from a user or process perspective; and
• reporting and output requirements.

The purpose is to make expected behaviour sufficiently clear that implementation and verification can be planned objectively.

Example: expedited reporting rule

A user requirement may state:

The system shall support submission of reportable post-authorisation ICSRs to EudraVigilance.

The functional specification could decompose this into behaviours such as:

• evaluate whether the case meets the configured reporting rule;
• calculate the applicable due date from the regulatory clock start;
• identify mandatory E2B(R3) data elements;
• prevent transmission of a structurally invalid message;
• transmit through the configured channel;
• capture acknowledgement status; and
• identify failed or rejected transmissions for follow-up.

These statements describe what the implemented system should do without requiring the FS itself to specify database tables, source code or network architecture.

Design Specification: How the Behaviour Is Implemented

The Design Specification describes the technical or configuration solution that realises the required functional behaviour. The exact level of detail depends heavily on the implementation model.

For a custom-built system, design documentation may include software architecture, data models, interfaces, component logic and infrastructure. For a commercial safety database, the most important design evidence may instead be customer-specific configuration records, reporting-rule tables, workflow configuration, role profiles, interface mappings and supplier technical documentation.

A Design Specification can therefore include or reference:

• application and service architecture;
• database or data-model elements relevant to regulated functions;
• configuration settings;
• interface mappings and transformations;
• authentication and authorisation implementation;
• audit-trail configuration;
• E2B(R3) message mappings;
• scheduled jobs and background services;
• technical exception and retry logic;
• backup and restoration arrangements; and
• infrastructure or cloud dependencies relevant to intended use.

The goal is not to document technology for its own sake. Technical detail belongs in the validation evidence when it is needed to understand, build, maintain or verify a function that matters to regulated use.

URS, FS and DS: Distinct but Not Rigid

The classic distinction is useful:

In practice, these layers may be combined. A SaaS implementation may use one controlled configuration specification that contains both functional and technical detail. A small low-risk tool may need only a concise requirements-and-configuration record. A complex custom application may need multiple functional and technical design documents.

Combining documents is not inherently weak, and separating them is not inherently robust. The quality test is whether the evidence is complete, understandable and traceable.

Risk-Based Depth of Specification

Specification effort should be proportionate to the consequences of failure, complexity of implementation and amount of customer-specific change.

A function that automatically calculates ICSR reporting due dates or transforms safety data into an E2B(R3) regulatory message deserves greater specification and assurance than a cosmetic display preference. The difference arises because failure of the first function can affect regulatory compliance and safety-data integrity.

Useful factors in determining specification depth include:

• importance of the supported PV process;
• degree of automation;
• impact of an incorrect output;
• complexity of business rules;
• amount of custom code or configuration;
• number and complexity of interfaces;
• data migration or transformation;
• supplier maturity and available evidence; and
• detectability of failure before regulated use.

Risk-based documentation should not be confused with incomplete documentation. The organisation still needs enough information to understand critical behaviour and to investigate or change it safely.

Commercial and SaaS Systems

Commercial off-the-shelf and SaaS systems challenge the assumption that the MAH must author every specification from first principles. The supplier may already maintain product requirements, architecture, design records, release documentation and qualification evidence.

EMA's inspection Q&A supports reliance on supplier qualification documentation where the MAH has assessed it as adequate. This creates a practical opportunity to avoid duplicate documents, but it does not transfer responsibility for intended use to the supplier.

The MAH should therefore distinguish:

supplier-controlled product design from customer-controlled intended use and configuration.

For example, the supplier may own the generic mechanism for generating E2B(R3) XML. The MAH may own the reporting rules, local product configuration, interface mappings, user roles and operating procedures that determine how that capability is used in production.

Questions to ask before relying on supplier specifications

A regulated organisation should understand:

• whether the supplier documentation describes the version actually used;
• which functions and configurations it covers;
• whether the supplier test environment is representative of production;
• how customer-specific configuration differs;
• whether relevant documentation can be made available during an inspection;
• how supplier changes are communicated; and
• which residual assurance activities remain with the MAH.

The answer may be a combination of supplier evidence and local specifications rather than an entirely duplicated local document set.

Traceability

Traceability provides the logical connection between requirement, behaviour, implementation and evidence. It is especially valuable for high-risk or highly configured functionality because it makes gaps and change impacts visible.

A traceability record might connect:

The exact matrix format is recommended practice, not a regulatory template. Traceability may instead be maintained in an application lifecycle tool, requirements platform or validated repository.

Bidirectional traceability

Forward traceability asks whether every important requirement has been implemented and tested. Reverse traceability asks whether implemented regulated functionality has an approved requirement and rationale.

Both directions can be useful. Untraced requirements suggest missing assurance; untraced configuration can indicate undocumented functionality or uncontrolled scope creep.

Interfaces and Data Transformation

Interfaces deserve particular attention because failures can occur even when both endpoint systems operate correctly. A specification should make clear:

• source and destination;
• transferred data elements;
• mapping and transformation rules;
• units, terminology and coding conversions;
• transfer frequency or trigger;
• error and retry handling;
• reconciliation or completeness controls; and
• ownership of exceptions.

In pharmacovigilance, examples include intake platforms feeding a safety database, safety databases connecting to EudraVigilance gateways, partner data exchanges, literature feeds and data warehouses supporting aggregate or signal analyses.

Where an interface affects regulatory reporting or case completeness, its specification should support end-to-end verification rather than testing only the transport layer.

Changes During the Lifecycle

Specifications become valuable after go-live when they function as a controlled baseline. A proposed change can be assessed against the intended use, functional behaviour and technical design to determine what is affected.

For a SaaS release, the MAH may receive supplier release notes rather than a revised local DS. The local change process should determine whether the release affects customer configuration, critical functionality, interfaces, procedures or previously established evidence.

Not every release requires rewriting every specification or repeating a standard validation package. The assurance response should follow the impact and risk of the change.

Potential Failure Modes

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

The specification hierarchy becomes a paperwork objective

A project produces separate URS, FS and DS documents because the procedure expects them, but the documents repeat the same statements and add little traceability. The result is more documentation without better assurance.

Functional requirements are too vague to test

Statements such as “the system shall comply with pharmacovigilance requirements” cannot be verified objectively. Important business rules should be decomposed sufficiently to define expected behaviour.

Technical design is undocumented because the product is commercial

A vendor-controlled application still has customer-specific configuration, interfaces, roles and operating dependencies. “COTS” or “SaaS” does not mean that the MAH has no design information to understand or control.

Supplier documents are accepted without applicability assessment

Extensive supplier documentation may describe a different software version, configuration or qualification environment. Reliance should be based on documented assessment rather than document volume.

Specifications and production configuration diverge

A technically elegant DS has little value if production no longer reflects it. Configuration change control should preserve alignment between the documented baseline and the actual system.

Every minor technical change forces a full specification rewrite

This often indicates that the documentation model is not proportionate. Change control should identify which requirements, behaviours and design elements are materially affected and update those records accordingly.

Inspection Considerations

An inspector evaluating a pharmacovigilance computerised system is likely to be more interested in fitness for purpose and traceable control than in whether the organisation uses a particular document title.

Illustrative questions include:

• What is the intended pharmacovigilance use of the system?
• Which functions are critical to that use?
• How are user requirements translated into implemented behaviour?
• Which specifications are maintained by the MAH and which by the supplier?
• How was supplier documentation assessed before reliance?
• How is customer-specific configuration documented?
• Can critical requirements be traced to verification evidence?
• How are interfaces and data transformations specified and tested?
• How are differences between supplier qualification and the production environment understood?
• How are specifications kept aligned with production after changes and releases?
• Can relevant supplier and internal documentation be made available promptly during inspection?

These are illustrative inspection questions; they are not a prescribed EMA checklist.

Practical Review Checklist

For a critical pharmacovigilance system, the specification evidence should allow the organisation to confirm that:

• intended use and regulated business processes are defined;
• critical functions and data flows are identifiable;
• functional behaviour is described at a level that permits objective verification;
• technical or configuration design is documented where necessary to understand implementation;
• customer-specific configuration is distinguished from generic supplier product design;
• interfaces, mappings and exception handling are adequately specified;
• supplier specifications are applicable to the deployed version and have been assessed before reliance;
• critical requirements can be traced to implementation and verification evidence;
• configuration and specification records reflect the production state;
• material changes are assessed for impact on requirements, behaviour, design and testing;
• obsolete documents are controlled; and
• the evidence model is proportionate rather than mechanically document-driven.

Key Takeaways

Functional and design specifications are methods for preserving the reasoning between a pharmacovigilance requirement and its technical implementation. A Functional Specification describes what the system should do; a Design Specification or equivalent record describes how that behaviour is implemented.

EU pharmacovigilance rules require an effective quality system and appropriate validation or qualification of critical systems, while the PSMF must describe relevant computerised systems, fitness for purpose and validation status. They do not prescribe a universal requirement for separate documents called FS and DS.

The appropriate specification model therefore depends on intended use, risk, complexity and implementation model. A highly configured global safety database may justify detailed functional, configuration and interface specifications. A simpler system may use combined controlled records. Supplier documentation can be leveraged where its adequacy and applicability are assessed.

The governing test is traceability: can the organisation explain what the regulated process requires, what the system does, how that behaviour is implemented, how it was verified and how the evidence remains current after change?

References

1. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module I – Pharmacovigilance systems and their quality systems. EMA/541760/2011. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-i-pharmacovigilance-systems-and-their-quality-systems_en.pdf
2. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module II – Pharmacovigilance system master file (Rev. 2). EMA/816573/2011 Rev. 2. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-ii-pharmacovigilance-system-master-file-rev-2_en.pdf
3. European Medicines Agency. Coordination of pharmacovigilance inspections — Q&A on validation/qualification of vendor electronic systems. https://www.ema.europa.eu/en/coordination-pharmacovigilance-inspections-0
4. European Commission. Commission Implementing Regulation (EU) No 520/2012, consolidated version current at 12 February 2026. https://eur-lex.europa.eu/eli/reg_impl/2012/520/2026-02-12/eng
5. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
6. International Society for Pharmaceutical Engineering. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. ISPE, 2022. Industry guidance; not legislation.
7. U.S. Food and Drug Administration. Computer Software Assurance for Production and Quality Management System Software. Guidance for Industry and FDA Staff, February 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software

Regulatory Note

This article distinguishes binding EU pharmacovigilance obligations, GVP guidance, EMA inspection interpretation and recommended specification practice. Separate documents titled Functional Specification and Design Specification are not presented as universal EU pharmacovigilance legal requirements. EU GMP Annex 11 is referenced as a useful computerised-system framework but is a GMP document. ISPE GAMP 5 is industry guidance. FDA's February 2026 Computer Software Assurance guidance is formally scoped to medical-device production and quality-management-system software and is referenced only for relevant risk-based assurance principles.