Cliniques universitaires Saint-Luc
A Brussels hospital runs Qwen3 on its own servers as an assistant inside its patient records
Cliniques universitaires Saint-Luc, a university hospital in Brussels, built a clinical assistant on the open-weight Qwen3-235B model, hosted entirely on its own servers and embedded in its Epic patient record system. After a one-month pilot, it went hospital-wide: 1,028 users and 14,910 conversations in five months.
Key figures
Copied exactly from the sources. Copy any figure with its citation.
The problem
Doctors spend a large share of their day in the electronic health record (EHR, the hospital's digital patient file). The paper notes that emergency physicians at this hospital spend on average 20 minutes per patient reading prior documents before a consultation. Hospitals also cannot send patient data to outside chatbots without breaking privacy rules such as the EU's GDPR.
What they built
Cliniques universitaires Saint-Luc, a university hospital in Brussels, built a chat assistant inside its Epic patient record system. It runs on Qwen3-235B, an open-weight model from Alibaba. Open-weight means the model's files are published, so an organisation can run it on its own servers instead of calling a vendor's service.
The assistant answers questions using the current patient's record, documents from Belgium's regional health-information network, the hospital's own procedures and a selected set of medical literature. Each answer lists the sources it used, with links that open inside the record.
How they did it
The hospital first ran workshops with physicians to collect and rank use cases. Information access came first, so the team built a retrieval-based assistant. Retrieval-augmented generation (RAG) means the system looks up relevant documents and gives them to the model before it answers.
Everything runs on a server the hospital bought, with 8 NVIDIA H200 chips, on the hospital network with no outside internet connection for the core pipeline. A network of physician "champions" helped design and test it. The hospital's data protection officer was consulted and a data protection impact assessment was completed before launch. The team notified the Belgian medicines agency of the tool as an in-house medical device.
Results
In a one-month pilot, 28 physicians from nine specialties held 482 conversations, and 64% used the assistant daily. After the pilot, the tool opened to the whole hospital, including nurses and students. Between 8 May and 13 October 2025, 1,028 users held 14,910 conversations, and 561 of them (54.6%) used it at least weekly.
Most use was finding information (36.8% of conversations) and summarizing records (26.5%). Drafting notes accounted for 20.7% and clinical decision support for 11.0%. The authors read this as staff using the tool as an information aid rather than as a diagnostic tool.
What went wrong
The study did not test whether the assistant saves time or improves care. Pilot feedback showed gaps: users flagged missing context such as pathology reports, and one reply misread a risk score. Rating volume dropped in production, so the hospital plans random sampling and automated checks of conversations.
What to copy
Start with the information tasks staff already ask for, embed the tool in their main system, and budget for monitoring after launch.
All reported figures
| Measure | Figure | Citation |
|---|---|---|
| Physicians in the one-month pilot, across nine specialties | 281 | |
| Pilot participants who used the assistant daily | 64%1 | |
| Unique users, hospital-wide, 8 May to 13 October 2025 | 1,0281 | |
| Conversations, hospital-wide, 8 May to 13 October 2025 | 14,910 (20,225 user messages)1 | |
| Users who engaged at least once a week | 561 (54.6% of users)1 | |
| Conversations by task type: information retrieval, summarization, note writing, decision support | 36.8%, 26.5%, 20.7%, 11.0% (remainder 5.0%)1 | |
| Explicit ratings left by users in production | 190 (90 positive, 100 negative), under 1% of assistant replies1 |
Lessons for your project
Ask clinicians what they need before building. Their top requests were finding and summarizing information, so the assistant was shaped around that, not around diagnosis.
Put the tool inside the system staff already use. The assistant opens within the patient record, so users do not switch screens or log in again.
Plan for review after launch. Voluntary feedback fell sharply once the tool was routine, so sampling of conversations is needed to watch quality at scale.
Make the privacy approach part of the design. The hospital completed a data protection impact assessment and kept all patient data on its own network.
Caveats
- The authors are the hospital's own team. The paper was peer reviewed, but the figures are the hospital's, not an outside audit.
- The study did not measure time saved or clinical outcomes. It measures adoption and how staff use the tool.
- Feedback was sparse, so true error rates are unknown. In the pilot, 47 of 815 replies were rated, 25 positive and 22 negative.
- The $400,000 server also serves other projects. The authors say lighter models can run on hardware costing under $50,000, but they did not test that in this deployment.
Sources
- Implementation of large language models in electronic health records
PLOS Digital Health · 2025-12-19 · Research paper · ncbi.nlm.nih.gov
Summarized in our own words from the sources above. Spotted an error? See corrections.