AI for doctors that keeps patient data inside the practice
An AI system for medical practices and outpatient clinics that reads reports, discharge letters and records, prepares summaries and draft reports, and runs on a server inside the practice. The doctor reviews and signs: the AI writes the draft, it doesn't decide.
What AI for doctors does (and what it doesn't)
In a medical practice or outpatient clinic a large share of time goes into documentation: rereading a patient's history before a visit, finding a lab value from two years ago, writing a report or a letter that draws on ten earlier documents. It is reading and writing work, and that is where a language model genuinely helps.
What I build is a documentation assistant: it searches one patient's documents, summarises them with references to the sources and prepares a draft in the practice's own format. It does not diagnose, does not suggest treatments and does not replace clinical judgement. Every text it produces is a draft the doctor reads, corrects and signs.
The difference from using ChatGPT or another online chatbot is where the data goes. Here the model, the document index and the logs live on the practice's own hardware: no report is sent to an external service.
Where AI saves doctors time
Record summary before the visit
One page with history, relevant tests, current medication and recent visits, drawn from the patient's documents. Every statement links to its source document, so the doctor can check it in one click.
Draft reports
The doctor dictates or types the key points, the AI puts them into the practice's report format and pulls in data already on file. It works on form and retrieval, not on conclusions.
Letters and referrals
Letters to the GP, notes for a colleague, summaries for the patient. Long texts that draw on many documents and today get written by copy and paste.
Search a patient's archive
Plain-language questions ("when was the last ultrasound?", "creatinine values over the last three years?") over a single patient's documents, with the answer and the source document.
Health data and GDPR: why the AI stays on-site
Health data is a special category of personal data (GDPR Article 9): it can be processed for care purposes by professionals bound by confidentiality, but under stricter safeguards. Sending reports to a generic cloud service adds a vendor, a transfer and often a non-EU country you have to justify.
The easiest choice to defend is not to let the data leave: a model running on a server in the practice or in the organisation's own data room, with no outbound calls. Documents, the search index, generated drafts and the access log all stay on-site.
On-site does not automatically mean compliant. You still need named accounts, data minimisation, an updated privacy notice and, with health data and a new technology, a data protection impact assessment (DPIA, GDPR Article 35) carried out with the organisation's DPO. My job is to design the system so these safeguards are technical and verifiable, not just written in a policy.
From document to signed draft, in four steps
Pseudonymisation, where possible
Name, tax code and contact details are replaced with a code in the search index; the lookup table is kept separately with tighter access. Free-text reports can still contain identifying details, so this is an extra layer, not the only one.
Per-patient search, with separate access
Every search is limited to one patient's documents, and the filter is enforced by the system, not requested from the model. Each user sees only the patients and functions their role allows.
Summary and draft, always reviewed by the doctor
The model works only on the retrieved documents and cites its sources. A draft stays a draft until the doctor reviews, corrects and approves it: no text leaves the system without that step.
Access log
Who searched for what, on which patient, which draft was generated and who approved it. A log you can consult in an audit, also kept on-site.
Local model, RAG and hardware
For an archive of 5-50 GB of reports, discharge letters and records (native PDFs, scans that need OCR, Word files) the real work happens before the model: extracting the text, splitting it sensibly, linking it to the right patient and indexing it. If that part is done badly, no model can fix it.
On top of the index I use an open-weight language model with 70-120 billion parameters. Here text quality matters more than speed: a model that size writes more accurate clinical language and makes fewer mistakes with numbers and dates than the small models that run on a laptop. The trade-off is time: a long summary takes tens of seconds, not an instant.
A quantised model of that size runs on a workstation with one or two high-end professional GPUs, or on a machine with a large amount of unified memory. The exact setup depends on how many doctors use it at the same time, and we define it after seeing the documents.
RAG or fine-tuning?
To make the system "know" patient documents you use RAG (retrieval-augmented generation): for each request the system retrieves the relevant passages and passes them to the model, which answers on that basis only. New documents are available as soon as they are indexed, and deleting a document really removes it from the answers. Fine-tuning, i.e. retraining the model, is not how it learns the records (the data would end up inside the model weights, where it can no longer be controlled): it is only for style, the practice's report format and classification tasks.
Online chatbot or on-site AI?
| Generic online chatbot | On-site AI in the practice | |
|---|---|---|
| Where documents go | To the vendor's servers | They stay on the practice's hardware |
| Per-patient search | Manual copy and paste | Per-patient index with separate access |
| Cited sources | Usually not | Every summary links to its documents |
| Access log | Not under your control | Local and auditable |
| Report format | Set up again every time | The practice's own |
| Cost | Per-user subscription | Upfront hardware and project, then maintenance |
Medical devices, the AI Act and the doctor's responsibility
Software is a medical device (EU Regulation 2017/745, MDR) when the manufacturer gives it a medical intended purpose, such as diagnosis or supporting treatment decisions. The tool described here has a different purpose: documentation, search and draft texts reviewed by the doctor. It is not a medical device and must not be used as one. If the intended use ever shifted towards diagnostic support, the qualification would change too and a dedicated regulatory path would be needed.
The EU AI Act (Regulation 2024/1689) classifies systems by intended use: systems that are safety components of medical devices are high-risk. A documentation assistant is a different case, but the classification has to be assessed case by case with the organisation's DPO and legal advisor. General obligations still apply, such as training the people who use the system.
Italy's AI law (Law 132/2025) states the same principle: in healthcare AI is a support and the decision stays with the doctor. The workflow is built on it: no draft becomes a document without review by the person who signs it.
A prototype on a sample first, then the whole practice
Free intro call (30 minutes)
You tell me how the practice works, what documents you have and where time gets lost. Together we assess whether the project makes sense and how to set it up.
Prototype on a sample
A subset of pseudonymised documents on a local machine. The point is to see summary quality on your real reports, not on a demo. If it doesn't convince, the project ends here with a contained investment.
Going live
Final hardware, indexing of the archive, users and roles, access log, training for the doctors and maintenance.
What it costs
I don't have a price list: the cost depends mostly on the hardware (which the practice keeps) and on the state of the documents, for instance how many are scans that need OCR. Scope and cost of the prototype are clear before we start.
Stefano Salvucci
Engineer registered with the Order of Engineers of Rome, 12+ years across software development, architecture and automation, co-founder of BusinessinCloud and YTILI Fellow 2019. I work as a fractional CTO: I design the system, build it and stay the technical point of contact. On legal and privacy matters I work alongside the organisation's DPO, not in their place.
What doctors and clinic managers ask
What is the best AI for doctors?
It depends on the task. For writing and summarising clinical documents with real patient data, the best one is the one you can use without sending data to third parties: a large open-weight model (70-120 billion parameters) installed on-site and connected to the practice archive through RAG. An online chatbot can be fine for general questions with no patient data.
Can I use ChatGPT with patient reports?
Pasting identifiable reports into an online chatbot means transferring health data (GDPR Article 9) to an external vendor, with everything that implies for legal bases, contracts and transfers. For daily use on real data, an on-site system is simpler and easier to defend.
Does the AI make diagnoses?
No. The system prepares summaries and draft texts from existing documents, with sources cited. Clinical assessment, diagnosis and signature remain the doctor's. It is not a medical device and must not be used for diagnostic support.
Does data leave the practice?
No. Model, document index, drafts and access log live on the practice's hardware, and the system makes no calls to external services to process documents. Updates and support are arranged so they don't require taking data off-site.
What is on-site AI and what hardware does it need?
It is a language model running on a computer in the practice instead of a vendor's cloud. For a quantised 70-120 billion parameter model you need a workstation with one or two high-end professional GPUs, or a machine with a large amount of unified memory. The setup depends on the number of concurrent users.
Why such a large model if it's slower?
Because in clinical text errors cost more than seconds. Larger models write more precise language and carry numbers, dates and medication over more reliably. A summary in a few tens of seconds is acceptable if the doctor then has less to correct.
Do we need to train the model on our records?
No. To make the model work on your documents you use RAG: the system retrieves the relevant passages and the model answers on those. Fine-tuning is only for adapting report style and format or for classification tasks, and can be done without identifying data.
Does it work for an outpatient clinic with several doctors?
Yes, and that is where separate access matters most: each doctor sees their own patients or those their role allows, front desk staff can have different functions, and the access log tracks everything.
Let's talk about your practice
30 minutes, free: we assess whether and how AI can help your practice.