Why start with the workflow
Before any model touches patient information, a research team usually needs to understand the system it is working in: how referrals arrive, where queues build up, which handovers lose information, what happens when one role is short-staffed. These are questions about process, and they can often be explored with a simulation that contains no personal data at all.
A workflow simulation lets practitioners and researchers change one assumption at a time and discuss the result together. It is a conversation tool first. If it later informs a study design, that is a bonus, not a premise.
Synthetic data as a safe sandbox
Synthetic records, generated to resemble the structure of real data without describing real people, are useful for building and testing interfaces, rehearsing analysis pipelines and training staff on a tool. They have limits. Synthetic data can reproduce the biases of whatever it was modelled on, and it cannot prove that a method works on real patients. We treat it as scaffolding: good for building, never the final evidence.
Synthetic data is not automatically anonymous. If it is generated from real records, information leakage and re-identification risks still need assessment before the dataset is shared or used.
In practice, every synthetic dataset we would use comes with a short data card: how it was generated, which real-world distributions it imitates, which it deliberately ignores, and which questions it should never be used to answer. That card travels with the prototype, so that nobody later mistakes a convincing demo for evidence. It also gives ethics reviewers something concrete to read, instead of a promise that the data is safe because it is artificial.
The same discipline applies to AI-assisted evidence exploration. A tool that helps researchers search and summarise literature can save time, but summaries can omit caveats or misattribute findings. We design such tools so that every statement links back to its source and a qualified reviewer signs off before anything enters a report.
Write down what the tool is for before writing the code. Then write down what it is not for.
Define intended use, in writing
Every health-related prototype we would co-develop starts with a short intended-use statement agreed with the research partner. It covers:
- Who uses it: for example, researchers or service planners, not patients.
- What it supports: exploring process scenarios, structuring literature searches, explaining concepts.
- What it must never do: diagnose, recommend treatment, triage individuals or act as a medical device.
- Which data it may touch: synthetic, public or properly governed research data only.
Human oversight that means something
The World Health Organization’s guidance on the ethics and governance of AI for health places human rights, accountability and governance at the centre. It is a framework of principles, not a certification scheme, and following it does not make any tool approved or safe by itself. In practice we translate it into named responsibilities: a qualified person checks AI-assisted summaries before they are used, every output can be traced to its sources, and the team agrees in advance when a prototype should be paused.
A starting checklist for research teams
- Map the workflow with the people who do the work.
- Agree the intended-use statement and its exclusions.
- Prototype with synthetic data and record its known limits.
- Assign a named reviewer for every AI-assisted output.
- Involve your ethics and data-protection processes before any real data is considered.
Where to go next
Our health research direction lists what we offer and what we do not. For the educational version of the same discipline, read AI and simulation: learning through decisions, or return to the blog index.
