Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, Redesign and Development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
      • Templates
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity
    • GP-025 Corporate Governance
    • GP-026 Product requirements for US market
    • GP-027 Product requirements for UK market
    • GP-028 Product requirements for the Brazilian market
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
  • Records
  • TF_Legit.Health_Plus
  • Licenses and accreditations
  • External documentation
  • Procedures
  • GP-019 Software validation plan

GP-019 Software validation plan

Purpose​

Describe the validation process pertinent to external software utilised, which could potentially impact the medical devices we manufacture and market.

Scope​

This procedure encompasses all externally-sourced software and applications utilised in manufacturing, design, and development, as well as other aspects of our quality system. This software is not entirely developed or produced by us but is acquired from suppliers and then configured and adapted to meet our specific needs.

For additional information on the processes adhered to during the manufacturing and validation of our software, please refer to the GP-012 Design, Redesign, and Development procedure.

Definitions​

  • High-risk process: When its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning an increased medical device risk.
  • Not high-risk process: When its failure to perform as intended would not result in a quality problem that foreseeably compromises safety. This includes situations where failure to perform as intended would not result in a quality problem, as well as situations where failure to perform as intended may result in a quality problem that does not foreseeably lead to compromised safety.
  • Process risk: This entails the potential to adversely affect production or the quality system, representing the likelihood and consequence of a process negatively influencing the reliability and quality of the production or quality management system.

Responsibilities​

JD-001​

To provide the organization with a set of appropriate resources and software tools to guarantee the efficacy of the QMS and the processes.

JD-004​

To control and establish the periodic activities for the software control that require validation and to review and ensure that the records of the activities performed are properly generated and archived.

JD-003​

Coordinate and verify the activities of software validation and revalidation involved in the production of the medical device.

JD-005​

Implement the mitigation actions required to avoid or minimize the risks or hazards found during the software configuration design.

Inputs​

Software tools used as part of medical device production or the quality system that required to be validated according to the classification established in this procedure.

Outputs​

  • T-019-001 Software validation report_Software name
  • T-019-002 External software list

Development​

Compliance​

Conducting a risk-based analysis for computer software assurance for production or quality system software is distinct from performing a risk analysis for a medical device as described in ISO 14971:2019 Medical device. Application of risk management to medical devices.

This procedure has been developed according to the requirements set out in ISO 13485 and to the following guidelines:

  • General Principles of Software Validation; Final Guidance for Industry and FDA Staff. January 11, 2002
  • Guidance for Industry. Computerized systems used in clinical investigations. FDA. May 2007
  • Draft of Computer software assurance CFR- FDA September 2022.

These guidelines state that it is required to validate software that is used as part of production or the quality system for its intended use.

Risk management​

For each external software or application that we configure, we perform a simplified risk analysis of their use case and characteristics, to determine appropriate assurance activities.

It is not necessary to follow ISO 14971 for this risk management as the software and applications used are broadly accepted by the community and by us as it can be consulted at their corresponding T-002-007 Process validation cards.

We will classify the processes as high-risk processes or not high-risk processes, according to the definitions explained in the corresponding section.

We will apply principles of risk-based testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk to determine the appropriate activities:

  • For high-risk software features, functions, and operations, we will consider more rigour such as the use of scripted testing or limited scripted testing, as appropriate, when determining their assurance activities.
  • For software features, functions, and operations that are not high-risk, we will consider using testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk of the intended use.

Requirements specification​

First of all, we determine the requirements of the software or application including the operating conditions, user characteristics, potential hazards and the intended use.

The requirements will specify the following when required:

  • All software system inputs;
  • All software system outputs;
  • All functions that the software system will perform;
  • All performance requirements that the software will meet, (e.g., data throughput, reliability, and timing);
  • The definition of all external and user interfaces, as well as any internal software-to-system interfaces;
  • How users will interact with the system;
  • What constitutes an error and how errors should be handled;
  • Required response times;
  • The intended operating environment for the software, if this is a design constraint (e.g., hardware platform, operating system);
  • All ranges, limits, defaults, and specific values that the software will accept; and
  • All safety-related requirements, specifications, features, or functions that will be implemented in software.
  • All internal and external security safeguards required

Each requirement identified in the software requirements specification will be evaluated for accuracy, completeness, consistency, testability, correctness, and clarity, to verify that:

  • There are no internal inconsistencies among requirements;
  • All of the performance requirements for the system have been spelt out;
  • Fault tolerance, safety, and security requirements are complete and correct;
  • Allocation of software functions is accurate and complete;
  • Software requirements are appropriate for the system hazards; and
  • All requirements are expressed in terms that are measurable or objectively verifiable.

Design Specification​

In the design process, we will describe what the software or application should do and how it should do it. We will describe all the details required to ensure that the person responsible for executing the design can perform the development without the need to make ad hoc design decisions.

The software design specification will include when applicable:

  • Software requirements specification, including predetermined criteria for acceptance of the software;
  • Software risk analysis;
  • Development procedures and coding guidelines (or other programming procedures);
  • Systems documentation (e.g., a narrative or a context diagram) that describes the systems context in which the program is intended to function, including the relationship of hardware, software, and the physical environment;
  • Hardware to be used;
  • Parameters to be measured or recorded;
  • Logical structure (including control logic) and logical processing steps (e.g., algorithms);
  • Data structures and data flow diagrams;
  • Definitions of variables (control and data) and description of where they are used;
  • Error, alarm, and warning messages;
  • Supporting software (e.g., operating systems, drivers, other application software);
  • Communication links (links among internal modules of the software, links with the supporting software, links with the hardware, and links with the user);
  • Security measures (both physical and logical security); and
  • Any additional constraints not identified in the above elements

Validation and revalidation process​

We assign internal staff members who are not involved in a particular design or its implementation, but who have sufficient knowledge to evaluate the project and conduct the verification and validation activities.

The validation operation will be done before the incorporation as a used tool in the process, with the corresponding evidence of correct operation and effectiveness.

Additionally, a new validation will be performed when a modification of the software or application configuration must be implemented.

Software classification​

There are different types of external software that we use in manufacturing, design and development, or other parts of the quality system, that could affect the medical devices we manufacture and commercialize. We list them within the T-019-002 External software list record, detailing their type, name, performance and the validation activities that we must conduct, when required, to ensure they comply with our requirements.

Design reviews​

Answers to some key questions should be documented during formal design reviews. These include:

  • Have the appropriate tasks and expected results, outputs, or products been established for each software life cycle activity?
  • Do the tasks and expected results, outputs, or products of each software life cycle activity:
    • Comply with the requirements of other software life cycle activities in terms of correctness, completeness, consistency, and accuracy?
    • Satisfy the standards, practices, and conventions of that activity?
    • Establish a proper basis for initiating tasks for the next software life cycle activity?

Test plan​

The test plan will identify the schedule, environment, resources, methodologies, cases, documentation and reporting criteria. The magnitude of effort to be applied throughout the testing process will be linked to complexity, criticality, reliability and safety issues.

Due to the nature of the software being validated throughout this procedure, the tests performed will be focused on the usability of the configuration established.

Acceptance criteria​

Each external software or application configuration will have its own specific tests according to the established requirements to comply with them that will contain their acceptance criteria, which will be compiled at the corresponding T-019-001 Software validation report_Software name.

Validation report​

All the information that is compiled and registered as a result of this procedure application, along with the evidence of the test performed will be documented in the T-019-001 Software validation report.

The essential content of the report will be:

  • The intended use of the software feature, function or operation.
  • The determination of risk
  • The requirements and design specifications of the software
  • The test plan with an explanation of the tests to perform and their acceptance criteria.
  • Test results with the acceptance or not.
  • Results or deviations detected: specification of the obtained results.
  • Conclusion: final judgment of acceptance or rejection of the results of each test (the absence of acceptance may be justified in the event of non-compliance when the risk analysis is favourable).
  • Date of the testing performance
  • Name, position and signature of the person who conducted the testing.
  • Signature and date of an individual with signatory authority to perform the review and approval.

Revalidation after a change​

Whenever software is changed, a validation analysis should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire software system.

Maintenance activities​

Change or anomaly evaluation​

When a need for change, problem or anomaly is detected, it will be communicated through the communication channels established to the JD-003 and JD-005. They will analyse the communication and they will approve (or not approved) the change. The change will be documented according to the procedure GP-023 Change control management and, when required, revalidation of the software and an update of the affected documents will be executed.

If the communication is considered a non-conformity, it will be registered and followed up according to the GP-006 Non-Conformities. Corrective and preventive actions procedure.

If the software is not subject to changes, we will perform a revalidation every 2 years to ensure its performance and compliance.

Associated documents​

  • GP-006 Non-Conformities. Corrective and preventive actions
  • GP-012 Design, redesign and development
  • T-002-007 Process validation cards
  • T-019-001 Software validation report_Software name
  • T-019-002 External software list

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

  • Author: Team members involved
  • Reviewer: JD-003, JD-004
  • Approver: JD-001
Previous
SP-018-001 Remote infrastructure control access policy
Next
Templates
  • Purpose
  • Scope
  • Definitions
  • Responsibilities
    • JD-001
    • JD-004
    • JD-003
    • JD-005
  • Inputs
  • Outputs
  • Development
    • Compliance
    • Risk management
    • Requirements specification
    • Design Specification
    • Validation and revalidation process
    • Software classification
    • Design reviews
    • Test plan
      • Acceptance criteria
    • Validation report
    • Revalidation after a change
  • Maintenance activities
    • Change or anomaly evaluation
  • Associated documents
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)