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_011 Non-Base64 encoded images are rejected

PLAN_011 Non-Base64 encoded images are rejected

Description​

This test verifies that the REST API rejects images that are not encoded in Base64 format and returns an appropriate error message.

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​

First, download this sample image to your computer. Using your preferred tool, open the image file and copy the raw binary data into a text file. Then, take this binary data from the text file and replace the placeholder text <Paste-the-binary-data-here> with it in each of the following two JSON payloads. You can automate the entire process by handling all these tasks programmatically.

  1. Request body for diagnosis support service.
{
"subject": {
"reference": "fake-patient-id"
},
"media": [
{
"contentType": "image/jpeg",
"data": <Paste-the-binary-data-here>,
}
]
}
  1. Request body for severity assessment service.
{
"subject": {
"reference": "fake-patient-id"
},
"media": {
"contentType": "image/jpeg",
"data": <Paste-the-binary-data-here>
},
"known_condition": {
"conclusion": {
"code": "EA80",
"display": "Atopic dermatitis",
"system_alias": "ICD-11"
}
},
"body_site": "arm_left",
"scoring_systems": [
"ascorad"
],
"questionnaire_response": [
{
"questionnaire": "ascorad",
"item": [
{"code": "surface", "answer": [{"value": 40}]},
{"code": "itchiness", "answer": [{"value": 3}]},
{"code": "sleeplessness", "answer": [{"value": 2}]},
],
},
],
}
Send binary data as string

Before adding the raw image bytes to the data field of the JSON, convert them to a text string. The payload only accepts JSON-serializable objects, which bytes are not.

Steps​

  1. Send a POST request to the /diagnosis-support endpoint, including the "stringified" binary image from "Input data" in the JSON payload for the diagnosis support service.
  2. Send a POST request to the /severity-assessment endpoint, including the "stringified" binary image from "Input data" in the JSON payload for the severity assessment service.

Expected outcome​

  • Both endpoints are unable to process the request and return an error message indicating that the image must be encoded in Base64 format.

Verifies software requirements​

  • REQ_005

Risk control for​

    1. Data transmission failure from care provider's system
    1. Data input failure

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_010 Base64 encoded images are accepted
Next
PLAN_012 Diagnosis support endpoint accepts 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.)