With verification and validation, we aim to develop a “level of confidence” that the software or device meets all requirements and user expectations.

Verification (internal process)

• Automated testing, static/dynamic analysis, code inspection, walkthroughs, etc.
• Checks for regulations, specifications, imposed conditions.
• Building product right?

Validation (often external process)

• Assurance software meets operational needs of customer or stakeholders. Confirmation by examination and objective evidence that requirements are consistently fulfilled. Comprehensive testing, inspections, analyses, simulation, etc.
• Acceptance, suitability.
• Building right product?

• Identify Processes.
• Requirements & Specifications (defined by user).
  • Requirements: reflect the stated or implied needs of the customer, and may be market-based, contractual, or statutory, as well as an organization's internal requirements.
  • Specification: a document that states requirements. It might include: drawings, patterns, documents, etc.
  • Needs & goals of stakeholders.
  • Inputs, outputs, functionality, performance, external/internal/user interfaces, user interactions, error and handling, response times, operating environment (OS, hardware, etc.), ranges/limits/defaults/specific values, safety requirements.
• Regulations.
• Decide on verification and/or validation.
• Validation protocol.
• Perform & document the following (what, how, quantity, when to verify/measure; define acceptance/rejection criteria and required documentation):
  • Installation qualification (IQ).
  • Operational qualification (OQ).
  • Performance qualification (PQ).
• Determine continuous process controls.
• Generate final report and approval.
• Control the process continuously.
• Revalidate process as appropriate.

If a software application has a critical impact on the quality of the product or service delivered to the end-user, and if the use of such software application has a risk associated with it, then such software application shall be validated in accordance with chapter 4.1.6 of the ISO 13485:2016.

There are some software programs and tools, that will not be validated as rule, because the software or tools do not do any calculation of process steps themselves. These include but are not limited to:

• Any tool or document created using Microsoft Word
• Any tool or document created using PowerPoint

Header

• <Company Name/Logo>
• SW Application Validation
• Version: <VersionNum>
• Document Control Number: <DocNumber>
• Release
  • Created by: Name, Title, Signature, Date
  • Reviewed by: Name, Title, Signature, Date
  • Released by: Name, Title, Signature, Date

Content

• 1 Purpose: <Content>
• 2 SW Application and Risk Assessment
  • Process
  • SW Application Name
  • Version
  • Risk Assessment
  • Validation Required? Yes/No
• 3 Approval and Signature
  • Place/Date, Name/Title
• 4 Document History
  • Version
  • Main Changes

Header

• <Company Name/Logo>
• SW Application Validation
• Version: <VersionNum>
• Document Control Number: <DocNumber>
• Release
  • Created by: Name, Title, Signature, Date
  • Reviewed by: Name, Title, Signature, Date
  • Released by: Name, Title, Signature, Date

Content

• 1 Purpose: <Content>
• 2 SW Application: <AppName>
  • Risk Identified
  • Validation Protocol
  • Validate Date
  • Validation Outcome
  • Validation Document
• 2.1 Validation Conclusion:
• 2.2 SW Application Approved? Approved / Not Approved
• 3 Approval and Signature: Place, Date, Name, Title
• 4 Document History
  • Version
  • Main Changes