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 Software Development Procedure
      • 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-027 Version delivery description
        • 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-036 Software development plan
        • 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
      • GP-012 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
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • 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
  • Procedures
  • GP-012 Software Development Procedure
  • Templates
  • T-012-041 Software Classification 62304

T-012-041 Software Classification 62304

Change history​

RevisionSummaryDate

Class Definition​

Instructions

Explain the classification of the software based on the potential severity of harm it may cause.

  • Determine if the software falls under Class A, B, or C following IEC 62304.
  • Justify the classification by referencing the risk evaluation and the residual risk after applying external mitigation measures.
  • Use the definitions for Class A (no injury), Class B (non-serious injury), and Class C (serious injury or death).

Priority of Software Risk Control Options​

Instructions

List and describe the order of priority for implementing software risk control measures.

  • Follow the required order:
    1. Design changes.
    2. Adding alerts or error messages.
    3. Organizational procedures.
    4. User warnings or recommendations.
  • Provide examples for each if applicable, and explain the rationale behind the prioritization.

Software Maintenance​

Instructions

Detail how risks are managed once the product design is completed.

  • Explain how new risks or information are assessed and how the risk analysis is updated.
  • Describe what happens if the product design changes.
  • Reference documentation used for recording these actions, e.g.:
    • Product Requirements Verification Checklist
    • Software Requirements Verification Checklist
    • Software Architecture Verification Checklist

Information Provided to the User​

Instructions for Use​

Instructions

Indicate what documents (e.g. IFU) are provided to the user to ensure proper usage of the PRODUCT.

  • Include the title, version number, and delivery format.
  • Make sure the information matches the actual documentation distributed.

Labeling​

Instructions

Describe all warnings, precautions, and labeling content that the user must be aware of.

  • Reference where this information is found (e.g. IFU).
  • Ensure compliance with applicable labeling regulations.

Information Provided Only in Electronic Format​

Instructions

Explain what information is only provided electronically.

  • Mention compliance with Regulation 2021/2226.
  • Specify how users can request a paper copy and the timeframe (e.g. within 5 calendar days).

Software Classification​

QuestionAnswer
Can a hazardous situation arise from a failure of the software?Yes (answer to next question). No (Class A)
After taking into consideration the risk control measures external to this software system (separate redundant and technologically different hardware or software system), does failure of the software result in an unacceptable risk?Yes, (answer to next question). No (Class A)
What severity of injury (worst case) that can result from this hazardous situation, is possible?Serious injury or death / Moderate injury
Instructions

Replace the placeholder text with a detailed explanation of the documentation level for the PRODUCT based on the answers to the questions above. This should include:

Considering the description Device Description, the intended use and end users, the environment of use, the answers to questions in Annex A of ISO 24971, the risks identified in the risk management file (Risk Analysis), the software requirements (T-012-028 Software Requirement Specification), the answers to questions of IEC/TR 80002-1, and the answer to above questions the classification of PRODUCT against IEC 62304:2006/A1:2015 is: Class A, B or C.

Security Class Rationale​

Most Critical Risks​

Instructions

Detail the most critical risks and their post-mitigation severity.

ID RiskClass Before RMMExternal RMMRisk acceptability after external RMMSeverity after external RMMFinal class

Software and Items Class​

Item ID#Risk ID€Risk acceptability after external RMMSeverity after external RMMClass & justification if applicable
ITSW-xxxRISK-009InnaceptableMajeurC

Justification of the Effectiveness of Segregation (Class C)​

Segregation ID#ItemsTest method
S1ITSW-xx1Verification by inspection of the segregation of Item in the SAD and in the code. See Test XXX of doc XXX
Previous
T-012-040 Documentation level FDA
Next
T-012-042 Regulatory Requirement
  • Change history
  • Class Definition
  • Priority of Software Risk Control Options
  • Software Maintenance
  • Information Provided to the User
    • Instructions for Use
    • Labeling
    • Information Provided Only in Electronic Format
  • Software Classification
    • Security Class Rationale
      • Most Critical Risks
      • Software and Items Class
      • Justification of the Effectiveness of Segregation (Class C)
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.)