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_012 Diagnosis support endpoint accepts multiple images

PLAN_012 Diagnosis support endpoint accepts multiple images

Description​

This test verifies that the API endpoint for the diagnosis support service accepts 1 to 5 clinical images per request and generates a preliminary diagnosis report by integrating findings from all images.

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.

Input data​

Download this sample image](https://upload.wikimedia.org/wikipedia/commons/6/63/Atopic_dermatitis_child.JPG) to your computer. Using your preferred tool or programming language, convert it to a Base64 string and copy the encoded image into a text file. Next, replace <Paste-the-encoded-image-here> with the encoded image in the JSON payload below. We use the three ellipses inside the media JSON key to show that the image needs to be replaced as many times as there are images to be sent, as indicated by the corresponding test.

{
"subject": {
"reference": "fake-patient-id"
},
"media": [
{
"contentType": "image/jpeg",
"data": <Paste-the-encoded-image-here>,
},
{
"contentType": "image/jpeg",
"data": <Paste-again-the-encoded-image-here>,
},
// ...
]
}

It's okay to use the same image repeatedly for this test, even though the results will be the same whether we use 1 or 5 images. Our goal here is to ensure the API can handle multiple images, not to evaluate the performance of the AI model.

Steps​

  1. Send three POST requests to the /diagnosis-support endpoint, each with 1, 3, and 5 images. Use the JSON payload from the β€œInput data” section for this.
  2. Verify that the service processes the requests and returns a preliminary diagnosis report for each case.

Expected outcome​

  • The API service successfully accepts and processes requests with 1, 3, and 5 images.
  • A preliminary diagnosis report is generated for each request.
  • The report combines individual findings with aggregated results from all the provided images.

Verifies software requirements​

  • SWR-007

Risk control for​

    1. Incorrect diagnosis or follow up
    1. Incorrect results shown to patient
    1. Sensitivity to image variability
    1. Lack of efficacy or clinical utility

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_011 Non-Base64 encoded images are rejected
Next
PLAN_013 Improved accuracy with multiple images
  • 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.)