R-TF-012-022 Software Design Phase 2 Checklist
Process Overview
The purpose of the Software Design review (Phase 2) is to ensure that all outputs of the Software Design phase satisfy the criteria required to proceed to Phase 3 (Software Development). This review validates that software requirements, architecture, test plans, and related procedural documents are complete and ready for implementation.
According to GP-012, Phase 2 establishes the input data for development and initiates parallel procedures for risk management, clinical evaluation, cybersecurity, AI/ML development, and usability.
| Information |
|---|
| Device name | Legit.Health Plus (hereinafter, the device) |
| Model and type | NA |
| Version | 1.1.0.0 |
| Basic UDI-DI | 8437025550LegitCADx6X |
| Certificate number (if available) | MDR 000000 (Pending) |
| EMDN code(s) | Z12040192 (General medicine diagnosis and monitoring instruments - Medical device software) |
| GMDN code | 65975 |
| EU MDR 2017/745 | Class IIb |
| EU MDR Classification rule | Rule 11 |
| Novel product (True/False) | TRUE |
| Novel related clinical procedure (True/False) | TRUE |
| SRN | ES-MF-000025345 |
- Project title: Legit.Health Plus Version 1.1.0.0
- Project manager: JD-007 (Technical Manager)
- Review date: 2025-12-01
- Reviewers: JD-001 (General Manager), JD-003 (Design & Development Manager), JD-007 (Technical Manager), JD-004 (Quality Manager & PRRC)
Planning
| Phase | Object | Done |
|---|
| Phase 1 Product Design Review | Establish input data | ✓ |
| Phase 2 Software Design Review | SRs, Architectural Design and UI Prototypes | ✓ |
| Phase 3 Software Development | Coding, integration and test plan | |
| Phase 4 Software Verification Review | Software version verified and residual anomalies | |
| Phase 5 Product Validation Review | Validation activities, Technical Documentation and DHF | |
Previous Reserves
All reserves from Phase 1 have been addressed and closed.
| N° | Issue from Phase 1 | Resolution | Status |
|---|
| - | No reserves | - | - |
Software Design Outputs Checklist
Software Planning and Specification Documents
| Document | Status | Reference | Comments |
|---|
| Software Development Plan | ✓ | R-TF-012-023 Software Development Plan | Complete, includes methodology and planning |
| Software Requirements Specification (SRS) | ✓ | R-TF-012-028 Software Requirement Specification | All SRS documented and traceable to PRs |
| Software Architecture Description | ✓ | R-TF-012-029 Software Architecture Description | Architecture defined with component interfaces |
| Software Configuration Management Plan | ✓ | R-TF-012-030 Software Configuration Management Plan | Version control and branching strategy defined |
| Software Test Plan | ✓ | R-TF-012-033 Software Test Plan | Test strategy and test cases defined |
| Software Test Description | ✓ | R-TF-012-034 Software Test Description | Detailed test procedures documented |
| Traceability Matrix (draft) | ✓ | R-TF-012-043 Traceability Matrix | PR → SRS → Test Cases traceability established |
| SOUP Components List | ✓ | R-TF-012-019 SOUPs | All SOUP components identified and assessed |
Software Requirements Quality
| Criterion | Status | Comments |
|---|
| Requirements are complete | ✓ | All functional and non-functional requirements documented |
| Requirements are understandable | ✓ | Clear, unambiguous language used |
| Requirements are traceable to Product Requirements | ✓ | Traceability matrix established (PR → SRS) |
| Requirements are testable | ✓ | Test criteria defined for each requirement |
| Requirements are uniquely identified | ✓ | Each SRS has unique identifier (GitHub Issues) |
| Requirements include user interface requirements | ✓ | UI/UX requirements documented |
| Requirements include cybersecurity requirements | ✓ | Security requirements traceable to Security Risks |
| Requirements include risk control measures | ✓ | Safety risk controls implemented in software documented |
Parallel Procedures Initiated (Other Procedures Kickoff)
According to GP-012, Phase 2 initiates parallel procedures. Important: AI/ML Development (GP-028) is unique in that it must be fully completed during Phase 2, unlike other procedures that continue through subsequent phases. This ensures the software development team receives complete, validated AI/ML components for integration in Phase 3.
| Procedure | Plan Document | Status | Responsible | Completion Phase |
|---|
| Risk Management (GP-013) | R-TF-013-001 Risk Management Plan | ✓ | JD-003, JD-004 | Phase 5 |
| Risk Management Record | R-TF-013-002 Risk Management Record | ✓ | JD-003, JD-004 | Phase 5 |
| Clinical Evaluation (GP-015) | R-TF-015-008 Clinical Evaluation Plan | ✓ | JD-018 | Phase 5 |
| Cybersecurity (GP-030) | R-TF-030-002 Cybersecurity Plan | ✓ | JD-007 | Phase 5 |
| Cybersecurity Risk Matrix | R-TF-030-003 Security Risk Matrix | ✓ | JD-007 | Phase 5 |
| Usability (GP-025) | R-TF-025-001 Usability plan | ✓ | JD-003 | Phase 5 |
AI/ML Development Complete Package (GP-028)
Critical: AI/ML development must be fully completed at the end of Phase 2, before Phase 3 begins. All AI/ML outputs, including algorithms, validation reports, and documentation, must be delivered to the software development team as a complete, verified package.
| Document | Status | Reference | Responsible | Comments |
|---|
| AI/ML Description | ✓ | R-TF-028-001 AI/ML Description | JD-017 | Algorithm specifications defined |
| AI/ML Development Plan | ✓ | R-TF-028-002 AI/ML Development Plan | JD-017 | Development methodology and resources planned |
| Data Collection | ✓ | R-TF-028-003 Data Collection Instructions | JD-017 | Data acquisition protocol complete |
| Data Annotation | ✓ | R-TF-028-004 Data Annotation Instructions | JD-017 | Annotation procedures complete |
| AI/ML Design Checks | ✓ | R-TF-028-009 AI/ML Design Checks | JD-017 | Design phase verification complete |
| AI/ML Development Report | ✓ | R-TF-028-005 AI/ML Development Report | JD-017 | Complete development and validation documentation |
| AI/ML Release Report | ✓ | R-TF-028-006 AI/ML Release Report | JD-017 | Integration specifications for software team |
| AI/ML V&V Checks | ✓ | R-TF-028-010 AI/ML V&V Checks | JD-017 | Verification and validation checklist complete |
| AI Risk Matrix | ✓ | R-TF-028-011 AI Risk Matrix | JD-017 | AI-specific risks identified and assessed |
| Algorithm Package | ✓ | SDK/Models ready for integration | JD-017 | Validated algorithms ready for software development team |
AI/ML Completion Confirmation:
- All AI/ML development activities complete ✓
- All algorithms validated and tested ✓
- Complete package delivered to software development team ✓
- Software team can begin Phase 3 integration ✓
Validation Plans
| Plan Document | Status | Reference | Responsible |
|---|
| Software Test Plan (Verification) | ✓ | R-TF-012-033 Software Test Plan | JD-007 |
| Usability Plan | ✓ | R-TF-025-001 Usability plan | JD-003 |
| Clinical Evaluation Plan | ✓ | R-TF-015-008 Clinical Evaluation Plan | JD-018 |
IEC 62304 Compliance Review
Planning (Class B Requirements)
| Requirement | Status | Evidence |
|---|
| 5.1 Software Development Plan established | ✓ | R-TF-012-023 Software Development Plan |
| 5.1.6 Software Verification planning | ✓ | R-TF-012-033 Software Test Plan |
| 5.1.9 Configuration Management documented | ✓ | R-TF-012-030 Software Configuration Management Plan |
Requirements Analysis (Class B)
| Requirement | Status | Evidence |
|---|
| 5.2 Software Requirements defined and documented | ✓ | R-TF-012-028 Software Requirement Specification |
| 5.2.3 Risk control measures in software | ✓ | R-TF-013-002 Risk Management Record |
| Requirements complete and verifiable | ✓ | All SRS are testable and traceable |
Architecture (Class B)
| Requirement | Status | Evidence |
|---|
| 5.3.1 Software Architecture documented | ✓ | R-TF-012-029 Software Architecture Description |
| 5.3.2 Interfaces between software elements | ✓ | Component interfaces defined in architecture |
| 5.3.3 SOUP functional/performance requirements specified | ✓ | R-TF-012-019 SOUPs |
| 5.3.4 SOUP hardware/software requirements | ✓ | SOUP prerequisites documented |
| 5.3.6 Architecture verification | ✓ | Architecture reviewed for consistency and feasibility |
Risk Management Integration (Class B)
| Requirement | Status | Evidence |
|---|
| 7.1.1 Hazardous software elements identified | ✓ | R-TF-013-002 Risk Management Record |
| 7.1.2-7.1.5 Software risk analysis performed | ✓ | Potential causes and sequences documented in Risk Management Record |
| 7.2 Risk control measures documented | ✓ | Controls traceable to SRS and implementation |
IEC 81001 (Cybersecurity) Compliance Review
| Requirement | Status | Evidence |
|---|
| Security requirements defined | ✓ | R-TF-030-003 Security Risk Matrix |
| Threat model established | ✓ | R-TF-030-002 Cybersecurity Plan |
| Security controls defined | ✓ | Security controls traceable to threats and SRS |
Design History File (DHF) Status
| Item | Status | Comments |
|---|
| DHF structure established | ✓ | All documentation organized and accessible |
| All Phase 2 outputs documented | ✓ | Complete documentation available |
| Document version control implemented | ✓ | Git-based version control active |
| Traceability established | ✓ | PR → SRS → Architecture → Test Cases |
Reserves and Pending Actions
| N° | Issue / Action Required | Owner | Targeted Date | Status |
|---|
| - | No reserves identified at this phase | - | - | - |
Conclusion
Review Outcome: The Phase 2 Software Design review has been successfully completed.
Assessment:
- All software design outputs are complete, available, and relevant
- Software Requirements Specification (SRS) is comprehensive, traceable, and testable
- Software architecture is well-defined with clear component interfaces
- All required plans (verification, risk management, clinical, cybersecurity, AI/ML, usability) have been established
- SOUP components have been identified and assessed
- IEC 62304 Class B requirements are satisfied
- IEC 81001 cybersecurity requirements are addressed
- Traceability from Product Requirements to Software Requirements is established
- Design History File is properly organized and up-to-date
Decision: The project is approved to proceed to Phase 3: Software Development.
Next Steps:
- Begin agile iterative development sprints
- Implement software according to SRS and architecture
- Continue parallel procedures (risk management, clinical, cybersecurity, AI/ML, usability)
- Maintain traceability throughout implementation
- Prepare for Phase 3 release candidate review
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 Design & Development Manager, JD-004 Quality Manager & Person Responsible for Regulatory Compliance (PRRC)
- Approver: JD-001 General Manager
ㅤ