Blog
Building paniAnetka: medical dictation that never leaves the room
A voice assistant for ultrasound physicians that runs entirely on the doctor's own computer. What a hard privacy constraint does to your architecture — and why it was the right constraint to accept.
A radiologist finishes an ultrasound examination and starts talking: organ, findings, measurements, conclusion. Somebody has to turn that speech into a structured, printable report. For years the choices were a human typist or a cloud transcription service — and for medical audio, "cloud" is doing a lot of quiet work in that sentence. The recording of a patient examination leaves the practice, crosses a border or two, and lands on infrastructure the physician has never seen and could not audit if they tried.
paniAnetka is my answer to a simple question: what if it just… didn't? What if the entire pipeline — speech recognition, medical language processing, report structuring — ran on the computer already sitting in the examination room?
The constraint is the product
"Fully on-device" started as a compliance requirement and became the defining architectural decision. Nothing to host, nothing to breach, no data processing agreement gymnastics: audio never leaves the machine, so the GDPR story collapses from a legal project into a sentence. For a solo physician's practice — the people who have no legal department — that difference decides whether the tool is usable at all.
But a hard constraint like this bills you elsewhere, and it billed me in hardware. Cloud vendors solve their performance problems with a bigger fleet; on-device, you have to choose which devices to bet on. I standardised on Apple Silicon — an M-series MacBook as the recommended machine — for reasons as much operational as technical: a handful of configurations to test instead of the endless PC matrix, unified memory that lets the speech models and a 14B-class language model share one machine sensibly, and enough performance for real-time transcription in an examination room. A CPU-only Lite mode covers ordinary Windows laptops, but the full product quality is an Apple Silicon story — and betting on one platform for initial adoption is a trade I accepted deliberately. A practice can buy one specific, well-understood laptop today; hardware progress does the rest, and in two or three years the same workload will run on whatever commodity machine is already on the desk. Within that envelope is where most of the engineering lives: model selection and quantisation, keeping the pipeline deterministic, and treating every megabyte of memory as contested territory.
Polish medical speech is its own problem
General-purpose speech models are trained on the internet's idea of language. An ultrasound report is not that. It is dense with abbreviations, Latin, measurements dictated at speed, and the particular phrasing conventions of Polish radiology — inflected, compressed, and unforgiving of transcription errors, because a wrong number in a report is not a typo, it is a clinical fact that somebody may act on. A large part of the system is a correction and normalisation layer that treats the raw transcript as a hypothesis, not an answer: numbers are cross-checked, units normalised, anatomical terms resolved against the vocabulary actually used in reports.
The bottleneck was never typing
The most valuable design insight did not come from the ML side at all. Watching how an examination room actually works made it obvious that the report is a workflow problem before it is a transcription problem: patients queue, the assistant preps the next examination while the physician finishes the previous one, and paper comes out of a printer at a specific desk. So paniAnetka grew a second face — the assistant's own day board: a live patient queue, one-click hand-off of the prepared patient to the physician, and finished reports printing at the assistant's station while the doctor keeps scanning. The dictation engine is the headline; the choreography is why the tool stays in the room.
What shipping it taught me
Shipping software to a non-technical user on their own hardware is a masterclass in humility. There is no ops team and no SSH access — the product must install itself, diagnose itself, and recover itself, or it dies quietly in a place you will never see. Every failure mode I did not design for became a phone call. The disciplines that made it work are the unglamorous ones: deterministic pipelines you can replay, aggressive preflight checks, and update channels boring enough to trust.
paniAnetka is live — in Polish, for the Polish market — at panianetka.pl (there is an English summary too). And if your product has a "this cannot leave the device" constraint hiding in it — that is exactly the kind of system I design and build.