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
      • Deprecated
      • Templates
        • T-012-004 Software version release
        • T-012-005 Design change control
        • T-012-006 _Product name_ life cycle plan and report_YYYY_nnn
        • T-012-007 Formative evaluation plan_YYYY_nnn
        • T-012-008 Formative evaluation report_YYYY_nnn
        • T-012-009 Validation and testing of machine learning models_YYYY_nnn
        • T-012-010 Device backup verification_YYYY_nnn
        • T-012-012 Customers product version control_YYYY_nnn
        • T-012-013 Design stage review
        • T-012-014 Summative evaluation plan_YYYY_nnn
        • T-012-015 Summative evaluation report YYYY_nnn
        • T-012-016 Software usability test guide
        • T-012-017 Integration test review
        • T-012-019 SOUP
        • T-012-020 Predetermined Change Control Plan
        • T-012-021 Product Design Phase 1 Checklist
        • T-012-022 Software Design Phase 2 Checklist
        • T-012-023 Software Development Plan
        • T-012-024 Software Candidate Release Phase 3 Checklist
        • T-012-025 Software Verification Phase 4 Checklist
        • T-012-026 Product Validation Phase 5 Checklist
        • T-012-028 Software Requirement Specification
        • T-012-029 Software Architecture Description
        • T-012-030 Software Configuration Management Plan
        • T-012-031 Product Requirements Specification
        • T-012-033 Software Tests Plan
        • T-012-034 Software Test Description
        • T-012-035 Software Test Run
        • T-012-037 Labeling and IFU Requirements
        • T-012-038 Verified Version Release
        • T-012-039 Validated Version Transfer
        • T-012-040 Documentation level FDA
        • T-012-041 Software Classification 62304
        • T-012-042 Regulatory Requirement
        • T-012-043 Traceability Matrix
      • GP-012 [Old version] Design, Redesign and Development
      • Specific procedures
    • 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
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity Risk Management
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery And Comissioning
    • 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
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Public tenders
  • Procedures
  • GP-012 Design, redesign and development
  • Templates
  • T-012-025 Software Verification Phase 4 Checklist

T-012-025 Software Verification Phase 4 Checklist

Actors​

NameTitleMeaningApproved Date & Time

Change history​

RevisionSummaryDate

Process overview​

The purpose of the Software Design Checklist review is to ensure the outputs of Phase 4 satisfy the criteria listed in the next section.

Project information​

  • Project title:
  • Project manager (name and function):

Planning​

PhaseObjectDone
Phase 1 Product Design ReviewEstablish input data
Phase 2 Software Design ReviewSRs, Architectural Design and UI Prototypes
Phase 3 Software Candidate ReleaseCoding, integration and test plan
Phase 4 Software Verification ReviewSoftware version verified and residual anomalies
Phase 5 Product Validation ReviewValidation activities, Technical Documentation and DHF

Previous reserves​

Instructions

If there were any reserves or outstanding issues identified during Phase 2, list them here. Include a brief description of each reserve, the actions required to address them, and assign an owner and targeted completion date. See T-012-024 Software Candidate Release Phase 3 Checklist for an example.

N°Documents / Purpose / Actions to implementOwnerTargeted DateSatisfying

Review according to 62304​

Verification​

ObjectRecords & CommentsSatisfyingReserves
5.5.2 EN 62304. The strategies, methods and procedures for verifying each SOFTWARE UNIT are documented [Class B, C]
5.5.3 EN 62304. The acceptance criteria for SOFTWARE UNITS before integration into SOFTWARE ELEMENTS are documented [Classes B, C]
5.5.4 EN 62304. Additional acceptance criteria for SOFTWARE UNITS are documented [Class C]
5.5.5 EN 62304. SOFTWARE UNIT VERIFICATION results are documented [Class B, C]

Software integration and integration testing​

ObjectRecords & CommentsSatisfyingReserves
5.6.1 EN 62304. The SOFTWARE UNITS are integrated in accordance with the integration plan. [Class B, C]
5.6.2 EN 62304. Integration verification is documented [Class B, C]
5.6.3 - 5.6.4 EN 62304. Testing of integrated SOFTWARE ELEMENTS is documented [Class B, C]
5.6.5 EN 62304. The integration testing procedures were evaluated to ensure their validity. [Class B, C]
5.6.6 - 5.6.7 EN 62304. Appropriate REGRESSION TESTS have been performed and documented to demonstrate that defects have not been introduced into previously integrated software [Class B, C]
5.6.8 EN 62304. ANOMALIES detected during software integration and integration testing are integrated into the software problem resolution PROCESS [Class B, C]

Software system testing​

ObjectRecords & CommentsSatisfyingReserves
5.7.1, 5.7.4 et 5.7.5 EN 62304. Carrying out and documenting a set of tests expressed in input stimuli, expected results, pass/fail criteria and SOFTWARE SYSTEM test execution procedures [Class B, C]
5.7.2 EN 62304. ANOMALIES detected during SOFTWARE SYSTEM testing are incorporated into the software problem resolution PROCESS [Class B, C]
5.7.3 EN 62304. When modifications are made during testing of the SOFTWARE SYSTEM [Class B, C]

Distribution of the software​

ObjectRecords & CommentsSatisfyingReserves
5.8.1 EN 62304. The software VERIFICATION has been completed and the results have been evaluated. [Class B, C]
5.8.2 EN 62304. All known residual ANOMALIES are documented [Class B, C]
5.8.3 EN 62304. All known residual ANOMALIES have been evaluated to ensure that they do not contribute to unacceptable RISK. [Class B, C]
5.8.4 EN 62304. The VERSION of the SOFTWARE PRODUCT that is released is documented [Class A, B, C]
5.8.5 - 5.8.8 EN 62304. The procedure and environment used to create the released software and delivery to the point of use without corruption or unauthorized change is documented. [Class B, C]
5.8.6 EN 62304. All ACTIVITIES and TASKS are completely completed and associated documentation is complete. [Classes B, C]

Design history file​

ObjectRecords & CommentsSatisfyingReserves
DHF updated. Available index and updated computer directories

Review according to IEC 81001​

Verification​

ObjectRecords & CommentsSatisfyingReserves
5.5.2 EN 81001. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that implementation reviews are performed for identifying, characterizing and feeding into the problem resolution PROCESS all SECURITY-related issues associated with the implementation of the secure design

Software integration testing​

ObjectRecords & CommentsSatisfyingReserves
5.6 EN 81001. The MANUFACTURER can perform some of the software system testing as a part of software integration testing

Software system testing​

ObjectRecords & CommentsSatisfyingReserves
5.7.1 EN 81001 SECURITY requirements testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that the HEALTH SOFTWARE SECURITY functions meet the SECURITY requirements and that the HEALTH SOFTWARE handles error scenarios and invalid input.
5.7.2 EN 81001 THREAT mitigation testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for testing the effectiveness of the mitigation for the THREATS identified and assessed in the THREAT MODEL.
5.7.3 EN 81001 VULNERABILITY testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for performing tests that focus on identifying and characterizing potential SECURITY VULNERABILITIES in the HEALTH SOFTWARE.
5.7.4 EN 81001 Penetration testing. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to identify and characterize WEAKNESSES via tests that focus on discovering and exploiting SECURITY VULNERABILITIES in the HEALTH SOFTWARE.
5.7.4 EN 81001 Managing conflicts of interest between testers and developers. The MANUFACTURER shall document means of ensuring objectivity of the test effort for the security requirements, threat mitigation, vulnerability and penetration testing.

Residual anomalies​

List here all residual anomalies detected during verification and their risk analysis

KeySummaryRisk assessment & control measureAcceptability

Reserves​

N°Documents / Purpose / Actions to implementOwnerTargeted Date

Conclusion​

Instructions
  • Begin with a brief summary of the review outcome, stating that the cited data is available, complete, and relevant.
  • Indicate clearly whether the milestone is confirmed or if any reservations prevent moving to the next phase.
  • If applicable, mention how the identified reservations will be addressed (e.g., "in a new release").
  • Explicitly confirm whether a risk analysis has been conducted on residual anomalies and whether they are acceptable.
  • Answer clearly: "Regarding the mentioned reserves, has the review been accepted?" — use “Yes” or “No”.
  • Use a formal, neutral, and conclusive tone throughout.
Previous
T-012-024 Software Candidate Release Phase 3 Checklist
Next
T-012-026 Product Validation Phase 5 Checklist
  • Actors
  • Change history
  • Process overview
  • Project information
  • Planning
  • Previous reserves
  • Review according to 62304
    • Verification
    • Software integration and integration testing
    • Software system testing
    • Distribution of the software
    • Design history file
  • Review according to IEC 81001
    • Verification
    • Software integration testing
    • Software system testing
  • Residual anomalies
  • Reserves
  • Conclusion
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.)