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-022 Software Design Phase 2 Checklist

T-012-022 Software Design Phase 2 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 2 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 1, 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 Product Design Phase 1 Checklist for an example.

N°Documents / Purpose / Actions to implementOwnerTargeted DateSatisfying

Review according to ISO 13485 section 7.3.3​

Product design​

ObjectRecords & CommentsSatisfyingReserves
Review of product design inputs
Main functions, Target Patient Population, Principle of operation, Intended conditions of use

Validation​

ObjectRecords & CommentsSatisfyingReserves
Validation protocol (including usability)
Analysis of clinical data needs and possible clinical investigations. Application of EN ISO 14155-1:2003

Marketing​

ObjectRecords & CommentsSatisfyingReserves
Market analysis : positioning/competing products/targeted markets

Regulatory​

ObjectRecords & CommentsSatisfyingReserves
Regulatory and Normative Plan
Software classification

Risk management​

ObjectRecords & CommentsSatisfyingReserves
Preliminary Risk Plan and Analysis
Initial Risk Management Report

Cybersecurity​

ObjectRecords & CommentsSatisfyingReserves
Cybersecurity risk plan

AI/ML Development​

ObjectRecords & CommentsSatisfyingReserves
AI/ML Development plan

Review according to EN 62304​

Planning (Class A, B, C)​

ObjectRecords & CommentsSatisfyingReserves
4.3 EN 62304. The class of the software is identified
5.1 EN 62304. Software Development Plan (Class A, B, C)
5.1.9 EN 62304. Method for documented configuration management (Class A, B, C)

Technical specification​

ObjectRecords & CommentsSatisfyingReserves
5.2 EN 62304. Technical specifications of the Medical Device Software (SRS) (Class A, B, C)
5.2.3 EN 62304. The requirements include RISK CONTROL measures implemented in the software to take into account hardware failures and possible software defects, depending on the MEDICAL DEVICE. (Class B, C)
Are they complete ?
Are they understandable ?
Are they traceable with Safety Risks and Product Requirements ?
Are they testable ? Can test criteria and performance of tests be determined ?
Are they uniquely identified ?
Do they include user interface related software requirements ?
Do they include cybersecurity related software requirements and traceable with Security Risks ?

Software verification planning​

ObjectRecords & CommentsSatisfyingReserves
5.1.6 EN 62304. Planning the software verification (Class B, C)

Architecture​

ObjectRecords & CommentsSatisfyingReserves
5.3.1 EN 62304. SRs have been transformed into a documented ARCHITECTURE (Class B, C)
5.3.2 EN 62304 ARCHITECTURE for the interfaces between the SOFTWARE ELEMENTS and external components external, as well as between the SOFTWARE ELEMENTS themselves. (Class B, C)
5.3.3 EN 62304 Specification of functional and performance requirements for SOUP SOFTWARE ELEMENTS (Class B, C)
5.3.4 EN 62304 Specification of SYSTEM hardware and software required for the SOUP SOFTWARE ELEMENT (Class B, C)
5.3.5 EN 62304 Identification of separations necessary for RISK CONTROL (Class C)
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Consistency of the architecture?
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Verify that the software architecture allows the implementation of SRS?
5.3.6 EN 62304 Checking the software ARCHITECTURE (Class B, C). Feasibility of use and maintenance of the system?
7.1.1 EN 62304 SOFTWARE ELEMENTS which could contribute to a dangerous situation are identified (See ISO 14971) (Class B, C)
7.1.2 - 7.1.5 EN 62304. Software Risk Analysis – Identification of potential causes / EVALUATION of published lists of SOUP ANOMALIES / Logging of potential causes / Logging of sequences of events (Class B, C)
7.2 EN 62304. RISK CONTROL measures for each potential cause of the SOFTWARE ELEMENT contributing to a dangerous situation are documented in the RISK MANAGEMENT FILE. (Class B, C)

Detailed conception​

ObjectRecords & CommentsSatisfyingReserves
5.4.1 EN 62304. The software ARCHITECTURE is broken down until it is represented by the SOFTWARE UNITS. (Class B, C)
5.4.2 EN 62304. Detailed design of each SOFTWARE UNIT of the SOFTWARE ITEM. (Class C)
5.4.3 EN 62304. Detailed design of possible interfaces between the SOFTWARE UNIT and external components (hardware and software), as well as for interfaces between SOFTWARE UNITS. (Class C)

Design history file​

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

Review according to IEC 81001​

Planning​

ObjectRecords & CommentsSatisfyingReserves
4.2 EN 81001-5. The MANUFACTURER shall establish a PROCESS for managing RISKS associated with SECURITY.
5.1.2 EN 81001-5. The MANUFACTURER shall establish risk-based procedural and technical controls for protecting the IT infrastructure used for development, production delivery and maintenance from unauthorized access, corruption and deletion.
5.1.3 EN 81001-5. The MANUFACTURER shall establish and maintain secure coding standards consistent with current best practices related to the design and implementation of secure software systems.

Software requirements analysis​

ObjectRecords & CommentsSatisfyingReserves
5.2.1 EN 81001-5. SECURITY requirements are documented for the HEALTH SOFTWARE including requirements for SECURITY CAPABILITIES related to installation, operation, maintenance and decommissioning.
5.2.3 EN 81001-5. The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) that identifies and manages the SECURITY risks of all REQUIRED SOFTWARE.

Software architectural design​

ObjectRecords & CommentsSatisfyingReserves
5.3.1 EN 81001-5. Specify a secure ARCHITECTURE
5.3.2 EN 81001-5. Identify, enforce and maintain secure design practices. Document secure design best practices.
5.3.3 EN 81001-5. Document and implement the architectural design review

Software design​

ObjectRecords & CommentsSatisfyingReserves
5.4.1 EN 81001-5. Develop and document a secure HEALTH SOFTWARE design and maintain the use of best practices for the secure design.
5.4.2 EN 81001-5. Include measures to address the THREATS identified in the THREAT MODEL.
5.4.3 EN 81001-5. Identify and characterize each interface of the HEALTH SOFTWARE including physical and logical interfaces.
5.4.4 EN 81001-5. Conduct design reviews to identify, characterize and track to closure WEAKNESSES associated with each significant revision of the secure design.

Reserves​

N°Documents / Purpose / Actions to implementOwnerTargeted Date

Conclusion​

Instructions

Summarize the outcome of the Software Design Phase 2 review. This section should:

  • State whether the reviewed output data is considered available, complete, and relevant.
  • Confirm whether the phase milestone can be validated.
  • Indicate clearly if any reserves have been raised and whether they affect the approval of the review.
  • Include a direct statement on whether the review has been accepted, even in the presence of minor reserves.

Keep the wording concise, objective, and aligned with the overall project assessment.

Previous
T-012-021 Product Design Phase 1 Checklist
Next
T-012-023 Software Development Plan
  • Actors
  • Change history
  • Process overview
  • Project information
  • Planning
  • Previous reserves
  • Review according to ISO 13485 section 7.3.3
    • Product design
    • Validation
    • Marketing
    • Regulatory
    • Risk management
    • Cybersecurity
    • AI/ML Development
  • Review according to EN 62304
    • Planning (Class A, B, C)
    • Technical specification
    • Software verification planning
    • Architecture
    • Detailed conception
    • Design history file
  • Review according to IEC 81001
    • Planning
    • Software requirements analysis
    • Software architectural design
    • Software design
  • 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.)