R-TF-012-033 Software Test Plan

Change history

Version	Date	Author	Reviewer	Approver	Summary of change
0.1	2025-12-18	Gerardo Fernández Moreno (JD-007)	TBD	TBD	Initial draft aligned to TestRail-governed, requirements-driven verification.
0.2	2025-12-18	Gerardo Fernández Moreno (JD-007)	TBD	TBD	Audit-oriented strengthening: objective acceptance criteria, evidence/records rigor, change control clarifications, execution governance, and removal of ambiguous placeholders.

Purpose

This Software Test Plan defines the verification strategy, governance, execution approach, and evidence records for the medical device exposed as a versioned HTTPS API. The plan is requirements-driven and provides complete traceability to the software requirements baseline, with execution evidence managed through TestRail and supporting CI/CD artifacts.

The objectives of this plan are to:

• Define the verification approach (test levels, test types, gating, regression strategy) for the API medical device.
• Specify how each software requirement is verified, including objective pass/fail criteria and required evidence.
• Establish traceability from requirements to test cases and test execution records.
• Define how test records are generated, reviewed, retained, and presented as regulated evidence.

Scope

In scope

• Verification of all requirements in the approved requirements baseline (functional, security, performance, reliability, data integrity, and operational/commissioning requirements).
• Verification of externally exposed API behaviors and contracts, including:
  • GET /device/health, GET /device/about
  • GET /clinical/severity-experts
  • POST /login
  • POST /clinical/diagnosis-support, POST /clinical/severity-assessment
• Verification of security and cybersecurity controls such as TLS enforcement, authentication/authorization behaviors, rate limiting, and audit trail behaviors.
• Performance verification under nominal load.

Out of scope

• Clinical validation or clinical performance claims of AI/ML outputs against ground truth datasets (handled under separate clinical evaluation/validation protocols).
• UI-level testing (no UI is in scope for an API-only device).
• Non-product tooling verification except where required to establish objective evidence capture (e.g., CI artifact generation, exports).

Test management system and governance

Tool confidence (TestRail and CI evidence pipeline)

The control of testing evidence is divided into distinct workflows to maintain a clear audit trail for version 1.1.0.0:

• Development Verification (Unit & Integration): These tests are executed locally. The resulting logs and a generated manifest file are uploaded manually to the 01_development_verification/ folder in S3.
• Software Verification: Test cases are defined and indexed in TestRail. Execution occurs on the Preproduction server, with results linked from TestRail to the 02_software_verification/ folder in S3.
• Commissioning: These environment-specific tests are managed via TestRail and executed in the Production environment. Evidence is stored in the 03_commissioning/ folder in S3.

To ensure the integrity of the manual upload process and the completeness of the release, a Manual Manifest Check is performed before final sign-off. This check confirms that all logs are present in the versioned S3 repository, matched against the manifest files, and that all TestRail-indexed activities contain valid links to their corresponding S3 objects.

s3://legit-health-plus/software-tests/v1.1.0.0/
├── 01_development_verification/
│   ├── unit_tests/                 <-- Local run logs + Manifest
│   └── integration_tests/          <-- Local run logs + Manifest
├── 02_software_verification/
│   └── preproduction/
│       └── test_plan_13/           <-- Requirement-based tests (from TestRail)
│           └── test_run_105/
├── 03_commissioning/
│   └── production/
│       └── test_plan_15/           <-- Environment/Deployment tests (from TestRail)
│           ├── test_run_274/
│           └── test_run_276/
└── manifest.json                   <-- Root manifest indexing all 3 folders

TestRail project structure

• Project: Medical Device
• Suite: single suite (regulated baseline)
• Sections (as implemented):
  • API
    • System Info
  • Diagnosis Support
  • Clinical Signs
  • Image metadata
  • Security
  • Report builder
  • Performance
  • Audit
  • Commissioning

Stable identifiers

• Primary Requirement Id field is authoritative and shall match the requirement code in the requirements baseline.
• Execution identity for a run is captured via:
  • version (TestRail run custom field)
  • Run naming convention including commit_sha
  • Evidence pack manifest including the immutable build identity tuple (release tag, commit SHA and image digest when applicable)

version follows the four-digit scheme (W.X.Y.Z) defined in GP-012: X is the major increment (W is reserved for exceptional, fundamental changes), Y is the minor increment, and Z captures bug fixes and patches.

Custom fields (as implemented)

Note on field naming

The field identifiers used in this plan (e.g., requirement_ids, primary_requirement_id, evidence_required) refer to the internal field names/keys in TestRail. The human-readable labels in the TestRail UI/export may differ. Where needed for audit/readability, a mapping between internal keys and UI labels is maintained in the TestRail administration configuration.

Test Cases

• requirement_ids (one per line; may include multiple; must include the authoritative RequirementID(s))
• primary_requirement_id (single primary RequirementID for reporting)
• test_level (Unit / Integration-Service / System-API / Commissioning)
• test_type (Functional / Security / Performance / Reliability / Data Integrity / Installation-Maintenance)
• automation (Automated / Manual / Hybrid)
• nrt (Non-Regression Test membership)
• risk_link (link to hazard/risk control IDs; if available)
• evidence_required (explicit evidence expectations; minimum evidence is defined in “Test execution, data recording, and evidence pack”)
• expected_results (objective pass/fail criteria; must be specific and measurable)
• preconditions (list that must be met before execution)

Test results

• version (four-digit tag, e.g., vW.X.Y.Z)

Naming conventions

Test Cases

• Title states what is going to be verified.
• The requirement_ids and primary_requirement_id fields must include RequirementIDs exactly as in the requirements baseline.

Test Runs

Test Plans vs Test Runs (TestRail)

• A "Test plan" is a container that groups multiple "Test Runs" under a single controlled verification activity for a specific build and environment (e.g., a given {release_version}, {commit_sha}, and {env_id}).
• A "Test Run" is the execution record where test case results (pass/fail/blocked), execution notes, and evidence are recorded for a defined scope and purpose (e.g., {run_purpose} such as Smoke, Regression, Performance, Commissioning).
• In this test process, the "Plan" represents the overall verification campaign for a build/environment, and each "Run" represents one execution slice within that campaign.

• Plan name: Medical Device API {release_version} (sha:{commit_sha}) — Verification Plan — {env_id}
• Run name: Medical Device API {release_version} (sha:{commit_sha}) — {run_purpose} — {env_id}
• {env_id} is one of: Dev / Pre / Pro.

Minimum required metadata to be present (either as run fields, run name, or in the evidence pack manifest):

• release version
• commit SHA
• environment ID

Change control for test cases

Test cases are treated as regulated records; any edits to approved cases must be controlled, traceable, and justified. To ensure the integrity of the verification process for version 1.1.0.0, the following controls are enforced:

• Reviewer Assignment: Every test case includes a dedicated Reviewer field and a Review Status (Draft, In Review, Approved). No test case may be executed for regulated evidence until its status is set to Approved.
• Independence of Review: To mitigate bias, the Reviewer assesses the test steps for accuracy and alignment with software requirements. For small-team configurations, the technical lead (CTO) may perform this review, provided the justification is documented in the final report to acknowledge the team-size constraint while maintaining clinical safety oversight.
• Freezing during execution: During an active verification campaign, test cases are frozen. Fixes for minor errors in test steps are handled as controlled updates and require a recorded justification in TestRail.
• Substantive Changes: Modifications that change the test objective, pass/fail criteria, or requirement coverage require a formal revision and a new Reviewer approval before execution.
• Evidence Consistency: Evidence requirements (evidence_required) are mandatory acceptance criteria. These must be strictly mapped to the S3 Evidence Pack structure (folders 01 through 03) and verified against the root manifest file to ensure a complete and untampered record of results.

Requirements taxonomy and verification strategy

Test levels (where executed)

• Unit: Development Environment. Fast verification of pure functions and internal logic. Logs are manually uploaded to S3 (01_development_verification/unit_tests/).
• Integration-Service: Development Environment. Service-to-service and persistence integration. Logs are manually uploaded to S3 (01_development_verification/integration_tests/).
• System-API: Preproduction Environment. End-to-end API contract, workflows, security controls, and response schema verification. Results are indexed in TestRail and evidence is stored in S3 (02_software_verification/).
• Commissioning (Production)
  • Purpose: Operational verification of the deployed production release (installation, readiness, and security controls).
  • Inputs: Controlled, non-identifying test data only.
  • Execution: Restricted to approved personnel.
  • Record: Commissioning outcomes are documented in controlled commissioning records:
    • R-TF-029-001 (Deployment & Configuration)
    • R-TF-029-002 (Functional & Interface)
    • R-TF-029-003 (Clinical Workflow & Operational Readiness)
  • Indexing: A dedicated TestRail Run with test_level = Commissioning is used to index execution results and provide direct links to evidence in S3 (03_commissioning/)

Entry and exit criteria (minimum)

Entry (before executing regulated evidence runs):

• Requirements baseline is approved and versioned.
• Test cases are reviewed and set to Approved status in TestRail.
• Target environment and build identity are defined (Release Version: 1.1.0.0, Commit SHA).

Exit (release verification complete):

• All required runs for the release/environment are executed (Unit/Integration + Preproduction Verification + Production Commissioning).
• Any failed cases have linked defect records, disposition, and documented re-test where applicable.
• Evidence Pack Integrity: S3 Evidence Pack is complete (Folders 01, 02, and 03) and includes the root manifest.json binding all results to the build identity.

Commissioning records (R-TF-029-001/002/003)

Commissioning in Production follows the structure of the R-TF-029 records to ensure regulatory compliance.

• Granularity rule: TestRail commissioning test cases are defined to match the main verification sections of the R-TF-029 records (e.g., “AI/ML Model Runtime Availability”).
• Evidence rule: Each TestRail result links to the relevant section of the R-TF-029 record and the corresponding S3 object.
• Baseline identification: Baseline identity is recovered from the manifest.json and includes the release version, commit SHA, and local container image IDs built via Bazel.

Test types (how classified)

• Functional: API behavior, workflow orchestration, report content.
• Security: TLS, JWT Authentication, and Audit controls.
• Performance: API latency verification (e.g., p95 latency < 10s under nominal load per Case C416).
• Reliability: Availability and operational readiness checks.
• Data Integrity: Schema constraints, EXIF stripping, and audit completeness.
• Installation: Deployment environment verification and model loading.

Gating and regression strategy

• Development Gate:
  • Unit and Integration tests pass locally.
  • Logs and local manifest are uploaded to S3 Folder 01.
• Release Candidate (Preproduction):
  • Execute System-API verification runs in TestRail (Folder 02).
  • Verify performance requirements (p95 latency).
• Production Commissioning:
  • Execute the Commissioning run in TestRail (Folder 03) before enabling clinical traffic.
  • Commissioning confirms environment-specific readiness and is governed by R-TF-029-001/002/003.

Test environment

Environment IDs and use

• Dev: Local workstation environment used for Unit and Integration test execution. Results are manually captured and uploaded to S3 folder 01_development_verification/.
• Pre: Dedicated Preproduction server used for System-API verification of release candidates. Results are indexed in TestRail and stored in S3 folder 02_software_verification/.
• Pro: Production environment used for Commissioning and final operational verification before clinical release. Results are indexed in TestRail and stored in S3 folder 03_commissioning/.

Environment controls

For each environment, the following identifiers must be versioned and referenced within the root manifest.json to maintain the software configuration baseline:

• API Configuration: Base URL and active routing prefix (e.g., https://plus.legit.health/v1.0/).
• Build Identity: The unique combination of Software Version (1.1.0.0) and the Git Commit SHA.
• Container Baseline: For the Production environment, the local Image IDs (generated by the local Bazel build) must be recorded to ensure the deployed artifacts match the verified baseline.
• Runtime Configuration: Reference to the configuration baseline identifier (SHA-256 of the redacted .env file).
• Security & Secrets: Credentials, API keys, and secrets (e.g., AWS_SECRET_ACCESS_KEY) SHALL NOT be stored in TestRail or evidence packs. Verification is limited to confirming that secrets are externalized and managed via protected environment variables.

Operational constraints for Pro commissioning

To ensure clinical safety and regulatory compliance during the final deployment phase:

• Access Control: Commissioning execution is strictly restricted to approved technical personnel (e.g., CTO/Lead Engineer).
• Data Privacy: Only non-identifying, synthetic, or anonymized test data (verified as PII-free via EXIF stripping) may be used in the Production environment.
• Evidence Integrity: The evidence pack must capture sufficient logs and health snapshots to prove operational readiness without exposing sensitive infrastructure data or plaintext secrets.

Planned tests

All requirement-driven verification test cases are defined and maintained in TestRail under the section structure defined above, and traced to requirements via requirement_ids / primary_requirement_id.

The traceability matrix is maintained as a controlled export.

Test execution, data recording, and evidence pack

What constitutes “execution evidence”

For each TestRail Run (e.g., R15, R16), the evidence pack includes:

• TestRail Run Export: A CSV/PDF export containing run metadata (release version, environment), tester identity, execution timestamps, and per-case outcomes.
• Test Case Definitions: A snapshot of the approved test case versions used during the run to ensure the pass/fail meaning is reconstructible.
• Manual Execution Artifacts:
  • Unit/Integration: Local terminal logs and coverage reports (coverage.py).
  • Verification: Request/response transcripts and server logs captured during preproduction testing.
  • Commissioning: Signed R-TF-029 records (PDF), deployment/config snapshots, and CloudWatch Synthetics screenshots.

Evidence pack storage

System of record: Amazon S3 serves as the immutable evidence store, with TestRail providing the execution index and direct artifact links.

S3 path convention (v1.1.0.0) Evidence is organized into the following controlled hierarchy:

• s3://legit-health-plus/software-tests/v1.1.0.0/
  • 01_development_verification/ (Unit/Integration logs + manifest)
  • 02_software_verification/ (Preproduction TestRail exports + logs)
  • 03_commissioning/ (Production TestRail exports + R-TF-029 records)
  • manifest.json (Root integrity index for all folders)

Evidence pack protection

• Access Control: Storage is restricted to authorized technical leads via IAM least-privilege policies.
• Immutability: Once the manifest.json is generated and uploaded, the pack is considered a frozen regulated record. Any necessary updates must be additive and require an updated manifest.
• Integrity: The root manifest.json binds all artifacts to the release identity (Version 1.1.0.0 and Commit SHA) using cryptographic checksums (ETags/MD5) for every file.

Relationship to T-012-035 (Test Run record)

The “Test Run record” required by the QMS is operationalized as the combined set of:

1. The TestRail Run Export (documenting the who, when, and what of the results).
2. The S3 Evidence Folder (containing the raw supporting artifacts).
3. The manifest.json (providing the integrity binding between the results and the build).

The manifest.json contains, at minimum:

• release_version (1.1.0.0).
• commit_sha (The unique Git identifier for the build).
• env_id (Dev / Pre / Pro).
• generated_at (UTC timestamp of the evidence pack finalization).
• Artifact Inventory: A complete list of files with their S3 URIs and MD5/SHA-256 checksums to support audit reconstruction.

Evidence pack completeness expectations

• Verification completeness: The 02_software_verification/ folder must contain logs for all System-API cases executed in TestRail.
• Commissioning completeness: The 03_commissioning/ folder must include the finalized and signed R-TF-029-001/002/003 records and supporting snapshots (e.g., DynamoDB audit entries, TLS certificates).
• Validation: The manifest.json inventory must match the stored artifacts exactly; any mismatch indicates a failure in the evidence collection process.

Traceability and coverage

Traceability mechanism

• Requirements baseline is the authoritative list of RequirementIDs.
• Traceability is achieved by:
  • Storing RequirementIDs in TestRail test cases (requirement_ids, primary_requirement_id)
  • Maintaining a controlled traceability matrix export (RequirementID → Test Case ID(s) → Evidence)
• Coverage rule: every RequirementID maps to at least one test case, or is explicitly justified as not applicable with documented rationale.

Coverage completeness

The requirements baseline and coverage status are defined by the controlled traceability matrix export included as Annex A. Coverage is considered complete when each requirement in the export is mapped to at least one planned test case (or has a documented verification rationale where testing is not applicable).

Defect management (GitHub Issues)

• Defects are tracked as GitHub Issues.
• Defect linkage rule:
  • Any failed test that indicates a product nonconformance to a requirement requires a linked GitHub Issue in the TestRail result comment.
  • Failures due to environmental issues (e.g., infrastructure outage) must be explicitly labeled as such in the test result comment, with objective evidence, and re-tested once the environment is restored.
• Required defect fields (minimum):
  • Fix version
  • Labels
  • Priority
  • Severity

Records retention

• Test evidence packs and exports (including TestRail Plan/Run exports, per-case results, CI artifacts such as JUnit XML/logs/coverage reports, performance reports and raw results, commissioning evidence, and the evidence pack manifest) are retained for 10 years.
• The system of record for test evidence packs is S3 using a release-scoped folder structure. Evidence integrity is supported by S3 bucket versioning and by storing an evidence pack manifest containing an inventory of artifacts and cryptographic checksums.
• TestRail is used as the execution record and index. For each regulated verification campaign, TestRail exports are generated and stored in the corresponding S3 evidence pack.
• Audit trail retention: Audit trail records are retained indefinitely in DynamoDB (no time-based deletion). Retention is verified by confirming that no automated TTL/expiry policy is configured for audit records and that audit data remains retrievable for historical periods. Access to audit trail data is restricted to authorized roles; audit data is not modified post-write except by controlled administrative operations.
• Disposal: test evidence packs and audit records are not deleted during the defined retention period. Any exceptional disposal (e.g., due to legal request or migration) is handled under controlled change with documented justification, approvals, and preservation of traceability and integrity.

References

• R-TF-029-001 Deployment and Configuration Commissioning Record
• R-TF-029-002 Functional and Interface Commissioning Record
• R-TF-029-003 Clinical Workflow and Operational Readiness Commissioning Record
• Applicable standards for software verification planning, traceability, and records: ISO 62304 and ISO 82304-1.
• EU MDR documentation retention expectations (used to define minimum evidence retention period).
• Requirements baseline: Software Requirements (authoritative RequirementIDs).
• Test management system: TestRail (project “Medical Device”).
• CI system: GitHub Actions.
• Defect tracker: GitHub Issues.

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: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001

Annexes

• Annex A: Traceability matrix
• Annex B: TestRail case list export

Annex A: Controlled export — Traceability matrix

SRS Id	SRS Name	Test Case Id	Test Case Title	Test Case URL	Test Id	Test URL	Status
SRS-7PJ	Network Service Exposure	C50	Verify the API service accepts incoming HTTP requests on the designated network port	View	T105	View	Passed
SRS-AQM	Standard HTTP Status Code Usage	C62	Verify API returns 200 HTTP status codes for successful requests	View	T106	View	Passed
SRS-BYJ	JSON Data Interchange Format	C68	Verify API processes JSON requests and returns JSON responses with correct Content-Type headers	View	T107	View	Passed
SRS-DW0	User Authentication Endpoint Implementation	C77	Verify successful user authentication and token generation via the POST /auth/login endpoint	View	T109	View	Passed
SRS-D3N	Provision of Clinical Parameter Endpoints	C73	Verify retrieval and filtering of clinical signs data via /clinical/severity-experts endpoint	View	T108	View	Passed
SRS-LBS	URL-Based API Versioning	C106	Verify API endpoints are accessible via URL paths prefixed with the major and minor version identifier	View	T110	View	Passed
SRS-MZC	Request Body Size Limitation	C110	Verify the API returns HTTP 413 when the request body exceeds the configured maximum size	View	T111	View	Passed
SRS-Q9M	Clinical Signs Analysis Endpoint Implementation	C124	Verify POST /clinical/severity-assessment returns quantified results for valid image and sign list	View	T112	View	Passed
SRS-RXK	Diagnostic Support Endpoint Implementation	C128	Verify the diagnosis-support endpoint accepts valid images and returns diagnostic analysis	View	T113	View	Passed
SRS-ZQO	Concurrent API Version Support	C162	Verify simultaneous availability and processing of requests across distinct API versions	View	T114	View	Skipped
SRS-ID7	Input Data Validation	C330	Verify API rejects malformed inputs with standardized 422 Unprocessable Entity responses	View	T115	View	Passed
SRS-EH4	Security-Safe Error Handling	C331	Verify API returns sanitized error responses with appropriate HTTP status codes and no internal details	View	T116	View	Passed
SRS-AQM	Standard HTTP Status Code Usage	C454	Verify API returns 401 HTTP status codes for wrong login requests	View	T272	View	Passed
SRS-AQM	Standard HTTP Status Code Usage	C455	Verify API returns 422 HTTP status code when invalid data is submitted	View	T273	View	Passed
SRS-GER	System Behavior on Internal Component Failure.	C456	Verification of controlled 503 response and graceful degradation during downstream service failure.	View	T300	View	Passed
SRS-6KE	API Health Check Endpoint	C169	Verify health check endpoint returns unhealthy when some service is unavailable	View	T121	View	Passed
SRS-6KE	API Health Check Endpoint	C46	Verify the public health endpoint returns HTTP 200 and status OK when operational	View	T118	View	Passed
SRS-BA6	Display the legal information about this medical device	C66	Verify retrieval of mandatory legal information, UDI, and regulatory metadata via API	View	T119	View	Passed
SRS-Z24	API Documentation Endpoint	C159	Verify availability of OpenAPI specification and interactive documentation endpoints	View	T120	View	Passed
SRS-Q3Q	Generate an aggregated ICD probability distribution from a set of images	C255	Verify API returns aggregated ICD probability distribution with structured code details in studyAggregate array	View	T122	View	Passed
SRS-0AB	Generate per-image ICD analysis with explainability heat map	C256	Verify response includes per-image ICD probabilities and heat maps for the top five categories	View	T123	View	Passed
SRS-58W	Include entropy score in report	C258	Verify response includes normalized entropy score between 0 and 1 in findings	View	T125	View	Passed
SRS-71I	Include the indicator of needing a high priority referral in the report	C260	Verify report response includes highPriorityReferral score within riskMetrics object	View	T127	View	Passed
SRS-8HY	Include the indicator of malignancy in the report	C261	Verify report response includes malignantConditionProbability score within riskMetrics object	View	T128	View	Passed
SRS-D08	Include the indicator of the image presenting a pigmented lesion in the report	C262	Verify report response includes pigmentedLesion score within riskMetrics object	View	T129	View	Passed
SRS-JLM	Include the indicator of the presence of a condition in the report	C263	Verify report response includes anyConditionProbability score within riskMetrics object	View	T130	View	Passed
SRS-KAS	Include the indicator of needing an urgent referral in the report	C264	Verify report response includes urgentReferral score within riskMetrics object	View	T131	View	Passed
SRS-K7M	Orchestrate diagnosis support workflow	C265	Verify diagnosis workflow returns ranked ICD-11 codes, binary indicators, and explainability maps for valid images	View	T132	View	Passed
SRS-A9F	Wound Bed Tissue - Epithelial	C266	Verify epithelial tissue classification returns right presence prediction and confidence score	View	T133	View	Passed
SRS-B3Z	Inflammatory Pattern Identification	C267	Verify API returns Hurley stage and inflammatory status with associated probabilities for valid image input	View	T134	View	Passed
SRS-B6L	Wound Bed Tissue - Necrotic	C268	Verify tissue wound bed necrotic classification returns right presence prediction and confidence score	View	T135	View	Passed
SRS-B8N	Pustule Intensity Quantification	C269	Verify pustule classification returns right intensity and confidence	View	T136	View	Passed
SRS-A4W	Inflammatory Nodular Lesion Quantification	C270	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for drainning tunnels	View	T137	View	Passed
SRS-A6T	Delimited Wound Edges Assessment	C271	Verify wound borders delimited classification returns right presence prediction and confidence score	View	T138	View	Passed
SRS-C1R	Serous Exudate Assessment	C272	Verify wound exudation serous classification returns right presence prediction and confidence score	View	T139	View	Passed
SRS-D7N	Purulent Exudate Assessment	C274	Verify wound exudation purulent classification returns right presence prediction and confidence score	View	T141	View	Passed
SRS-D9T	Maceration Surface Quantification	C275	Verify wound maceration segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T142	View	Passed
SRS-E4R	Erythema Intensity Quantification	C276	Verify erythema classification returns right intensity and confidence	View	T143	View	Passed
SRS-Y6F	Crusting Intensity Quantification	C277	Verify crusting classification returns right intensity and confidence	View	T144	View	Passed
SRS-F2K	Thickened Wound Edges Assessment	C278	Verify thickened wound borders classification returns right presence prediction and confidence score	View	T145	View	Passed
SRS-T3K	Induration Intensity Quantification	C279	Verify induration classification returns right intensity and confidence	View	T146	View	Passed
SRS-F6J	Hair Loss Surface Quantification	C280	Verify hair loss segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T147	View	Passed
SRS-G3P	Wound Perilesional Erythema Assessment	C281	Verify wound perilesional erythema classification returns right presence prediction and confidence score	View	T148	View	Passed
SRS-G9R	Wound Stage Classification	C282	Verify wound stage classification returns right score and confidence metrics from a valid wound image	View	T149	View	Passed
SRS-H5K	Erythema Surface Quantification	C283	Verify erythema segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T150	View	Passed
SRS-H9X	Lichenification Intensity Quantification	C284	Verify lichenification classification returns right intensity and confidence	View	T151	View	Passed
SRS-I7T	Wound Affected Tissue - Intact Skin	C285	Verify wound affected tissues intact classification returns right presence prediction and confidence score	View	T152	View	Passed
SRS-J5P	Hair Follicle Quantification	C286	Verify API returns follicle count, bounding boxes, and confidence scores for a valid scalp image	View	T153	View	Passed
SRS-J9V	Indistinguishable Wound Edges Assessment	C287	Verify wound borders indistinguishable classification returns right presence prediction and confidence score	View	T154	View	Passed
SRS-K3H	Wound Affected Tissue - Subcutaneous	C288	Verify wound affected tissues subcutaneous classification returns right presence prediction and confidence score	View	T155	View	Passed
SRS-K4U	Orthopedic Material Surface Quantification	C289	Verify wound orthopedic material segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T156	View	Passed
SRS-L4W	Damaged Wound Edges Assessment	C290	Verify wound borders damaged classification returns right presence prediction and confidence score	View	T157	View	Passed
SRS-L8Y	Biofilm and Slough Surface Quantification	C291	Verify wound biofilm material segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T158	View	Passed
SRS-M2L	Xerosis Intensity Quantification	C292	Verify xerosis classification returns right intensity and confidence	View	T159	View	Passed
SRS-M6P	Granulation Tissue Surface Quantification	C293	Verify wound granulation segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T160	View	Passed
SRS-N2C	Bone Surface Segmentation	C294	Verify wound bone segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T161	View	Passed
SRS-N5Q	Swelling Intensity Quantification	C295	Verify swelling classification returns right intensity and confidence	View	T162	View	Passed
SRS-N8W	Wound Affected Tissue - Dermis-Epidermis	C296	Verify wound exudation serous classification returns right presence prediction and confidence score	View	T163	View	Passed
SRS-O5M	Wound Affected Tissue - Muscle	C297	Verify wound affected tissues muscle classification returns right presence prediction and confidence score	View	T164	View	Passed
SRS-L3X	Skin Surface Segmentation	C298	Verify skin segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T165	View	Passed
SRS-Z5N	Hive Lesion Quantification	C299	Verify hive detector return correct counts and bounding boxes for hives	View	T166	View	Passed
SRS-Z8P	Biofilm-Compatible Tissue Assessment	C300	Verify wound biofilm tissue classification returns right presence prediction and confidence score	View	T167	View	Passed
SRS-P4X	Wound Bed Tissue - Slough	C302	Verify tissue wound bed slough classification returns right presence prediction and confidence score	View	T169	View	Passed
SRS-P9W	Desquamation Intensity Quantification	C303	Verify desquamation classification returns right intensity and confidence	View	T170	View	Passed
SRS-Q1L	Hypopigmentation or Depigmentation Surface Quantification	C304	Verify hypopigmentation segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T171	View	Passed
SRS-Q8Z	Diffuse Wound Edges Assessment	C305	Verify wound borders diffused classification returns right presence prediction and confidence score	View	T172	View	Passed
SRS-R3W	Wound Bed Surface Quantification	C306	Verify wound bed segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T173	View	Passed
SRS-R7C	Oozing Intensity Quantification	C307	Verify oozing classification returns right intensity and confidence	View	T174	View	Passed
SRS-S2V	Wound Affected Tissue - Bone	C308	Verify wound affected tissues bone classification returns right presence prediction and confidence score	View	T175	View	Passed
SRS-S8M	Acneiform Lesion Type Quantification	C309	Verify acneiform detector return correct counts and bounding boxes for papules, pustules, spots	View	T176	View	Passed
SRS-T6H	Wound AWOSI Score Quantification	C310	Verify AWOSI classification returns right score and confidence metrics from a valid wound image	View	T177	View	Passed
SRS-T9U	Wound Bed Tissue - Closed	C311	Verify tissue wound bed closed classification returns right presence prediction and confidence score	View	T178	View	Passed
SRS-U4M	Perilesional Maceration Assessment	C312	Verify wound perilesional maceration classification returns right presence prediction and confidence score	View	T179	View	Passed
SRS-U8Z	Nail Lesion Surface Quantification	C313	Verify nail lesion segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T180	View	Passed
SRS-V1D	Excoriation Intensity Quantification	C314	Verify excoriation classification returns right intensity and confidence	View	T181	View	Passed
SRS-V7Q	Necrosis Surface Quantification	C315	Verify wound necrosis segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T182	View	Passed
SRS-W3R	Hyperpigmentation Surface Quantification	C316	Verify hyperpigmentation segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T183	View	Passed
SRS-W9K	Bloody Exudate Assessment	C317	Verify wound bloody exudation classification returns right presence prediction and confidence score	View	T184	View	Passed
SRS-X5B	Fibrinous Exudate Assessment	C318	Verify wound exudation fibrinous classification returns right presence prediction and confidence score	View	T185	View	Passed
SRS-X8Q	Follicular and Inflammatory Pattern Identification	C319	Verify follicular and inflammatory pattern identification returns right result	View	T186	View	Passed
SRS-Y2E	Wound Bed Tissue - Granulation	C320	Verify wound tissue wound bed granulation classification returns right presence prediction and confidence score	View	T187	View	Passed
SRS-W6T	Orchestrate Clinical Signs Analysis Workflow	C321	Verify generation of structured clinical assessment report with quantified results for requested signs via API	View	T188	View	Passed
SRS-E1V	Body Surface Segmentation	C325	Verify body surface segmentation analysis returns segmentation masks and the right percentage of surface affected	View	T193	View	Passed
SRS-S8M	Acneiform Lesion Type Quantification	C446	Verify acneiform detector return correct counts and bounding boxes for nodules, pustules and scabs	View	T264	View	Passed
SRS-S8M	Acneiform Lesion Type Quantification	C447	Verify acneiform detector return correct counts and bounding boxes for scabs, comedones, papules and pustules	View	T265	View	Passed
SRS-Z5N	Hive Lesion Quantification	C448	Verify hive detector return correct counts and bounding boxes for hives (second image)	View	T266	View	Passed
SRS-A4W	Inflammatory Nodular Lesion Quantification	C449	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for non drainning tunnels	View	T267	View	Passed
SRS-A4W	Inflammatory Nodular Lesion Quantification	C450	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for nodules	View	T268	View	Passed
SRS-H2V	Head Detection	C323	Verify head detection returns right bounding boxes and heads count inside an image	View	T191	View	Passed
SRS-9ZT	The product classifies the image's modality	C327	Verify API returns ""clinical"" for image modality category when a skin image is provided	View	T195	View	Passed
SRS-O93	The product checks the image's clinical domain	C328	Verify API returns image domain category equals to ""dermatological"" and confidence score for a skin image	View	T196	View	Passed
SRS-Y5W	The product checks the image quality with the Dermatological Image Quality Assessment (DIQA) algorithm	C329	Verify API returns dermatological image quality score, interpretation, and acquisition feedback	View	T197	View	Passed
SRS-9ZT	The product classifies the image's modality	C451	Verify API returns ""dermoscopic"" for image modality category when a skin image is provided	View	T269	View	Passed
SRS-O93	The product checks the image's clinical domain	C452	Verify API returns image domain category equals to ""non_dermatological"" and confidence score for a dog image	View	T270	View	Passed
SRS-F05	Generate FHIR DiagnosticReport Base Structure	C453	Verify FHIR DiagnosticReport base structure for a segmenter	View	T271	View	Passed
SRS-1KW	Secure Communication Protocol Enforcement	C332	Verify API accepts requests over HTTPS using TLS 1.2 or 1.3	View	T198	View	Passed
SRS-1KW	Secure Communication Protocol Enforcement	C333	Verify API rejects or redirects unencrypted HTTP requests	View	T199	View	Passed
SRS-28X	Implement progressive delays between failed login attempts	C335	Verify progressive increase in enforced delay across consecutive failed authentication attempts	View	T201	View	Passed
SRS-28X	Implement progressive delays between failed login attempts	C336	Verify delay resets upon successful authentication	View	T202	View	Passed
SRS-A25	Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions	C337	Verify successful access to permitted endpoints for an authorized role	View	T203	View	Passed
SRS-A25	Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions	C338	Verify access denial for endpoints outside the assigned role scope	View	T204	View	Passed
SRS-A2B	API Rate Limiting	C339	Verify HTTP 403 response when request volume exceeds defined threshold	View	T205	View	Passed
SRS-A2B	API Rate Limiting	C340	Verify request acceptance after rate limit time window expiration	View	T206	View	Passed
SRS-MM8	Generated JWTs must have an expiration date	C341	Verify generated authentication tokens include the expiration claim	View	T207	View	Passed
SRS-MM8	Generated JWTs must have an expiration date	C342	Verify access denial for requests using an expired JWT	View	T208	View	Passed
SRS-SDZ	Use hashed and salted passwords	C343	Verify generation of authentication token using valid credentials	View	T209	View	Passed
SRS-SDZ	Use hashed and salted passwords	C344	Verify rejection of authentication requests with invalid credentials	View	T210	View	Passed
SRS-SDZ	Use hashed and salted passwords	C345	Verify password update functionality and subsequent authentication	View	T211	View	Passed
SRS-TPK	Lock accounts after five failed attempts	C346	Verify account lockout enforcement after threshold reached	View	T212	View	Passed
SRS-TPK	Lock accounts after five failed attempts	C347	Verify failed attempt counter reset on successful login	View	T213	View	Passed
SRS-TPK	Lock accounts after five failed attempts	C348	Verify administrative manual account unlock capability	View	T214	View	Passed
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	C349	Verify enforcement of password complexity and length constraints	View	T215	View	Passed
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	C350	Verify authentication behavior for expired passwords	View	T216	View	Passed
SRS-WER	Endpoint Access Control	C351	Verify protected endpoints allow access with a valid OAuth 2.0 Bearer token	View	T217	View	Passed
SRS-WER	Endpoint Access Control	C352	Verify protected endpoints reject requests lacking a valid token with 401 Unauthorized	View	T218	View	Passed
SRS-WER	Endpoint Access Control	C353	Verify public endpoints are accessible without an Authorization header	View	T219	View	Passed
SRS-WGF	AES-256 encryption for data at rest	C354	Verify AES-256 encryption configuration for data storage	View	T220	View	Passed
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	C355	Verify authorized administrator can retrieve current user information for review	View	T221	View	Passed
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	C356	Verify authorized administrator can revoke permissions during access review	View	T222	View	Passed
SRS-IC4	Software and Configuration Integrity Verification	C357	Verify successful execution and audit logging of system integrity checks	View	T223	View	Passed
SRS-BK7	Encrypted Backup and Integrity Verification	C363	Verify backup generation	View	T225	View	Passed
SRS-BK7	Encrypted Backup and Integrity Verification	C364	Verify automated backup generation	View	T226	View	Passed
SRS-CCD	Intrusion Prevention and Malicious Traffic Detection	C366	Verify blocking of anomalous high-frequency request bursts	View	T228	View	Passed
SRS-F05	Generate FHIR DiagnosticReport Base Structure	C368	Verify FHIR DiagnosticReport base structure for a detector	View	T230	View	Passed
SRS-FMG	Record Analysis Duration in Report	C369	Verify analysisDuration field population in DiagnosticReport	View	T231	View	Passed
SRS-JC6	The product provides a final image validity summary	C370	Verify isAssessable is true when domain and quality criteria are met	View	T232	View	Passed
SRS-JC6	The product provides a final image validity summary	C371	Verify isAssessable is false when image quality is unacceptable	View	T233	View	Passed
SRS-JC6	The product provides a final image validity summary	C372	Verify isAssessable is false when image is non-dermatological	View	T234	View	Passed
SRS-K6N	Map Per-Image Analysis to a dedicated object in the report	C373	Verify single image analysis maps to structured object in imageAnalyses array	View	T235	View	Passed
SRS-K6N	Map Per-Image Analysis to a dedicated object in the report	C374	Verify multiple image analyses map to distinct objects in imagingAnalysis array	View	T236	View	Passed
SRS-H3J	Deterministic Response Schemas	C375	Verify response structure compliance with OpenAPI success schema	View	T237	View	Passed
SRS-H3J	Deterministic Response Schemas	C376	Verify response structure compliance with OpenAPI error schema	View	T238	View	Passed
SRS-W5Z	Assign DiagnosticReport Identifier	C377	Verify Assignment of Official Identifier to DiagnosticReport	View	T239	View	Passed
SRS-W5Z	Assign DiagnosticReport Identifier	C378	Verify Uniqueness of Generated DiagnosticReport Identifiers	View	T240	View	Passed
SRS-D6W	Accurate Time Synchronization	C382	Verify System Timestamp Accuracy via API Response Headers	View	T244	View	Passed
SRS-D6W	Accurate Time Synchronization	C383	Verify System Time Synchronization and Accuracy Status	View	T245	View	Passed
SRS-SI2	Secure Audit Trail Access Interface	C388	Verify Role-Based Access Control for Audit Trail Interface	View	T247	View	Passed
SRS-SI2	Secure Audit Trail Access Interface	C389	Verify Audit Trail Search and Export Capabilities	View	T248	View	Passed
SRS-T5P	Audit Record Integrity Protection	C391	Verify audit records cannot be modified or deleted via API	View	T249	View	Passed
SRS-PU2	Comprehensive Event Auditing	C395	Verify audit trail generation for authentication lifecycle and security anomalies	View	T251	View	Passed
SRS-U2P	Consolidated Audit Record Content	C398	Verify audit record completeness for successful API event	View	T252	View	Passed
SRS-U2P	Consolidated Audit Record Content	C399	Verify audit record completeness for failed API event	View	T253	View	Passed
SRS-PU2	Comprehensive Event Auditing	C410	Verify audit trail generation for clinical data creation events	View	T255	View	Passed
SRS-T95	Audit System Failure Handling	C413	Audit record preservation during database unavailability	View	T258	View	Passed
SRS-BWB	Performance and Latency	C416	Verify p95 API latency remains under 10 seconds during nominal load	View	T261	View	Passed

Annex B: TestRail Test Case Export

Annex_B_TestRail_Test_Case_Export.csv