Functional Specifications and Design Specifications in Pharmacovigilance

Introduction

Once business requirements have been defined within the User Requirements Specification (URS), the next challenge is determining how those requirements will be implemented within the computerised system. This transition from business expectations to system implementation is achieved through Functional Specifications (FS) and Design Specifications (DS).

Although these documents are fundamental components of many Computerised System Validation (CSV) programmes, they are frequently misunderstood. Functional Specifications are sometimes confused with User Requirements Specifications, while Design Specifications may be incorrectly treated as technical implementation documents with little regulatory significance.

In reality, each document serves a distinct purpose within the validation lifecycle. Together they establish the logical relationship between approved business requirements, software implementation and objective validation evidence.

This article explains the purpose, content and regulatory expectations for Functional Specifications and Design Specifications within pharmacovigilance. It also discusses modern risk-based approaches, the impact of Computer Software Assurance (CSA), the use of commercial off-the-shelf software and how experienced validation professionals determine the appropriate level of documentation for different computerised systems.

Learning Objectives

After reading this article, you should be able to:

• distinguish User Requirements Specifications, Functional Specifications and Design Specifications;
• explain the purpose of Functional Specifications and Design Specifications;
• understand how these documents support validation and traceability;
• recognise when supplier documentation may be appropriate;
• apply risk-based documentation principles;
• identify common deficiencies observed during audits and inspections.

Why Functional Specifications and Design Specifications Exist

The User Requirements Specification defines what the organisation expects a computerised system to achieve. However, it deliberately avoids describing how those requirements will be implemented.

Before software can be configured, developed or validated, approved business requirements must be translated into logical system behaviour and ultimately into a technical implementation. Functional Specifications and Design Specifications provide this essential bridge between business expectations and the implemented computerised system.

Without these intermediate documents, validation teams may struggle to determine whether the implemented solution accurately reflects approved business requirements or whether validation testing has adequately verified the intended functionality.

Bridging the Gap Between Business and Technology

Computerised systems are developed and implemented by multidisciplinary teams that often include business users, pharmacovigilance professionals, software suppliers, information technology specialists, quality assurance personnel and validation experts.

Each group views the system from a different perspective.

Business users focus on operational processes and regulatory obligations.

Software developers focus on system functionality and implementation.

Infrastructure specialists focus on technical architecture, security and performance.

Validation professionals focus on generating objective evidence that the implemented system satisfies approved business requirements.

Functional Specifications and Design Specifications establish a common understanding between these different stakeholders by progressively translating business needs into implementable and verifiable system behaviour.

Progressive Refinement of Requirements

Validation documentation should evolve logically throughout the system lifecycle.

Each document adds additional detail while remaining traceable to the documents preceding it.

Conceptually, the relationship can be viewed as follows:

Business Need

↓

User Requirements Specification

↓

Functional Specification

↓

Design Specification

↓

System Configuration or Development

↓

Validation Testing

↓

Operational Use

At each stage, additional information is introduced without changing the underlying business objectives established within the User Requirements Specification.

This progressive refinement improves consistency while supporting effective change control and lifecycle management.

Supporting Objective Validation

One of the principal objectives of Functional Specifications and Design Specifications is to support objective validation.

Validation teams must be able to determine:

• how each approved requirement has been implemented;
• which system functions satisfy each requirement;
• how those functions will be verified;
• whether implementation remains consistent with intended use.

These documents therefore provide an important link between business requirements and validation evidence.

Without them, demonstrating complete traceability becomes considerably more difficult, particularly for large or highly configured pharmacovigilance systems.

Supporting Supplier Communication

Many pharmacovigilance systems are implemented using commercial software supplied by external vendors.

Functional Specifications and Design Specifications help establish a common understanding between the regulated organisation and the supplier by documenting the expected system behaviour before implementation begins.

This reduces misunderstanding, simplifies configuration discussions and provides a structured basis for reviewing proposed solutions.

Where supplier documentation already provides appropriate detail, organisations may choose to leverage existing documentation rather than reproduce equivalent information, provided that intended use remains clearly defined and traceability is maintained.

Supporting Lifecycle Management

The value of Functional Specifications and Design Specifications extends well beyond the initial implementation project.

Throughout the operational life of the system they support:

• software upgrades;
• configuration changes;
• supplier changes;
• impact assessments;
• periodic reviews;
• regression testing;
• revalidation activities.

By documenting how approved requirements have been implemented, these documents simplify assessment of proposed changes while supporting maintenance of the validated state.

Scientific Foundation

Functional Specifications and Design Specifications do not replace the User Requirements Specification. They progressively translate approved business requirements into implementable, testable and maintainable system behaviour while preserving traceability throughout the validation lifecycle.

Relationship Between the User Requirements Specification, Functional Specification and Design Specification

The User Requirements Specification, Functional Specification and Design Specification describe the same computerised system from three different perspectives.

Although they are closely related, they serve different purposes and answer different questions.

Maintaining this separation is one of the fundamental principles of effective Computerised System Validation because it preserves traceability, supports lifecycle management and allows changes to be managed without unnecessarily affecting higher-level business requirements.

Understanding the relationship between these documents helps organisations produce validation documentation that is logical, maintainable and inspection ready.

Three Different Questions

Each document answers a different question.

The User Requirements Specification answers:

"What does the business need?"

The Functional Specification answers:

"What functions will the system provide to satisfy those business needs?"

The Design Specification answers:

"How will those functions be implemented within this specific system?"

Although the documents build upon one another, they should not duplicate each other's purpose.

The User Requirements Specification

The User Requirements Specification represents the business perspective.

It defines the intended use of the computerised system by describing the capabilities required to support regulated pharmacovigilance activities.

The URS deliberately avoids implementation decisions.

It should remain sufficiently stable that different software products or future system upgrades can continue to satisfy the same underlying business requirements.

The Functional Specification

The Functional Specification translates approved business requirements into logical system behaviour.

It describes what the implemented system will do from the perspective of users and business processes.

Typical topics include:

• workflow behaviour;
• business rules;
• user interactions;
• calculations;
• reporting functions;
• interface behaviour;
• exception handling.

The Functional Specification therefore explains how approved business requirements will be realised from an operational perspective without describing the detailed technical implementation.

The Design Specification

The Design Specification describes how the approved functional behaviour will be implemented within the selected computerised system.

Depending upon the system, this may include:

• application architecture;
• infrastructure;
• database design;
• interface architecture;
• configuration approach;
• security implementation;
• technical components.

The Design Specification is therefore technology dependent.

Unlike the User Requirements Specification, it will often change when software products, infrastructure or technical architecture change.

Why the Documents Should Remain Separate

Keeping these documents separate provides several important advantages.

Business requirements remain stable even when technical solutions evolve.

Technical implementation can change without requiring modification of fundamental business objectives.

Validation testing can demonstrate that implemented functionality satisfies approved requirements.

Change impact assessments become significantly easier because reviewers can identify whether a proposed change affects:

• business requirements;
• functional behaviour;
• technical implementation;

or some combination of these.

This structured approach supports efficient lifecycle management throughout the operational life of the system.

Traceability Across the Validation Lifecycle

Each document should maintain clear traceability to the documents that precede and follow it.

A typical relationship is:

Business Requirement

↓

User Requirement

↓

Functional Behaviour

↓

Technical Design

↓

Configured System

↓

Validation Test

↓

Operational Evidence

This progressive traceability allows organisations to demonstrate that every approved business requirement has been translated into implemented functionality and verified through objective validation evidence.

Commercial Off-the-Shelf Systems

Modern pharmacovigilance systems are frequently implemented using commercial off-the-shelf (COTS) software.

In these situations, suppliers often provide extensive functional and technical documentation.

Rather than reproducing this information, regulated organisations may reference appropriate supplier documentation where it adequately describes the implemented functionality and remains subject to appropriate document control.

The organisation nevertheless retains responsibility for ensuring that approved business requirements remain completely traceable to the implemented solution and associated validation evidence.

Modern Validation Approaches

Modern guidance, including GAMP 5 Second Edition and the FDA's Computer Software Assurance approach, encourages organisations to produce documentation that is proportionate to system complexity and regulatory risk.

Consequently, the Functional Specification and Design Specification should contain sufficient detail to support implementation, validation and lifecycle management without introducing unnecessary duplication.

The objective is to generate meaningful assurance rather than excessive documentation.

Scientific Foundation

The User Requirements Specification, Functional Specification and Design Specification are complementary rather than competing documents. Together they provide a logical progression from business need to implemented solution while preserving traceability, supporting change control and maintaining confidence throughout the system lifecycle.

Functional Specifications

The Functional Specification (FS) describes how approved business requirements will be realised from the perspective of system behaviour. It translates the User Requirements Specification into a logical description of the functions that the computerised system will perform while remaining largely independent of the underlying technical implementation.

Where the User Requirements Specification answers the question "What does the business need?", the Functional Specification answers "What will the system do to satisfy those needs?"

The Functional Specification therefore serves as the primary bridge between business requirements and technical implementation.

Purpose of the Functional Specification

The principal objective of the Functional Specification is to describe the expected behaviour of the computerised system in sufficient detail to support:

• system configuration;
• software development where applicable;
• validation planning;
• validation testing;
• traceability;
• user acceptance;
• change impact assessment.

The document should explain how users interact with the system and how the system responds under both normal and reasonably foreseeable operating conditions.

Who Develops the Functional Specification?

Responsibility varies between organisations and implementation models.

Depending upon the project, the Functional Specification may be developed by:

• the software supplier;
• implementation consultants;
• business analysts;
• pharmacovigilance subject matter experts;
• system owners;
• validation specialists.

Regardless of authorship, the regulated organisation remains responsible for ensuring that the Functional Specification accurately reflects approved user requirements and supports the intended use of the validated system.

Typical Contents of a Functional Specification

Although document structures vary, Functional Specifications commonly describe:

• business workflows;
• user interactions;
• functional processes;
• business rules;
• calculations;
• system notifications;
• exception handling;
• reporting functionality;
• interface behaviour;
• security functions from a user perspective.

The level of detail should be proportionate to the complexity and regulatory significance of the system.

Functional Specifications in Pharmacovigilance

Within pharmacovigilance, Functional Specifications frequently describe how the system supports regulated business activities.

Examples include:

• creation and processing of Individual Case Safety Reports;
• MedDRA coding workflows;
• WHO Drug dictionary management;
• duplicate detection workflows;
• medical review processes;
• expedited reporting workflows;
• E2B message generation;
• literature case management;
• signal detection workflows;
• aggregate reporting processes.

The emphasis should remain on describing expected business behaviour rather than database structures or software architecture.

Example of a Functional Requirement

Consider the following approved User Requirement:

"The system shall support electronic submission of Individual Case Safety Reports to regulatory authorities."

A corresponding Functional Specification might describe:

• selection of reportable cases;
• validation of mandatory data fields;
• generation of E2B(R3) messages;
• management of submission queues;
• receipt of acknowledgements;
• handling of transmission failures;
• notification of unsuccessful submissions.

Notice that the Functional Specification explains how the business requirement will operate from the user's perspective without describing the technical mechanisms used to achieve those functions.

Functional Specifications Support Validation

Functional Specifications provide an important reference during validation.

Validation teams use the document to determine:

• which functions require testing;
• expected system behaviour;
• expected workflow outcomes;
• acceptance criteria;
• exception scenarios.

Well-developed Functional Specifications therefore improve the consistency and completeness of validation testing.

Functional Specifications Support Change Control

As computerised systems evolve, Functional Specifications provide an important reference for assessing proposed changes.

Reviewers can determine whether modifications affect:

• existing workflows;
• business rules;
• user interactions;
• regulatory functionality;
• reporting processes.

This understanding supports impact assessment and helps determine whether additional validation activities are required.

Functional Specifications Should Remain Business Focused

Although Functional Specifications contain more detail than the User Requirements Specification, they should not become technical design documents.

Questions such as:

• database architecture;
• server configuration;
• programming languages;
• network topology;
• infrastructure design;

belong within the Design Specification or equivalent technical documentation.

Maintaining this separation improves document clarity while supporting long-term lifecycle management.

Scientific Foundation

The Functional Specification describes how approved business requirements will behave from the perspective of users and regulated business processes. It provides the logical description of system functionality that connects business requirements with technical implementation and objective validation evidence.

Design Specifications

The Design Specification (DS) describes how the approved functional behaviour of the computerised system will be implemented within the selected technical solution. Whereas the Functional Specification focuses on expected system behaviour from the user's perspective, the Design Specification explains the technical architecture, configuration and implementation necessary to deliver that behaviour.

The Design Specification therefore represents the technical blueprint for the validated system.

Unlike the User Requirements Specification and many elements of the Functional Specification, the Design Specification is closely linked to the chosen software platform, infrastructure and implementation approach.

Purpose of the Design Specification

The primary purpose of the Design Specification is to translate approved functional behaviour into a technically implementable solution.

It supports:

• software configuration;
• software development where applicable;
• infrastructure implementation;
• interface development;
• cybersecurity implementation;
• database configuration;
• technical testing;
• maintenance activities.

The document provides sufficient technical information to ensure that the implemented system remains consistent with the approved Functional Specification while supporting validation and future lifecycle activities.

Who Develops the Design Specification?

Depending upon the implementation model, the Design Specification may be prepared by:

• software suppliers;
• implementation consultants;
• solution architects;
• technical architects;
• application specialists;
• infrastructure engineers;
• system integrators.

Business users typically review the resulting functionality rather than the technical design itself.

However, the regulated organisation remains responsible for ensuring that the implemented design supports the approved intended use.

Typical Contents of a Design Specification

The contents of a Design Specification vary according to system complexity.

Typical sections include:

• system architecture;
• application components;
• database architecture;
• interface design;
• infrastructure design;
• network architecture;
• security implementation;
• authentication mechanisms;
• authorisation model;
• audit trail implementation;
• backup strategy;
• disaster recovery architecture;
• configuration details.

The Design Specification should contain sufficient technical detail to support implementation and future maintenance without duplicating supplier documentation unnecessarily.

Design Specifications in Pharmacovigilance

Within pharmacovigilance, Design Specifications frequently describe the technical implementation of systems supporting regulated activities.

Examples include:

• configuration of safety database workflows;
• implementation of MedDRA dictionaries;
• electronic reporting architecture;
• E2B(R3) interface configuration;
• gateway integration;
• audit trail implementation;
• user authentication architecture;
• disaster recovery configuration;
• database replication;
• reporting infrastructure.

These implementation details demonstrate how the selected technology supports approved business requirements.

Commercial Off-the-Shelf Systems

Many pharmacovigilance systems are commercial off-the-shelf (COTS) applications.

For these systems, substantial elements of the technical design may already exist within supplier documentation.

Rather than recreating this information, organisations may reference controlled supplier documentation where it adequately describes:

• application architecture;
• configuration options;
• infrastructure requirements;
• interface design;
• security mechanisms;
• operational limitations.

Additional organisation-specific documentation should be produced only where necessary to describe local configuration or implementation decisions.

Design Specifications and Change Control

The Design Specification becomes particularly valuable after the system enters operational use.

Whenever technical changes are proposed, reviewers can evaluate whether modifications affect:

• application architecture;
• configured functionality;
• interfaces;
• infrastructure;
• security controls;
• operational resilience.

This assessment supports impact analysis, regression testing and maintenance of the validated state.

Design Specifications Should Not Duplicate Functional Specifications

Although Functional Specifications and Design Specifications are closely related, they answer different questions.

The Functional Specification explains:

What the system will do.

The Design Specification explains:

How the selected technology will achieve that behaviour.

Maintaining this distinction simplifies document maintenance and prevents unnecessary duplication throughout the validation lifecycle.

Risk-Based Technical Documentation

Modern validation guidance encourages organisations to produce technical documentation that is proportionate to system complexity and regulatory risk.

Highly configured pharmacovigilance platforms may require extensive Design Specifications.

Conversely, implementation of a standard commercial application with minimal configuration may rely primarily on controlled supplier documentation supplemented by concise organisation-specific design records.

The level of technical documentation should therefore be determined by the complexity of the implementation rather than by a predetermined documentation template.

Scientific Foundation

The Design Specification provides the technical blueprint that transforms approved functional behaviour into an implemented computerised system. Its purpose is not to redefine business requirements but to document the technical solution that delivers those approved requirements while supporting validation, maintenance and lifecycle management.

Comparing User Requirements Specifications, Functional Specifications and Design Specifications

Although the User Requirements Specification (URS), Functional Specification (FS) and Design Specification (DS) describe the same computerised system, they do so from different perspectives and for different audiences.

Understanding these distinctions improves document quality, supports traceability and prevents unnecessary duplication throughout the validation lifecycle.

Each document progressively adds detail while remaining traceable to the approved business requirements established within the User Requirements Specification.

Comparison of Validation Documents

Why This Separation Matters

Maintaining separate User Requirements, Functional Specifications and Design Specifications provides several important advantages.

Business requirements remain stable even when software products or technical architectures change.

Functional behaviour can evolve without redefining the underlying business objectives.

Technical implementation can be modified while preserving validated business processes.

This separation also simplifies:

• software upgrades;
• supplier changes;
• impact assessments;
• regression testing;
• lifecycle maintenance;
• inspection preparation.

Perhaps most importantly, it enables organisations to demonstrate complete traceability from business need to implemented solution and ultimately to objective validation evidence.

When Documents May Be Combined

Not every computerised system requires three independent specification documents.

For relatively simple or low-risk systems, organisations may combine the Functional Specification and Design Specification into a single controlled document.

Similarly, implementation of standard commercial off-the-shelf software may rely heavily upon supplier documentation supplemented by organisation-specific configuration records.

Regardless of document structure, organisations should always ensure that:

• intended use is clearly defined;
• business requirements remain identifiable;
• functional behaviour is documented appropriately;
• technical implementation is sufficiently described;
• complete traceability is maintained.

The objective is not to maximise documentation but to provide sufficient evidence that the computerised system remains fit for its intended use throughout its lifecycle.

Scientific Foundation

The distinction between the User Requirements Specification, Functional Specification and Design Specification reflects three complementary perspectives of the same validated system: business intent, functional behaviour and technical implementation. Together they establish the logical pathway from organisational need to validated operational capability.

Configuration Specifications

Many modern pharmacovigilance systems are implemented using configurable commercial software rather than custom-developed applications. Instead of writing software code, organisations configure existing functionality to support their business processes, regulatory obligations and operational workflows.

Consequently, configuration becomes a critical component of the validation lifecycle.

Configuration Specifications document how standard software has been configured to satisfy approved business and functional requirements while maintaining traceability throughout the lifecycle of the system.

Why Configuration Specifications Are Important

Commercial pharmacovigilance applications often provide hundreds or thousands of configurable options.

Examples include:

• workflow configuration;
• user roles and permissions;
• case processing rules;
• coding dictionaries;
• reporting schedules;
• notification rules;
• interface mappings;
• business rules;
• electronic reporting settings;
• dashboard configuration.

Although these changes may not involve software development, they directly influence the behaviour of the validated system and therefore require appropriate control.

Configuration Specifications provide documented evidence explaining these implementation decisions.

Configuration Is Not Custom Development

One of the most common misconceptions is that configuration and software development require identical documentation.

They do not.

Configuration uses functionality already developed, tested and supported by the software supplier.

The organisation determines how that existing functionality will be applied within its own business environment.

Consequently, validation focuses primarily on demonstrating that approved configuration correctly supports the intended business process rather than validating the underlying software code itself.

Typical Contents of a Configuration Specification

Depending upon the complexity of the implementation, a Configuration Specification may describe:

• configured workflows;
• organisational hierarchies;
• user roles;
• security profiles;
• business rules;
• coding dictionaries;
• report parameters;
• interface mappings;
• configurable notifications;
• lookup tables;
• system parameters;
• electronic submission settings.

Each configuration decision should remain traceable to one or more approved business or functional requirements.

Configuration Specifications in Pharmacovigilance

Examples of configuration activities include:

• configuring case processing workflows;
• defining medical review stages;
• configuring seriousness assessment workflows;
• establishing product hierarchies;
• configuring MedDRA versions;
• implementing WHO Drug dictionaries;
• defining E2B(R3) transmission settings;
• configuring literature review workflows;
• establishing signal management workflows;
• configuring regulatory reporting rules.

Although these activities do not alter the underlying application software, they significantly influence regulated pharmacovigilance processes.

Configuration Control

Configuration should remain under formal change control throughout the operational life of the system.

Before implementing configuration changes, organisations should evaluate:

• affected business processes;
• regulatory impact;
• patient safety impact;
• data integrity risks;
• validation requirements;
• regression testing requirements.

Even apparently minor configuration changes may affect critical pharmacovigilance activities and should therefore undergo appropriate assessment.

Configuration and Traceability

Configuration Specifications form an important link within the validation lifecycle.

Ideally, organisations should be able to demonstrate traceability from:

Business Requirement

↓

User Requirement

↓

Functional Specification

↓

Configuration Specification

↓

Configured System

↓

Validation Testing

↓

Operational Use

Maintaining this traceability helps demonstrate that approved business requirements have been implemented consistently and verified through objective evidence.

Configuration Specifications and Commercial Software

For commercial off-the-shelf pharmacovigilance systems, Configuration Specifications often become more important than detailed Design Specifications.

The supplier is generally responsible for the design of the application itself.

The regulated organisation is responsible for documenting how that application has been configured to support its own regulated business processes.

Consequently, Configuration Specifications frequently represent the principal implementation document maintained by the marketing authorisation holder.

Configuration Should Remain Business Driven

Configuration decisions should always originate from approved business requirements rather than individual user preferences or historical practices.

Each configuration choice should be capable of answering two questions:

• Which approved requirement does this configuration support?

• Why is this configuration necessary?

Maintaining this discipline reduces unnecessary complexity, simplifies future upgrades and supports efficient lifecycle management.

Scientific Foundation

Configuration Specifications document how commercial software has been configured to implement approved business requirements. They provide the essential link between supplier-developed functionality and organisation-specific implementation while supporting validation, change control and maintenance of the validated state.

Vendor Documentation and Commercial Off-the-Shelf (COTS) Systems

Most pharmacovigilance organisations do not develop their own safety databases or signal management platforms. Instead, they implement commercial off-the-shelf (COTS) software that has already been designed, developed and tested by specialist software vendors.

Examples include safety databases, literature monitoring platforms, signal management systems, electronic reporting gateways and quality management systems.

This changes the nature of Computerised System Validation. Rather than validating software development itself, organisations focus on demonstrating that the selected commercial application has been appropriately assessed, configured, implemented and maintained to support its intended use.

What Is a Commercial Off-the-Shelf System?

A Commercial Off-the-Shelf (COTS) system is software developed for multiple customers rather than for a single organisation.

Unlike bespoke software, the core application is maintained by the supplier.

The regulated organisation typically performs activities such as:

• supplier qualification;
• business process definition;
• system configuration;
• interface implementation;
• user acceptance testing;
• operational governance;
• change control;
• maintenance of the validated state.

Validation therefore concentrates on how the software is implemented rather than how the software itself was engineered.

Leveraging Supplier Documentation

One of the major advantages of commercial software is the availability of extensive supplier documentation.

Depending upon the supplier, documentation may include:

• Functional Specifications;
• Design Specifications;
• architecture documentation;
• release documentation;
• test evidence;
• configuration guides;
• installation guides;
• security documentation;
• user manuals.

Modern validation guidance encourages organisations to leverage appropriate supplier documentation rather than recreating equivalent documents unnecessarily.

However, supplier documentation should always be reviewed to ensure that it adequately supports the organisation's intended use.

Supplier Validation Does Not Replace Organisational Validation

Software suppliers frequently validate their own development processes and software releases.

Although this information provides valuable assurance, it does not eliminate the responsibility of the regulated organisation.

The Marketing Authorisation Holder remains responsible for demonstrating that:

• the selected software is appropriate for its intended use;
• configuration supports regulated business processes;
• interfaces operate correctly;
• organisational procedures are effective;
• users are appropriately trained;
• validation remains complete and traceable.

Supplier validation therefore complements, but never replaces, organisational validation.

Supplier Qualification

Confidence in a commercial application begins with confidence in the supplier.

Supplier qualification should consider factors such as:

• quality management systems;
• software development lifecycle;
• release management;
• customer support;
• cybersecurity practices;
• regulatory experience;
• documentation quality;
• incident management;
• long-term product support.

The depth of supplier assessment should remain proportionate to the significance of the system and the risks associated with its intended use.

Configuration and Local Implementation

Although commercial software provides standard functionality, every organisation configures the application to support its own business processes.

Examples include:

• workflow configuration;
• user roles and permissions;
• organisational structures;
• reporting schedules;
• electronic submission settings;
• interface mappings;
• business rules;
• notification rules.

These local implementation decisions are the responsibility of the regulated organisation and should be documented, assessed and validated appropriately.

Cloud-Based and Software-as-a-Service Platforms

Increasingly, pharmacovigilance applications are delivered through cloud-hosted or Software-as-a-Service (SaaS) models.

In these environments, suppliers often manage:

• infrastructure;
• operating systems;
• application deployment;
• routine maintenance;
• security patching.

Nevertheless, responsibility for ensuring that the system remains fit for its intended use continues to rest with the regulated organisation.

Validation activities should therefore include assessment of supplier governance, service agreements, change notification processes, disaster recovery capabilities and ongoing operational performance.

Shared Responsibilities

Successful implementation of commercial pharmacovigilance software requires clearly defined responsibilities between the supplier and the regulated organisation.

In general:

The supplier is responsible for developing, maintaining and supporting the application.

The regulated organisation is responsible for ensuring that the application has been selected appropriately, configured correctly, validated for its intended use and maintained within a validated state throughout its operational lifecycle.

Clear allocation of responsibilities reduces ambiguity and strengthens overall system governance.

Vendor Documentation Should Support, Not Replace, Validation

Experienced validation professionals do not measure the quality of a validation programme by the volume of supplier documentation collected.

Instead, they evaluate whether available documentation provides sufficient objective evidence to demonstrate that:

• business requirements have been satisfied;
• critical risks have been controlled;
• implemented configuration supports intended use;
• the validated state can be maintained throughout the system lifecycle.

The objective is meaningful assurance rather than duplication of supplier information.

Scientific Foundation

Commercial Off-the-Shelf software changes the focus of Computerised System Validation from validating software development to validating supplier selection, configuration, implementation and lifecycle governance. Regulatory responsibility for ensuring fitness for intended use always remains with the regulated organisation, regardless of the supplier's validation activities.

Risk-Based Documentation and Computer Software Assurance (CSA)

Computerised System Validation has evolved considerably over the past two decades. Earlier validation programmes frequently emphasised the production of extensive documentation, with similar levels of detail applied to almost every computerised system regardless of complexity or regulatory significance.

Modern validation guidance adopts a different philosophy.

Current approaches emphasise scientific justification, quality risk management and generation of objective evidence that provides meaningful assurance that computerised systems remain fit for their intended use.

The objective is no longer to maximise documentation but to maximise confidence.

From Documentation-Centred Validation to Assurance

Historically, organisations often produced large validation packages containing numerous documents with substantial overlap.

Although these packages demonstrated considerable effort, they did not necessarily provide proportionately greater confidence that the system would perform reliably.

Modern guidance recognises that excessive documentation may:

• consume validation resources;
• delay implementation;
• obscure critical information;
• complicate lifecycle maintenance;
• increase the effort required for future changes.

Accordingly, contemporary validation focuses on producing documentation that directly supports understanding, implementation, verification and lifecycle management.

GAMP 5 Second Edition

GAMP 5 Second Edition reinforces a lifecycle approach based upon scientific thinking and quality risk management.

Rather than prescribing identical documentation for every implementation, GAMP encourages organisations to determine documentation based upon factors such as:

• system complexity;
• intended use;
• patient safety impact;
• data integrity risk;
• product quality impact;
• supplier maturity;
• degree of configuration;
• extent of custom development.

This allows validation documentation to remain proportionate while continuing to provide appropriate assurance.

FDA Computer Software Assurance (CSA)

The FDA's Computer Software Assurance (CSA) guidance further develops this philosophy by encouraging organisations to focus validation activities on functions that are most important to patient safety, product quality and data integrity.

Within the CSA framework, organisations should consider:

• which functions are critical;
• what evidence is required;
• which testing activities provide meaningful assurance;
• where supplier evidence may be leveraged;
• how documentation supports confidence rather than compliance alone.

CSA does not reduce regulatory expectations.

Instead, it encourages organisations to spend validation effort where it produces the greatest value.

Applying Risk-Based Documentation

The amount of documentation should reflect the significance of the computerised system.

For example, a highly configured global pharmacovigilance safety database supporting expedited regulatory reporting will generally require substantially more documentation than a standard document repository used for administrative records.

Similarly, custom-developed interfaces usually require more extensive design documentation than standard supplier functionality that remains unchanged.

The level of documentation should therefore be determined by risk rather than by a fixed documentation template.

Leveraging Existing Evidence

Modern validation programmes make effective use of existing evidence wherever appropriate.

Examples include:

• supplier validation documentation;
• supplier testing records;
• release documentation;
• standard operating procedures;
• infrastructure qualification records;
• cybersecurity assessments;
• configuration records.

Leveraging existing evidence reduces unnecessary duplication while maintaining confidence in the validated system.

The regulated organisation should nevertheless evaluate whether available evidence adequately supports its own intended use.

Critical Thinking Rather Than Checklist Validation

Risk-based validation requires professional judgement.

Rather than asking:

"Which validation documents are missing?"

experienced validation professionals ask:

• What risks exist?
• Which functions are critical?
• What evidence provides confidence?
• What documentation genuinely supports lifecycle management?
• Where are additional controls required?

This approach produces validation programmes that are both scientifically justified and operationally efficient.

Pharmacovigilance Examples

Examples of risk-based documentation include:

• extensive Functional and Configuration Specifications for a global safety database supporting expedited reporting;

• concise implementation documentation for a standard learning management system with minimal configuration;

• additional interface documentation for automated E2B(R3) exchanges with regulatory authorities;

• enhanced validation evidence for systems supporting signal detection, benefit-risk evaluation or aggregate reporting.

The documentation reflects the significance of the regulated business process rather than the popularity or size of the software application.

Maintaining Proportionality

Risk-based documentation should not be interpreted as producing fewer documents regardless of circumstances.

Highly complex pharmacovigilance systems may legitimately require substantial documentation because the associated risks are significant.

Conversely, producing unnecessary documentation for simple, low-risk systems does not improve validation quality.

The objective is proportionality.

Every validation document should exist because it provides meaningful assurance, supports lifecycle management or contributes to inspection readiness.

Scientific Foundation

Modern Computerised System Validation measures success by the quality of assurance rather than the quantity of documentation. Documentation should be proportionate to system risk, scientifically justified and capable of demonstrating continued confidence that the computerised system remains fit for its intended use throughout its operational lifecycle.

Common Mistakes

Deficiencies relating to Functional Specifications and Design Specifications are frequently identified during validation projects, internal audits and regulatory inspections. In many cases, these deficiencies do not arise because documentation is missing, but because the relationship between business requirements, system behaviour and technical implementation has not been clearly defined.

Most problems originate from poor separation of responsibilities, inadequate traceability or excessive documentation that adds complexity without improving assurance.

Understanding these recurring mistakes helps organisations produce validation documentation that remains scientifically justified, proportionate and maintainable throughout the system lifecycle.

Confusing Requirements with Design

One of the most common mistakes is mixing User Requirements, Functional Specifications and Design Specifications into a single document without maintaining clear distinctions between their purposes.

Examples include:

• describing database structures within the User Requirements Specification;
• documenting business requirements within the Design Specification;
• repeating identical information across multiple documents.

When document boundaries become blurred, traceability becomes more difficult and lifecycle maintenance becomes unnecessarily complex.

Each document should answer its own question while remaining traceable to the documents before and after it.

Excessive Technical Detail

Some organisations attempt to document every technical aspect of the implemented system regardless of its relevance to validation.

Examples include:

• detailed database schemas;
• source code descriptions;
• infrastructure configuration unrelated to regulated functions;
• operating system settings with no impact on intended use.

Although technical documentation may be valuable for system maintenance, it should only be included within the validation package when it contributes to demonstrating fitness for intended use, maintaining the validated state or supporting regulatory expectations.

Insufficient Functional Detail

The opposite problem also occurs.

Functional Specifications sometimes describe system behaviour only at a very high level without explaining how approved business requirements are expected to operate.

Examples include missing descriptions of:

• workflow logic;
• exception handling;
• business rules;
• user interactions;
• reporting behaviour;
• interface processing.

Insufficient functional detail makes validation testing more difficult because expected behaviour has not been adequately defined.

Poor Traceability

Traceability deficiencies remain among the most common validation weaknesses.

Examples include:

• Functional Specifications that cannot be linked to approved User Requirements;
• Design Specifications that cannot be linked to Functional Specifications;
• validation tests without corresponding functional requirements;
• implemented functionality lacking documented justification.

Effective traceability demonstrates that every important business requirement has been implemented appropriately and verified through objective evidence.

Reproducing Supplier Documentation

For Commercial Off-the-Shelf systems, organisations sometimes reproduce large sections of supplier documentation within their own validation documents.

This approach increases document maintenance while adding little additional assurance.

Instead, supplier documentation should be referenced where appropriate, with organisation-specific documentation focusing on:

• intended use;
• local configuration;
• interfaces;
• organisation-specific workflows;
• business rules;
• validation evidence.

This approach reduces duplication while maintaining complete validation records.

Failure to Maintain Documentation

Functional Specifications and Design Specifications should evolve together with the computerised system.

Common deficiencies include:

• obsolete workflow descriptions;
• undocumented configuration changes;
• outdated interface documentation;
• inconsistent version control;
• failure to update documentation following software upgrades.

These deficiencies may reduce confidence that the validation package accurately reflects the implemented system.

Ignoring Configuration

For configurable pharmacovigilance systems, organisations occasionally focus almost exclusively on supplier documentation while providing little evidence describing their own configuration decisions.

However, configuration often determines how the regulated business process actually operates.

Accordingly, configuration should remain subject to:

• documented specifications;
• change control;
• risk assessment;
• validation testing;
• lifecycle management.

Documentation Without Purpose

One of the most significant mistakes is producing documents simply because they have traditionally existed within validation programmes.

Every specification should contribute meaningfully to:

• understanding the implemented solution;
• supporting validation;
• facilitating change control;
• maintaining the validated state;
• demonstrating inspection readiness.

Documentation that provides no additional assurance increases complexity without improving validation quality.

Professional Insight

High-quality validation documentation is characterised by clarity, traceability and purpose. Every Functional Specification, Design Specification and Configuration Specification should exist because it contributes objective evidence supporting confidence in the validated computerised system—not because it appears on a historical document checklist.

Inspection Perspective

During pharmacovigilance inspections, Functional Specifications and Design Specifications are rarely reviewed as isolated documents. Instead, inspectors evaluate whether these specifications collectively demonstrate that approved business requirements have been translated into an implemented and validated computerised system in a logical, controlled and traceable manner.

The emphasis is therefore placed upon the quality of the validation process rather than the existence of individual documents.

Inspectors seek confidence that organisations understand how their computerised systems support regulated pharmacovigilance activities and that changes to those systems remain appropriately governed throughout the system lifecycle.

What Inspectors Want to Demonstrate

When reviewing Functional Specifications and Design Specifications, inspectors typically seek objective evidence that:

• approved business requirements have been translated into implemented functionality;
• functional behaviour remains consistent with intended use;
• technical implementation supports validated business processes;
• critical functions have been appropriately verified;
• changes have been controlled;
• documentation accurately reflects the implemented system.

These questions are considered together rather than independently.

The objective is to determine whether confidence in the computerised system is justified.

Demonstrating Traceability

Traceability remains one of the most important aspects of inspection readiness.

Inspectors should be able to follow critical business requirements throughout the validation lifecycle.

For important pharmacovigilance functions, organisations should be able to demonstrate relationships between:

• approved User Requirements;
• Functional Specifications;
• Design or Configuration Specifications;
• implemented configuration;
• validation testing;
• documented deviations;
• final system approval.

Where traceability is incomplete, inspectors may question whether important business requirements have been implemented or verified appropriately.

Functional Behaviour Should Match Operational Reality

Inspectors frequently compare validation documentation with the operational system.

Typical sources of evidence include:

• live system demonstrations;
• standard operating procedures;
• workflow documentation;
• training records;
• user interviews;
• validation test evidence.

If documented functional behaviour differs significantly from actual system operation, inspectors may conclude that validation documentation no longer reflects the validated state.

Maintaining consistency between documentation and operational practice is therefore essential.

Configuration Is Frequently Reviewed

For commercial pharmacovigilance systems, inspectors often focus on organisation-specific configuration rather than supplier-developed software.

Examples include:

• workflow configuration;
• user roles;
• reporting rules;
• electronic submission settings;
• interface mappings;
• security configuration;
• organisation-specific business rules.

Inspectors expect these configuration decisions to be documented, justified and maintained under formal change control.

Supplier Documentation Is Evaluated in Context

Supplier documentation may provide valuable evidence supporting validation.

However, inspectors generally expect organisations to demonstrate that supplier documentation has been reviewed and assessed for local implementation.

Simply possessing supplier documentation does not demonstrate that the implemented system supports the organisation's intended use.

Inspectors therefore evaluate how supplier information has been incorporated into the organisation's own validation programme.

Common Inspection Findings

Recurring findings relating to Functional Specifications and Design Specifications include:

• incomplete traceability from approved requirements;
• unclear separation between functional and technical documentation;
• outdated specifications following software upgrades;
• undocumented configuration changes;
• inadequate assessment of interfaces;
• inconsistent version control;
• insufficient documentation supporting organisation-specific configuration;
• failure to evaluate supplier changes adequately.

Most of these observations reflect weaknesses in lifecycle governance rather than isolated documentation deficiencies.

Inspection Readiness Is Continuous

Functional Specifications and Design Specifications should remain accurate throughout the operational life of the computerised system.

Inspection readiness is achieved by maintaining these documents under effective document control, ensuring that approved changes are reflected promptly and preserving traceability between business requirements, implemented functionality and validation evidence.

Organisations that continuously maintain accurate specifications are generally better prepared for inspections than those attempting to update documentation immediately before regulatory review.

Inspection Insight

Inspectors are not assessing whether Functional Specifications and Design Specifications are lengthy or technically sophisticated. They are assessing whether these documents provide a clear, traceable and accurate explanation of how approved business requirements have been implemented and maintained within the validated pharmacovigilance system.

How an Experienced CSV Lead Thinks About Functional and Design Specifications

Experienced Computerised System Validation professionals do not regard Functional Specifications and Design Specifications as documents produced simply to satisfy regulatory expectations. Instead, they view these specifications as essential tools for translating business intent into a validated operational system.

Their primary objective is not to create documentation. It is to create confidence that approved business requirements have been implemented correctly, can be verified objectively and will remain maintainable throughout the operational life of the computerised system.

They Start With the Business Problem

Experienced CSV Leads rarely begin by reviewing software architecture or configuration options.

Instead, they first ask:

• What business process is being supported?
• Which pharmacovigilance activities depend upon this system?
• What regulatory obligations must be satisfied?
• Which failures could affect patient safety or data integrity?
• What evidence will demonstrate that the business need has been fulfilled?

Only after understanding these questions do they review functional behaviour or technical implementation.

The technology exists to support the business process—not the other way around.

They Protect the Separation Between Documents

Experienced professionals deliberately maintain clear boundaries between the User Requirements Specification, Functional Specification and Design Specification.

They recognise that each document serves a different purpose.

When these boundaries become blurred:

• traceability becomes more difficult;
• change impact assessments become more complex;
• duplicate documentation increases;
• lifecycle maintenance becomes unnecessarily burdensome.

Maintaining clear document responsibilities simplifies both validation and long-term system governance.

They Think About Traceability Before Testing

Experienced validation professionals understand that every important business requirement should eventually become objective validation evidence.

While reviewing a Functional Specification they naturally ask:

• Which User Requirement does this function satisfy?
• How will this function be verified?
• Which validation protocol will test it?
• What objective evidence will demonstrate successful implementation?

This mindset produces validation programmes with strong traceability rather than isolated collections of documents.

They Challenge Complexity

Experienced CSV Leads recognise that additional functionality inevitably increases:

• implementation effort;
• validation effort;
• regression testing;
• lifecycle maintenance;
• operational support.

Consequently, they continually ask:

• Is this functionality genuinely required?
• Does it support a regulated business process?
• Can existing functionality satisfy the same need?
• Will this increase long-term maintenance unnecessarily?

Their objective is to achieve the simplest implementation capable of supporting the approved intended use.

They Understand That Configuration Is the Product

For commercial pharmacovigilance systems, experienced professionals recognise that the supplier has already developed the software.

The regulated organisation is primarily validating its own implementation.

Consequently, their attention focuses upon:

• local configuration;
• workflow design;
• interface behaviour;
• security roles;
• reporting rules;
• organisational business processes.

The validated system is therefore defined not only by the supplier's software but also by the organisation's configuration decisions.

They Think Across the Entire Lifecycle

Experienced validation professionals do not prepare Functional Specifications and Design Specifications solely for implementation projects.

They consider how these documents will support:

• software upgrades;
• supplier releases;
• interface modifications;
• regulatory changes;
• periodic review;
• change control;
• system retirement.

Specifications that remain useful throughout the lifecycle provide substantially greater value than documents created only for initial validation.

They Think Like Inspectors

Experienced CSV Leads routinely review their documentation from an inspector's perspective.

Typical questions include:

• Could an independent reviewer understand how business requirements became implemented functionality?
• Is the technical implementation consistent with the approved intended use?
• Can every critical function be traced through validation?
• Does the documentation accurately describe the operational system?
• Would today's documentation still support confidence after the next software upgrade?

This perspective promotes continuous inspection readiness rather than periodic documentation exercises.

They Value Clarity Over Volume

Experienced professionals understand that excellent validation documentation is rarely characterised by its size.

Instead, it is characterised by:

• clarity;
• logical structure;
• traceability;
• proportionality;
• maintainability;
• scientific justification.

Every specification should exist because it improves understanding of the validated system and supports confidence in its continued operation.

Professional Reflection

Experienced CSV professionals recognise that Functional Specifications and Design Specifications are not ends in themselves. Their purpose is to create a clear, traceable and maintainable pathway from approved business requirements to a validated computerised system that consistently supports safe, reliable and compliant pharmacovigilance activities.

Key Takeaways

Functional Specifications and Design Specifications provide the critical link between approved business requirements and the implemented computerised system.

The Functional Specification describes how the system is expected to behave from the perspective of users and regulated business processes, while the Design Specification explains how that behaviour is technically implemented within the selected solution.

Together, these documents support traceability, validation testing, change control and lifecycle management while providing objective evidence that approved business requirements have been implemented consistently and appropriately.

Modern validation approaches emphasise risk-based documentation, proportionality and meaningful assurance. Well-structured specifications therefore remain valuable throughout the operational life of the system, supporting upgrades, inspections, supplier changes and maintenance of the validated state.