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.1.0.0
        • Requirements
        • Test plans
        • Test runs
          • TEST_001 The user receives quantifiable data on the intensity of clinical signs
          • TEST_002 The user receives quantifiable data on the count of clinical signs
          • TEST_003 The user receives quantifiable data on the extent of clinical signs
          • TEST_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • TEST_007 If something does not work, the API returns meaningful information about the error
          • TEST_008 Notify the user image modality and if the image does not represent a skin structure
          • TEST_009 Notify the user if the quality of the image is insufficient
          • TEST_010 The user specifies the body site of the skin structure
          • TEST_011 We facilitate the integration of the device into the users' system
          • TEST_012 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • TEST_013 The data that users send and receive follows the FHIR healthcare interoperability standard
          • TEST-014 The user authentication feature is functioning correctly
          • TEST_015 Ensure all API communications are conducted over HTTPS
          • TEST_016 Ensure API compliance with Base64 image format and FHIR standard
          • TEST_017 Verification of authorized user registration and body zone specification in device API
          • TEST_018 Ensure API stability and cybersecurity of the medical device
        • Review meetings
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.1.0.0
  • Test runs
  • TEST_007 If something does not work, the API returns meaningful information about the error

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

Test type​

System user acceptance

Linked activities​

  • MDS-450

Result​

  • Passed
  • Failed

Description​

Tests carried out at the medical device's receiver module, to verify that when errors occur due to improperly formatted or invalid data in the request body, the API provides clear and meaningful error information. The goal of these tests is to enhance the user experience by offering transparent guidance when things go awry.

These error messages are designed to be both descriptive and actionable. They not only convey the nature of the problem but also offer insights into the specific location within the request where the issue lies. This empowers developers and integrators to quickly pinpoint and rectify the root cause of the problem. By delivering informative error messages, we aim to expedite the troubleshooting process, reducing the time required to identify and address issues.

Moreover, these tests assess the compliance of error codes and status responses with industry standards, ensuring consistency and predictability in how errors are handled.

Test checklist​

The following checklist verifies the completion of the goals and metrics specified in the requirement: REQ_007.

Requirement verification​

  • User sends an image
  • User sends an image in the correct format
  • User sends symptom data
  • User sends symptom data in the correct format

Evidence​

Payload sent by the user to the API must contain at least two images:

payload = {
"resourceType": "CommunicationRequest",
"identifier": {
"system": "The namespace for the identifier value",
"value": "The value that is unique",
},
"subject": {
"reference": "patient/id",
},
"payload": [
{"attachment": {"contentType": "image/jpeg", "data": "base64 image 1"}},
{"attachment": {"contentType": "image/png", "data": "base64 image 2"}},
],
}

If the user submits one or no images, the API will return the following error message:

API Error: 422
{
"detail": [
{
"type": "too_short",
"loc": [
"body",
"data",
"content"
],
"msg": "Set should have at least 2 items after validation, not 1",
//...
}

Another API usage policy is that the user must send images encoded in Base64 string format. This format looks like this:

"/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wgARCAOEBkADASIAAhEBAxEB/8QAGwAAAgMBAQEAAAAAAAAAAAAAAgMAAQQFBgf/xAAZAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAX/2gAMAwEAAhADEAAAAfRjYb40pigRIBdEJVXVkMGhsBiS5ZLkLurLsbSSSpVyKsrzaZClsquiIbopUWKvPIOBvO5VKCrz0aOAwrpQuAW9Ljfux6+81GipTzJzee6ARfLTqEdHZhy9QIUraWuDrUVWJlIDS2ZdHrZ93fLnLLpCWrJZtXz0ZdOuOOXaPitrr1zTroM5+lbSxfLsTkuppVfTMq4VLhJVlXISVZUkAwb+dCXIfz3JdVckSSWtSVZJLJJIZry6dTVztnPTlha/BpSTGwBsbLqpF3bEjaZFsVeD4iukcsB7Dgy2iCD+hzuju69CmaryW5Bh1c1VjqKw68K4OX0OXw7A5TufRjAYG0HZWwn8OeRe9eM89fQVvOGaq3A3K39IxjW51kR0EZvNx9HnGZZH2VDrWlL0Jml2NKzVhLeNg4k756sIqZgWOp9ICV1CsgoRgxVSVKqJbFMHmtiFY2XKhcqy7GBVKorG4IgsYS7UyWUHYWGNLKynjwThenzaGznOhTYLs7FBoCM7T0bluNugC9PDWUNNcbma5mNIXqXLkydDF6c4FvD05zC8KURGU62819PN1q26k6PVmwLPuZOXt43JScpeautZ4rDWQ1udlaunxOr0u0THpsmqdo26vpmSQkkJJCrkJVwklAc7fzM0HofjVyrqSQl1dlS6JJZUkGac+hD5/R51nFWwfDQjCzUDoGxLG6sxOjTpxrF..."

If an image is sent in a format other than Base64 string, the user will receive the following response:

API Error: 422
{
"detail": [
{
"type": "value_error",
"loc": [
"body",
"data",
"content",
0
],
"msg": "Value error, Only base64 data is allowed",
"input": "imgs/sample-hematoma.jpeg",
"ctx": {
"error": {}
},
"url": "https://errors.pydantic.dev/2.4/v/value_error"
}
]
}

To assess the severity of a skin disease, the device needs to know several patient's non-visual symptoms that are associated with the pathology we are interested in measuring (in addition, automatic scoring systems will also need one or several images of the affected skin area). Each scoring system has a questionnaire that the user must fill in and include in the body request sent to the API. It is necessary to answer all mandatory questions, which can be found in the API Instructions for Use.

Let's take as an example a patient whose known condition is atopic dermatitis. In this case, ASCORAD is the most appropriate scoring system, as it is composed of six visual signs defined in the REQ_001 and REQ_003 that are useful to quantify the severity of the condition. The answers for the ASCORAD questionnaire are as follows:

{
//...,
"ASCORAD_LOCAL": {
"surfaceValue": 27,
"itchinessScorad": 2,
"sleeplessness": 2
},
//...,
}

If the user ignores answering the sleeplessness question or mistypes the symptom, the device will not generate data and will complain with the following error message:

API Error: 422
{
"detail": [
{
"type": "missing",
"loc": [
"body",
"sleeplessness"
],
"msg": "Field required",
"input": {
"surfaceValue": 27,
"itchinessScorad": 2
},
"url": "https://errors.pydantic.dev/2.4/v/missing"
}
]
}

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-004
  • Approver: JD-005
Previous
TEST_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
Next
TEST_008 Notify the user image modality and if the image does not represent a skin structure
  • Test type
  • Linked activities
  • Result
  • Description
  • Test checklist
    • Requirement verification
  • Evidence
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.)