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