Software Validation

QMS requirements for medical device companies

READ ARTICLE

Introduction

The integrity and reliability of software, whether embedded in a device or used as part of a quality management system (QMS), are not just operational concerns; they are regulatory imperatives. Among the key pillars of medical device compliance lies software validation, a process that ensures software performs consistently and reliably for its intended purpose. When software is used in processes that support regulatory compliance, such as document control, complaint management, or design controls, validation becomes a critical requirement under ISO 13485, FDA 21 CFR Part 820, and other regulatory frameworks.

In this article, we’ll explore the concept of software validation in the context of medical device QMS requirements, unpack regulatory expectations, and provide practical guidance for implementation.

What is software validation?

The U.S. Food and Drug Administration FDA, defines software validation as:

“Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”

Put simply, validation ensures that a software system meets its intended purpose in the real-world environment in which it is used. It confirms that the software is fit for use, performs as intended, and does not introduce unintended risks to the medical device, patients, or the quality system.

Why is software validation required?

Unlike manual processes, software operates on assumptions, logic trees, and configurations often invisible to users. If improperly configured or inadequately tested, software can:

  • Produce incorrect records (e.g., incorrect product release status)
  • Miss critical actions in a process
  • Delete or corrupt audit trails
  • Allow unauthorised access to critical data
  • Introduce compliance risk or patient harm indirectly

Regulators expect companies to understand the potential impact of software on product quality and patient safety, and to validate that the software performs reliably under real operating conditions.

What needs to be validated?

A common misconception is that all software must be validated. In fact, validation should be risk-based. Medical device manufacturers should keep a process to determine which software products should be validated, including key questions such as:

  • Is the software part of the Quality Management System (QMS)? Medical device companies often use off-the-shelf (OTS) or custom-built software to automate or manage parts of their QMS. Under FDA 21 CFR 820.70(i) and ISO 13485:2016 clause 4.1.6, any computer software used in the QMS affecting product quality must be validated to ensure consistent performance.
  • Does the software impact product quality or regulatory compliance?
  • Could failure of the software lead to nonconformance?
  • Is the software used in decision-making, documentation, or data integrity?

Generally, any software that touches the product or the QMS will probably need to be validated. As with most QMS processes, I recommend making a list of all the software used in the company (best practice for cybersecurity, anyway) and providing a rationale for the software validation decision.

Examples of software not necessarily requiring full validation:

  • MS Outlook for general communication
  • Zoom or Teams for virtual meetings

The risk-based approach is also reflected in GAMP 5 (Good Automated Manufacturing Practice), which classifies software based on complexity and configurability.

Elements of a software validation process

A robust software validation program should include the following components:

  • User Requirements Specification (URS): Define what the software needs to do. This should be based on actual use cases and needs. Map each user requirement to specific test cases with a traceability matrix, ensuring complete coverage.
  • Risk Assessment: Identify potential risks the software could pose to quality or compliance. Apply ISO 14971-style thinking: severity × probability. Consider using Failure Mode and Effects Analysis (FMEA) or a similar method.
  • Validation Plan: Outlines the approach, responsibilities, and deliverables for validation. Include the scope, software type (OTS vs custom), risk level, and required testing as a minimum.
  • Installation Qualification (IQ): Ensure the software is installed correctly and consistently across intended environments.
  • Operational Qualification (OQ): Verify that the software performs key functions as intended under normal and edge-case conditions.
  • Performance Qualification (PQ): This measure demonstrates that the software performs consistently in its actual intended use by trained users in the live system.
  • Validation Report: Summarises the entire effort, including deviations, test outcomes, and final conclusion: “fit for use”.
  • Maintaining the validation state: Validation is not a one-time event. It must be maintained over the software lifecycle when:
    • Revalidate after major updates, configuration changes, or new integrations
    • Include the software in your change control and internal audit program
    • Train users and log training records
    • Periodically review vendor performance and incident logs

Validating off-the-shelf (OTS) and cloud-based software

Many modern software systems are hosted in the cloud and updated frequently. Validation in these scenarios requires a collaborative approach with vendors, for example:

  • Request validation packages or certifications from the vendor (e.g., IQ/OQ documentation)
  • Perform PQ testing in your own environment using your workflows
  • Establish a change control process for vendor-driven updates
  • Document user access roles and data integrity controls
  • Review SLAs and data security practices, especially for data management legislation compliance

Best practices for medical device companies

  • Apply a Risk-Based Approach: Focus validation efforts where software failure could affect patient safety, product quality, or regulatory compliance. This includes validating tools like Microsoft Excel if used for design control or quality records.
  • Define and Document Requirements: Start with a clear User Requirements Specification (URS) and ensure you validate your actual use of the software, not just rely on vendor documentation or certifications.
  • Create Use-Case Driven Test Scripts: Develop test scripts based on your real configurations and workflows, not generic templates. This ensures relevance and traceability from requirements to results.
  • Embed Validation in Your QMS: Treat software validation as a core part of your quality system, aligned with ISO 13485 and FDA 21 CFR 820. Involve QA, IT, engineering, and end-users, and include key systems in your internal audit program.
  • Maintain Validation Over Time: Keep validation up to date through ongoing documentation, user training, and re-validation after any system changes, updates, or upgrades—especially for SaaS platforms that update automatically.

Conclusion

In the medical device industry, compliance is not just about ticking boxes—it’s about building systems that ensure safety, quality, and trust. Software validation as part of your QMS is a fundamental requirement under global regulations. When executed well, it protects your company from compliance risks and ensures your digital infrastructure supports efficient, scalable, and high-quality operations.

Whether you’re validating an ERP system, a complaint-handling tool, or a cloud-based eQMS platform, the principles are the same: understand how it’s used, assess the risk, define the requirements, test it, and document it.

Validation is not about perfection—it’s about fitness for purpose, accountability, and control.

Resources

    United States of America (USA):

    Food and Drug Administration (FDA), Federal Food, Drug, and Cosmetic Act (FD&C Act):

    International Standards

    ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes

    • Clause 4.1.6 “The organization shall document procedures for the validation of the application of computer software used in the quality management system… prior to initial use and, as appropriate, after changes to such software or its application.”

    Best Practice Frameworks and Methodologies

    Audit: A systematic, independent examination of a manufacturer’s processes, procedures, and products to ensure compliance with regulatory standards and quality requirements. Also see Internal Audit.

    Change Control: The systematic process of managing and documenting modifications to a device or its manufacturing process to ensure that all changes are assessed, approved, implemented, and tracked in compliance with regulatory standards and quality management systems.

    Compliance: Adherence to regulations, standards, and guidelines set forth by regulatory authorities.

    Enterprise Resource Planning (ERP) Systems: Integrated software platforms that manage and automate core business processes across an organisation, facilitating the flow of information and improving efficiency.

    Fault Tree Analysis (FTA): A top-down, deductive failure analysis used to determine the chain of events that could cause a system-level failure.

    Failure Mode and Effects Analysis (FMEA): A systematic method for identifying potential failure modes of a device and assessing their potential effects on device performance and patient safety.

    FDA Approval: The process by which the U.S. Food and Drug Administration (FDA) officially recognises that a medical device is safe and effective for its intended use.

    Good Manufacturing Practices (GMP): Regulations that require manufacturers to ensure products are consistently produced and controlled according to quality standards.

    International Medical Device Regulators Forum (IMDRF): A global regulatory collaboration focused on harmonising medical device regulations to facilitate patient access to safe and effective devices. This organisation was formerly the Global Harmonization Task Force (GHTF).

    ISO 13485: An international standard that specifies requirements for a quality management system (QMS) specific to the medical devices industry.

    ISO 14971: An international standard for the application of risk management to medical devices.

    Lifecycle Management: The process of overseeing a product, service, or system from its initial development through its growth, maturity, and eventual decline or disposal, ensuring optimal performance and resource utilisation at each stage.

    Manufacturer: A legal entity that designs, produces, assembles, or labels a medical device with the intention of placing it on the market.

    Notified Body (NB): An organisation designated by a country authority to assess the conformity of certain products before being placed on the market, ensuring they meet applicable regulatory requirements and standards.

    Process Controls: The tools and methods to monitor and manage medical device manufacturing processes.

    Process Performance Qualification (PPQ) Studies:

    • Installation Qualification (IQ): Verifying that equipment and installations meet the required specifications.

    • Operational Qualification (OQ): Confirming that equipment and processes operate correctly under defined conditions.

    • Performance Qualification (PQ): Demonstrating that processes perform effectively and reproducibly in real-world conditions.

    Process Verification: Uses process controls to check individual manufacturing steps and components against specifications.

    Process Validation: Ensures that the entire manufacturing process, supported by process controls, reliably produces products meeting all requirements.

    Quality Management System (QMS): A formalised system that documents the structure, responsibilities, and procedures required to achieve effective quality management.

    Quality Management System Regulation (QMSR): The U.S. Food and Drug Administration (FDA) regulation that aligns its medical device quality system requirements with ISO 13485:2016 to streamline global compliance and enhance device safety and effectiveness.

    Quality System Regulation (QSR): Outlined in 21 CFR Part 820, the U.S. Food and Drug Administration (FDA) framework requires medical device manufacturers to establish and maintain a quality management system to ensure their products consistently meet applicable requirements and specifications.

    Record: A documented piece of evidence detailing activities, decisions, or results, created and maintained to demonstrate compliance with regulatory requirements and quality management standards.

    Regulation: The rules, laws, standards, and requirements set by regulatory authorities to ensure the safety, efficacy, and quality of devices intended for medical use.

    Regulatory Authority: An official body overseeing and enforcing laws, regulations, and standards within a specific industry or sector to ensure compliance and protect public interests. Also known as a Regulatory Authority. Also see Competent Authority and Notified Body.

    Risk: The combination of the probability of occurrence of harm and the severity of that harm.

    Risk Analysis: The systematic use of available information to identify hazards and to estimate the risk.

    Risk Assessment: The overall process comprising risk analysis and risk evaluation.

    Risk Evaluation: The process of comparing the estimated risk against given risk criteria to determine the acceptability of the risk.

    Risk Management (RM): The systematic application of management policies, procedures, and practices to the tasks of analysing, evaluating, controlling, and monitoring risk.

    Safety: The condition of being protected from or unlikely to cause danger, risk, or injury.

    Software Validation: The documented process of ensuring that software performs as intended for its specific use within a regulated environment.

    Standard: A document that provides guidance, requirements, or specifications established by regulatory bodies, industry organisations, or international consensus groups.

    Supplier: An entity or organisation that provides materials, components, or finished products used in the manufacturing, assembly, or distribution of medical devices.

    Supplier Management: Overseeing and controlling the relationships and activities with external suppliers to ensure the quality, reliability, and regulatory compliance of sourced materials and components.

    Supply Chain: Activities, processes, and entities involved in the sourcing, manufacturing, distribution, and logistics management of these devices from suppliers to end-users.

    Traceability Matrix: A document that maps and links requirements throughout the development lifecycle, ensuring that each requirement is tested and validated, thereby demonstrating compliance with regulatory standards.

    User Requirements: The requirements and preferences of the intended users, which must be considered and addressed in the device design. Also known as User Needs or Customer Specifications.

    Validation: Confirmation by examining and providing objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

    Updated on 10 May 2024