Privacy by Design: Client-Side Medical AI Processing

The Privacy Problem in Medical AI

Every medical AI product faces the same fundamental tension: AI models need patient data to provide clinical value, but patient data is the most sensitive category of personal information under virtually every privacy regulation worldwide.

The conventional architecture — upload images to a cloud server, run inference, return results — creates a cascade of compliance requirements. Under KVKK (Turkey's data protection law), GDPR (EU), and HIPAA (US), transmitting patient imaging data to an external server triggers obligations around data processing agreements, encryption in transit and at rest, access controls, audit logging, breach notification, and cross-border transfer restrictions.

For a startup building medical AI, the compliance burden of server-side processing can consume more engineering time and legal cost than building the AI itself.

The Alternative: Process Everything in the Browser

Client-side processing inverts the architecture. Instead of sending the patient's data to the model, the model is sent to the patient's data. The AI runs entirely within the surgeon's web browser. The patient's DICOM images are loaded locally, processed locally, and the results are displayed locally. No pixel data ever leaves the device.

This is not a theoretical concept — it is the architecture the Salnus Surgeon Portal uses in production. The OA screening model (DenseNet-121, 27MB) is served as a static ONNX file, downloaded once, and cached in the browser. ONNX Runtime Web executes inference using WebGL GPU acceleration, producing results in approximately 110 milliseconds per image on a standard laptop.

From a privacy perspective, this architecture is transformative. If no patient data reaches the server, there is no patient data to protect on the server. The data processing agreement becomes simpler. The encryption requirements are reduced to transport-layer security for the application code itself (not patient data). The breach notification scenario changes fundamentally — a server compromise cannot expose patient imaging because no patient imaging exists on the server.

How It Works: The Technical Architecture

The client-side medical AI pipeline consists of four components.

Model delivery serves the ONNX model file as a static asset via CDN, identical to how JavaScript libraries or CSS files are delivered. The model is versioned, checksummed, and cached using standard browser caching mechanisms. No session-specific data is involved in model delivery.

Image loading reads the DICOM file directly from the user's local filesystem into browser memory using the File API. The pixel data is extracted, windowed, normalised, and resized — all within the browser's JavaScript execution environment. At no point is the image transmitted over the network.

Inference executes the ONNX model using ONNX Runtime Web, which leverages WebGL for GPU acceleration. The input tensor (preprocessed image) and output tensor (classification probabilities) exist only in browser memory. The inference result — a classification and confidence score — is displayed in the UI.

Visualisation generates GradCAM heatmaps — attention maps overlaid on the original image showing which regions influenced the AI's decision.

The entire pipeline runs in the browser's sandboxed execution environment. The server never sees the input (patient image) or the output (clinical result).

What the Server Does See

Transparency requires stating what the server does handle. In the Salnus architecture, the server manages user authentication (JWT tokens, email addresses, hashed passwords), application code delivery (Next.js pages, React components, CSS), model file delivery (ONNX files), and usage telemetry (feature usage counts, error logs — no patient data).

The authentication database (Supabase PostgreSQL) stores surgeon email addresses and bcrypt-hashed passwords. No patient names, no imaging data, no clinical results, and no DICOM metadata are stored server-side. This clear separation is documented in our data processing agreement provided to partner institutions.

Regulatory Implications

Under KVKK Article 12, the data controller must implement appropriate technical and organisational measures to ensure personal data security. When patient imaging data never leaves the surgeon's device, the data controller (the hospital or clinic) retains full physical and technical control over the data. Salnus, as the software provider, never becomes a data processor for patient imaging — because we never process it.

Under HIPAA, the key question is whether Salnus qualifies as a Business Associate. Since we do not receive, maintain, or transmit protected health information (PHI), the Business Associate Agreement (BAA) requirements are significantly simplified compared to server-side AI vendors.

Under GDPR, the architecture aligns with the "data minimisation" principle (Article 5(1)(c)) — we collect only the minimum data necessary for the service (user authentication), and processing of health data occurs entirely on the data subject's side.

Limitations and Honest Trade-offs

Client-side processing is not a universal solution. Models larger than approximately 100MB become impractical for initial load. Complex multi-stage pipelines (3D segmentation, volumetric analysis) may exceed browser GPU capabilities. And the model itself must be distributed to the client, raising intellectual property considerations.

For these reasons, client-side processing is best suited for focused, single-input tasks: classification from a single image, measurement from a single radiograph, screening from a standard view. Server-side processing remains necessary for batch operations, multi-modal analysis, and computationally intensive tasks like 3D mesh generation.

The pragmatic approach is a hybrid architecture: client-side for routine AI tasks that touch patient data (classification, measurement, screening) and server-side for heavy computation on anonymised or synthetic data (model training, batch validation, 3D reconstruction from pre-anonymised datasets).

The Architect's Argument

When choosing between "build complex server-side privacy infrastructure" and "architect the system so privacy infrastructure is unnecessary for the most sensitive data," the engineering answer is clear. The most secure data is data that never leaves the point of origin.

If you are building or evaluating medical AI tools, ask the vendor a simple question: does patient imaging data leave my network? If the answer is yes, ask why it needs to. In 2026, the technology to run clinically useful AI entirely in the browser exists and is production-ready.

---

Disclaimer: This article discusses technical architecture and should not be construed as legal advice. Organisations should consult qualified legal counsel for regulatory compliance guidance.