Use Case 002 - PASI demo calculator using clinical-signs models

1. Identifier

• UC ID: VAL-UC-002
• Title: PASI demo calculator using clinical-signs models

2. Purpose and Coverage

• Intended use covered: Combine models to estimate erythema (E), induration (I) and desquamation (D) from a lesion image, then compute a PASI-like severity score using a user-provided % affected area; show lesion segmentation and per-image quality.
• System requirements covered: SRS-W6T (orchestrate clinical-signs workflow), SRS-E4R (erythema), SRS-T3K (induration), SRS-P9W (desquamation), SRS-Y5W / SRS-2VA (DIQA quality), SRS-JC6 (final image validity), SRS-1KW / SRS-038 (secure transport), SRS-BYJ / SRS-042 (JSON), SRS-AQM / SRS-046 (HTTP codes), SRS-DW0 / SRS-067 (login), SRS-WER / SRS-047 (endpoint access control), SRS-BWB / SRS-045 (latency).
• Validation scope: End-to-end flow (frontend → backend → medical-device API → backend → frontend), including auth, quality screening, three clinical-signs calls, segmentation display, and PASI computation.

3. Method & Acceptance

• Validation method: Functional testing with predefined datasets (per the validation plan's method/acceptance selection).
• Input information (datasets, configs):
  • Healthy skin image; psoriasis mild, moderate, severe (one each).
  • Non-skin image; low-quality dermatology image.
• Objective acceptance criteria:
  1. Quality gate: images below the DIQA threshold are rejected; UI shows a per-image quality error; no signs analysis runs on rejected images.
  2. Clinical signs outputs: backend performs 3 API calls (E/I/D) for valid images; response includes quality score and sufficient-quality flag; UI displays E, I, D and the segmentation artifact.
  3. PASI computation: $R = 0.5 \times (E + I + D) \times \text{Area}$; UI displays the resulting score.
  4. Security/transport: HTTPS/TLS enforced; JSON payloads; protected endpoints require a valid JWT obtained via /login.
  5. Performance: end-to-end p95 latency under nominal load < 10 000 ms.

4. Enablers & Environment

• Operating environment(s):
  • Frontend: Next.js 16 (Vercel).
  • Backend: Node.js service.
  • Medical-device API: Docker on AWS, release v1.1.0.0.
• IT-NETWORK specifics:
  • TLS ≥ 1.2 over 443; JSON; base64 images.
  • JWT expiry: 1 hour; max request size: 10 MB.
  • Information flow: Frontend → Backend → API (/login, clinical-signs endpoints) → Backend → Frontend.

5. Roles & Independence

• Validation personnel: JD-007 (Technology Manager with medical-software validation experience).
• Independence level: Independent of the development team within the organization.

6. Preconditions & Setup

• Preconditions: Software release v1.1.0.0 frozen; IFU and Technical Description available; baseline risk file approved.
• Configuration: API endpoints enabled; HTTPS enforced; frontend requires no user login.

7. Procedure

1. Start the PASI demo app.
2. Upload a lesion image and enter % affected area; include non-skin and low-quality samples for rejection checks.
3. Backend obtains JWT via /login and invokes the three clinical-signs endpoints (E/I/D).
4. Verify low-quality images are rejected with a UI quality error; valid images proceed to analysis.
5. Confirm UI shows E, I, D, the segmentation, the quality score, and the computed PASI using $R = 0.5 \times (E + I + D) \times \text{Area}$.
6. Execute on healthy, mild, moderate, and severe psoriasis samples.
7. Record performance (p95 latency) under nominal load.

• Data capture: Request/response IDs and timestamps; model/API version; JWT events; per-image quality scores; E/I/D values; segmentation artifact (file/URL); HTTP status codes; UI screenshots (rejections and final report); backend/API logs; audit entries.

8. Risks & Constraints

• Known limitations/constraints impacting feasibility: None identified for this validation run.
• IT-NETWORK hazardous situations considered: None identified for this validation run.

9. Traceability

• Links: Intended use (PASI-like severity demonstration) → SRS (as listed) → VAL-UC-002.

10. Expected Evidence

• Results to record: Test conditions and outcomes per dataset; anomalies (if any) with references; validator identity and date.
• Residual risk status: Acceptable if all acceptance criteria are met and no unresolved anomalies remain.

11. Deviation & Re-validation Rules

• Deviation handling: Any deviation is justified and logged in the validation report.
• Anomaly handling & re-validation trigger: Repeat affected parts if criteria are not met; re-validate upon changes to API, AI model, or configuration affecting functionality or performance.