Engineering FAIR Privacy-preserving Applications that Learn Histories of Disease

This paper presents a successful in-browser deployment of a generative transformer model for predicting individual disease morbidity risk, demonstrating a secure, client-side architectural blueprint that adheres to the Reusability principle of FAIR data standards while eliminating privacy concerns associated with data downloads.

The Gist

🏥 The Big Problem: The "Glass House" of Medical AI

Imagine you have a very smart, super-intelligent doctor (an AI) who can look at your medical history and predict what illnesses you might get in the future. This is amazing for early prevention!

However, there's a catch. To get this doctor's advice, you usually have to mail your entire medical file to a giant, central hospital server.

• The Risk: You have to trust that the server won't leak your secrets, get hacked, or sell your data.
• The Fear: Many people are scared to use these tools because they don't want their private health data leaving their house.

🚀 The Solution: The "Pocket Doctor"

The team in this paper asked a simple question: "What if we didn't have to send the data to the doctor? What if we could bring the doctor to the data?"

They built a web application that runs entirely inside your web browser (like Chrome or Safari).

• No Uploads: Your medical history never leaves your computer.
• No Installations: You don't need to download a heavy app; you just visit a website.
• The Result: The AI does the math right there on your screen, in your "living room," and then disappears. Your data never travels across the internet.

🧱 How Did They Do It? (The Engineering Magic)

To make a giant, complex AI run on a regular computer without a supercomputer, they used three main "tools":

1. The Universal Translator (ONNX)

Think of the original AI model as a high-end French chef trained in a fancy kitchen (using a framework called PyTorch). You can't just ask this chef to cook in a tiny camping stove (a web browser); the equipment doesn't match.

The team used a tool called ONNX to translate the chef's recipe into a "Universal Language."

• The Analogy: It's like taking a complex French recipe and rewriting it so a campfire, a microwave, or a fancy stove can all cook the exact same dish. This allowed the AI to leave its "fancy kitchen" and run on the "camping stove" of your web browser.

2. The Bridge (WebAssembly)

Even with the recipe translated, your browser is usually a bit slow at doing heavy math.

• The Analogy: Imagine the browser is a bicycle, but the AI needs a race car. WebAssembly is like a turbocharger. It lets the browser run the AI code at nearly the speed of a native computer program, making it fast enough to give you predictions in real-time.

3. The Personal Assistant (The SDK)

The AI speaks in a language of numbers and codes that humans can't read.

• The Analogy: The team built a custom JavaScript SDK (a software toolkit) that acts as a translator.
  • Input: You type in your medical history (e.g., "I had a broken leg at age 10"). The SDK translates this into numbers the AI understands.
  • Processing: The AI runs the math.
  • Output: The SDK takes the AI's raw numbers and turns them back into human words: "Based on this, you have a 15% chance of developing arthritis by age 60."

🎮 What Does It Look Like?

The team created a website (a "Delphi App") that looks like a timeline.

1. Left Side: You enter your past health events (like a timeline of your life).
2. Right Side: As you type, the AI instantly draws a line into the future, predicting what might happen next.
3. The Magic: All of this happens instantly on your screen. If you refresh the page, the data is gone. It never touched a server.

🌟 Why Is This Important? (The "FAIR" Principles)

The paper mentions "FAIR" principles (Findable, Accessible, Interoperable, Reusable). In simple terms:

• Interoperable: They proved that AI models don't have to be stuck in one specific computer system. They can move anywhere.
• Reusable: They didn't just build a one-time trick; they built a blueprint (a "blueprint for privacy") that other developers can use to build their own secure medical apps.

⚠️ The Catch (Limitations)

The authors are honest about the limitations:

• The Training Data: The AI they used was trained on fake (synthetic) data because real patient data is too private to share easily. So, while the technology works perfectly, the predictions aren't as accurate as they would be if the AI had learned from millions of real patients.
• Future Goal: They hope to eventually use real data (with strict privacy rules) to make the predictions truly life-saving.

🏁 The Bottom Line

This paper is a proof-of-concept that says: "We don't have to choose between powerful AI and your privacy."

By moving the "brain" of the AI from a central server to your local browser, they created a secure way to use advanced medical technology. It's like taking a supercomputer out of the cloud and shrinking it down to fit in your pocket, so you can keep your secrets safe while still getting the benefits of the future.

Technical Summary

1. Problem Statement

The paper addresses a critical bottleneck in applying Generative AI to personalized healthcare: data privacy and governance.

• The Challenge: Predictive models for disease trajectories (e.g., predicting morbidity or mortality) typically require sending sensitive Electronic Health Records (EHR) to centralized cloud servers for processing. This creates significant regulatory, ethical, and privacy risks.
• The Gap: While models like Delphi 2M (a generative transformer trained on health trajectories) show immense potential for early intervention, their deployment is hindered by the need for data upload. Existing implementations lack Interoperability and Reusability (key components of the FAIR data principles) for end-users who cannot or will not share raw patient data.
• Objective: To engineer a solution that allows the Delphi 2M model to run entirely client-side (in a web browser) without requiring data uploads, software installations, or server-side inference.

2. Methodology

The authors engineered a "build once, run anywhere" architecture by migrating a PyTorch-based model to a client-side JavaScript environment. The process involved four key technical stages:

A. Model Conversion (PyTorch to ONNX)

• Source: The original Delphi 2M model, trained on 7,144 synthetic patient trajectories using a PyTorch framework (based on nanoGPT).
• Conversion: The trained model was exported to the Open Neural Network Exchange (ONNX) format.
• Purpose: ONNX acts as a universal interchange format, decoupling the model from its training framework (PyTorch) and enabling execution in diverse runtimes, including web browsers.

B. Runtime Environment (WebAssembly & WebGPU)

• Execution Engine: The ONNX model runs via ONNX Runtime Web.
• Optimization:
  • WebAssembly (Wasm): Used for CPU-bound computations, compiled from the C++ core of ONNX Runtime to ensure near-native performance in the browser.
  • WebGPU: Utilized for GPU acceleration where available, further enhancing inference speed.
• Result: Complex deep learning inference pipelines execute locally on the user's device (mobile or desktop) without network latency for data transfer.

C. Custom JavaScript SDK Development

A dedicated SDK was built to bridge the gap between user input and the ONNX runtime. Its workflow includes:

1. Loading: Fetching the ONNX model file and establishing an inference session.
2. Preprocessing: Converting human-readable inputs (ICD-10 codes, age) into structured numeric tensors matching the model's input signature.
3. Inference Loop (generateTrajectory):
   • The model predicts the next medical event and the time-to-event ($t_{next}$) using a dual loss function.
   • Sampling: A time-to-event sampling method is applied using the formula $t_{next} = -e^{\text{logits}} \cdot \ln(u)$, where $u$ is a pseudo-random number.
   • Selection: The event with the minimum predicted time is selected, and the patient's age is incremented.
   • Termination: The loop continues until a "Death" token is generated or the maximum age (default 85) is reached.
4. Postprocessing: Converting raw output logits back into human-readable morbidity risk estimates (events and ages).

D. Application Deployment

• The SDK was integrated into a web application built on ObservableHQ.
• The interface allows users to input a health trajectory (ICD-10 codes) and visualize future predictions in real-time.
• Privacy Guarantee: No data leaves the user's device; all computation occurs locally.

3. Key Contributions

• Client-Side Generative AI: Successfully demonstrated the feasibility of running a large-scale generative transformer (Delphi 2M) entirely within a standard web browser.
• FAIR Principles Implementation: Specifically addressed the Interoperability (I) and Reusability (R) of the FAIR data principles by creating a portable, framework-agnostic artifact (ONNX) and a reusable SDK.
• Privacy-Preserving Architecture: Established a blueprint for "zero-trust" AI deployment where sensitive health data never leaves the user's local device, aligning with strict data governance standards.
• Open Source Tooling: Released the full pipeline, including the web app, GitHub repository, and the custom JavaScript SDK, enabling others to replicate or extend the work.

4. Results

• Functional Prototype: A working web application (available at epiverse.github.io/delphiTrajectories) that generates health trajectory predictions in real-time without server communication.
• Performance: The system achieves high-performance inference on diverse platforms, from mobile devices to GPU-accelerated desktops, validating the efficiency of the ONNX/Wasm/WebGPU stack.
• Validation: The model successfully replicated the inference logic of the original PyTorch implementation, proving that the migration to JavaScript did not compromise the core algorithmic integrity.
• Limitation: The current proof-of-concept uses a model trained on a small subset of synthetic data (7,144 trajectories) rather than the full real-world dataset (400k trajectories) used in the original Delphi 2M paper. Consequently, predictive accuracy is currently limited compared to the full-scale model.

5. Significance and Future Directions

• Paradigm Shift: This work shifts the paradigm of medical AI from "data to server" to "model to data," fundamentally changing how privacy-sensitive AI can be deployed.
• Scalability: The "build once, run anywhere" approach allows the same model to serve users globally without maintaining massive centralized inference clusters.
• Future Work:
  • Real-World Validation: Retraining the model on full real-world datasets to improve clinical utility.
  • Continuous Learning: Exploring client-side fine-tuning and decentralized federated learning to allow models to improve over time using local user feedback without ever exposing raw data.

In conclusion, this paper provides a robust engineering blueprint for the future of private, generative AI in medicine, proving that high-performance predictive modeling can be achieved while strictly adhering to patient privacy and data sovereignty.