Phase 1: Product Design Review
Process Overview
The purpose of the Product Design review (Phase 1) is to ensure that the outputs of Product Design satisfy the criteria required to move forward to Phase 2 (Software Design). This review validates that the product concept, intended use, and high-level requirements are clearly defined and ready for technical implementation.
According to GP-012, Phase 1 establishes the foundation for all subsequent development phases.
General Information
| 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 792790 |
| 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 Information
- Project title: Legit.Health Plus Version 1.1.0.0
- Project manager: JD-003 (Design & Development Manager)
- Review date: 2025-11-10
- Reviewers: JD-001 (General Manager), JD-003 (Design & Development Manager), JD-007 (Technical Manager), JD-004 (Quality Manager & PRRC)
Context of Initialization
This project was initiated to develop Legit.Health Plus Version 1.1.0.0, a medical device software designed for dermatological diagnosis and disease tracking. The device addresses the medical need for objective, consistent, and scalable assessment of skin conditions using AI/ML-powered image analysis.
Key technological elements include:
- Machine learning models for skin condition recognition
- Image processing and analysis
- User interface for clinicians
- Integration with healthcare systems
This is an evolution of previous versions, incorporating regulatory compliance improvements and enhanced functionality for EU MDR and FDA requirements.
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 |
Product Design Checklist
Device Description and Intended Use
| Item | Status | Reference |
|---|---|---|
| Description of the Intended Use | ✓ | R-TF Device Description and Specification |
| Device Description (operating principles, core functions) | ✓ | R-TF Device Description and Specification |
| STED (Summary of Technical Documentation) | ✓ | R-TF Summary of Technical Documentation (STED) |
Product Requirements
| Item | Status | Reference | Comments |
|---|---|---|---|
| List of product requirements documented | ✓ | R-TF-012-031 Product Requirements Specification | Product Requirements (PRs) are defined and documented |
| Requirements are complete | ✓ | All stakeholder needs addressed | |
| Requirements are understandable | ✓ | Clear language, no ambiguity | |
| Requirements are consistent | ✓ | No contradictions between requirements | |
| Requirements are feasible | ✓ | Technically and commercially viable | |
| Requirements do not contradict one another | ✓ | Internal consistency verified | |
| Requirements are uniquely identified | ✓ | Each requirement has unique identifier | |
| Requirements are traceable to intended use | ✓ | Traceability maintained throughout |
Medical Device Classification
| Item | Status | Value | Reference |
|---|---|---|---|
| Device meets definition of medical device | ✓ | Yes | R-TF Device Description and Specification |
| Estimated medical device class (EU MDR) | ✓ | Class IIb | R-TF Device Description and Specification |
| Estimated medical device class (FDA) | ✓ | Class II | R-TF-012-040 Documentation level FDA |
| Estimated software class (IEC 62304) | ✓ | Class B | R-TF-012-041 Software Classification 62304 |
| Estimated software class (FDA) | ✓ | Level of Concern: Moderate | R-TF-012-040 Documentation level FDA |
Stakeholder Requirements Analysis
According to IEC 62304 and MDR 2017/745, product requirements must address all stakeholder needs. The following stakeholders have been identified and their requirements captured:
Internal Stakeholders (Company)
| Stakeholder | Category | Engagement Status | Requirements Contribution |
|---|---|---|---|
| JD-001 (General Manager) | Business | ✓ | Business strategy and market requirements |
| JD-003 (Design & Development Mgr) | Regulatory | ✓ | Regulatory requirements and product requirements definition |
| JD-007 (Technical Manager) | Technical | ✓ | Technical feasibility and high-level architecture |
| JD-004 (Quality Manager & PRRC) | Quality | ✓ | Quality requirements and compliance verification |
| JD-018 (Clinical Affairs) | Clinical | ✓ | Clinical needs and clinical evidence requirements |
External Stakeholders (Users, Patients, Regulatory, Market)
| Stakeholder Type | Category | Engagement Status | Requirements Contribution |
|---|---|---|---|
| Primary Users (Clinicians) | End User | ✓ | Usability requirements, clinical workflow needs, interface requirements |
| Patients | Patient | ✓ | Safety requirements, data privacy, patient-centric outcomes |
| Regulatory Bodies (EU, FDA) | Regulatory | ✓ | Compliance requirements (MDR, FDA 510(k)), safety standards |
| Target Markets (EU/EEA, USA) | Market | ✓ | Regional requirements, language, local regulations |
| Healthcare Institutions | Customer | ✓ | Integration requirements, technical specifications |
| Notified Body | Regulatory | ✓ | Technical documentation requirements, conformity assessment |
Stakeholder Requirements Coverage:
- ✓ User needs captured through usability studies and clinical feedback
- ✓ Patient safety requirements incorporated through risk management
- ✓ Regulatory requirements identified for EU MDR (Class IIb) and FDA (Class II)
- ✓ Market-specific requirements analyzed for target regions
- ✓ Clinical requirements validated by clinical affairs team
- ✓ Business and company requirements aligned with product strategy
Documentation Completeness
| Document | Status | Reference |
|---|---|---|
| Device Description and Specifications | ✓ | R-TF Device Description and Specification |
| STED | ✓ | R-TF Summary of Technical Documentation (STED) |
| Product Requirements (within SDP) | ✓ | R-TF-012-031 Product Requirements Specification |
Reserves and Pending Actions
| N° | Issue / Action Required | Owner | Targeted Date | Status |
|---|---|---|---|---|
| - | No reserves identified at this phase | - | - | - |
Conclusion
Review Outcome: The Phase 1 Product Design review has been successfully completed.
Assessment:
- All design inputs and outputs are complete, available, and relevant
- The device description and intended use are clearly documented
- Product requirements are comprehensive, traceable, and feasible
- Medical device and software classifications have been determined
- All stakeholders have been engaged and provided input
Decision: The project is approved to proceed to Phase 2: Software Design.
Next Steps:
- Initiate Software Design activities as defined in GP-012
- Begin development of Software Requirements Specification (SRS)
- Establish software architecture and design documents
- Initiate parallel procedures: Risk Management, Clinical Evaluation, Cybersecurity, AI/ML Development, and Usability
Approved by:
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