Remote Treatment Monitoring Intelligence Layer

Async monitoring → explainable signals → clinician review

A production-oriented prototype for converting remote treatment monitoring submissions into structured, auditable decision-support signals for clinician prioritization.

Architecture | Demo Workflow | Engineering Overview | Validation

---

Why This Exists

Remote treatment monitoring produces asynchronous patient submissions that clinicians need to review efficiently. The system converts those submissions into structured quality, view, longitudinal, and timing signals so clinicians can prioritize review while retaining complete control over the final decision.

Prototype / Decision Support: This is a technical prototype, not a medical diagnostic system. AI/CV outputs are decision-support signals only, and clinical decisions remain with qualified clinicians.

---

1. The Problem

In teledentistry and remote orthodontic monitoring, patients asynchronously submit monitoring photographs at regular intervals. Clinicians are tasked with reviewing hundreds of these submissions daily. The workflow problem is twofold:

1. Administrative Overhead: Reviewing compliance and image quality manually consumes valuable clinical time.
2. Lack of Prioritization: Clinicians lack an automated way to screen for incomplete uploads, blurry photos, or tracking deviations before manually inspecting a case.

The RTM Intelligence Layer solves this by automatically flagging quality and view anomalies, allowing clinicians to focus first on cases that require immediate retakes or clinical escalation. It does NOT diagnose dental disease, automate clinical decision-making, or replace clinicians.

---

2. The Solution

The system isolates automated signal generation from final clinician decision-making:

Patient Submission
        ↓
     Go API
        ↓
  202 Accepted
        ↓
   Redis Queue
        ↓
    Go Worker
        ↓
 CV / ML Analysis
        ↓
Quality + View Validation
        ↓
Longitudinal Comparison
        ↓
Explainable Triage
        ↓
 Clinician Review
        ↓
  Human Decision
        ↓
   Audit Trail

By returning 202 Accepted immediately upon upload validation, the patient experience remains low-latency, while heavy computations (blur analysis, brightness parsing, ONNX neural net classification, longitudinal comparative hashing) are processed asynchronously in the queue.

---

3. Architecture

The following diagram represents the actual containerized services in the repository:

                    PATIENT
                       │
                       ▼
              React Patient Portal
                       │
                       ▼
                Go API Gateway
                       │
                  202 Accepted
                       │
                       ▼
                  Redis Queue
                       │
                       ▼
                 Go Worker
                  /       \
                 /         \
                ▼           ▼
       Python CV Service   PostgreSQL
          /        \
         ▼          ▼
      OpenCV       ONNX
         \          /
          ▼        ▼
       Quality + ML Signals
                │
                ▼
        Explainable Triage
                │
                ▼
       Clinician Workspace
                │
                ▼
       Human Review / Action
                │
                ▼
           Audit Trail

---

4. Engineering Decisions

• Go: Selected for the API Gateway and background worker because of its compiled speed, extremely low memory usage, and native concurrency mechanisms (goroutines). This enables efficient handling of WebSocket connections and high-throughput background queues.
• Redis: Serves as the asynchronous job queue (BLPop blocking consumer) and Pub/Sub broker, decoupling photo uploads from heavy image processing and facilitating real-time WebSocket synchronization across instances.
• Python: Serves as the microservice runner for computer vision (fastapi + OpenCV), grouping libraries like NumPy and OpenCV in a stable, isolated environment without bloating the Go binary or introducing Cgo bindings.
• ONNX Runtime: Serializes and serves the trained MobileNetV3-Small model. Using ONNX decouples model training (PyTorch) from serving, allowing lightweight inference on the CPU without requiring a GPU or a PyTorch package dependency.
• PostgreSQL: Serves as the relational system of record, storing patient profiles, active aligner stages, signals, explainable scoring metrics, and audit trail events inside transactional database blocks.
• WebSockets: Feeds real-time queue notifications and priority updates to the clinician dashboard immediately when the background worker commits assessments.

---

5. Core Product Workflow

The local demonstration scenario contains pre-seeded credentials:

• Patient Portal: patient_demo_1 / password123
• Clinician Portal: clinician_demo_1 / password123

Steps:

1. Patient Login: Log in as patient_demo_1.
2. View Protocol: Observe that the current treatment protocol requires FRONT, LEFT, and RIGHT views.
3. Upload Available Images: Choose image files for FRONT and LEFT, but intentionally leave RIGHT missing.
4. Confirm Image Integrity: Check the mandatory box: "I confirm these images have not been digitally modified."
5. Submit: Click submit. Confirm the warning dialog regarding the missing RIGHT view.
6. 202 Accepted Response: The client receives a 202 Accepted response immediately. The portal displays an active pipeline stepper: Submission received → Added to queue → Running Quality Checks → Running Triage Scoring
7. Background Processing: The worker dequeues the files, triggers CV analysis, runs longitudinal comparison against the previous approved stage, and calculates the triage score.
8. Clinician Dashboard: Sign out and log in as clinician_demo_1. The new card appears in the queue in real-time.
9. Triage Inspection: View the priorities and score contributors (+40 for missing required view).
10. Visual Comparison: Inspect the CURRENT STAGE vs PREVIOUS APPROVED STAGE side-by-side comparator showing visual change signals.
11. Review Telemetry: Observe the ML/Heuristic analysis telemetry card.
12. Record Verdict: Type notes, defocus input, and press keyboard shortcut R (Request Photos).
13. Audit Trail: Scroll down to verify the append-only audit trail logs the review transaction.

---

6. Explainable Triage

Scores are calculated deterministically on the backend (Ruleset: triage-v1):

• Base Score: 0
• Missing Required View: +40
• Poor Quality (Blur/Exposure): +30
• Stage Timing Deviation: +15
• Previous Retake Requested: +15
• Clamping: Clamped at a maximum of 100.

Demo Scenario Math:

0 (Base) + 40 (Missing RIGHT view) + 15 (Stage timing deviation) = 55 (MEDIUM Priority)

Recommendation: REVIEW
Priority level: MEDIUM (Scores 30-59)

---

7. Longitudinal Monitoring

The comparator enables a detailed audit of progress photos against the last completed and approved stage:

CURRENT STAGE
      ↕
PREVIOUS APPROVED STAGE

Available Signals:

• Similarity Index: Perceptual similarity score computed using 64-bit average hashing (aHash).
• Perceptual Difference: Relative Hamming distance between current and approved image hashes.
• Image Availability: Identifies if a comparative baseline image exists.
• Quality Status: Logs blur and exposure parameters of the current photo.
• Stage Timing: Registers days since the last clinician approval.

Visual comparison is a decision-support signal and is not a clinically validated determination of treatment outcome. [Decision Support Only]

---

8. ML Architecture

The view classification pipeline is structured as follows:

Dataset
   ↓
Leakage Audit
   ↓
Train / Validation / Test Split
   ↓
PyTorch
   ↓
MobileNetV3-Small
   ↓
ONNX Export
   ↓
ONNX Runtime / CPU
   ↓
CV Service
   ↓
Clinician Workspace

Telemetry Display:

The clinician dashboard renders the active model configuration or heuristic fallback:

• ML Active:

  Analysis Method: ML
  Model: MobileNetV3-Small
  Version: view-classifier-v1
  Inference: ONNX Runtime / CPU
  

• Heuristic Fallback:

  Analysis Method: HEURISTIC
  Model: heuristic-v1
  Reason: ML inference unavailable (confidence < 0.85 threshold)
  

---

9. ML Validation — Honest Presentation

The current ML validation demonstrates training, export, runtime inference, integration, and dataset integrity checks. The available seed dataset is insufficient to estimate clinical generalization performance.

Verified Dataset Integrity Audit:

• Patient-level splits: 0 subject overlaps (integrity verified).
• Exact Duplicates: 0 duplicate SHA-256 hashes (integrity verified).
• Perceptual Duplicates: 0 cross-split duplicate aHash values (integrity verified).

---

10. External Validation

The independent validation report is available in EXTERNAL_DATASET_VALIDATION_REPORT.md.

Known CV Limitations:

• Laplacian Blur Sensitivity: Large intraoral photographs with smooth tooth surfaces and soft lighting gradients can naturally produce low Laplacian variance. The current blur heuristic therefore requires calibration against representative clinical imagery.
• Heuristic Thresholds: Basic thresholds serve as a priority triage filter rather than a diagnostic standard.

---

11. Testing & Verification

The verification commands have been executed and validated:

Component	Verification	Result
Go	Unit tests	PASS (go test ./...)
Go	Race detector	PASS (go test -race ./...)
Python	Pytest	PASS (pytest)
Frontend	Production build	PASS (npm run build / zero build warnings)
E2E	Playwright flows	PASS (node e2e_test.js)
Security	Path traversal review	PASS (storage.go Rel validation checks)
Dataset	Leakage audit	PASS (check_leakage.py duplicate audits)

---

12. Security

The prototype implements the following security controls:

• JWT & RBAC: Gateway verifies role permissions (PATIENT or CLINICIAN) embedded in signed JWT tokens.
• Bcrypt Hashing: Passwords are fully salted and hashed using Bcrypt (cost factor 12) before database write.
• Upload Validation: Capped at 10MB; gateway uses http.DetectContentType magic-byte inspection to verify image/jpeg or image/png types.
• Path Traversal Prevention: The file storage system cleans keys using filepath.Clean and validates that the resolved path is sub-nested under the base storage root using filepath.Rel:

  rel, err := filepath.Rel(s.basePath, fullPath)
  if err != nil || strings.HasPrefix(rel, "..") {
      return filepath.Join(s.basePath, filepath.Base(cleanKey))
  }

• SQL Parameterization: Queries use PGX parameter syntax ($1, $2), preventing SQL injection vectors.
• CORS Policies: Configured restricted origin maps for local dev tools.

---

13. Product Walkthrough

The following screenshots (available in docs/screenshots/) demonstrate the complete end-to-end user flow:

1. Portal Login

Clinician and patient login interface with Bcrypt credentials validation.

2. Patient Progress Dashboard

Patient portal detailing treatment protocol, instructions, and stages progress.

3. Required/Optional View checklist

Image upload section displaying view criteria, format guidelines, and safety integrity check.

4. Asynchronous Processing Stepper

Live pipeline steps tracking database audit events as they complete.

5. Priority Feedback Result

Patient visual feedback showing queued status and quality warning alerts.

6. Clinician Priority Review Queue

Dashboard showing incoming submissions sorted by prioritized triage scores.

7. Longitudinal Comparison & ML Telemetry

Comparator displaying visual change signal, telemetry card details, and rule weights.

8. Clinician Review Action

Clinician notes panel and keyboard shortcuts trigger to request photo retakes.

9. System Audit Trail

Relational database audit history showing all lifecycle timestamps.