Engineering Desktop and Web Software for AI-Assisted Medical Imaging

Client: Dectrocel. Type: client project. Our role: software engineering around AI models supplied by the client. Published with Dectrocel's permission.

Overview

Dectrocel builds AI-assisted tools for radiology, covering X-ray and CT workflows. Dectrocel developed and supplied the AI models. Yesinfosolutions engineered the software around them: desktop applications that run the models, a CT workflow that sends studies to a server for processing, integration with hospital PACS, and the web platform that connects these parts.

The challenge

A trained model only becomes useful inside software that radiology teams can install, trust and use every day. The software needed to run X-ray models on ordinary workstations, including without an internet connection, handle CT studies that are far larger than X-ray images, connect to the imaging systems hospitals already use, and fit into a wider web platform.

What we were responsible for

• Desktop applications for X-ray analysis
• Packaging and integrating local inference for the supplied X-ray models
• A desktop application for CT studies, with upload to server-side processing
• Integration with hospital PACS (picture archiving and communication systems)
• The supporting web platform and the integration between all of these parts

The AI models, their training and their clinical validation are Dectrocel's work, not ours.

Desktop applications for X-ray

The X-ray applications are cross-platform desktop apps built with Tauri and Rust. Tauri produces small installers and uses the operating system's own web view for the interface, while Rust handles file processing and running the models. This keeps the applications light enough for shared hospital workstations.

Local inference and offline use

The supplied X-ray models run on the user's own machine. Images do not have to leave the workstation to be analysed, and the applications keep working without an internet connection, which matters in settings where connectivity is unreliable.

CT studies and server-side processing

CT studies are much larger than X-ray images, around 150 MB each, and the processing is heavier than a typical workstation should carry. The CT application therefore takes a different approach: it uploads the study to a server, where the model runs, and returns the result to the user.

Hospital PACS integration

Radiology departments store and move images through PACS. We integrated the software with hospital PACS so that it works with the systems radiology teams already use, instead of adding a separate manual step.

Supporting web platform

A web platform connects the desktop applications and the server-side processing into one product.

Engineering trade-offs

• Local or server inference. Running X-ray models locally keeps images on the device and works offline. CT studies are too large and too heavy for that, so server processing was the better fit. Choosing per modality, rather than forcing one approach on both, gave each workflow what it needed.
• Tauri rather than Electron. Smaller installers and lower memory use suit shared clinical workstations. The trade-off is a smaller ecosystem than Electron's.
• Large uploads. Moving studies of this size over hospital networks has to cope with interruptions and show clear progress to the user.

Technologies

Tauri, Rust.

Building software around AI models you already have, or connecting it to hospital systems? We would be glad to talk it through.