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

Category

Major

Source

• Andy Aguilar, General Manager at Legit.Health
• Gerardo Fernández Moreno, Technology Manager

• INTERNAL SYSTEM INPUTS AND OUTPUTS
• DESIGN INTERFACES
• USER SAFETY INSTALLATION
• OPERATION AND MAINTENANCE
• REGULATORY FUNCTIONAL AND CAPACITY ARCHITECTURE

Activities generated

• MDS-252

Causes failure modes

• Interception of data during transmission (Man-in-the-Middle attacks) due to inadequate or insufficient encryption.
• Slow response times due to inefficient algorithms or overloaded servers.
• Requests timing out due to long processing times or server issues.
• Insufficient server resources leading to delays or failures in processing requests.
• Intermittent or unreliable network connections causing request failures.
• Incorrect implementation of access control, leading to unauthorized access or denial of service (DDoS attacks).
• Insufficient protections against brute force attacks (e.g., not implementing rate limiting and account lockout mechanisms), allowing attackers to guess passwords.
• Failure to generate or validate access tokens could prevent users from accessing the system.
• Failure to properly handle token expiration could lead to users being logged out unexpectedly or able to use expired tokens.
• Revoked or blacklisted tokens are still accepted, enabling previously authorized users to keep access even after their permissions have been revoked.
• An attacker forces the system to use a less secure algorithm for token verification, making it easier to forge tokens. If the API accepts tokens signed with weak algorithms, it becomes vulnerable to forgery.
• Failure to properly hash passwords before storage could leave plaintext passwords exposed.
• Inability to register new users if the user management service is not properly implemented.

Related risks

• 1. The endpoints of the device are not compatible with the user's software
• 11. Data transmission failure from care provider's system: the user can't send data to the device
• 12. Data input failure: the device can't receive data from the user
• 13. Data accessibility failure: the user can't receive data from the device
• 14. Data transmission failure: the device can't send data to the user
• 15. Interruption of service: users suddenly can't use the medical device due to downtime
• 16. An organisation that is not a licensed care provider gets access to the service
• 19. The device is integrated by untrained technicians
• 20. Non-compliance with the General Safety & Performance Requirements (GSPR)
• 22. Medical device input requirements are not defined to users for its proper operation
• 23. Instructions for use not available or separate from the product
• 24. Inadequate specification of the product's intended purpose
• 26. Data breach or unauthorized access: unauthorized persons have access to confidential data of the practitioners and patients
• 31. System incompatibility: integration of our device is not compatible with the user platform
• 33. Data overwrite: the data cannot be shown in a time-series that reflects the evolution
• 36. Integration failure or errors: the user lacks the knowledge required to integrate the product in their system
• 40. Device failure or performance degradation: the device is overwhelmed by its use: either not enough storage capacity or unable to handle requests

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

• User Requirement 5.1: Users shall be able to send secure and efficient requests to the device and receive outputs in a timely manner.
• Software Requirement Specification 5.2: The device shall be designed to handle multiple concurrent requests and respond with minimal latency, ensuring data privacy and integrity during transmission.
• Design Requirement 5.3: Design the device endpoints in a RESTful manner, ensuring straightforward access and response management, while implementing HTTPS for secure communication.
• Regulatory Requirement 5.4: The device shall be compliant with data privacy regulation (Regulation (EU) 2016/679 (General Data Protection Regulation)).
• Regulatory Requirement 5.5: The device shall be compliant with MDR 2017/745, Annex I, point 17.2, 17.4, 18.8, 23.4(ab).

To achieve them, we employ a multifaceted approach that integrates various elements to create a robust and versatile solution.

Description

Efficient and secure interaction with algorithms plays a pivotal role in the functioning of our medical device, ensuring both patient safety and user satisfaction. The requirements deriving from this reasoning are:

RESTful API implementation

One of the most effective methods for interacting with our algorithms is through the establishment of a Representational State Transfer (REST) API. This API acts as the bridge between the user interface and the underlying algorithms, facilitating data exchange. By adhering to REST principles, we ensure that our API is resourceful, stateless, and scalable, enabling it to efficiently handle requests while maintaining high performance.

Stringent security measures

Given the sensitive nature of medical data, the security of our system is paramount. To safeguard the integrity and confidentiality of patient information, we implement a comprehensive security protocol. This includes:

• Authentication and authorization: We employ robust authentication mechanisms such as OAuth 2.0 or JWT to ensure that only authorized users can access the API. Role-based access control further restricts user privileges, enhancing data security.
• Data encryption: All data transmitted between the user and the API is encrypted using industry-standard encryption protocols, such as SSL/TLS, to protect against eavesdropping and data breaches.

Minimized service downtime

To provide an uninterrupted service experience, we prioritize minimizing service downtime through the following strategies:

• High availability architecture: Our system is designed with redundancy and failover mechanisms to ensure uninterrupted service even in the event of hardware or software failures.

Other control measures

As part of the sales process, a contract between Legit.Health and customers shall be signed. The contract includes a clause in which the customer declares they are a healthcare provider.

Success metrics

Goal	Metric
User can interact with the device	Successful user interaction with the device via HTTP POST
User cannot interact with the device without a client key	Device only accepts calls with a registered key
High data encryption coverage	The percentage of encrypted data (both in transit and at rest) is over 85%
High uptime	The total time the service is available and operational is at least 99%. This translates to no more than 8.76 hours of downtime per year
Cyber attackers cannot compromise device security	The device is enough resilient to withstand and counteract simulated cyber attacks under penetration testing

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