Ask where AI should first touch medical content and the answers are usually manuscripts or clinical study reports — the two places where the constraints are tightest. The better answer is the one nobody gives: plain language summaries.
Why they exist, and why there are so many
Lay summaries are not a nice-to-have. Under the EU Clinical Trials Regulation 536/2014, a sponsor must submit to the EU database a summary of results accompanied by a summary written so that a layperson can understand it. The deadlines are fixed: within 12 months of trial end for adult trials, 6 months for paediatric trials, and up to 30 months for non-therapeutic Phase 1.
Separately, a plain language protocol synopsis is required as part of the initial application under Annex I D.24 — authored in English and then translated into the local language of every country where the study runs.
And GPP 2022 explicitly brought plain language summaries into the scope of good publication practice, alongside manuscripts, abstracts, posters, congress presentations and preprints.
Add those together and you get a document class that is mandatory, deadline-bound, produced at volume, and multiplied by the number of countries a trial runs in. That is a lot of writing that has to happen whether or not anyone has capacity for it.
The reason this is the right first use case
The constraint that governs everything else in medical publishing is that you cannot put unpublished manuscripts or patient data into general-purpose LLMs — Wiley, Wolters Kluwer and Elsevier all warn against it explicitly.
Plain language summaries are largely derived from material that is already approved, already public, or both. A lay summary of results is written from a completed, locked dataset and an approved technical summary. A plain language protocol synopsis is derived from an approved protocol. The source is not a draft manuscript circulating before peer review.
That single difference changes the risk profile substantially. It does not make the work unregulated — accuracy obligations are, if anything, higher, because the audience is patients. But it moves the work out of the category where the tooling question is closed before it opens.
What AI is genuinely good at here
- Readability transformation. Converting technical register into lay register against a target reading level is close to the canonical language-model task, and it is the part human writers find most tedious.
- Multilingual output. The synopsis must exist in the local language of every participating country. That is a volume-and-consistency problem, not a creative one.
- Consistency against the source. Checking that the lay version has not quietly changed a result while simplifying it — mechanical, exhaustive, and exactly where human error creeps in.
- Template conformance. Annex V has expected content. Checking presence and structure before a human reads it saves a review cycle.
Where it goes wrong, and it goes wrong badly
Two failure modes, and the second is the one to fear.
Simplification that changes meaning. "No statistically significant difference was observed" is not "the treatment did not work", and a model optimising for readability will happily make that substitution. In a document written for patients, that is not a style error. It is a misrepresentation of a trial result to the people who took part in it.
False confidence in tone. Lay summaries must convey uncertainty. Generated text tends to read fluently and definitively, and fluency is easily mistaken for accuracy by a reviewer skimming a document that looks finished.
Both failure modes are caught by the same control: a named human sign-off that cannot be skipped, and a diff against the technical summary. Not a policy sentence — a workflow step. In our clinical-NLP work that structure produced 100% clinician sign-off on every summary while still cutting turnaround by 60%.
How to start
Smaller than you would expect, because the point is to prove the control, not the capability.
- Take a set of already-published lay summaries and their technical sources.
- Generate lay versions from the technical summaries alone, then compare against the human-written originals. You are testing for meaning drift, not for style.
- Count the differences that matter. If a model changes a result even once in twenty, you have learned exactly what your review step must catch.
- Only then run it forward on live work, with the sign-off step in place from day one.
For where this sits in the wider workflow, see AI for medical publishing; for the tools by job, see AI tools for medical publishing.