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.0.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
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • REQ_007 If something does not work, the API returns meaningful information about the error

REQ_007 If something does not work, the API returns meaningful information about the error

Category​

Functional

Source​

  • Taig Mac Carthy, Design & Development Manager

INTERNALINTERFACES ALARMS, WARNINGS AND MESSAGES NETWORK REGULATORY FUNCTIONAL AND CAPACITY ARCHITECTURE

Activities generated​

  • MDS-450

Causes failure modes​

  • The API returns vague or generic error messages that do not provide actionable information for users to diagnose the issue.
  • Error messages lack essential details such as error codes, descriptions, or the context of the error.
  • Different types of errors return the same message, making it difficult to identify the root cause.
  • Similar errors result in different error messages, causing inconsistency.
  • The API returns incorrect HTTP status codes that do not match the nature of the error (e.g., returning a 200 OK for an error condition).
  • Error messages are filled with technical jargon that non-technical users cannot understand.
  • Exposing stack traces or internal technical details that are not helpful for end users.
  • Error messages reveal sensitive information about the system that could be exploited by attackers.
  • Detailed error messages that should only appear in development are shown in production environments.

Related risks​

    1. Image artefacts/resolution: the medical device receives an input that does not have sufficient quality in a way that affects it performance
    1. Data transmission failure from care provider's system: the care provider's system cannot connect to the device to send data
    1. Data input failure: the medical device cannot receive data from care providers
    1. Data accessibility failure: the care provider cannot receive data from the medical device
    1. Data transmission failure: the medical device cannot send data to care providers
    1. Interruption of service: users suddenly can't use the medical device due to downtime
    1. Device failure or performance degradation: the device is overwhelmed by its use: either not enough storage capacity or unable to handle requests
    1. The device inputs images that do not represent skin structure

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

  • User Requirement 7.1: Users shall be notified with meaningful error messages when an issue arises.
  • Software Requirement Specification 7.2: Implement error-handling mechanisms to generate user-friendly error messages for all potential issues during device interactions.
  • Design Requirement 7.3: Design the error response format to be consistent and self-explanatory, using clear key naming and utilising HTTP status codes effectively.
  • Regulatory Requirement 7.4: Device shall be developed according to the requirements set out in EN ISO 14971:2019 and EN 62366-1:2015/A1:2020.
  • Regulatory Requirement 7.5: Design and manufacture of the device shall be complaint with MDR 2017/745, Annex I, points 3 and 4.

Description​

Efficiently engaging with intricate systems necessitates a comprehensive grasp of their functionalities. While meticulous documentation and adherence to interoperability standards like FHIR are in place, it's crucial to acknowledge that users may encounter challenges in using the device accurately. To mitigate the risk of misuse or incorrect outcomes, the device abstains from generating data when the input is erroneous. An illustrative case in point is the inability to process image-less requests, which are promptly rejected.

In this context, our primary objective is to craft clear and informative error messages for various conceivable scenarios. These messages serve to elucidate users about the nature of the issue whenever a problem arises.

Key Error Categories​

Applicable to All Use Cases:

  1. Missing Image Data
  2. Incorrect Image Format
  3. Low-Quality Image
  4. Image Lacking Skin Structure

Specific to Some Use Cases:

  1. Missing Body Site
  2. Unrecognised Body Site
  3. Absent Symptom
  4. Incorrect Symptom Value

Success metrics​

GoalMetric
User sends an imageThe medical device issues a 400 HTTP response along with a self-explanatory message when the user does not send an image
Users sends an image in the correct formatThe medical device issues a 400 HTTP response along with a self-explanatory message when the users sends an image in an incorrect format
User sends an image of good qualityThe medical device issues a 400 HTTP response along with a self-explanatory message when the users sends an image of low quality
User sends an image containing a skin structureThe medical device issues a 400 HTTP response along with a self-explanatory message when the image does not contain a skin structure
User sends body site dataThe medical device issues a 400 HTTP response along with a self-explanatory message when the users does not send body site data
User sends body site data in the correct formatThe medical device issues a 400 HTTP response along with a self-explanatory message when the users sends body site data in an incorrect format
User sends symptom dataThe medical device issues a 400 HTTP response along with a self-explanatory message when the users does not send symptom data
Users sends symptom data in the correct formatThe medical device issues a 400 HTTP response along with a self-explanatory message when the users sends symptom data in an incorrect format

Previous related requirements​

  • REQ_005
  • REQ_006

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
Previous
REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
Next
REQ_008 Notify the user if the image does not represent a skin structure
  • Category
  • Source
  • Activities generated
  • Causes failure modes
  • Related risks
  • User Requirement, Software Requirement Specification, Design requirement and Regulatory Requirement
  • Description
    • Key Error Categories
  • 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.)