Cathy

About the project Inspiration

In endovascular procedures, many of the most important decisions are made before the wire moves: which access site to use, which wire to choose, and which path to take through the aortic arch. Most training tools focus on manual skill. We wanted to build one that trains the decisions themselves and shows a learner which choice cost them the most. That became Cathy, a browser-based decision trainer for catheter navigation, named after its built-in voice assistant. Cathy uses simplified device mechanics; it is not a clinical device, and we make no claim of patient benefit.

What it does

A trainee picks a case, plans a route branch by branch through the vessel tree, compares it with the best routes the engine can find, then drives the wire in 3D or X-ray view. They can steer by keyboard, gamepad, webcam hand gestures, or voice (“Hey Cathy, what’s the best next artery?”). The Results screen names the single most important thing to change, scores the plan and the drive, and replays the drive over the best route. Cases include generated teaching arches and three cases derived from real CT angiograms in the open TotalSegmentator dataset.

How we built it

Cathy is written in TypeScript and three.js and runs entirely in the browser. The engine models each vessel tree as a graph of centrelines and measures every candidate route on length $L$, sharpest turn $\theta_{\max}$, narrowest radius $r_{\min}$, risk-zone crossings, and estimated radiation. Radiation is estimated with an illustrative model, labelled as such in the app:

$$t_{\text{fluoro}} \approx 1\,\tfrac{\text{s}}{\text{cm}}\cdot L \;+\; 3\,\text{s}\cdot\frac{\Theta}{90^\circ},$$

where $\Theta$ is the total turning along the route. The engine keeps the Pareto frontier, the routes that no other route beats on every measure, and ranks them by the trainee’s own priorities:

$$S(r) = \sum_k w_k\,\hat{c}_k(r), \qquad \sum_k w_k = 1.$$

The plan score is 0 for an infeasible route, is capped at 40 for crossing a heavy risk zone, and is capped at 80 for a route off the frontier. Otherwise it comes from the trainee’s regret at their own weights:

$$\text{regret}(r) = S(r) - \min_{r^} S(r^).$$

The wire runs in one of two modes. In the fast rail model, the tip is bent by the wire’s preset angle $\alpha$ and rolled by the trainee’s twist $\varphi$. It enters a branch only if the angle between the tip and the branch is within $25^\circ$:

$$\angle\big(\mathbf{t}(\alpha,\varphi),\ \mathbf{d}_{\text{branch}}\big) \le 25^\circ.$$

The experimental physics mode models the wire as a chain of links with a shaped tip and lag between the hub’s twist and the tip’s. Hand tracking uses MediaPipe. Cathy’s answers come from the engine. We also designed an optional language-model layer: it only interprets questions and words the answers, and a grounding check rejects any number or vessel name that isn’t in the engine’s facts.

Challenges

Our hardest problem was a beginner case that testers called impossible. Measuring it showed why: one key branch left the arch at about $68^\circ$ from the wire’s heading, while the default wire’s tip bent only $\alpha = 45^\circ$. Under the $25^\circ$ entry rule, only a $21^\circ$ window of twist out of $360^\circ$ entered the branch. Rather than distort the anatomy, we made the angle visible and controllable, with a live twist dial, fine twist control, and exact angle entry. Webcam gestures that worked on recorded clips were also harder to hold live, so we redesigned them more than once. Finally, coordinating four developers through a merge freeze and a deployment rate limit taught us to lean heavily on automated tests.

What we learned

We learned that an AI assistant in a training tool is most trustworthy as an interface, not an authority. We learned to measure a problem before tuning it. And we learned that a disciplined design system made late changes, such as a full rebrand and a new colour scheme, quick and safe.