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
        • T-019-001 Software validation report_Software name_YYYY_nnn
        • T-019-002 External software list_YYYY_nnn
    • 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
  • Templates
  • T-019-001 Software validation report_Software name_YYYY_nnn

T-019-001 Software validation report_Software name_YYYY_nnn

Scope​

The aim is to gather additional requirements and configuration specifications not encompassed within the application, together with their respective validations. This ensures adherence to both our internal requirements and those imposed by regulatory bodies. This involves detailing specifications and criteria which are external to the application but fundamental for ensuring our outputs align with all requisite standards and regulations.

Software description​

Name​

Manufacturer​

Intended use​

Risk-based analysis​

Requirements and design specification​

info

To assign a requirement ID for each one of them following the coding Requirement XX, being XX a sequential number.

Assurance activities and test plan​

info

To include the differents tests or checks to perform to each feature or function along with their corresponding acceptance criteria. Identify each test following the coding Test XX, being XX a sequential number.

IDTest descriptionAcceptance criteriaRequirement tested
Test XX

Test Results and deviations detected​

info

To include if the tests pass or not. Add the following information for each test, along with the evidence.

ID: Test XX Result: Deviation:

Design review​

Result
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?⬜️

Conclusion​

Record signature meaning​

  • Author: JD-004 Author name
  • Review: JD-003 Reviewer name
  • Approval: JD-005 Approver name

Template signature meaning​

info

Delete this section when you create a new record from this template.

  • Author: JD-004 María Diez
  • Review: JD-003 Taig Mac Carthy
  • Approval: JD-001 Andy Aguilar
Previous
Templates
Next
T-019-002 External software list_YYYY_nnn
  • Scope
  • Software description
    • Name
    • Manufacturer
    • Intended use
  • Risk-based analysis
  • Requirements and design specification
  • Assurance activities and test plan
  • Test Results and deviations detected
  • Design review
  • Conclusion
  • Record signature meaning
  • Template signature meaning
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.)