R-TF-012-033 Software Test Plan

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 (Local)

• Execution: Unit and Integration tests must pass with 100% success on the developer's local workstation.
• Evidence: Logs and a local manifest must be generated and uploaded to S3 folder 01_development_verification/ before a build is promoted to Preproduction.

Regression Strategy (Preproduction)

To ensure that new versions (e.g., v1.1.0.0) do not introduce regressions into established clinical workflows, the following strategy is applied:

• Automated NRT: All test cases flagged in TestRail as Non-Regression Test (NRT) = Yes must be executed.
• Impact-Based Testing: If a substantive change is made to a specific AI/ML expert or clinical sign (e.g., Erythema grading), all associated clinical workflow tests in Folder 02 must be re-executed, regardless of their NRT flag.
• Performance Baseline: A regression check of API latency is mandatory; the p95 latency must not deviate significantly from the approved baseline (max 10s).

Release Candidate Gate (Preproduction)

• Execution: Successful completion of the designated System-API verification run in TestRail (Folder 02).
• Review: All "Approved" test cases must show a "Passed" status, and any "Failed" cases must have a linked GitHub Issue with a documented risk disposition.

Production Commissioning Gate (Production)

• Execution: Execute the Commissioning run in TestRail (Folder 03) before enabling clinical traffic.
• Readiness: Commissioning confirms environment-specific readiness (not functional behavior) and is governed by the signed R-TF-029-001/002/003 records.

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

• Authoritative Baseline: The requirements baseline is the definitive list of RequirementIDs for Legit.Health Plus v1.1.0.0.
• TestRail Integration: Traceability is established by mapping RequirementIDs directly into the primary_requirement_id and requirement_ids fields within TestRail test cases.
• Traceability Matrix: A controlled export (RequirementID → Test Case ID → Evidence URI) serves as the primary record for auditing coverage.
• Coverage Rule: Every RequirementID must map to at least one test case or be accompanied by a documented justification explaining why testing is not applicable.

Coverage completeness

The requirements baseline and coverage status are formalized in the Traceability Matrix (Annex A). Coverage is considered complete when:

1. Every requirement in the baseline maps to at least one Approved test case in TestRail.
2. The manifest.json in the S3 evidence pack confirms that evidence exists for all test cases mapped to those requirements.
3. Any requirement not tested has a documented verification rationale approved by the technical lead.

Defect management (GitHub Issues)

Defects identified during the verification and commissioning of Legit.Health Plus are managed as controlled records to ensure clinical safety.

Problem Resolution Workflow

• Tracking System: Defects are tracked as GitHub Issues.
• Linkage Rule: Any failed test result in TestRail that represents a nonconformance to a requirement must include a link to the corresponding GitHub Issue in the result comment.
• Environmental Failures: Failures caused by infrastructure (e.g., S3 timeout) rather than software bugs must be labeled as "Environmental" in the TestRail comment. Objective evidence of the environment issue must be provided, and a re-test must be executed once the environment is stable.
• Mandatory Defect Fields: Each GitHub Issue must record, at minimum:
  • Fix Version: (e.g., 1.1.0.0).
  • Labels: (e.g., bug, clinical-risk, commissioning).
  • Priority: (Urgency of the fix).
  • Severity: (Impact on medical safety or device performance).

Final Disposition

The Software Test Report (STR) must confirm that all defects linked during the v1.1.0.0 campaign have been resolved, mitigated, or deferred with a documented risk assessment.

Records retention

• Retention Period: All test evidence packs and exports—including TestRail Plan/Run exports, per-case results, local Unit/Integration logs, coverage reports, performance results, commissioning records (R-TF-029), and the root manifest file—are retained for a minimum of 10 years.
• System of Record: The authoritative repository for evidence packs is Amazon S3, organized by software version (e.g., v1.1.0.0/). Evidence integrity is maintained through S3 bucket versioning and the storage of a manifest.json containing a full inventory of artifacts and their cryptographic checksums.
• Execution Index: TestRail serves as the live execution record. For every regulated verification campaign, TestRail exports (CSV/PDF) are generated and archived within the corresponding versioned S3 folder to ensure the testing record remains accessible regardless of the live tool's state.
• Audit Trail Retention: Clinical and security audit records are retained indefinitely in DynamoDB. Retention is verified by ensuring no automated Time-to-Live (TTL) or expiry policies are active for audit tables. Audit data is immutable post-write; any administrative access or migration is performed under controlled change management with documented justification.
• Disposal: No test evidence or audit records shall be deleted during the defined retention period. Any exceptional disposal required by legal or data protection mandates must be handled as a controlled event, preserving the overall traceability and integrity of the device's regulatory history.

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-007
• Approver: JD-001

Annexes

• Annex A: Traceability matrix
• Annex B: Verification Test Cases Export

Annex A: Traceability matrix

SRS Id	SRS Name	Commit SHA	Test Case Id	Test Case Title	Reviewer	Review Status	Test Case URL
SRS-7PJ	Network Service Exposure	3e665d001836b7047732f81944bc46a1b78d4491	C50	Verify the API service accepts incoming HTTP requests on the designated network port	Gerardo Fernández	Approved	View
SRS-AQM	Standard HTTP Status Code Usage	5437d177ca46efc0a2aee07795a01f277e7d6309	C62	Verify API returns 200 HTTP status codes for successful requests	Gerardo Fernández	Approved	View
SRS-BYJ	JSON Data Interchange Format	5437d177ca46efc0a2aee07795a01f277e7d6309	C68	Verify API processes JSON requests and returns JSON responses with correct Content-Type headers	Gerardo Fernández	Approved	View
SRS-DW0	User Authentication Endpoint Implementation	9457a72ec5a38e1da7230ded0eab6009653e2d02	C77	Verify successful user authentication and token generation via the POST /auth/login endpoint	Gerardo Fernández	Approved	View
SRS-D3N	Provision of Clinical Parameter Endpoints	175ceb47259bb94067a1b32781d296431f3de0d2	C73	Verify retrieval and filtering of clinical signs data via /clinical/severity-experts endpoint	Gerardo Fernández	Approved	View
SRS-LBS	URL-Based API Versioning	c0e67a0f3c8791c893d82e34e250822316f1a1b6	C106	Verify API endpoints are accessible via URL paths prefixed with the major and minor version identifier	Gerardo Fernández	Approved	View
SRS-MZC	Request Body Size Limitation	45df8326922e46467821cd50f5ed256c1fc91265	C110	Verify the API returns HTTP 413 when the request body exceeds the configured maximum size	Gerardo Fernández	Approved	View
SRS-Q9M	Clinical Signs Analysis Endpoint Implementation	83628274c21ab0a9f5b8708a5ba260e704cf1f04	C124	Verify POST /clinical/severity-assessment returns quantified results for valid image and sign list	Gerardo Fernández	Approved	View
SRS-RXK	Diagnostic Support Endpoint Implementation	e0acb00226584d123dbf076320fa5c982bae3de4	C128	Verify the diagnosis-support endpoint accepts valid images and returns diagnostic analysis	Gerardo Fernández	Approved	View
SRS-ZQO	Concurrent API Version Support	c0e67a0f3c8791c893d82e34e250822316f1a1b6	C162	Verify simultaneous availability and processing of requests across distinct API versions	Gerardo Fernández	Approved	View
SRS-ID7	Input Data Validation	9ddd7569150f49e8a8e7bf7dea474fd0151d969f	C330	Verify API rejects malformed inputs with standardized 422 Unprocessable Entity responses	Gerardo Fernández	Approved	View
SRS-EH4	Security-Safe Error Handling	e73a2e5b9fb16994ed8863928fc1170d27c89ec2	C331	Verify API returns sanitized error responses with appropriate HTTP status codes and no internal details	Gerardo Fernández	Approved	View
SRS-AQM	Standard HTTP Status Code Usage	5437d177ca46efc0a2aee07795a01f277e7d6309	C454	Verify API returns 401 HTTP status codes for wrong login requests	Gerardo Fernández	Approved	View
SRS-AQM	Standard HTTP Status Code Usage	5437d177ca46efc0a2aee07795a01f277e7d6309	C455	Verify API returns 422 HTTP status code when invalid data is submitted	Gerardo Fernández	Approved	View
SRS-GER	System Behavior on Internal Component Failure.	1a0ccc9ff2e12bfabbb7416413594855054492a3	C456	Verification of controlled 503 response and graceful degradation during downstream service failure.	Gerardo Fernández	Approved	View
SRS-6KE	API Health Check Endpoint	67fcd201c0c34f02bf9a7f296f5d30b48a449bdf	C169	Verify health check endpoint returns unhealthy when some service is unavailable	Gerardo Fernández	Approved	View
SRS-6KE	API Health Check Endpoint	67fcd201c0c34f02bf9a7f296f5d30b48a449bdf	C46	Verify the public health endpoint returns HTTP 200 and status OK when operational	Gerardo Fernández	Approved	View
SRS-BA6	Display the legal information about this medical device	be09165d77882d22cd597701fc7208e781c4b4fd	C66	Verify retrieval of mandatory legal information, UDI, and regulatory metadata via API	Gerardo Fernández	Approved	View
SRS-Z24	API Documentation Endpoint	c5299af33cd65649bc9ac05042ddc2af2f27ec46	C159	Verify availability of OpenAPI specification and interactive documentation endpoints	Gerardo Fernández	Approved	View
SRS-Q3Q	Generate an aggregated ICD probability distribution from a set of images	ce07d6bc71d9381b29143f6991553e397e2af717	C255	Verify API returns aggregated ICD probability distribution with structured code details in studyAggregate array	Gerardo Fernández	Approved	View
SRS-0AB	Generate per-image ICD analysis with explainability heat map	bb4ee4ec42e52cc235bcbdd8b8521075e1522883	C256	Verify response includes per-image ICD probabilities and heat maps for the top five categories	Gerardo Fernández	Approved	View
SRS-58W	Include entropy score in report	66516edac9d596a17b83405b07e4b49a5ab9d25a	C258	Verify response includes normalized entropy score between 0 and 1 in findings	Gerardo Fernández	Approved	View
SRS-71I	Include the indicator of needing a high priority referral in the report	12c87e3ebe43cb2888704a822e151ed65ae08d03	C260	Verify report response includes highPriorityReferral score within riskMetrics object	Gerardo Fernández	Approved	View
SRS-8HY	Include the indicator of malignancy in the report	7a23b8e8e140bfc891a5a336b57503df3290c076	C261	Verify report response includes malignantConditionProbability score within riskMetrics object	Gerardo Fernández	Approved	View
SRS-D08	Include the indicator of the image presenting a pigmented lesion in the report	7a23b8e8e140bfc891a5a336b57503df3290c076	C262	Verify report response includes pigmentedLesion score within riskMetrics object	Gerardo Fernández	Approved	View
SRS-JLM	Include the indicator of the presence of a condition in the report	e1ff30861d0ca1d17a688780ffdc8416b08af50e	C263	Verify report response includes anyConditionProbability score within riskMetrics object	Gerardo Fernández	Approved	View
SRS-KAS	Include the indicator of needing an urgent referral in the report	12c87e3ebe43cb2888704a822e151ed65ae08d03	C264	Verify report response includes urgentReferral score within riskMetrics object	Gerardo Fernández	Approved	View
SRS-K7M	Orchestrate diagnosis support workflow	ccd236d6da920ea8518d49352917abde3a07e380	C265	Verify diagnosis workflow returns ranked ICD-11 codes, binary indicators, and explainability maps for valid images	Gerardo Fernández	Approved	View
SRS-A9F	Wound Bed Tissue - Epithelial	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C266	Verify epithelial tissue classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-B3Z	Inflammatory Pattern Identification	13d2f3fee665834cab27bf4c7775d70fc032e79f	C267	Verify API returns Hurley stage and inflammatory status with associated probabilities for valid image input	Gerardo Fernández	Approved	View
SRS-B6L	Wound Bed Tissue - Necrotic	69f87eca8bd38d25b519b7b3ae45a8b57ef87d37	C268	Verify tissue wound bed necrotic classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-B8N	Pustule Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C269	Verify pustule classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-A4W	Inflammatory Nodular Lesion Quantification	9aa3c03db45e210c2e0ebf416de2b4313876d0dd	C270	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for drainning tunnels	Gerardo Fernández	Approved	View
SRS-A6T	Delimited Wound Edges Assessment	0b81afcee7dfbb8aa6c62ad3642235d545c017f9	C271	Verify wound borders delimited classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-C1R	Serous Exudate Assessment	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C272	Verify wound exudation serous classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-D7N	Purulent Exudate Assessment	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C274	Verify wound exudation purulent classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-D9T	Maceration Surface Quantification	cd6d5708a7544686f7423a834ed3aa128f84cf1f	C275	Verify wound maceration segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-E4R	Erythema Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C276	Verify erythema classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-Y6F	Crusting Intensity Quantification	fafd6724110f48c2a14b22d8899654fec857e6cf	C277	Verify crusting classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-F2K	Thickened Wound Edges Assessment	0b81afcee7dfbb8aa6c62ad3642235d545c017f9	C278	Verify thickened wound borders classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-T3K	Induration Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C279	Verify induration classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-F6J	Hair Loss Surface Quantification	80aca9ea492b4a00d38fb9475f641d95ca7538f9	C280	Verify hair loss segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-G3P	Wound Perilesional Erythema Assessment	524ed8f71f74ccb494929fd9fd2d79649e755d99	C281	Verify wound perilesional erythema classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-G9R	Wound Stage Classification	1c08ac0744595495e59baf99844d92ca240e36af	C282	Verify wound stage classification returns right score and confidence metrics from a valid wound image	Gerardo Fernández	Approved	View
SRS-H5K	Erythema Surface Quantification	524ed8f71f74ccb494929fd9fd2d79649e755d99	C283	Verify erythema segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-H9X	Lichenification Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C284	Verify lichenification classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-I7T	Wound Affected Tissue - Intact Skin	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C285	Verify wound affected tissues intact classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-J5P	Hair Follicle Quantification	3da6d2f72803c32efa59bd6330f16e472e1dffb5	C286	Verify API returns follicle count, bounding boxes, and confidence scores for a valid scalp image	Gerardo Fernández	Approved	View
SRS-J9V	Indistinguishable Wound Edges Assessment	0b81afcee7dfbb8aa6c62ad3642235d545c017f9	C287	Verify wound borders indistinguishable classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-K3H	Wound Affected Tissue - Subcutaneous	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C288	Verify wound affected tissues subcutaneous classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-K4U	Orthopedic Material Surface Quantification	ac4cc1b8609bc67fb67de904cae2305a35000eb3	C289	Verify wound orthopedic material segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-L4W	Damaged Wound Edges Assessment	0b81afcee7dfbb8aa6c62ad3642235d545c017f9	C290	Verify wound borders damaged classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-L8Y	Biofilm and Slough Surface Quantification	6b479d5371886e425abf08bd1fa0fe9db1851b27	C291	Verify wound biofilm material segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-M2L	Xerosis Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C292	Verify xerosis classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-M6P	Granulation Tissue Surface Quantification	4b3ed220fbc0dac3ac8ba4ed25dc854824596a8d	C293	Verify wound granulation segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-N2C	Bone Surface Segmentation	21985a46323f455af83abb1de509450461fb8945	C294	Verify wound bone segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-N5Q	Swelling Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C295	Verify swelling classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-N8W	Wound Affected Tissue - Dermis-Epidermis	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C296	Verify wound exudation serous classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-O5M	Wound Affected Tissue - Muscle	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C297	Verify wound affected tissues muscle classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-L3X	Skin Surface Segmentation	6402f7f36831b49314b9b1602e4a928cfc6c771e	C298	Verify skin segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-Z5N	Hive Lesion Quantification	b43e1688a3b7bd57bebe34920cbdf4382ac5a463	C299	Verify hive detector return correct counts and bounding boxes for hives	Gerardo Fernández	Approved	View
SRS-Z8P	Biofilm-Compatible Tissue Assessment	6b479d5371886e425abf08bd1fa0fe9db1851b27	C300	Verify wound biofilm tissue classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-P4X	Wound Bed Tissue - Slough	6b479d5371886e425abf08bd1fa0fe9db1851b27	C302	Verify tissue wound bed slough classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-P9W	Desquamation Intensity Quantification	7b50a8f3820cd7e662dcfc14c8c6d003f9c704a9	C303	Verify desquamation classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-Q1L	Hypopigmentation or Depigmentation Surface Quantification	9a0390133a15a446f1eef9a4aeda874fdd747902	C304	Verify hypopigmentation segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-Q8Z	Diffuse Wound Edges Assessment	0b81afcee7dfbb8aa6c62ad3642235d545c017f9	C305	Verify wound borders diffused classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-R3W	Wound Bed Surface Quantification	98cf89c1cea8c7a15217017e778fdb2aebfe91cb	C306	Verify wound bed segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-R7C	Oozing Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C307	Verify oozing classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-S2V	Wound Affected Tissue - Bone	21985a46323f455af83abb1de509450461fb8945	C308	Verify wound affected tissues bone classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-S8M	Acneiform Lesion Type Quantification	e8e6d9d811a14cfb28c0280ad89ad897b3195237	C309	Verify acneiform detector return correct counts and bounding boxes for papules, pustules, spots	Gerardo Fernández	Approved	View
SRS-T6H	Wound AWOSI Score Quantification	1c08ac0744595495e59baf99844d92ca240e36af	C310	Verify AWOSI classification returns right score and confidence metrics from a valid wound image	Gerardo Fernández	Approved	View
SRS-T9U	Wound Bed Tissue - Closed	3cc2af57186b3e2d6e104bbd4d0fa453bb933a05	C311	Verify tissue wound bed closed classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-U4M	Perilesional Maceration Assessment	cd6d5708a7544686f7423a834ed3aa128f84cf1f	C312	Verify wound perilesional maceration classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-U8Z	Nail Lesion Surface Quantification	c9bff523adf85be5af207f9249ef5f0d69d47a12	C313	Verify nail lesion segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-V1D	Excoriation Intensity Quantification	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C314	Verify excoriation classification returns right intensity and confidence	Gerardo Fernández	Approved	View
SRS-V7Q	Necrosis Surface Quantification	69f87eca8bd38d25b519b7b3ae45a8b57ef87d37	C315	Verify wound necrosis segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-W3R	Hyperpigmentation Surface Quantification	492182224cc07eb6b28363eeda7d44d7650a6c9d	C316	Verify hyperpigmentation segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-W9K	Bloody Exudate Assessment	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C317	Verify wound bloody exudation classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-X5B	Fibrinous Exudate Assessment	8a90efa14fb67f3f8ae28a1561537d8b46f13f1f	C318	Verify wound exudation fibrinous classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-X8Q	Follicular and Inflammatory Pattern Identification	3da6d2f72803c32efa59bd6330f16e472e1dffb5	C319	Verify follicular and inflammatory pattern identification returns right result	Gerardo Fernández	Approved	View
SRS-Y2E	Wound Bed Tissue - Granulation	4b3ed220fbc0dac3ac8ba4ed25dc854824596a8d	C320	Verify wound tissue wound bed granulation classification returns right presence prediction and confidence score	Gerardo Fernández	Approved	View
SRS-W6T	Orchestrate Clinical Signs Analysis Workflow	ccd236d6da920ea8518d49352917abde3a07e380	C321	Verify generation of structured clinical assessment report with quantified results for requested signs via API	Gerardo Fernández	Approved	View
SRS-E1V	Body Surface Segmentation	3089eb6b2b1f76b9df0498e37cf2b05ac05cbeb6	C325	Verify body surface segmentation analysis returns segmentation masks and the right percentage of surface affected	Gerardo Fernández	Approved	View
SRS-S8M	Acneiform Lesion Type Quantification	e8e6d9d811a14cfb28c0280ad89ad897b3195237	C446	Verify acneiform detector return correct counts and bounding boxes for nodules, pustules and scabs	Gerardo Fernández	Approved	View
SRS-S8M	Acneiform Lesion Type Quantification	e8e6d9d811a14cfb28c0280ad89ad897b3195237	C447	Verify acneiform detector return correct counts and bounding boxes for scabs, comedones, papules and pustules	Gerardo Fernández	Approved	View
SRS-Z5N	Hive Lesion Quantification	b43e1688a3b7bd57bebe34920cbdf4382ac5a463	C448	Verify hive detector return correct counts and bounding boxes for hives (second image)	Gerardo Fernández	Approved	View
SRS-A4W	Inflammatory Nodular Lesion Quantification	9aa3c03db45e210c2e0ebf416de2b4313876d0dd	C449	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for non drainning tunnels	Gerardo Fernández	Approved	View
SRS-A4W	Inflammatory Nodular Lesion Quantification	9aa3c03db45e210c2e0ebf416de2b4313876d0dd	C450	Verify inflammatory nodular lesion detector return correct counts and bounding boxes for nodules	Gerardo Fernández	Approved	View
SRS-H2V	Head Detection	d696b2e9d092bfea4a77f88806660c119cbf7b88	C323	Verify head detection returns right bounding boxes and heads count inside an image	Gerardo Fernández	Approved	View
SRS-9ZT	The product classifies the image's modality	9316f7a8be2d571d85c8a0ddec7efba1cd488443	C327	Verify API returns ""clinical"" for image modality category when a skin image is provided	Gerardo Fernández	Approved	View
SRS-O93	The product checks the image's clinical domain	9316f7a8be2d571d85c8a0ddec7efba1cd488443	C328	Verify API returns image domain category equals to ""dermatological"" and confidence score for a skin image	Gerardo Fernández	Approved	View
SRS-Y5W	The product checks the image quality with the Dermatological Image Quality Assessment (DIQA) algorithm	ea193ffa19a80d2322d0fbd7d22fe17ca1f45571	C329	Verify API returns dermatological image quality score, interpretation, and acquisition feedback	Gerardo Fernández	Approved	View
SRS-9ZT	The product classifies the image's modality	9316f7a8be2d571d85c8a0ddec7efba1cd488443	C451	Verify API returns ""dermoscopic"" for image modality category when a skin image is provided	Gerardo Fernández	Approved	View
SRS-O93	The product checks the image's clinical domain	9316f7a8be2d571d85c8a0ddec7efba1cd488443	C452	Verify API returns image domain category equals to ""non_dermatological"" and confidence score for a dog image	Gerardo Fernández	Approved	View
SRS-F05	Generate FHIR DiagnosticReport Base Structure	866081f8469c001d52f6d7ca4493dbd2b820f9f4	C453	Verify FHIR DiagnosticReport base structure for a segmenter	Gerardo Fernández	Approved	View
SRS-1KW	Secure Communication Protocol Enforcement	45df8326922e46467821cd50f5ed256c1fc91265	C332	Verify API accepts requests over HTTPS using TLS 1.2 or 1.3	Gerardo Fernández	Approved	View
SRS-1KW	Secure Communication Protocol Enforcement	45df8326922e46467821cd50f5ed256c1fc91265	C333	Verify API rejects or redirects unencrypted HTTP requests	Gerardo Fernández	Approved	View
SRS-28X	Implement progressive delays between failed login attempts	ae97659c200e930e6d482ada87d85320eb6b980d	C335	Verify progressive increase in enforced delay across consecutive failed authentication attempts	Gerardo Fernández	Approved	View
SRS-28X	Implement progressive delays between failed login attempts	ae97659c200e930e6d482ada87d85320eb6b980d	C336	Verify delay resets upon successful authentication	Gerardo Fernández	Approved	View
SRS-A25	Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions	56792dc7766f00e6c3cd7f07da45da4808739d82	C337	Verify successful access to permitted endpoints for an authorized role	Gerardo Fernández	Approved	View
SRS-A25	Role-Based Access Control (RBAC) with Least Privilege Principle to restrict users to essential functions	56792dc7766f00e6c3cd7f07da45da4808739d82	C338	Verify access denial for endpoints outside the assigned role scope	Gerardo Fernández	Approved	View
SRS-A2B	API Rate Limiting	05a6336f79c149468746b6b212d597b7d5c1eb76	C339	Verify HTTP 403 response when request volume exceeds defined threshold	Gerardo Fernández	Approved	View
SRS-A2B	API Rate Limiting	05a6336f79c149468746b6b212d597b7d5c1eb76	C340	Verify request acceptance after rate limit time window expiration	Gerardo Fernández	Approved	View
SRS-MM8	Generated JWTs must have an expiration date	0fb498ac02a4da9cf0c06e2311082a8876ad246e	C341	Verify generated authentication tokens include the expiration claim	Gerardo Fernández	Approved	View
SRS-MM8	Generated JWTs must have an expiration date	0fb498ac02a4da9cf0c06e2311082a8876ad246e	C342	Verify access denial for requests using an expired JWT	Gerardo Fernández	Approved	View
SRS-SDZ	Use hashed and salted passwords	dfbc23d18a8ad4e1026b749c2357e213aa2935ae	C343	Verify generation of authentication token using valid credentials	Gerardo Fernández	Approved	View
SRS-SDZ	Use hashed and salted passwords	dfbc23d18a8ad4e1026b749c2357e213aa2935ae	C344	Verify rejection of authentication requests with invalid credentials	Gerardo Fernández	Approved	View
SRS-SDZ	Use hashed and salted passwords	dfbc23d18a8ad4e1026b749c2357e213aa2935ae	C345	Verify password update functionality and subsequent authentication	Gerardo Fernández	Approved	View
SRS-TPK	Lock accounts after five failed attempts	b60cff1087fe074f380a201655ba882b3ca9d32b	C346	Verify account lockout enforcement after threshold reached	Gerardo Fernández	Approved	View
SRS-TPK	Lock accounts after five failed attempts	b60cff1087fe074f380a201655ba882b3ca9d32b	C347	Verify failed attempt counter reset on successful login	Gerardo Fernández	Approved	View
SRS-TPK	Lock accounts after five failed attempts	b60cff1087fe074f380a201655ba882b3ca9d32b	C348	Verify administrative manual account unlock capability	Gerardo Fernández	Approved	View
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	f620de037a1e1c3b92d9ececc17b6f15cba83b4f	C349	Verify enforcement of password complexity and length constraints	Gerardo Fernández	Approved	View
SRS-U8M	Enforce strong password policies (min. 12 characters, complexity rules, expiration policies)	f620de037a1e1c3b92d9ececc17b6f15cba83b4f	C350	Verify authentication behavior for expired passwords	Gerardo Fernández	Approved	View
SRS-WER	Endpoint Access Control	c5299af33cd65649bc9ac05042ddc2af2f27ec46	C351	Verify protected endpoints allow access with a valid OAuth 2.0 Bearer token	Gerardo Fernández	Approved	View
SRS-WER	Endpoint Access Control	c5299af33cd65649bc9ac05042ddc2af2f27ec46	C352	Verify protected endpoints reject requests lacking a valid token with 401 Unauthorized	Gerardo Fernández	Approved	View
SRS-WER	Endpoint Access Control	c5299af33cd65649bc9ac05042ddc2af2f27ec46	C353	Verify public endpoints are accessible without an Authorization header	Gerardo Fernández	Approved	View
SRS-WGF	AES-256 encryption for data at rest	d053992d42d60f71a88a28d3e56ea6da46294a5f	C354	Verify AES-256 encryption configuration for data storage	Gerardo Fernández	Approved	View
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	f620de037a1e1c3b92d9ececc17b6f15cba83b4f	C355	Verify authorized administrator can retrieve current user information for review	Gerardo Fernández	Approved	View
SRS-X9J	Conduct periodic access reviews to verify permissions align with job functions	f620de037a1e1c3b92d9ececc17b6f15cba83b4f	C356	Verify authorized administrator can revoke permissions during access review	Gerardo Fernández	Approved	View
SRS-IC4	Software and Configuration Integrity Verification	dc4180b5afa19d3b2bac9c1805f1b65eed2ab8bb	C357	Verify successful execution and audit logging of system integrity checks	Gerardo Fernández	Approved	View
SRS-BK7	Encrypted Backup and Integrity Verification	d053992d42d60f71a88a28d3e56ea6da46294a5f	C363	Verify backup generation	Gerardo Fernández	Approved	View
SRS-BK7	Encrypted Backup and Integrity Verification	d053992d42d60f71a88a28d3e56ea6da46294a5f	C364	Verify automated backup generation	Gerardo Fernández	Approved	View
SRS-CCD	Intrusion Prevention and Malicious Traffic Detection	45df8326922e46467821cd50f5ed256c1fc91265	C366	Verify blocking of anomalous high-frequency request bursts	Gerardo Fernández	Approved	View
SRS-F05	Generate FHIR DiagnosticReport Base Structure	866081f8469c001d52f6d7ca4493dbd2b820f9f4	C368	Verify FHIR DiagnosticReport base structure for a detector	Gerardo Fernández	Approved	View
SRS-FMG	Record Analysis Duration in Report	ef4c4f23bc67f3e0ab17075c219294dc8ff39fa1	C369	Verify analysisDuration field population in DiagnosticReport	Gerardo Fernández	Approved	View
SRS-JC6	The product provides a final image validity summary	ea193ffa19a80d2322d0fbd7d22fe17ca1f45571	C370	Verify isAssessable is true when domain and quality criteria are met	Gerardo Fernández	Approved	View
SRS-JC6	The product provides a final image validity summary	ea193ffa19a80d2322d0fbd7d22fe17ca1f45571	C371	Verify isAssessable is false when image quality is unacceptable	Gerardo Fernández	Approved	View
SRS-JC6	The product provides a final image validity summary	ea193ffa19a80d2322d0fbd7d22fe17ca1f45571	C372	Verify isAssessable is false when image is non-dermatological	Gerardo Fernández	Approved	View
SRS-K6N	Map Per-Image Analysis to a dedicated object in the report	c7651f8d92ca3b2231bf87c202edb67903ca164a	C373	Verify single image analysis maps to structured object in imageAnalyses array	Gerardo Fernández	Approved	View
SRS-K6N	Map Per-Image Analysis to a dedicated object in the report	c7651f8d92ca3b2231bf87c202edb67903ca164a	C374	Verify multiple image analyses map to distinct objects in imagingAnalysis array	Gerardo Fernández	Approved	View
SRS-H3J	Deterministic Response Schemas	9ddd7569150f49e8a8e7bf7dea474fd0151d969f	C375	Verify response structure compliance with OpenAPI success schema	Gerardo Fernández	Approved	View
SRS-H3J	Deterministic Response Schemas	9ddd7569150f49e8a8e7bf7dea474fd0151d969f	C376	Verify response structure compliance with OpenAPI error schema	Gerardo Fernández	Approved	View
SRS-W5Z	Assign DiagnosticReport Identifier	7c98fffc302ad65ccecb6237d6579ea5dc9c6d04	C377	Verify Assignment of Official Identifier to DiagnosticReport	Gerardo Fernández	Approved	View
SRS-W5Z	Assign DiagnosticReport Identifier	7c98fffc302ad65ccecb6237d6579ea5dc9c6d04	C378	Verify Uniqueness of Generated DiagnosticReport Identifiers	Gerardo Fernández	Approved	View
SRS-D6W	Accurate Time Synchronization	107088729759f59e8b256bc374b3553b28c4ac47	C382	Verify System Timestamp Accuracy via API Response Headers	Gerardo Fernández	Approved	View
SRS-D6W	Accurate Time Synchronization	107088729759f59e8b256bc374b3553b28c4ac47	C383	Verify System Time Synchronization and Accuracy Status	Gerardo Fernández	Approved	View
SRS-SI2	Secure Audit Trail Access Interface	d053992d42d60f71a88a28d3e56ea6da46294a5f	C388	Verify Role-Based Access Control for Audit Trail Interface	Gerardo Fernández	Approved	View
SRS-SI2	Secure Audit Trail Access Interface	d053992d42d60f71a88a28d3e56ea6da46294a5f	C389	Verify Audit Trail Search and Export Capabilities	Gerardo Fernández	Approved	View
SRS-T5P	Audit Record Integrity Protection	d053992d42d60f71a88a28d3e56ea6da46294a5f	C391	Verify audit records cannot be modified or deleted via API	Gerardo Fernández	Approved	View
SRS-PU2	Comprehensive Event Auditing	d053992d42d60f71a88a28d3e56ea6da46294a5f	C395	Verify audit trail generation for authentication lifecycle and security anomalies	Gerardo Fernández	Approved	View
SRS-U2P	Consolidated Audit Record Content	ccce090b3840da989088cd689cfa68e49ace8825	C398	Verify audit record completeness for successful API event	Gerardo Fernández	Approved	View
SRS-U2P	Consolidated Audit Record Content	ccce090b3840da989088cd689cfa68e49ace8825	C399	Verify audit record completeness for failed API event	Gerardo Fernández	Approved	View
SRS-PU2	Comprehensive Event Auditing	d053992d42d60f71a88a28d3e56ea6da46294a5f	C410	Verify audit trail generation for clinical data creation events	Gerardo Fernández	Approved	View
SRS-T95	Audit System Failure Handling	1a0ccc9ff2e12bfabbb7416413594855054492a3	C413	Audit record preservation during database unavailability	Gerardo Fernández	Approved	View
SRS-BWB	Performance and Latency	ef4c4f23bc67f3e0ab17075c219294dc8ff39fa1	C416	Verify p95 API latency remains under 10 seconds during nominal load	Gerardo Fernández	Approved	View

Annex B: Verification Test Cases Export

• File: test_rail_verification_tests.csv