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
          • PLAN-001 Users submit their credentials to receive an access token
          • PLAN_002 Token expiration in user authentication process
          • PLAN_003 Account lockout for user authentication
          • PLAN_004 Enforcing HTTPS protocol for API communications
          • PLAN_005 Valid SSL/TLS certificates
          • PLAN_006 Rate limiting for anonymous users
          • PLAN_007 Rate limiting for authenticated users
          • PLAN_008 Logging and monitoring of rate limit violations
          • PLAN_009 Validation of request and response data against FHIR schemas
          • PLAN_010 Base64 encoded images are accepted
          • PLAN_011 Non-Base64 encoded images are rejected
          • PLAN_012 Diagnosis support endpoint accepts multiple images
          • PLAN_013 Improved accuracy with multiple images
          • PLAN_014: Password hashing during user registration
          • PLAN_015: Password hash comparison during login
          • PLAN_016: Registration of a new user by authorized individuals
          • PLAN_017 Specification of body zone for scoring systems requiring zone factor
          • PLAN_018 The device's API maintains an uptime of at least 99% over a one-month period
          • PLAN_019 API penetration testing with Intruder.io
        • Test runs
        • 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 plans
  • PLAN_017 Specification of body zone for scoring systems requiring zone factor

PLAN_017 Specification of body zone for scoring systems requiring zone factor

Description​

This test verifies that the API request includes the specific body region where the lesion is located and where the image was taken. The body zone must be submitted to the /severity-assessment endpoint when the user wants to get results from the following scoring systems:

  • APASI
  • ASALT
  • ASCORAD

If the user doesn't specify the body zone, the system cannot infer the body zone factor for the scoring system. Consequently, it will be impossible to solve the mathematical formula needed to determine the final score for a skin condition.

System requirements​

This test can be executed with standard hardware, and it is not necessary to use any specific software. Any commonly available system should be sufficient for the task.

Preconditions​

  • The entire system (including the reverse proxy, REST API, and all upstream services) is deployed, operational, and accessible online.
  • You have successfully obtained an access token by providing valid credentials to the /login endpoint, and the token has not yet expired.

Input data​

First, download the two images below to your computer:

  • Alopecia
  • Atopic dermatitis

Next, use your preferred tool to convert each downloaded image into a Base64 string. Save each encoded image in a separate text file. These Base64 strings will be used in the JSON payloads for this test, replacing the corresponding placeholder text with the appropriate Base64 string.

  • Payload 1. Data to be sent for ASCORAD and APASI:
{
"subject": {
"reference": "fake-patient-id"
},
"media": {
"contentType": "image/jpeg",
"data": "<Paste-the-base64-image-of-atopic-dermatitis-here>"
},
"known_condition": {
"conclusion": {
"code": "EA80",
"display": "Atopic dermatitis",
"system_alias": "ICD-11"
}
},
"body_site": "arm_left",
"scoring_systems": ["apasi", "ascorad"],
"questionnaire_response": [
{
"questionnaire": "apasi",
"item": [{ "code": "surface", "answer": [{ "value": 4 }] }]
},
{
"questionnaire": "ascorad",
"item": [
{ "code": "surface", "answer": [{ "value": 78 }] },
{ "code": "itchiness", "answer": [{ "value": 4 }] },
{ "code": "sleeplessness", "answer": [{ "value": 6 }] }
]
}
]
}
  • Payload 2. Data to be sent for ASALT:
{
"subject": {
"reference": "fake-patient-id"
},
"media": {
"contentType": "image/jpeg",
"data": "<Paste-the-base64-image-of-alopecia-here>"
},
"known_condition": {
"conclusion": {
"code": "ED70",
"display": "Alopecia",
"system_alias": "ICD-11"
}
},
"body_site": "head_right",
"scoring_systems": ["asalt"]
}

Although multiple scoring systems can be specified in a single request, we've used two separate JSON payloads for this test. This approach is necessary because it doesn't make clinical sense to request both ASCORAD and ASALT scores for the same lesion, as they measure very different visible signs.

Don't forget the token

For each request to the protected endpoints (including /severity-assessment), make sure to include the access token in the request headers as shown below:

{ "Authorization": "Bearer <Paste-your-access-token-here>" }

Steps​

  1. Send two distinct POST requests to the /severity-assessment API endpoint: one with the body "Payload 1" and the other with "Payload 2" from test data.
  2. Observe the responses from the server. Note down the status codes, response body, and headers received.
  3. Remove or comment out the body_site key from each JSON payload, then resend the requests using the modified JSON.
  4. Again, examine the responses.

Expected outcome​

  • The API returns a 200 OK status code when the body site is specified in the request, and the response includes a diagnostic report with the results for the selected scoring systems.
  • The API responds with a 422 Unprocessable Entity status code when the body site is missing from requests for scoring systems that require it, preventing the device from generating any preliminary diagnostic report. The API's error message appears as follows:
{
"detail": [
{
"type": "missing",
"loc": ["body", "bodySite"],
"msg": "Field required",
"input": {
"subject": { "reference": "fake-patient-id" },
"media": {
"contentType": "image/jpeg",
"data": "/9j/4AAQSkZJRgABAQAAAQABAAD/2wB..."
},
"known_condition": {
"conclusion": {
"code": "EA80",
"display": "Atopic dermatitis",
"system_alias": "ICD-11"
}
},
"scoring_systems": ["apasi", "ascorad"],
"questionnaire_response": [
{
"questionnaire": "apasi",
"item": [{ "code": "surface", "answer": [{ "value": 4 }] }]
},
{
"questionnaire": "ascorad",
"item": [
{ "code": "surface", "answer": [{ "value": 78 }] },
{ "code": "itchiness", "answer": [{ "value": 4 }] },
{ "code": "sleeplessness", "answer": [{ "value": 6 }] }
]
}
]
}
}
]
}

Verifies software requirements​

  • REQ_011

Risk control for​

    1. The endpoints of the device are not compatible with the user's software
    1. Incorrect clinical information
    1. Incorrect diagnosis or follow up
    1. Incorrect results shown to patient

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
PLAN_016: Registration of a new user by authorized individuals
Next
PLAN_018 The device's API maintains an uptime of at least 99% over a one-month period
  • Description
  • System requirements
  • Preconditions
  • Input data
  • Steps
  • Expected outcome
  • Verifies software requirements
  • Risk control for
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.)