Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • Legit.Health Plus Version 1.1.0.0
    • Index of Technical Documentation or Product File
    • Summary of Technical Documentation (STED)
    • Description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File
      • Requirements
        • User Requirement Specification (URS)
        • Software Requirement Specification (SRS)
          • SRS-001 The device handles user accounts through an internal user registration service
          • SRS-002 The REST API enforces HTTPS for all communications to ensure data security
          • SRS-003 The REST API implements rate limiting to prevent abuse
          • SRS-004 The REST API verifies the access token for every request to secure endpoints
          • SRS-005 Data exchanged with clinical endpoints of the API adhere to the FHIR standard
          • SRS-006 The REST API only accepts and outputs images in Base64 format
          • SRS-007 The diagnosis support service accepts multiple images to deliver more accurate results
          • SRS-008 The user's password is stored in the database as a hashed password
        • 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
      • Test plans
      • Test runs
      • Review meetings
      • 🥣 SOUPs
      • REL-001 Version 1.1.0.0
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
    • Usability and Human Factors Engineering
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Legit.Health Plus Version 1.1.0.0
  • Design History File
  • Requirements
  • Software Requirement Specification (SRS)
  • SRS-001 The device handles user accounts through an internal user registration service

SRS-001 The device handles user accounts through an internal user registration service

Category​

  • Security
  • Regulatory

Importance​

  • Critical

Description​

The user registration service will be integrated into the company's internal network, making it accessible only within the organization. This service will offer an interface for authorized personnel to create and manage API user accounts, incorporating necessary validation and authentication mechanisms. By preventing self-registration, this setup supports the pay-per-use business model, ensuring controlled access and usage of API endpoints. Additionally, the service should include logging and monitoring features to track registration activities and ensure adherence to internal security policies.

An efficient way to fulfill this requirement is to develop backend code for the user account management service, including user registration functionality, and provide a REST API or CLI as the user interface. The next step is to launch a basic-tier compute instance with the cloud provider and clone the code repository there. For a CLI, authorized personnel would execute the "main" file to start the command line interface on demand. For an API, the application would run continuously on the instance.

In either scenario, only authorized personnel with the necessary access keys can connect to the cloud instance and use the user account management service, thereby entrusting much of the security responsibility to the cloud provider.

Rationale​

This requirement ensures controlled access to the API by restricting user registration to company staff, thus maintaining the integrity of the pay-per-use model. It prevents unauthorized access and potential misuse by limiting the ability to create new users to internal personnel only.

Source​

  • Alejandro Carmena Magro
  • Inherent to the business model

Tested by software tests​

  • PLAN_017: Registration of a new user by authorized individuals

Activities generated​

  • Design and develop the user registration service or tool, which will perform high-level CRUD operations on the user database.
  • Develop an interface for authorized staff to use the user registration system.
  • Implement network restrictions to ensure internal-only access.

Implements user or system needs​

This requirement fulfills the need for secure and controlled user registration, making sure that only authorized personnel can register new users, which aligns with the operational model of the API service.

Regulatory requirements​

9.1: The device shall be compliant with MDR 2017/745, Annex I, point 17.2, 17.4, 18.8, 23.4(ab).

Causes failure modes​

  • Unauthorized access if network restrictions fail.
  • Inability to register new users if the service is not properly implemented.

Implements risk control measures​

  • By restricting the user registration service to the internal network, the risk of unauthorized access is significantly reduced.
  • The registration service will incorporate authentication mechanisms to verify the identity of the personnel accessing the interface.
  • All registration activities will be logged and monitored to detect any unusual or unauthorized activities promptly.
  • The internal network will be secured with firewalls, intrusion detection systems (IDS), and other security measures to prevent external attacks and make sure that the registration service is not exposed to the internet.

Acceptance criteria​

  • The user registration service is accessible only within the internal network.
  • Company staff can successfully register new API users through the service, but also carry out all other CRUD operations.
  • Unauthorized attempts to access the registration service are logged and prevented.

Constraints​

No specific constraints are needed to limit the developers' freedom in implementing this requirement.

Dependencies​

  • Availability and accessibility to an AWS DocumentDB or MongoDB database.
  • Internal private network (either in the cloud or on-premises).

Performance considerations​

There are no specific performance considerations for this requirement. Performance is not a critical factor here.

Additional notes​

No additional remarks are required.

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
Software Requirement Specification (SRS)
Next
SRS-002 The REST API enforces HTTPS for all communications to ensure data security
  • Category
  • Importance
  • Description
  • Rationale
  • Source
  • Tested by software tests
  • Activities generated
  • Implements user or system needs
  • Regulatory requirements
  • Causes failure modes
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
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.)