Estimated reading time: 7 minutes · Last updated:
Healthcare AI training works best when it teaches the whole data team to build, test and question complete pipelines, not just to try out chatbots. That is the case Eric Just and Aik Choon Tan make in a ten-rule framework published in PLOS Computational Biology. Their rules grew out of a two-day hands-on course, Privacy-First AI Systems for Healthcare, taught to more than sixty people at a comprehensive cancer center, including data engineers, analysts, data scientists and managers. The method rests on four ideas: synthetic but messy clinical data, small models kept inside the institution's walls, a separate model type for each job, and evaluation before any tuning. The authors report that later cohorts carried the rules into financial services.
Key takeaways
- The framework: Eric Just and Aik Choon Tan set out ten rules for teaching practical AI to health data teams in PLOS Computational Biology, volume 22, issue 10, article e1014915.
- Who was trained: The rules came from a two-day course, Privacy-First AI Systems for Healthcare, attended by more than sixty data staff and managers at a comprehensive cancer center.
- Privacy by design: Trainees used synthetic breast cancer pathology reports, synthetic clinical guidelines and a mock genomic database, so no protected health information entered the course.
- Evaluation first: The eighth rule puts system evaluation ahead of optimisation, with test criteria tied to the clinical decisions a model's output would support.
- After the course: A hackathon six weeks later produced an immune-related adverse events explorer with a Guideline-Grounded Retrieval-Augmented Generation module.
Table of contents
- Key takeaways
- Why the Whole Data Team Belongs in the Classroom
- Synthetic Data Built to Misbehave
- Small Local Models, Taught With Their Limits
- One Model Type per Job, With the Wiring Exposed
- Testing Comes Before Tuning, and Rules Check the Models
- What Lasts After the Course Ends
- Will this approach spread beyond one cancer center?
- What to be careful about
- Frequently asked questions
Why the Whole Data Team Belongs in the Classroom
Just and Tan start from a split they see inside many health systems. AI projects go to a small data science group, while engineers are left writing database queries and analysts produce business intelligence reports. The authors argue this leaves an organisation poorly prepared, because working AI depends on the pipelines, governance rules and semantic layers that engineers build.
Their course therefore enrolled engineers, analysts, developers, data scientists and operational leaders side by side. It also steered away from chat interfaces and the excitement around autonomous agents. Learners were taught to see an AI system as a chain: take in raw data, pull out structured signals, retrieve relevant documents, rank candidates, combine several sources and measure the result.
That framing borrows from work clinical data engineers already do. A retrieval step looks far less exotic when it sits beside the ingestion jobs a team already runs, and the authors present new tools as an extension of existing infrastructure rather than a separate experiment run by specialists.
Synthetic Data Built to Misbehave
Real clinical information is scattered across progress notes, free-text pathology narratives, imaging metadata and cancer registry extracts. Just and Tan argue that tidy tutorial datasets leave staff unprepared for that reality. Synthetic data, meaning records generated to resemble patient data without coming from any real patient, let the course mimic the mess without the legal exposure.
For training, the system was given made-up versions of three kinds of material: clinical guidelines, pathology reports on breast cancer cases, and a database of genomic records built as a stand-in for a real one. The flaws were intentional. Schemas did not match, names were applied inconsistently, records were missing and some sources contradicted others.
Trainees had to reconcile those conflicts themselves. The authors say this built practical problem-solving skill while keeping the course fully within privacy rules, and it gave the group a realistic baseline for judging how reliable model outputs further down the pipeline actually were.
Small Local Models, Taught With Their Limits
The authors separate two ideas that are often blurred together. A small model, typically several billion parameters, runs on commodity hardware and lowers the cost of getting started. Local deployment is a different matter: it means clinical data stays inside boundaries the institution controls, whether a centrally managed virtual desktop, an on-premises server or a private cloud tenancy.
Just and Tan do not oversell either one. Running a model locally does not on its own satisfy every legal requirement, they note, although keeping data inside the perimeter removes major leakage risks.
The course also set out to puncture overconfidence. Trainees tested where small models struggle on reasoning depth, breadth of context and language robustness, and compared them with larger external systems. The aim was for staff to treat a model as a specialised tool with a defined route for escalating harder cases.
One Model Type per Job, With the Wiring Exposed
Generative chat tools dominate public attention, so health data teams often reach for them on every problem. Just and Tan teach a division of labour instead. In the course's cancer registry workflow, an encoder searched for relevant clinical practice guidelines, a cross-encoder ranked what it found, and a generative decoder summarised a pathology report using only the validated guideline text.
The authors call their teaching style a breadboard approach, after the boards electronics engineers use to prototype circuits. Code sat in plain notebooks and short scripts so students could change low-level settings and watch the effect. Orchestration frameworks came only later, as accelerators rather than black boxes.
Labs ran in pre-configured Amazon Web Services environments preloaded with synthetic data and notebooks, but students installed model runtimes themselves. Exercises were rigged to fail visibly, through empty extraction tables, dropped documents and confident factual errors, so learners had to work out whether the weights, the prompt format or the surrounding code was at fault.
Testing Comes Before Tuning, and Rules Check the Models
The eighth rule makes evaluation a first step rather than an afterthought. Trainees learned to build ground truth, sample outputs systematically, run structured human review and analyse failure modes. Just and Tan insist test criteria should come from the clinical decision the output supports.
In a biomarker extraction exercise, learners traced what a wrong answer could cause: an unsuitable chemotherapy regimen, a crippling bill for the patient, or exclusion of an eligible patient from a clinical trial. Scoring covered both answer accuracy and processing time, so teams weighed speed against safety.
The authors also favour hybrid designs over end-to-end neural systems. In a cancer genomics exercise, a model read free-text breast pathology reports for biomarker status, ordinary Structured Query Language pulled the matching genomic records, and explicit business logic checked whether the two agreed. The fixed rules can be verified directly while the model's guesses stay under monitoring.
What Lasts After the Course Ends
Six weeks after the two-day course, the same cohort returned for an internal hackathon on problems they chose themselves. One team built an immune-related adverse events explorer. Its core is a Guideline-Grounded Retrieval-Augmented Generation module, a design in which a model first retrieves passages from trusted documents and then answers from them, here using national oncology guidelines alongside data analytics modules.
Just and Tan also flag how fast course content ages. The specific model checkpoints taught to the first cohort were overtaken within months. Their conclusion is that training built around products expires, while the underlying ideas of ingestion, retrieval, specialised inference, deterministic checks and evaluation stay useful.
| Model type | What it does | Task in the course |
|---|---|---|
| Encoder | Represents text meaning; runs vector search | Retrieved clinical practice guidelines |
| Cross-encoder | Re-ranks and classifies candidates precisely | Ranked retrieved guidelines by relevance |
| Autoregressive decoder | Generates structured text | Summarised a pathology report from guideline text |
Will this approach spread beyond one cancer center?
The case for
- Synthetic training data lets institutions run hands-on courses without exposing protected health information.
- Small models on commodity hardware lower the cost of entry for health systems without large compute budgets.
- Teaching durable concepts rather than specific products sidesteps the obsolescence the authors saw within months.
- Later cohorts adapted the rules to financial services, suggesting they transfer to other tightly governed sectors.
The case against
- Local deployment does not by itself meet every legal requirement, so compliance work remains for each institution.
- Small models have limits in reasoning depth, context breadth and language robustness that need escalation routes.
- The course did not mandate any regulatory framework, leaving governance choices to the teams themselves.
What to be careful about
- The framework comes from a single course at one comprehensive cancer center, so its results in other settings are untested in the published work.
- Model errors in biomarker extraction could lead to unsuitable chemotherapy or trial exclusion if evaluation is skipped or rushed.
- Specific models taught in such courses can be superseded within months, so material tied to products dates quickly.
The bottom line
The paper by Just and Tan is a teaching method, not a clinical trial, and it should be read that way. It reports one course, at one cancer center, for more than sixty staff, and it offers no measured outcomes for the people trained. What it does supply is a coherent design: put engineers and analysts in the room with data scientists, give them flawed synthetic data, keep models local and test their limits, and measure before optimising. The strongest argument may be the one about obsolescence. If the models taught in a course are overtaken within months, the lasting value lies in teams that can evaluate the next model on their own clinical problems.
What to watch
- Watch for whether the immune-related adverse events explorer built at the hackathon moves from prototype into routine use; no date has been given.
- Watch for published results from the financial services cohorts that adapted the ten rules; no date has been set.
Frequently asked questions
Does running AI models locally make a hospital compliant with privacy law?
Not on its own, according to Eric Just and Aik Choon Tan. Local deployment keeps data within boundaries the institution controls, which removes major leakage risks, but it does not automatically meet every legal requirement.
Can the ten rules be used outside healthcare?
The authors report that later cohorts adapted the ten rules to financial services. That sector shares strict data governance and privacy demands, which is why they see the systems-level approach as transferable.
What did trainees build after the course?
At a hackathon held six weeks after the two-day course, participants built an immune-related adverse events explorer. It answers clinical management questions using national oncology guidelines through a Guideline-Grounded Retrieval-Augmented Generation module, backed by data analytics modules.
Related reading
