AI can describe a study. Can it design one safely?

Editorial infographic distinguishing fluent text from a verified code list. A study protocol leads through clinical concept, candidate codes and expert review; the final check concerns the coding system, version and inclusion logic. Source DOI 10.1007/s11095-026-04190-5.

Original editorial illustration; the example is illustrative, not a study finding. Source: Zhang et al., Pharmaceutical Research (2026), DOI: 10.1007/s11095-026-04190-5.

A language model can produce a convincing description of a drug study: identify participants, propose a follow-up period and explain the chosen outcome. The difficulty emerges when polished prose must become precise rules for selecting data. New research shows why evaluating AI should go beyond asking whether its answer sounds professional. Even a favourable comparison with expert assessments does not establish that a system can independently design studies or make clinical decisions.

What did the researchers actually test?

Xinyao Zhang and colleagues used 46 publicly available pharmacoepidemiology study protocols from the HMA–EMA Catalogue, including the DARWIN EU programme, and the US Sentinel System. Pharmacoepidemiology examines issues such as medication use, effectiveness and safety in populations. This experiment did not treat 46 patients: its starting material consisted of documents describing research plans. The full paper was published in Pharmaceutical Research on 11 September 2026.

Experts extracted a reference set of study-design answers from the protocols. These covered matters such as the start of follow-up, eligibility criteria, drug exposure, outcomes and additional variables considered in the analysis. The models’ answers were compared with that reference. An important detail is that the models did not receive the complete protocol documents. This was therefore not simply a test of accurately summarising supplied text.

The assessment separated several questions: how closely answers matched the reference, the quality of their justification and agreement on database codes. These are different capabilities. A correct sentence about diabetes does not guarantee that a program will select the appropriate diabetes records. Likewise, a plausible explanation does not establish that an exposure definition answers the research question.

General-purpose models performed better—but this was not a verdict on medical specialisation

In the configurations tested, general-purpose models, particularly GPT-4o and DeepSeek-R1, performed better than the selected smaller biomedical models. That finding should not become a claim that medical specialisation harms AI, or that every popular chatbot is superior to a specialist system. The comparison involved particular available configurations, not simply the presence or absence of medical knowledge.

The groups differed in model size, architecture, instruction tuning and deployment conditions. Some smaller models also used different numerical precision. These differences make it difficult to identify a single explanation for the performance gap. The defensible conclusion is that these general-purpose configurations performed better on this test. The result is neither a permanent product ranking nor a prediction of what future versions will achieve.

Similar caution applies to prompting techniques. Comparing two strategies within the same GPT-4o model did not show a significant difference in overall relevance: the paired comparison gave p = 0.93. This does not establish equivalence across all applications. Nor does it justify promising that a sufficiently elaborate prompt will remove a model’s limitations. The methods and results are available in the original paper.

AI assessed AI. Can those ratings be trusted?

GPT-4o assigned some of the ratings, including ratings of its own generated answers. That reasonably raises the possibility of a preference for its own style or reasoning. It does not establish that such bias occurred. The researchers conducted an additional blinded human check in a selected subsample: the experts did not know the identity of the model being assessed or the automated label.

Within the checked subsample, the experts reproduced the automated assessments. This positive result deserves to be stated clearly, rather than leaving readers with an unresolved suggestion of self-assessment bias. However, a checked subset does not become the entire dataset, and agreement between assessors does not change what the experiment tested. It still evaluated answers against historical protocols, rather than a system’s performance in everyday practice.

Two meanings of “validation” must therefore remain separate. Here, the researchers checked the reliability of part of the benchmark’s assessment process. They did not demonstrate that deploying the model in a new team improves decisions, reduces errors in real analyses or benefits patients. Accurately reporting the first type of validation does not allow us to assume the second. That distinction is essential when communicating AI research.

Codes: the hidden detail that can change a study

Medical databases use structured identifiers as well as disease and medication names. Code selection helps determine which records enter an analysis and which events count as outcomes. If important codes are missing, the study may cover a different population from the one intended. If the list is too broad, it may include records outside the chosen definition.

Mapping these codes remained a weakness of the assessed models. There is an important qualification: not every disagreement with the reference was an invented code or a medical error. Some differences involved identifier conventions, such as native codes versus corresponding identifiers in the OMOP data model. A valid concept expressed in another system requires an agreed mapping, not an automatic accusation of hallucination.

The practical lesson is not that every AI-generated code is false. It is that linguistic quality and operational correctness need separate checks. The authors discuss controlled dictionaries, agreed mappings and rule-based validation. A model can suggest a direction, but its code list needs verification against the appropriate terminology, version and research context. See the paper’s Ontology-Code Agreement and Discussion sections.

What does a strong benchmark result leave unanswered?

Agreement with a historical protocol is not the same as general methodological validity. Two reasonable study proposals can differ, and an answer that diverges from the reference document need not be wrong. Conversely, matching an existing document does not guarantee that a model will identify a problem absent from that reference. The result must be interpreted alongside the study’s definition of success.

The possibility that memorisation of public material contributed to agreement was not excluded. A stronger test would prospectively use new protocols developed after the training-data period, with assessment criteria specified in advance. This is a direction for further evaluation, not an allegation of proven data leakage in this study. Similarity to a reference answer does not, by itself, explain how the answer was produced.

Another limitation was missing human ratings of justification quality, distributed unevenly across configurations. Looking only at assessable answers can give a different picture from accounting for unsuccessful attempts. The authors presented sensitivity analyses. When reading the charts, it is therefore worth asking not only how high the scores are, but also which answers are absent from them.

Including protocols from several sources should not be confused with fully validating deployment in an external setting. Diverse material is a strength, but does not reproduce every language, documentation practice or team workflow. The reference points here were particular documents and defined tasks. A new centre may have different inputs and different consequences of error. Before transferring the result to a local project, a test under its actual working conditions would be needed, involving those responsible for the final analysis. It is particularly important to define when an answer is unusable and must be escalated to an expert rather than accepted because it looks complete.

What would a cautious pilot look like?

The following steps are practical workflow suggestions, not a procedure validated by this experiment. Start with a narrow task, such as drafting selected protocol elements. Then decide what a person checks, what a dictionary or program checks, and what the system cannot approve independently. A broad instruction to “design a study” cannot replace that allocation of responsibility.

Before using an answer, record the model version, instructions and sources supporting individual decisions. Review should cover the population, comparator, timeline, exposure and outcome definitions, and completeness of the codes—not just fluent writing. Decisions should be traceable, with a named person approving the final document. Professional-looking prose does not compensate for an absent review trail.

A pilot’s evaluation should include time spent checking and correcting answers, not merely the time taken to generate them. It should consider error types and whether the tool helps with difficult cases or only routine examples. This paper does not provide a complete implementation cost calculation or demonstrate labour savings in every organisation. Such benefits should not be promised on its basis.

Privacy, cybersecurity and the permitted scope of use require separate assessment. Research based on public protocols does not establish that sending patient records to an external service is safe. It also does not replace a review of the organisational and legal requirements of a particular deployment. Until that work is done, a favourable scientific result should not be treated as permission for unrestricted data use or automated decision-making.

What should patients, clinicians and project leaders remember?

For patients, the key point is that this study did not compare the effectiveness of treatment delivered by a clinician with treatment delivered by AI. It does not justify changing medication or replacing a consultation with a chatbot. For clinicians and researchers, it supports scrutiny of the entire process rather than an attractive answer. For project leaders, it reinforces the need to match a tool to its task and control the consequences of errors.

We do not have to choose between enthusiasm and rejection. AI can help prepare working material while people retain responsibility for definitions, data and conclusions. In this study, stronger agreement with protocols and human confirmation of part of the assessment are valuable findings. They are not a licence for autonomy. Before introducing a model into your team’s work, ask: who will verify the output, against which criteria, and how will we recognise failure?

Source and transparency

Zhang X, Heckmann NS, Del Castillo Suero M, Speca FP, Sessa M. Employing General-Purpose and Biomedical Large Language Models with Advanced Prompt Engineering for Pharmacoepidemiologic Study Design. Pharmaceutical Research, 2026. DOI: 10.1007/s11095-026-04190-5. The authors declare no conflicts of interest; open-access funding was provided by the University of Copenhagen. The source article is available under CC BY 4.0. This is an independently written educational commentary, not a translation of the complete research paper. The journal’s quartile remains unverified.

Autor: prof. dr hab. n. med. Krzysztof Łukaszuk