Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.1.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
          • software-design-specification
          • software-requirement-specification
          • user-requirement-specification
        • Test plans
        • Test runs
        • Review meetings
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.1.0.0
  • Requirements
  • REQ_012 Users can easily integrate the device into their system

REQ_012 Users can easily integrate the device into their system

Category​

Minor

Source​

  • Victor Li, Board Member, CIO

USER REGULATORY FUNCTIONAL AND CAPACITY INTERFACES INSTALLATION OPERATION AND MAINTENANCE NETWORK USER MAINTENANCE

Activities generated​

  • MDS-461
  • Following our GP-001 Documents and records control we validate the documentation created as a result of this requirement implementation and compile the evidence within the R-TF-001-006 IFU and label validation_2023_001

Causes failure modes​

  • The device's API might not be compatible with the users' existing systems or require significant modifications to work.
  • The integration process might be too complex or time-consuming, requiring extensive configuration and setup.
  • Poor or insufficient documentation makes it difficult for users to understand how to integrate the device.
  • Users do not have access to adequate technical support during the integration process.
  • Integration with the device introduces significant latency, affecting the performance of users' systems.
  • The integration process introduces security vulnerabilities into users' systems.
  • Users cannot easily customize the device's settings to fit their specific needs.
  • Users find it difficult to scale the integration as their needs grow (e.g., handling more data or users).
  • Frequent updates to the device's API that are not backward compatible, requiring repeated integration efforts.

Related risks​

    1. The endpoints of the device are not compatible with the user's software
    1. Incompatibility in classification systems: the name or code of the ICD category of the medical device do not match the ones used by the care provider's software
    1. Unauthorized patient access to clinical data: the patient somehow manages to get access to the clinical endpoints of the device
    1. Inaccessible skin areas: the patient can't capture the affected skin area inside the picture
    1. HCPs who lack specific training use the medical device
    1. The device is not used under the supervision of an HCP
    1. The device is integrated by untrained technicians
    1. Non-compliance with GSPR 3 (absence of a risk management process)
    1. Instructions for use not available or separate from the product
    1. Inadequate specification of the product accessories
    1. Non-compliance with GSPR 3 (absence of a PMS & PMCF process)
    1. Inadequate instructions for use: product information for clinical safety is not included at the IFU
    1. Inadequate instructions for use: product information for cyber security is not included at the IFU
    1. System incompatibility: integration of our device is not compatible with the user platform
    1. Integration failure or errors: the user lacks the knowledge required to integrate the product in their system
    1. Incorrect interpretation or override of device outputs: the HCP validates the wrong skin condition, even if the device outputs the correct result
    1. Non-compliance with GSPR 23: Inadequate labeling - labeling cannot be included within the device due to its nature
    1. Non-compliance with GSPR 23: Inadequate Instructions for Use
    1. Complicated instructions for use: the instructions for use are too complicated and more intricate than they need to be
    1. Inadequate warning of adverse effects
    1. Maintenance is inadequate to the planned functions
    1. Inadequate or absent maintenance specifications, including performance checks
    1. Inadequate maintenance: users do not properly maintain the device
    1. Absence of limitation of product lifetime
    1. Design and development input requirements are not defined (user, technical and/or regulatory)
    1. Instructions for use are not available at the time of use due to downtime
    1. Electronic instructions for use are not compatible with different devices
    1. Lack of version control or traceability: the HCP cannot identify the version of the device being used
    1. SOUP presents an anomaly that makes it incompatible with other SOUPs or with software elements of the device
    1. SOUP is not being maintained nor regularly patched
    1. SOUP presents cybersecurity vulnerabilities
    1. Insufficient knowledge to display electronic IFU
    1. Electronic IFU are tampered
    1. Electronic IFU and their paper copies are unavailable

User Requirement, Software Requirement Specification, Design Requirement and Regulatory Requirement​

  • User Requirement 12.1: Users should find it straightforward to integrate the device into their existing systems.
  • Software Requirement Specification 12.2: The device should be designed and documented in such a way that facilitates straightforward integration into various systems, with comprehensive documentation.
  • Design Requirement 12.3: Ensure the device design adheres to RESTful principles and industry best practices, providing clear endpoint documentation and example requests/responses.
  • Regulatory Requirement 12.4: The device shall be designed and developed to be compliant with all the applicable general safety and performance requirements set out in MDR 2017/745, Annex I.

Description​

Legit.Health Plus has been thoughtfully designed with users in mind, making it easy to use and ensuring a smooth experience. To make sure our users can get the most out of our device, it's crucial that we provide clear and complete instructions on how to operate it, and the proper label of the device in compliance with MDR 2017/745 regulation.

In light of this importance, we are dedicated to creating a comprehensive user manual for our medical device. This manual will include a step-by-step guide on how to effectively use the device, helping users seamlessly integrate it into their healthcare routines.

The documentation will cover various aspects, such as the specific functions (endpoints) of the device, the types of information it needs (body requests), the format and content required for each data field, and how to understand and make sense of the device's responses. This way, users will have all the information they need to utilize the device to its fullest potential.

Due to the nature of the device, the IFU should be electronic to guarantee the users always access to the last version of them.

The IFU content and versions are managed and stored using Git. The IFU content can be edited only by using signed commits with GPG Keys. Implementation of branch structure with approvals for merging changes and automated verification of code correctness and lack of bugs or errors before merge, secure stage of environment variables in Git repository, implementation of redundant backups, both in Git repository and deployment server, implementation of a robust authentication systems for administrative access and a role-based access control (RBAC) framework for delineating user permissions are other control measures implemented.

Additionally, we include within the device outputs not only the version of the device, but also the label information required by the regulation, with the eIFU URL to guarantee users can access and view the device IFU and the more detailed label and to comply with GSPR 23.1(a) and (b).

We also have in place the internal procedure SP-001-001 eIFU management in which we explain how customers can request paper IFU and which is the process to follow when we receive such requests (including responsibilities).

Success metrics​

GoalMetric
To create the device IFU and label in compliance with the all the established requirements.IFU and label validation is successful
GSPR are reviewed and we comply with requirements
Usability validation is successful

Previous related requirements​

  • REQ_005
  • REQ_006
  • REQ_007

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: JD-004, JD-005, JD-009, JD-017
  • Approver: JD-003
Previous
REQ_011 The user specifies the body site of the skin structure
Next
REQ_013 The user receives the pixel coordinates of possible ICD categories
  • Category
  • Source
  • Activities generated
  • Causes failure modes
  • Related risks
  • User Requirement, Software Requirement Specification, Design Requirement and Regulatory Requirement
  • Description
  • Success metrics
  • Previous related requirements
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.)