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

• 9. Image artefacts/resolution: the medical device receives an input that does not have sufficient quality in a way that affects it performance
• 11. Data transmission failure from care provider's system: the care provider's system cannot connect to the device to send data
• 12. Data input failure: the medical device cannot receive data from care providers
• 13. Data accessibility failure: the care provider cannot receive data from the medical device
• 14. Data transmission failure: the medical device cannot send data to care providers
• 15. Interruption of service: users suddenly can't use the medical device due to downtime
• 40. Device failure or performance degradation: the device is overwhelmed by its use: either not enough storage capacity or unable to handle requests
• 54. 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:

5. Missing Body Site
6. Unrecognised Body Site
7. Absent Symptom
8. Incorrect Symptom Value

Success metrics

Goal	Metric
User sends an image	The 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 format	The 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 quality	The 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 structure	The 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 data	The 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 format	The 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 data	The 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 format	The 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:

• Author: JD-004, JD-005, JD-009, JD-017
• Approver: JD-003