University Hospital Bonn
University Hospital Bonn runs DeepSeek-R1 in an isolated server for its radiologists
University Hospital Bonn in Germany deployed the open-weight DeepSeek-R1 model on an isolated server inside its data center, with approval to process unanonymized patient data. In a one-week pilot, 22 radiologists rated translation and text correction highest and reported most errors when the model drafted report conclusions.
Key figures
Copied exactly from the sources. Copy any figure with its citation.
22
(17 residents, 3 board-certified radiologists, 2 senior attending radiologists)
Radiologists who completed the one-week pilot in July 20251
10.0
System stability rating, median, scale 0 to 101
9.5
Output quality rating for report translation, median, scale 0 to 101
6
Tasks with zero reported critical errors, out of ten tested1
What it took
Cost, team size and timeline were not disclosed in the sources.
The problem
Radiologists write and correct long reports, translate them and draft letters. Language models can help, but German hospitals generally cannot send patient data to outside AI services under privacy rules such as the EU's GDPR. University Hospital Bonn wanted a model it could run itself and still get approval to process unanonymized patient data.
What they built
The hospital built an isolated, self-hosted service around DeepSeek-R1, an open-weight model. Open-weight means the model's files are published, so a hospital can run the model on its own hardware. The team used the full 671-billion-parameter version, compressed (quantized) to fit on a server with eight NVIDIA A100 chips. The service sits behind a chat screen with ten ready-made prompt templates, such as report correction and translation. The hospital published the deployment package as open source.
How they did it
The design assumes a possible breach. Network zones separate the web interface from the model, firewall rules block outside traffic, and automatic tests check that the isolation holds. A monitor watches for unexpected outside connections.
In parallel, the team ran an approval process. It involved clinic management, the data protection officer, the information security officer, the compliance department and the works council (the staff representatives). The works council agreed on condition that no per-employee usage statistics are collected and that use stays voluntary. Staff must complete an AI literacy course before they can log in.
In July 2025, 22 radiologists used the system for one week.
Results
The approval process succeeded, and the hospital describes the service as the base for a permanent offering for over 10,000 employees. In the pilot, users rated stability at a median of 10.0 out of 10 and user friendliness at 9.0. Speed was rated 7.0. The monitor detected no outside connection events.
Tasks built on text the user provides did best. Report translation had a median quality rating of 9.5, and six of ten tasks had no reported critical errors. A critical error is a wrong statement, omission or invented content that needs manual correction.
What went wrong
Drafting conclusions from imaging findings had the highest error rate. Of 16 users of that task, one reported a single critical error and two reported several. ICD-10 coding (the standard disease codes used for billing) was rated promising, but users said checking the suggested codes saved little time. Speed ratings were lower than for stability, which the authors link to their older server hardware.
What to copy
Start with correction, translation and simplification of text the user already has. Treat generation of new clinical content as higher risk and test it separately.
All reported figures
| Measure | Figure | Citation |
|---|---|---|
| Radiologists who completed the one-week pilot in July 2025 | 22 (17 residents, 3 board-certified radiologists, 2 senior attending radiologists)1 | |
| System stability rating, median, scale 0 to 10 | 10.01 | |
| Output quality rating for report translation, median, scale 0 to 10 | 9.51 | |
| Tasks with zero reported critical errors, out of ten tested | 61 | |
| Conclusion generation: users reporting a critical error (one error, multiple errors), of 16 users of that task | 1 reported a single error, 2 reported multiple errors1 | |
| Median time to first token | 3.13 seconds1 | |
| External connection events detected by the isolation monitor during the pilot | 01 |
Lessons for your project
Pick tasks where the model works from text the user supplies, such as translating or correcting a report. Open-ended drafting from findings produced the most serious errors.
Budget time for approvals, not just software. The hospital needed sign-off from management, data protection, information security, compliance and the works council.
Make training a condition of access. The hospital required an AI literacy course before users could log in, to meet its EU AI Act duties as a deployer.
Do not tie the design to one model. The stack is model-agnostic, so the hospital can swap in newer open models without redoing security work.
Caveats
- This is a preprint (an unreviewed research paper) by the hospital's own radiology and IT teams, so the figures are the hospital's own.
- The pilot was one week with 22 volunteers at one site. Errors were reported by the users themselves, not checked by independent experts.
- Utility and time-saving figures are users' ratings on a 0 to 10 scale, not measured minutes. For ICD-10 coding the perceived time-saving median was only 3.5.
- The paper says a permanent service for over 10,000 employees is the current base, but it reports no usage figures from that wider rollout.
Sources
- Secure On-Premise Deployment of Open-Weights Large Language Models in Radiology: An Isolation-First Architecture with Prospective Pilot Evaluation
arXiv · 2026-03-25 · Research paper · arxiv.org
Summarized in our own words from the sources above. Spotted an error? See corrections.