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 /, GET /health, GET /device-information
  • GET /params/body-sites, GET /params/clinical-signs,
  • POST /login
  • POST /diagnosis-support, POST /clinical-signs
• 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 (TestRail)

Tool confidence (TestRail and CI evidence pipeline)

TestRail is used as the controlled execution record and index; regulated evidence is obtained from TestRail exports plus CI artifacts stored in the evidence pack. The CI evidence pipeline (export generation, artifact capture, and manifest creation) is maintained under version control, changes are peer-reviewed, and each release verification includes a sanity check that required artifacts and manifest fields are generated and retrievable.

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:
  • release_version (TestRail run custom field)
  • Run naming convention including commit_sha and gha_run_id
  • Evidence pack manifest including the immutable build identity tuple (release tag, commit SHA, GitHub Actions run ID, and image digest when applicable)

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 Runs

• release_version (SemVer tag, e.g., vMAJOR.MINOR.PATCH)

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}, {gha_run_id}, 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}, gha:{gha_run_id}) — 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
• CI pipeline identity (GitHub Actions run ID)
• environment ID

Change control for test cases

• Test cases are regulated records. Edits to approved test cases are controlled and reviewable.
• During an active release candidate verification campaign, test cases used by that campaign are treated as frozen (no substantive edits); fixes are handled as controlled updates with reviewer approval and recorded justification.
• Substantive changes that affect pass/fail meaning, test objective, or requirement coverage require controlled revision and reviewer approval prior to execution for regulated evidence.
• Evidence expectations (evidence_required) are treated as part of the acceptance criteria and must be kept consistent with the CI/TestRail evidence pipeline.

Requirements taxonomy and verification strategy

Test levels (where executed)

• Unit: Dev (CI pipeline). Fast verification of pure functions and internal logic.
• Integration-Service: Dev (CI pipeline). Service-to-service and persistence integration.
• System-API: Pre. End-to-end API contract, workflows, security controls, and response schema verification.
• Commissioning (Pro)
  • Purpose: Operational verification of the deployed production release (installation/readiness/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 created to index commissioning execution and link to the above records.

Entry and exit criteria (minimum)

Entry (before executing regulated evidence runs):

• Requirements baseline is approved and versioned.
• Test cases are reviewed/controlled (no unreviewed substantive edits).
• Target environment and build identity are defined (release version, commit SHA, CI run identity, and env_id).

Exit (release verification complete):

• All required runs for the release/environment are executed (Dev CI + Pre verification + Pro commissioning).
• Any failed cases have linked defect records, disposition, and documented re-test where applicable.
• Evidence pack is complete and includes manifest binding results to build identity.

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

Commissioning in TestRail (alignment with R-TF-029 records)

Commissioning activities in Pro are executed and recorded using controlled commissioning records:

• R-TF-029-001 — Deployment & Configuration Commissioning Record
• R-TF-029-002 — Functional & Interface Commissioning Record
• R-TF-029-003 — Clinical Workflow & Operational Readiness Commissioning Record

To ensure consistent reporting and evidence retrieval, commissioning is also represented in TestRail as a dedicated Commissioning section and a dedicated Commissioning run for each release/environment.

Granularity rule (minimum):

• Commissioning TestRail test cases SHALL be defined at the level of the main verification sections in the R-TF-029 records (e.g., “End-to-End Clinical Workflow Execution”, “AI/ML Model Runtime Availability”, “Clinical Output Integrity and Structure”).
• Detailed step-by-step execution remains in the R-TF-029 records; TestRail records the pass/fail outcome per section and links to the corresponding evidence items and signed record.

Evidence rule:

• Each commissioning test result SHALL link to the relevant section of the completed R-TF-029 record and to the supporting evidence referenced in the Evidence Register and/or the evidence pack.

Relationship to TestRail and evidence packs:

• A dedicated TestRail Run with test_level = Commissioning is created to execute and record commissioning.
• Commissioning outcomes are recorded per commissioning test case (aligned to the main verification sections of R-TF-029-001/002/003), with an overall run summary derived from the per-case results.
• The TestRail commissioning run links to the completed R-TF-029 records and to the supporting evidence items referenced in those records.

Baseline identification alignment:

• For commissioning evidence, the baseline identity SHALL be recoverable from the evidence set, including: {release_version}, {commit_sha}, {gha_run_id} (or equivalent CI pipeline identity), {env_id}, and (when applicable) container image digests.
• If commit SHA / CI run ID are not recorded directly inside the R-TF-029 record, they SHALL be recorded in the commissioning TestRail run metadata and/or in the evidence pack manifest.

Interface naming alignment:

• API endpoints and routing prefixes used in commissioning SHALL be documented in the commissioning evidence set (base URL and any routing prefix such as /vX.Y/).
• If production routing paths differ from the logical endpoints used in the requirements baseline, the evidence set SHALL include a mapping (e.g., “requirements endpoint” → “production route”).

Test types (how classified)

• Functional (API behavior, workflow orchestration, report content)
• Security (TLS/auth/rate-limits/audit controls)
• Performance (p95 latency and load behavior)
• Reliability (availability, resilience expectations, controlled operational checks)
• Data Integrity (schema constraints, traceability IDs, audit completeness)
• Installation-Maintenance (readiness endpoints, monitoring, operational checks)

Gating and regression strategy

• Pull Request gate (Dev):
  • Unit + integration must pass in CI
  • JUnit XML + logs are produced as artifacts
  • Coverage report is produced as artifact
• Release candidate (Pre):
  • Execute the System-API NRT run (all cases flagged nrt = Yes)
  • Execute targeted non-NRT suites for changed components (risk-based selection; documented in the run notes)
  • Execute the performance run
• Production commissioning (Pro):
  • Execute the Commissioning run in TestRail before enabling/confirming traffic for the release
  • Commissioning focuses on operational readiness checks and evidence capture; it does not replace Pre verification
  • Commissioning execution is governed by the controlled commissioning records (R-TF-029-001/002/003) and linked as evidence from the Commissioning run

Test environment

Environment IDs and use

• Dev: unit/integration execution
• Pre: system/API verification (release candidates)
• Pro: commissioning, operational verification

Environment controls

For each environment, the following must be versioned and referenced from the evidence pack:

• API base URL + routing prefix (e.g., /vX.Y/)
• Deployment artifact identity (release version + commit SHA + CI run identity; include container image digest when applicable)
• Runtime configuration baseline reference
• Credentials/secrets handling (not stored in TestRail; not stored in evidence packs)

Operational constraints for Pro commissioning:

• Commissioning execution is restricted to approved personnel.
• Commissioning test data is non-identifying and controlled.
• Evidence pack captures operational readiness without exposing secrets or sensitive data.

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:

• TestRail Run export (PDF/CSV) containing:
  • Run metadata (release_version, env_id in name), tester, timestamps, per-case outcomes
  • Per-case comments and defect links
  • A snapshot of the executed test case definitions (via TestRail export or equivalent) is retained in the evidence pack to ensure the pass/fail meaning is reconstructable for the executed release.
• Attachments per evidence_required:
  • CI artifacts: JUnit XML, logs, coverage HTML (coverage.py) and performance reports as applicable
  • Request/response transcripts (from logs) for System-API cases
  • Commissioning evidence: deployment/config exports, monitoring snapshots

Evidence pack storage (decision)

System of record for evidence packs: S3 (immutable evidence store), with TestRail containing the index and links.

S3 path convention

• s3://<md-evidence-bucket>/software-tests/{release_version}/{env_id}/{testrail_plan_id}/
  • testrail/ (plan/run exports)
  • ci/ (JUnit XML, logs, coverage)
  • perf/ (jMeter reports)
  • commissioning/ (config exports, screenshots)
  • hashes/ (manifest of artifacts + checksums)

Evidence pack protection (minimum)

• Evidence packs SHALL be stored in an access-controlled location with least-privilege permissions for read/write.
• Evidence pack contents SHALL be protected from modification after creation; if updates are required (e.g., re-test evidence), they SHALL be additive and traceable (e.g., new artifact versions + updated manifest).
• The hashes/ manifest SHALL bind artifacts to the release identity (release version, commit SHA, CI run identity, env_id) to support audit reconstruction.

Commissioning evidence (Pro)

• System of record for evidence packs remains: S3.
• For commissioning runs, the S3 evidence pack SHALL include under commissioning/:
  • The completed/signed commissioning records (R-TF-029-001/002/003) as PDFs/exports, and
  • The key referenced artifacts (e.g., deployment/config exports, monitoring snapshots), OR immutable links to their controlled sources (e.g., CloudWatch/DynamoDB identifiers) when exports are not practical.
• The evidence pack manifest SHALL record, at minimum:
  • {release_version}, {env_id}, {testrail_plan_id}, {testrail_run_id}
  • {commit_sha} and {gha_run_id} (or equivalent CI pipeline identity)
  • Container image digest(s) when applicable
• Any differences between “requirements endpoint naming” and “production routing paths” SHALL be documented in the commissioning evidence set (base URL, routing prefix such as /vX.Y/, and a simple mapping when needed).

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

The “Test Run record” (T-012-035) is operationalized as:

• The TestRail Run export (including execution timestamps, outcomes, testers and per-case results), plus
• The linked evidence pack folder for that run, plus
• An evidence pack manifest that binds the execution record to the exact build identity and artifacts.

The evidence pack manifest is a structured file stored in the evidence pack (e.g., manifest.json) containing, at minimum:

• release_version
• commit_sha
• gha_run_id (CI pipeline identity)
• env_id (Dev / Pre / Pro)
• TestRail identifiers (Plan ID and Run ID)
• Artifact inventory (file list) including cryptographic checksums (e.g., SHA-256) for each artifact
• Evidence pack creation timestamp and creator identity (system/service account)

Evidence pack completeness expectations for a regulated run:

• TestRail Run export (PDF/CSV) is present in the evidence pack (or the evidence pack includes an immutable link to it).
• CI artifacts referenced by executed automated cases are present (JUnit XML, logs, coverage report, and any generated reports).
• Performance artifacts are present when performance cases are executed (raw results + generated report).
• Commissioning artifacts are present when commissioning cases are executed (deployment/config evidence and operational check evidence).
• The manifest inventory matches the stored artifacts (no missing files; checksums validate).

Evidence pack immutability expectations:

• Evidence packs are stored in a controlled evidence repository with restricted write access.
• Evidence packs are protected from post-hoc modification by enabling repository controls (e.g., bucket/object versioning and write-once controls) and recording immutable artifact identities (checksums) in the manifest.
• TestRail retains the execution timestamps and user identity; the evidence pack manifest and storage controls prevent silent alteration of the supporting artifacts.

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
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 in TestRail
SRS-1KW	Secure Communication Protocol Enforcement	C332	Verify API accepts requests over HTTPS using TLS 1.2 or 1.3	View in TestRail
SRS-1KW	Secure Communication Protocol Enforcement	C333	Verify API rejects or redirects unencrypted HTTP requests	View in TestRail
SRS-1KW	Secure Communication Protocol Enforcement	C334	Verify API rejects connections using deprecated TLS versions	View in TestRail
SRS-1XR	Include model sensitivity in report	C257	Verify analysis response includes numeric sensitivity within performanceIndicator object	View in TestRail
SRS-28X	Implement progressive delays between failed login attempts	C335	Verify progressive increase in enforced delay across consecutive failed authentication attempts	View in TestRail
SRS-28X	Implement progressive delays between failed login attempts	C336	Verify delay progression counter resets upon successful authentication	View in TestRail
SRS-36U	System Information Endpoint Implementation	C43	Verify retrieval of system status and version via the root API endpoint	View in TestRail
SRS-58W	Include entropy score in report	C258	Verify response includes normalized entropy score between 0 and 1 in performanceIndicator	View in TestRail
SRS-66O	Include model specificity in report	C259	Verify analysis response includes correct model specificity in performanceIndicator	View in TestRail
SRS-6KE	API Health Check Endpoint	C169	Verify health check endpoint returns HTTP 503 when service is unavailable	View in TestRail
SRS-6KE	API Health Check Endpoint	C46	Verify the public health endpoint returns HTTP 200 and status OK when operational	View in TestRail
SRS-71I	Include the indicator of needing a high priority referral in the report	C260	Verify report response includes highPriorityReferral score within clinicalIndicator object	View in TestRail
SRS-7PJ	Network Service Exposure	C50	Verify the API service accepts incoming HTTP requests on the designated network port	View in TestRail
SRS-8HY	Include the indicator of malignancy in the report	C261	Verify the final report response includes the malignancy probability within the clinicalIndicator object	View in TestRail
SRS-8QR	Encapsulate Proprietary Data	C367	Verify proprietary metrics are encapsulated in additionalData object	View in TestRail
SRS-9ZT	The product classifies the image's modality	C327	Verify API returns modality confidence scores and sets the final value to the highest scoring modality	View in TestRail
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 in TestRail
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 in TestRail
SRS-A2B	API Rate Limiting	C339	Verify HTTP 429 response when request volume exceeds defined threshold	View in TestRail
SRS-A2B	API Rate Limiting	C340	Verify request acceptance after rate limit time window expiration	View in TestRail
SRS-A4W	Inflammatory Nodular Lesion Quantification	C270	Verify API returns accurate counts and bounding boxes for HS lesion types in valid image requests	View in TestRail
SRS-A57	Audit Trail Data Retention Policy	C379	Verify administrator configuration of audit trail retention period	View in TestRail
SRS-A57	Audit Trail Data Retention Policy	C380	Verify automated archiving of audit trails exceeding active retention period	View in TestRail
SRS-A57	Audit Trail Data Retention Policy	C381	Verify secure and logged disposal of audit trail archives after total retention period	View in TestRail
SRS-A6T	Delimited Wound Edges Assessment	C271	Verify wound boundary classification returns present or absent with confidence score	View in TestRail
SRS-A9F	Wound Bed Tissue - Epithelial	C266	Verify epithelial tissue analysis returns valid binary prediction and confidence score	View in TestRail
SRS-AQM	Standard HTTP Status Code Usage	C62	Verify API returns appropriate 2xx, 4xx, and 5xx HTTP status codes based on request outcome	View in TestRail
SRS-B3Z	Inflammatory Pattern Identification	C267	Verify API returns Hurley stage and inflammatory status with associated probabilities for valid image input	View in TestRail
SRS-B6L	Wound Bed Tissue - Necrotic	C268	Verify necrotic tissue analysis returns binary prediction and confidence score	View in TestRail
SRS-B8N	Pustule Intensity Quantification	C269	Verify generation of normalized probability vector and derived severity score via API for pustule intensity quantification	View in TestRail
SRS-BA6	Display the legal information about this medical device	C66	Verify retrieval of mandatory legal information, UDI, and regulatory metadata via API	View in TestRail
SRS-BK7	Encrypted Backup and Integrity Verification	C363	Verify encrypted backup generation and integrity verification logging	View in TestRail
SRS-BK7	Encrypted Backup and Integrity Verification	C364	Verify backup schedule configuration persistence	View in TestRail
SRS-BWB	Performance and Latency	C416	Verify p95 API latency remains under 10 seconds during nominal load	View in TestRail
SRS-BYJ	JSON Data Interchange Format	C68	Verify API processes JSON requests and returns JSON responses with correct Content-Type headers	View in TestRail
SRS-C1R	Serous Exudate Assessment	C272	Verify API returns binary prediction and confidence score for serous fluid detection requests	View in TestRail
SRS-C7K	Acneiform Inflammatory Lesion Quantification	C273	Verify API returns correct lesion count and bounding boxes for valid acneiform image request	View in TestRail
SRS-CCD	Intrusion Prevention and Malicious Traffic Detection	C365	Verify rejection of requests containing malicious attack signatures	View in TestRail
SRS-CCD	Intrusion Prevention and Malicious Traffic Detection	C366	Verify blocking of anomalous high-frequency request bursts	View in TestRail
SRS-D08	Include the indicator of the image presenting a pigmented lesion in the report	C262	Verify report generation includes pigmentedLesion probability in clinicalIndicator	View in TestRail
SRS-D3N	Provision of Clinical Parameter Endpoints	C73	Verify retrieval and filtering of clinical master data via parameter endpoints	View in TestRail
SRS-D6W	Accurate Time Synchronization	C382	Verify System Timestamp Accuracy via API Response Headers	View in TestRail
SRS-D6W	Accurate Time Synchronization	C383	Verify NTP Configuration and Synchronization Status	View in TestRail
SRS-D6W	Accurate Time Synchronization	C384	Verify NTP Synchronization Failure Reporting	View in TestRail
SRS-D7N	Purulent Exudate Assessment	C274	Verify API returns valid purulent exudate classification and confidence score for a wound image	View in TestRail
SRS-D9T	Maceration Surface Quantification	C275	Verify generation of maceration segmentation mask, percentage, and absolute area from a valid wound image request	View in TestRail
SRS-DW0	User Authentication Endpoint Implementation	C77	Verify successful user authentication and token generation via the POST /login endpoint	View in TestRail
SRS-E1V	Body Surface Segmentation	C325	Verify generation of 5-class anatomical segmentation mask and BSA metrics via API	View in TestRail
SRS-E4R	Erythema Intensity Quantification	C276	Verify erythema quantification API returns probability vector, calculated severity, and confidence score	View in TestRail
SRS-EH4	Security-Safe Error Handling	C331	Verify API returns sanitized error responses with appropriate HTTP status codes and no internal details	View in TestRail
SRS-F05	Generate FHIR DiagnosticReport Base Structure	C368	Verify FHIR DiagnosticReport base structure and fixed coding values	View in TestRail
SRS-F2K	Thickened Wound Edges Assessment	C278	Verify wound edge analysis returns valid presence prediction and confidence score	View in TestRail
SRS-F6J	Hair Loss Surface Quantification	C280	Verify hair loss quantification API returns segmentation mask and calculated percentage	View in TestRail
SRS-F9L	Fitzpatrick Skin Type Identification	C324	Verify API returns Fitzpatrick type, probabilities, and confidence score for a valid image request	View in TestRail
SRS-FMG	Record Analysis Duration in Report	C369	Verify analysisDuration field population in DiagnosticReport	View in TestRail
SRS-G3P	Wound Perilesional Erythema Assessment	C281	Verify perilesional erythema assessment returns binary prediction and confidence score	View in TestRail
SRS-G9R	Wound Stage Classification	C282	Verify API returns stage label, probability distribution, and confidence score for valid image input	View in TestRail
SRS-H2V	Head Detection	C323	Verify API returns subject coordinates, count, and multi-subject status for valid image input	View in TestRail
SRS-H3J	Deterministic Response Schemas	C375	Verify response structure compliance with OpenAPI success schema	View in TestRail
SRS-H3J	Deterministic Response Schemas	C376	Verify response structure compliance with OpenAPI error schema	View in TestRail
SRS-H5K	Erythema Surface Quantification	C283	Verify API returns erythema segmentation mask and area metrics for valid wound image	View in TestRail
SRS-H9X	Lichenification Intensity Quantification	C284	Verify lichenification model outputs probabilities, weighted severity score, and confidence metric	View in TestRail
SRS-I7T	Wound Affected Tissue - Intact Skin	C285	Verify intact skin classification and confidence score generation for valid wound image input	View in TestRail
SRS-IC4	Software and Configuration Integrity Verification	C357	Verify successful execution and audit logging of system integrity checks	View in TestRail
SRS-IC4	Software and Configuration Integrity Verification	C358	Verify detection and logging of configuration integrity failures	View in TestRail
SRS-ID7	Input Data Validation	C330	Verify API rejects malformed, oversized, or out-of-bounds inputs with standardized 400 Bad Request responses	View in TestRail
SRS-J5P	Hair Follicle Quantification	C286	Verify API returns follicle count, bounding boxes, and confidence scores for a valid scalp image	View in TestRail
SRS-J9V	Indistinguishable Wound Edges Assessment	C287	Verify API returns valid binary prediction and confidence score for edge assessment	View in TestRail
SRS-JC6	The product provides a final image validity summary	C370	Verify final validity summary is positive when all criteria are met	View in TestRail
SRS-JC6	The product provides a final image validity summary	C371	Verify final validity summary is negative when image quality is unacceptable	View in TestRail
SRS-JC6	The product provides a final image validity summary	C372	Verify final validity summary is negative when image is non-dermatological	View in TestRail
SRS-JLM	Include the indicator of the presence of a condition in the report	C263	Verify the generated report response contains the hasCondition probability within the clinicalIndicator structure	View in TestRail
SRS-K3H	Wound Affected Tissue - Subcutaneous	C288	Verify subcutaneous tissue analysis API returns valid binary prediction and confidence score	View in TestRail
SRS-K4U	Orthopedic Material Surface Quantification	C289	Verify API returns orthopedic material segmentation, metrics, and exposure alert for valid wound image input	View in TestRail
SRS-K6N	Map Per-Image Analysis to a dedicated object in the report	C373	Verify single image analysis maps to structured object in imagingAnalysis array	View in TestRail
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 in TestRail
SRS-K7M	Orchestrate diagnosis support workflow	C265	Verify diagnosis workflow returns ranked ICD-11 codes, binary indicators, and explainability maps for valid images	View in TestRail
SRS-KAS	Include the indicator of needing an urgent referral in the report	C264	Verify report response includes urgentReferral score within clinicalIndicator object	View in TestRail
SRS-L3X	Skin Surface Segmentation	C298	Verify skin segmentation API returns binary mask, coverage percentage, and confidence score	View in TestRail
SRS-L4W	Damaged Wound Edges Assessment	C290	Verify API returns binary prediction and confidence score for wound edge analysis	View in TestRail
SRS-L8Y	Biofilm and Slough Surface Quantification	C291	Verify API returns biofilm segmentation mask and quantification metrics for valid wound image	View in TestRail
SRS-LBS	URL-Based API Versioning	C106	Verify API endpoints are accessible via URL paths prefixed with the major and minor version identifier	View in TestRail
SRS-LOG	Log Overflow Protection	C400	Verify Log Rotation and Archival Upon Threshold	View in TestRail
SRS-LOG	Log Overflow Protection	C414	Verify audit log monitoring and alert generation	View in TestRail
SRS-LOG	Log Overflow Protection	C415	Verify archival of aged audit records to long-term storage	View in TestRail
SRS-M2L	Xerosis Intensity Quantification	C292	Verify xerosis quantification returns valid probability vector, calculated severity score, and confidence	View in TestRail
SRS-M6P	Granulation Tissue Surface Quantification	C293	Verify granulation tissue quantification returns segmentation mask and area metrics	View in TestRail
SRS-MM8	Generated JWTs must have an expiration date	C341	Verify generated authentication tokens include the expiration claim	View in TestRail
SRS-MM8	Generated JWTs must have an expiration date	C342	Verify access denial for requests using an expired JWT	View in TestRail
SRS-MZC	Request Body Size Limitation	C110	Verify the API returns HTTP 413 when the request body exceeds the configured maximum size	View in TestRail
SRS-N2C	Bone, Cartilage, or Tendon Surface Quantification	C294	Verify deep structure quantification metrics and segmentation mask generation	View in TestRail
SRS-N5Q	Swelling Intensity Quantification	C295	Verify swelling quantification response includes normalized probabilities, weighted severity score, and confidence	View in TestRail
SRS-N7P	Body Site Identification	C322	Verify API returns anatomical classification and confidence metrics for valid image input	View in TestRail
SRS-N8W	Wound Affected Tissue - Dermis-Epidermis	C296	Verify dermis-epidermis involvement prediction and confidence score generation for valid image input	View in TestRail
SRS-O5M	Wound Affected Tissue - Muscle	C297	Verify muscle tissue involvement classification and confidence score generation for a valid wound image	View in TestRail
SRS-O93	The product checks the image's clinical domain	C328	Verify API response contains clinical domain confidence score and dermatological status flag	View in TestRail
SRS-P2Y	Acneiform Inflammatory Pattern Identification	C301	Verify generation of IGA severity grade and confidence scores from a dermatological image request	View in TestRail
SRS-P4X	Wound Bed Tissue - Slough	C302	Verify Slough tissue classification and confidence score generation in API response	View in TestRail
SRS-P9W	Desquamation Intensity Quantification	C303	Verify desquamation quantification returns valid probability distribution, severity score, and confidence	View in TestRail
SRS-PU2	Comprehensive Event Auditing	C394	Verify audit trail generation for data modification and administrative security actions	View in TestRail
SRS-PU2	Comprehensive Event Auditing	C395	Verify audit trail generation for authentication lifecycle and security anomalies	View in TestRail
SRS-PU2	Comprehensive Event Auditing	C410	Verify audit trail generation for clinical data creation events	View in TestRail
SRS-PU2	Comprehensive Event Auditing	C411	Verify audit trail generation for successful and failed authentication attempts	View in TestRail
SRS-Q1L	Hypopigmentation or Depigmentation Surface Quantification	C304	Verify hypopigmentation quantification returns segmentation mask and affected surface percentage	View in TestRail
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 conclusion array	View in TestRail
SRS-Q8Z	Diffuse Wound Edges Assessment	C305	Verify API returns diffuse wound edge classification and confidence score for valid image input	View in TestRail
SRS-Q9M	Clinical Signs Analysis Endpoint Implementation	C124	Verify POST /clinical-signs-analysis returns quantified results for valid image and sign list	View in TestRail
SRS-Q9M	Clinical Signs Analysis Endpoint Implementation	C419	Verify PASI clinical signs request returns intensity and surface metrics for erythema, plus intensity for induration and crusting	View in TestRail
SRS-R3W	Wound Bed Surface Quantification	C306	Verify wound bed quantification returns segmentation mask and geometric measurements for valid image input	View in TestRail
SRS-R7C	Oozing Intensity Quantification	C307	Verify exudation analysis returns valid probability vector and weighted severity score	View in TestRail
SRS-RXK	Diagnostic Support Endpoint Implementation	C128	Verify the diagnosis-support endpoint accepts valid images and returns diagnostic analysis	View in TestRail
SRS-S2V	Wound Affected Tissue - Bone	C308	Verify API returns valid bone involvement classification and confidence score for a provided wound image	View in TestRail
SRS-S8M	Acneiform Lesion Type Quantification	C309	Verify API returns correct counts and bounding boxes for papules, pustules, cysts, comedones, and nodules	View in TestRail
SRS-SDZ	Use hashed and salted passwords	C343	Verify generation of authentication token using valid credentials	View in TestRail
SRS-SDZ	Use hashed and salted passwords	C344	Verify rejection of authentication requests with invalid credentials	View in TestRail
SRS-SDZ	Use hashed and salted passwords	C345	Verify password update functionality and subsequent authentication	View in TestRail
SRS-SI2	Secure Audit Trail Access Interface	C388	Verify Role-Based Access Control for Audit Trail Interface	View in TestRail
SRS-SI2	Secure Audit Trail Access Interface	C389	Verify Audit Trail Search and Export Capabilities	View in TestRail
SRS-T3K	Induration Intensity Quantification	C279	Verify induration quantification returns valid probability distribution, severity score, and confidence metrics	View in TestRail
SRS-T5P	Audit Record Integrity Protection	C391	Verify audit records cannot be modified or deleted via API	View in TestRail
SRS-T6H	Wound AWOSI Score Quantification	C310	Verify generation of AWOSI score, probability distribution, and confidence metrics from a valid wound image	View in TestRail
SRS-T95	Audit System Failure Handling	C412	Verify audit message acknowledgement upon successful persistence	View in TestRail
SRS-T95	Audit System Failure Handling	C413	Verify audit message retention upon persistence failure	View in TestRail
SRS-T9U	Wound Bed Tissue - Closed	C311	Verify API returns valid closure classification and confidence score for wound image	View in TestRail
SRS-TPK	Lock accounts after five failed attempts	C346	Verify account lockout enforcement after threshold reached	View in TestRail
SRS-TPK	Lock accounts after five failed attempts	C347	Verify failed attempt counter reset on successful login	View in TestRail
SRS-TPK	Lock accounts after five failed attempts	C348	Verify administrative manual account unlock capability	View in TestRail
SRS-U2P	Consolidated Audit Record Content	C398	Verify audit record completeness for successful API event	View in TestRail
SRS-U2P	Consolidated Audit Record Content	C399	Verify audit record completeness for failed API event	View in TestRail
SRS-U4M	Perilesional Maceration Assessment	C312	Verify generation of periwound moisture classification and confidence score via API	View in TestRail
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	C349	Verify enforcement of password complexity and length constraints	View in TestRail
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	C350	Verify authentication behavior for expired passwords	View in TestRail
SRS-U8Q	High Availability and Load Balancing Support	C417	Verify stateless request processing across multiple instances	View in TestRail
SRS-U8Q	High Availability and Load Balancing Support	C418	Verify API availability during single instance failure	View in TestRail
SRS-U8Z	Nail Lesion Surface Quantification	C313	Verify API returns segmentation mask and lesion percentage for valid nail image request	View in TestRail
SRS-V1D	Excoriation Intensity Quantification	C314	Verify calculation of ordinal probabilities and continuous severity score for excoriation analysis	View in TestRail
SRS-V4Q	Surface Area Quantification	C326	Verify API returns calibrated area and depth metrics for images containing reference markers	View in TestRail
SRS-V7Q	Necrosis Surface Quantification	C315	Verify API returns necrosis segmentation mask and area metrics for valid wound image	View in TestRail
SRS-W3R	Hyperpigmentation Surface Quantification	C316	Verify generation of hyperpigmentation segmentation mask and surface percentage from input image	View in TestRail
SRS-W5Z	Assign DiagnosticReport Identifier	C377	Verify Assignment of Official Identifier to DiagnosticReport	View in TestRail
SRS-W5Z	Assign DiagnosticReport Identifier	C378	Verify Uniqueness of Generated DiagnosticReport Identifiers	View in TestRail
SRS-W6T	Orchestrate Clinical Signs Analysis Workflow	C321	Verify generation of structured clinical assessment report with quantified results for requested signs via API	View in TestRail
SRS-W9K	Bloody Exudate Assessment	C317	Verify API returns binary classification and confidence for hemorrhagic exudate presence	View in TestRail
SRS-WER	Endpoint Access Control	C351	Verify protected endpoints allow access with a valid OAuth 2.0 Bearer token	View in TestRail
SRS-WER	Endpoint Access Control	C352	Verify protected endpoints reject requests lacking a valid token with 401 Unauthorized	View in TestRail
SRS-WER	Endpoint Access Control	C353	Verify public endpoints are accessible without an Authorization header	View in TestRail
SRS-WGF	AES-256 encryption for data at rest	C354	Verify AES-256 encryption configuration for data storage	View in TestRail
SRS-X5B	Fibrinous Exudate Assessment	C318	Verify generation of binary prediction and confidence score for fibrinous exudate analysis	View in TestRail
SRS-X8Q	Follicular and Inflammatory Pattern Identification	C319	Verify HS phenotype classification and confidence metrics are returned for a valid image request	View in TestRail
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	C355	Verify authorized administrator can retrieve current user permissions for review	View in TestRail
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	C356	Verify authorized administrator can revoke permissions during access review	View in TestRail
SRS-Y2E	Wound Bed Tissue - Granulation	C320	Verify granulation tissue classification and confidence score generation for a valid wound image request	View in TestRail
SRS-Y5W	The product checks the image quality with the Dermatological Image Quality Assessment (DIQA) algorithm	C329	Verify API returns DIQA overall quality score and dimension subscores upon valid image submission	View in TestRail
SRS-Y6F	Crusting Intensity Quantification	C277	Verify generation of crusting probability vector and weighted severity score	View in TestRail
SRS-Z24	API Documentation Endpoint	C159	Verify availability of OpenAPI specification and interactive documentation endpoints	View in TestRail
SRS-Z5N	Hive Lesion Quantification	C299	Verify API returns hive count and bounding boxes for valid dermatological image input	View in TestRail
SRS-Z8P	Biofilm-Compatible Tissue Assessment	C300	Verify API returns valid biofilm classification and confidence score for wound image input	View in TestRail
SRS-ZQO	Concurrent API Version Support	C162	Verify simultaneous availability and processing of requests across distinct API versions	View in TestRail

Annex B: TestRail Test Case Export

Annex_B_TestRail_Test_Case_Export.csv