# About Source: https://playbook.pharmatools.ai/about Why this playbook exists, how it is maintained, how AI was used to write it, and the interests behind it. ## Who wrote this The Medical Writing AI Playbook was created by Nick Lamb, a medical writer and AI developer working at the intersection of healthcare communication and applied AI. ## Background Nick has more than 20 years of experience in medical communications, working across publications, medical affairs, and regulatory writing. Alongside that work, he has been building practical AI tools for the problems that show up repeatedly in medical writing — verifying claims against references, checking content for compliance issues, extracting structured data from source documents, and making complex medical information easier to understand. ## Why this playbook exists Most guides to AI focus on generic prompts, productivity tips, or tool lists. Medical writing needs something more specific. Evidence-based scientific communication depends on four things that general AI guidance rarely addresses: * Source grounding — every claim tied to a specific document * Accurate interpretation — numbers, endpoints, and populations reported as the source describes them * Regulatory awareness — understanding what can and cannot be said in a given context * Careful wording — the difference between "associated with" and "improves" is not cosmetic This playbook was written to provide practical guidance for using AI across the full medical writing lifecycle — from evidence handling through drafting, adaptation, verification, and delivery — in a way that respects those constraints. ## Informed by practical systems Many of the examples, workflows, and failure modes described in the playbook are informed by real systems built for medical writing and healthcare communication — including tools such as [RefCheckr](/tools/refcheckr) for closed-loop claim verification and rewrite, [MedCheckr](/tools/medcheckr) for compliance review, and [Patiently AI](/tools/patiently-ai) for plain language explanation. The aim of the playbook is not to promote any particular tool. It is to share the patterns — what works, what fails, and what deserves human judgement — that have emerged from building and using them in practice. ## How this playbook is maintained The playbook makes specific, dated claims about journal policies, regulatory positions and tool capabilities. Those claims go out of date. This is how they are kept current. **Review cycle.** Every page is reviewed at least quarterly. The "Last reviewed" date at the foot of each page is the real date of that review, not the date of the last typo fix. **Event-driven updates.** Pages are updated out of cycle when something material changes — a journal revising its AI policy, a regulation coming into force, a tool changing what it does. Two examples from 2026: [JAMA Network moved three categories from "disclose" to "not permitted"](/principles/declaring-ai-use) in August, and the [EU AI Act's transparency obligations became enforceable](/principles/ai-regulation) on 2 August. Both were reflected within days. **Sourcing.** Factual claims link to a primary source — the publisher's own policy page, the regulation, the agency guidance. Where a policy is likely to change, the playbook links to it rather than reproducing it, so a stale copy here cannot quietly contradict the real thing. **Corrections.** If something here is wrong, [report it](https://github.com/nickjlamb/medical-writing-ai-playbook/issues/new/choose). Corrections are made openly and noted in the [changelog](/changelog) — the full edit history is public in the [GitHub repository](https://github.com/nickjlamb/medical-writing-ai-playbook). **Version.** The playbook is versioned, and every version is archived with a downloadable PDF. If you are working from a saved copy, the version and date are on its cover. *** ## Disclosures The playbook asks writers to declare AI use and disclose interests. It should hold itself to the same standard. **Commercial interest.** The playbook is written by the founder of [PharmaTools.AI](https://pharmatools.ai), and several tools referenced in it — RefCheckr, MedCheckr, Patiently AI, LLMentor, PLS Generator, PosterLens, PubCrawl — are PharmaTools.AI products. They are commercial. That is a real interest, and it is the reason those tools appear at the workflow steps where they fit. **How that is handled.** Workflow pages name third-party alternatives alongside the PharmaTools.AI options, and the [tool ecosystem page](/tools/ecosystem) covers the wider landscape regardless of who built it. The principles, risk framework, disclosure guidance and review standards are tool-agnostic and stand whether or not you use any of these products. Where a general-purpose model does the job, the playbook says so. **Independence.** The playbook receives no external funding and carries no sponsorship, advertising or paid placements. No pharmaceutical company, publisher, agency or AI vendor has reviewed, approved or paid for any of this content. **Free and ungated.** Every page is public. There is no login, no paywall, no email capture. The PDF is a direct download. *** ## How AI was used to write this Applying the [disclosure template](/templates/disclosure-language) from this playbook to the playbook itself: > Claude (Anthropic) was used throughout the development of the Medical Writing AI Playbook — for research and source gathering, page structure and outlining, prose drafting, and for the repository tooling, build scripts and site configuration. All content was reviewed, edited and verified by Nick Lamb, who takes responsibility for the accuracy and integrity of the published material. Some specifics, because vague disclosure is the thing this playbook argues against: **Every factual claim was verified against a primary source by a human.** No journal policy, regulatory date or tool capability appears here because a model asserted it. This matters most for references and citations, which are [the failure mode most likely to embarrass you](/principles/ai-failure-modes) — nothing in this playbook cites a source that was not opened and checked. **AI drafted; it did not decide.** Risk tiers, review requirements, what belongs in the playbook and what does not, and every judgement about where AI should not be used are editorial decisions made by a person. **The same limits apply here as anywhere.** This playbook was produced with AI assistance, and it is not thereby exempt from the failure modes it documents. If you find a claim that does not hold up, that is exactly what the [corrections process](https://github.com/nickjlamb/medical-writing-ai-playbook/issues/new/choose) is for. *** ## Using and citing this playbook The playbook is published under [CC BY 4.0](https://github.com/nickjlamb/medical-writing-ai-playbook/blob/main/LICENSE). You can use, adapt and build on it — including commercially, and including inside your organisation's SOPs and training materials — with attribution. **Suggested attribution:** > Adapted from the Medical Writing AI Playbook by Nick Lamb / PharmaTools.AI, licensed under CC BY 4.0. [https://playbook.pharmatools.ai](https://playbook.pharmatools.ai) **Suggested citation:** > Lamb N. Medical Writing AI Playbook. PharmaTools.AI; 2026. Available from: [https://playbook.pharmatools.ai](https://playbook.pharmatools.ai) *** ## Selected writing [A Day in the Life of an MSL Powered by AI: Combining AI Technologies to Transform Training](https://jngr5.com/jngr/article/view/70/53) — *Journal of Next-Generation Research 5.0*. A conceptual example of how RAG, generative AI, multimodal systems, and AI agents combine to support pharmaceutical workflows. [How to Break a Large Language Model](https://ai.gopubby.com/how-to-break-a-large-language-model-4a557b28581a) — *AI Advances*. On the ways large language models fail under stress and ambiguous prompts. [Translation, not Interpretation: Rethinking Language Model Design for Healthcare](https://link.springer.com/article/10.1007/s42399-026-02316-9) — a deeper discussion of why healthcare AI systems should focus on translation rather than interpretation. *** AI tools will keep changing. The fundamentals of good medical writing will not: clear evidence, careful interpretation, and responsible communication. *** *Last reviewed: 20 August 2026 · 6 min read* # Changelog Source: https://playbook.pharmatools.ai/changelog Version history and updates to the Medical Writing AI Playbook. ## v2.8 — 19 August 2026 * **[Choosing Your Model](/principles/choosing-your-model) gains a fourth selection axis: resource cost.** Cost, quality and latency are what you trade against on a single task; at team scale, energy and water move alongside them. The new section covers why over-powered model choice compounds — the tasks already listed as reasoning-model overkill are the ones where the saving is free — why CSRD-driven environmental questions are starting to reach agency RFPs through procurement, and the proportionality point: a frontier model on a high-stakes regulatory document is a good use of resources, the same model generating fifty social captions is not. Sized with the [AI Water and Energy Footprint Calculator](https://www.pharmatools.ai/water-consumption-calculator). * **[Agentic Workflows](/principles/agentic-workflows)** — new entry under "When an agent is the wrong tool": a single instruction becomes many model calls, so a loop that is not earning its keep multiplies the same overkill rather than causing a different one * **Homepage rewritten above the fold** — the hero subhead now leads with the accountability tension rather than listing lifecycle stages, and the `description`, `og:description` and `twitter:description` tags are decoupled from it into a single keyword-bearing line, synced with the homepage entry in `product/SEO-METADATA.md` (the two had drifted, so the SEO copy had never reached the page it was written for) ## v2.7 — 16 August 2026 * **[AI Regulation in Pharma](/principles/ai-regulation) updated for Article 50 coming into force.** The EU AI Act's transparency obligations became enforceable on 2 August 2026, and foundation model providers have begun marking their output at source — [Anthropic watermarking Claude's text output globally](https://www.anthropic.com/news/claude-text-watermark), Google's SynthID doing the same for Gemini, and C2PA content credentials on generated image files. The page previously described detectability as a future obligation; it now describes what has actually shipped and what it means for writers: * New **Provider-side content marking** section — what text watermarking is, which providers have deployed it, and the limits of detection: there is no public cross-provider detector, Anthropic's detection API is announced but unreleased, and the signal is weakest on short, factually constrained or heavily rewritten text, which describes most medical writing after author review and MLR * **The marking obligation sits on the provider, not on you** — a watermark is not a disclosure and changes nothing about what you declare * **Article 50(4)'s human editorial review exemption made explicit** — text published under a named person holding editorial responsibility is not, in the Act's own terms, undisclosed synthetic content, which puts the named-reviewer model the playbook argues for throughout on a statutory footing * **Implementation timeline** corrected to present tense, with the 2 December 2026 grace period for machine-readable marking of synthetic content added ## v2.6 — 11 August 2026 * **Disclosure guidance updated for JAMA Network's tightened AI policy** ([editorial, 10 August 2026](https://jamanetwork.com/journals/jama/fullarticle/2852772), doi:10.1001/jama.2026.16613). JAMA has moved three categories from "disclose" to "not permitted": AI-generated or AI-formatted references, AI-drafted Opinion articles, Letters to the Editor and online Comments, and AI-created or AI-manipulated clinical images, illustrations, video and audio. The playbook's disclosure pages assumed any use could be disclosed into acceptability; that framing no longer holds, so the change is threaded through five pages rather than confined to the policy table: * **[Declaring AI Use](/principles/declaring-ai-use)** — JAMA row rewritten with the full set of prohibitions and the expanded disclosure fields (tool, version, manufacturer, dates of use, portions affected, statement of author responsibility); new framing on the shift from disclosure to prohibition; the "what counts as AI use" table revised, with new rows for Opinion drafting and for permitted adjustment of existing scientific images; two new Common Mistakes entries * **[Disclosure Language Template](/templates/disclosure-language)** — reference **verification** (still acceptable) separated from reference **generation** (now prohibited); figure snippet scoped to conceptual visuals, with a new snippet for uniform adjustment of existing scientific images; manufacturer and dates of use added throughout; new section documenting the uses that deliberately have no template because they are barred * **[Pre-Submission QC Checklist](/templates/pre-submission-qc-checklist)** — new checks for prohibited uses, AI-free reference compilation, clinical-image provenance, uniform image adjustment and retained originals, plus a sign-off row * **[AI in Peer Review](/principles/ai-in-peer-review)** — notes that journals are now responding upstream with policy, not only at the automated screening gate * **[Generate Concept Visuals](/workflows/generate-concept-visuals)** — reality check extended to cover journal submissions, not just regulatory and MLR-bound materials ## v2.5 — 26 July 2026 * **[The Description–Discernment Loop](/principles/description-discernment)** added to Principles — applying concepts from the AI Fluency Framework (Dakan & Feller, as taught in Anthropic's AI Fluency courses) to medical writing: * **Description** — briefing AI like you'd brief a writer: approved prior work as voice examples, injecting the context AI can't know (client sensitivities, MLR history, audience realities), and describing the approach (source-grounding rules) not just the output — with a confidentiality warning on what may be uploaded * **Discernment beyond accuracy** — an explicit "does it sound like us?" voice check, and process-level discernment (recurring corrections belong in the brief, not in another round of edits) * **Closing the loop** — a specific-vs-vague revision instruction table, plus two safety rules: pin what must not change, and re-verify anything the model touched * **Briefing packs** — a reusable per-client/per-product context document that accumulates what each project teaches you * **[Voice and Authenticity Check](/prompts/review-prompts#7-voice-and-authenticity-check)** added to Review Prompts — compares a draft against approved reference examples for generic AI register, vocabulary drift, and register mismatch * **[Final Human Review](/workflows/final-human-review)** checklist extended with a voice check under AI-specific checks ## v2.4 — 16 May 2026 * **Playbook now available as a downloadable PDF** — every page of the playbook (cover, principles, workflows, prompt patterns, tools, templates) bundled into a single A4 PDF with auto-generated table of contents and section dividers. Linked from the homepage hero ("Download as PDF") and the [Start Here](/start) page. Rebuilt automatically on every content update via GitHub Actions and published to GitHub Releases so the download URL always serves the latest version. ## v2.3 — 4 May 2026 * **Five new Principles pages** covering the 2025–26 AI landscape: * **[Declaring AI Use](/principles/declaring-ai-use)** — journal, regulator, and sponsor disclosure expectations, with mid-2026 policy snapshot for ICMJE, NEJM, Lancet, JAMA Network, BMJ, Nature, Science/AAAS, and WAME (each linked to the publisher's actual AI policy page) * **[AI Regulation in Pharma](/principles/ai-regulation)** — the EU AI Act's risk-tier system, Article 50 transparency obligations, foundation model provider obligations, with brief notes on FDA, EMA, MHRA, WHO, PMDA, and NMPA frameworks * **[Choosing Your Model](/principles/choosing-your-model)** — when to reach for a reasoning model vs. a standard LLM vs. a frontier model, with a practical decision matrix and a worked example of mixing model classes across a manuscript workflow * **[Agentic Workflows](/principles/agentic-workflows)** — generalising the closed-loop pattern (RefCheckr) to other agent applications, with five agent patterns and the failure modes specific to agentic systems * **[AI in Peer Review](/principles/ai-in-peer-review)** — what publishers run on submissions before peer review, where the screens work well vs. where they don't, and a pre-submission QC checklist * **Glossary expanded** with twelve recent AI terms — Computer use, Frontier model, Grounding, Guardrails, Harness, Human-in-the-loop (HITL), Open-loop AI, Prompt injection, Reasoning model, Skill, System prompt, and Tool use * **Homepage hero** added — gradient-background block with the playbook headline, subtitle, and primary/secondary CTAs replacing the previous doc-page intro; auto-rendered title suppressed via project-level CSS scoped to the homepage only **Version numbering.** Entries below this point were originally numbered v2.0–v2.24. They were renumbered to the v1.x series on 19 August 2026 to clear six duplicate version numbers, created when the current series restarted at v2.3 on 4 May 2026. Only the numbers changed; dates and content are untouched. ## v1.24 — 4 May 2026 * **RefCheckr rearchitected as closed-loop AI** — RefCheckr now runs a Verify (Perplexity) → Fix (Claude) → Re-check (Perplexity + MedCheckr ABPI compliance) loop, re-running on failure. It no longer just flags mismatches: it rewrites claims using only evidence from the paper (with guardrails — no new numbers, no new endpoints, no stronger language) and re-verifies the rewrite before returning it * **[RefCheckr tool page](/tools/refcheckr)** rewritten with a "How the closed loop works" table covering Verify, Fix, and Re-check steps and the underlying stack * **Closed-loop AI** added to the [glossary](/glossary), anchored to RefCheckr as the working example * **Playbook-wide language refresh** — workflow tool-stack tables, the Verify Claims Against References workflow header diagram and steps, the Tool decision tree, the PubCrawl comparison table, the Source grounding principle, the homepage card, the Start guide, and the about page all updated to describe RefCheckr's closed-loop behaviour rather than the old verify-only framing ## v1.23 — 20 April 2026 * **Generate Concept Visuals with AI** workflow page added under Drafting — when to use AI image generation (conceptual figures, visual abstracts, slide visuals, social graphics), the tool landscape (Nano Banana 2, Midjourney, ChatGPT, Adobe Firefly), four prompting patterns, and a "Reality check" section covering what AI images must not be used for (exact scientific figures, data visualisations, regulatory-facing materials without review, patient depictions implying outcomes, identifiable people or products) * **Nano Banana 2** and **Midjourney** added to the [Tool ecosystem](/tools/ecosystem) under a new **AI image generation** section, with an explicit pointer that AI image tools are not substitutes for BioRender or a medical illustrator on scientific figures * **Decision tree** updated with a new row for concept images, visual abstracts, slide visuals, and social graphics ## v1.22 — 18 April 2026 * **Claude Design** added to the [Tool ecosystem](/tools/ecosystem#claude-design) under a new **Design and brand concepting** section — Anthropic Labs' design surface for pitch decks, leavepieces, marketing collateral, and prototypes, framed for medical writers who are increasingly being asked to generate visual concepts before a designer takes over * **Decision tree** updated with a new row mapping brand concepts, leavepieces, ad mockups, and pitch deck visuals to Claude Design ## v1.21 — 15 April 2026 * **AI Failure Modes in Medical Writing** page added to Principles — ten predictable ways AI fails when working with scientific evidence, each with example, why it matters, and how to catch it, plus a summary table ## v1.20 — 14 April 2026 * **Which tool when** decision tree added to the Tools section — a Mermaid flowchart plus fast-reference list mapping common medical writing tasks to the right tool, covering both third-party options and the PharmaTools.AI suite ## v1.19 — 14 April 2026 * **Claude Cowork** section on the Tool ecosystem page expanded with a practical example workflow, example prompt, and a short "Why this workflow matters" explainer ## v1.18 — 13 April 2026 * **Patiently AI** tool page updated with OpenClaw installation option — Patiently AI is now available as a skill on ClawHub (`clawhub install patiently-ai`) ## v1.17 — 9 April 2026 * **Tool ecosystem page** added to the Tools section — single consolidated reference covering all 16 third-party tools the playbook points to (Claude Cowork, NotebookLM, Elicit, Consensus, Perplexity, Scite.ai, Zotero, EndNote, Claude, ChatGPT, Microsoft Copilot, BioRender, Napkin, Gamma, Otter.ai, Fireflies.ai) * Tools grouped by job-to-be-done (multi-document workflows, single-paper exploration, literature search, reference management, general-purpose AI, enterprise productivity, figures, presentation generation, transcription) * Each entry links to the playbook workflows and tool pages that already reference it, so readers can jump from the directory back into context * The Tools sidebar group now contains the seven PharmaTools.AI products plus a single ecosystem entry, preserving the section's role as a product surface while giving readers one place to discover external options ## v1.16 — 9 April 2026 * **BioRender** added (Slide Deck, Manuscript) — publication-quality biological figures * **Microsoft Copilot** added (Slide Deck, Manuscript, Regulatory Document) — in-Word/PowerPoint drafting for enterprise pharma environments * **Otter.ai / Fireflies.ai** added (Extract Key Messages) — transcription for advisory boards, KOL interviews, and focus groups * **Scite.ai** added (Verify Claims, Find Evidence, RefCheckr complementary tools) — citation context analysis ## v1.15 — 9 April 2026 * **Claude Cowork** added as a third-party tool across 6 pages (Find Evidence, Extract Study Data, Extract Key Messages, Write a Manuscript, Draft a Regulatory Document, PubCrawl) * Positioned for structured workflows involving multiple source documents (analysing papers together, comparing trials, drafting from multiple sources) * Distinct from NotebookLM (single-paper exploration) and inline Claude/ChatGPT (pasted text) * **Glossary expanded** from 27 to 48 terms — added DOI, EMA, EudraCT, FDA, HEOR, IB, ICH, MCP, MedDRA, MeSH, MOA, MSL, ORR, OS, PFS, PICO, PMCPA, PMID, PRISMA, QALY, SAP, TFL * **PubCrawl tool page** updated with MCP server explanation and installation details ## v1.14 — 9 April 2026 * **NotebookLM** added as a third-party tool across 6 pages (Find Evidence, Summarise a Paper, Extract Study Data, Extract Key Messages, Write a Manuscript, PubCrawl) * Positioned for source-grounded summarisation, paper familiarisation, and theme identification * Homepage intro rewritten for clarity and directness * Meta description simplified ## v1.13 — 8 April 2026 * **Risk Levels** renamed to **Understanding AI Risk in Medical Writing** and rewritten as a conceptual page (why risk varies, failure modes, risk factors) * **AI Risk Framework** tightened as the operational page (tier model, workflow mapping, review expectations) * Overlap between the two pages reduced: conceptual content lives on Understanding AI Risk, operational content lives on the Framework * Cross-links added between the two pages * All references to "Risk Levels" updated across the playbook ## v1.12 — 8 April 2026 * **AI Risk Framework** added to Principles: a 4-tier governance framework (Assistive → Structured Transformation → Evidence-Critical → Human Authority Required) * Maps all 17 workflows to risk tiers with notes on context-dependent classification * Includes review expectations by tier and practical guidance for writers, teams, and stakeholder conversations ## v1.11 — 8 April 2026 * **Workflows grouped in sidebar** into 5 lifecycle stages: Evidence & Insight, Drafting, Adaptation, Validation, Delivery * Reduces visual clutter of the 17-item flat list and reinforces the lifecycle structure ## v1.10 — 8 April 2026 * **3 new regulatory-adjacent workflows** added: Draft a Regulatory Document, Convert Statistical Outputs to Narrative, Check Document Consistency * Integrated into existing lifecycle: regulatory drafting sits in the Draft stage, document consistency sits in the Validate stage * Homepage lifecycle map and card grid updated with new workflows * Cross-links added from Write a Manuscript, Extract Study Data, Build an Outline, and Verify Claims to the new workflows * Playbook now covers 17 workflows across publications, medical affairs, medcomms, regulatory writing, and promotional content ## v1.9 — 8 April 2026 * **Workflow lifecycle map** added to homepage: a 6-stage table (Evidence → Insight → Draft → Adapt → Validate → Deliver) linking all 14 workflows * Card grid reordered to match the lifecycle sequence * Cards grouped by lifecycle stage using natural CardGroup breaks (3-2-3-2-2-2 layout) * Two navigation modes now supported: lifecycle overview (table) and task-based access (cards) ## v1.8 — 8 April 2026 * Sidebar reordered: Congress Summary moved after Summarise a Paper (reflects the evidence-first lifecycle) * Slide deck sidebar title changed to "Create a Slide Deck" for verb consistency * Cross-links improved: Find Evidence → Congress Summary, Congress Summary → Extract Study Data, Extract Key Messages → outline/deliverable context * Minor consistency fixes across workflow Next steps sections ## v1.7 — 8 April 2026 * **4 new workflows** added: Find Evidence, Extract Study Data, Create a Medical Slide Deck, Write a Manuscript * Workflow sidebar reordered to follow the medical writing project lifecycle: Evidence → Insight → Draft → Adapt → Validate → Deliver * Homepage decision section updated to include all 14 workflows * Cross-links added between related workflows (summarise → extract data, outline → manuscript/slides) * Playbook now covers 14 workflows across publications, medical affairs, medcomms, and promotional writing ## v1.6 — 8 April 2026 * **External tool ecosystem** integrated across the playbook (Claude, ChatGPT, Elicit, Consensus, Zotero, EndNote, Napkin, Gamma) * PharmaTools remain the primary workflow tools; external tools added as alternatives or complements * Ecosystem note added to the homepage * Complementary tools sections added to PubCrawl and RefCheckr tool pages * MedCheckr compliance section kept focused with no external competitors ## v1.5 — 8 April 2026 * Reduced em dash density by \~30% across all published content to improve writing naturalness ## v1.4 — 8 April 2026 * **Serif headings** — Newsreader font for headings (matches PharmaTools.AI brand), cleaner editorial feel * **Risk-tier callout system** — Low risk workflows use green `Tip`, Medium use blue `Info`, High/Critical use amber `Warning`. Visual colour coding reinforces the risk framework. * **Workflow flow diagrams** — Every workflow now shows a compact one-line flow summary (e.g., "Full paper → AI summary → Data verification → Final summary") inside the risk callout ## v1.3 — 8 April 2026 * **Time estimates** added to all 10 workflow info callouts (e.g., "\~10 min with AI, \~45 min without") * **Worked examples** added to 3 key workflows: Summarise a Paper, Extract Key Messages, Verify Claims — showing source → AI output → issues caught → reviewed final * **Glossary page** — single-page reference for abbreviations used across the playbook (ITT, MLR, SmPC, etc.) * **Changelog page** — version history for the playbook * **Search** enabled with custom prompt * **OG metadata** configured for social sharing ## v1.2 — 8 April 2026 * Removed checkbox syntax from review checklists — cleaner bullet formatting * Renamed all content files from `.md` to `.mdx` for full Mintlify component support ## v1.1 — 8 April 2026 Major playbook redesign. * **New homepage** — "What do you need to do?" decision-based entry replaces the V1 pipeline visualisation * **Standardised workflow template** — all 10 workflows now follow a consistent structure: risk tier callout, Steps component, Output section, Why this works, Common mistakes (accordions), Review checklist (accordion), Tool stack with links * **Progressive disclosure** — detailed risk tables and review checklists moved into expandable accordions * **Tighter copy** — removed redundant sections, merged "Where AI helps" and "Where human judgement is essential" into a single "Why this works" section * **Tool links** — all tool references in workflow pages now link directly to tool pages * **Start page** reworked with cleaner heading hierarchy ## v1.0 — 6 April 2026 Initial release of the Medical Writing AI Playbook. * 10 workflows covering summarisation, messaging, outlining, adaptation, compliance, verification, and final review * 4 core principles: human-in-the-loop, source grounding, risk levels, review accountability * 20+ prompt patterns across 4 categories * 7 PharmaTools.AI tool pages with workflow integration * Role-based Start Here guide for medical writers, agency teams, and pharma stakeholders * Four-tier risk framework (Low, Medium, High, Critical) # Glossary Source: https://playbook.pharmatools.ai/glossary Definitions for abbreviations and terms used across the Medical Writing AI Playbook. | Term | Definition | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ABPI** | Association of the British Pharmaceutical Industry. UK pharmaceutical industry body whose Code of Practice governs promotional materials. | | **AE** | Adverse event. Any undesirable medical occurrence in a patient during a clinical trial, whether or not it is related to the treatment. | | **AI agent** | A program that uses a language model to plan and carry out multi-step tasks by calling tools, retrieving information, or acting on behalf of a user. Differs from a simple chatbot in that it takes actions rather than only generating text. | | **Algorithmic bias** | Systematic errors in AI output that disadvantage particular groups, usually because of skews in training data or design choices. In medical contexts: under-representation of women, ethnic minorities, paediatric, or older populations leads to outputs that work less well for those groups. A quality and equity consideration in any patient-facing AI use. | | **Chatbot** | An AI that holds a turn-by-turn conversation with a user. Distinct from an AI agent: a chatbot generates responses, while an agent plans, calls tools, observes results, and adapts. Most consumer-facing AI products are chatbots; some are agentic underneath. | | **CI** | Confidence interval. A range of values within which the true treatment effect is expected to fall (e.g., 95% CI: 0.52–0.84). | | **Closed-loop AI** | An AI system that acts, observes the result, and adjusts — repeating that cycle without a human in each step. Contrasts with open-loop use, where the model produces a single output and a human decides what to do next. [RefCheckr](/tools/refcheckr) is one example: it verifies a claim against the source paper, rewrites it if the data don't match, then re-verifies and checks ABPI compliance, looping again if anything fails. | | **Computer use** | A model that can see the screen, move a cursor, and type — controlling a computer or browser the way a person does. Used for agents that automate desktop tasks. Higher risk than text generation because actions are taken in the real world, not just suggested. | | **Context window** | The amount of text (input plus output) a language model can process in a single call, measured in tokens. A 200,000-token window holds roughly 150,000 words. Sets the limit on how much source material can be provided in one prompt. | | **CSR** | Clinical study report. The comprehensive report of a clinical trial, including methods, results, and analysis. Primary source document for many medical writing deliverables. | | **Deepfake** | AI-generated audio, video, or images depicting real people doing or saying things they didn't. Increasingly relevant to medical writing because image-manipulation screens used by journals (see [AI in Peer Review](/principles/ai-in-peer-review)) flag both deliberate manipulation and AI-generated figures presented as authentic data. | | **Digital twin** | A virtual model of a real-world system (a patient, an organ, a manufacturing process) used to simulate behaviour and predict outcomes. In pharma, increasingly applied to in silico trial control arms, dose-response modelling, and patient-response prediction. | | **DOI** | Digital object identifier. A unique, persistent identifier for published articles (e.g., 10.1000/xyz123). | | **Embedding** | A numerical representation of text that captures semantic meaning, used to compare how similar two pieces of text are. Underpins retrieval in RAG systems and semantic search. | | **EMA** | European Medicines Agency. The EU regulatory authority responsible for the scientific evaluation and approval of medicines. | | **EU CTR** | EU Clinical Trials Regulation. Requires sponsors to publish lay-friendly summaries of trial results. | | **EudraCT** | European Clinical Trials Database. The EU register for clinical trials, referenced in regulatory submissions and PLS documents. | | **Fair balance** | Regulatory requirement that promotional materials present both benefits and risks of a treatment in a balanced manner. | | **FDA** | Food and Drug Administration. The US regulatory authority responsible for approving drugs, biologics, and medical devices. | | **Fine-tuning** | Additional training that adapts a general-purpose language model to a specific domain, style, or task using a smaller dataset of examples. | | **Foundation model** | A large AI model trained on broad data that serves as the base for downstream applications and tools. Claude, GPT, Gemini, and Llama are foundation models. Different from a frontier model: any foundation model can be the frontier model at a given time, but most are not. | | **Frontier model** | Shorthand for the most capable models available at any given time (e.g., Claude Opus 4.X, GPT-5). The label moves as new releases arrive, so today's frontier model is a generation behind within a year. | | **Generative AI** | AI that produces new content — text, images, audio, video, code — rather than only classifying or predicting. Most of the AI covered in this playbook is generative AI. | | **Grounding** | Anchoring an AI's output to a specific source rather than letting the model rely on what it learned during training. *Source grounding* is the medical-writing application: every claim must trace to provided evidence. See [Source Grounding](/principles/source-grounding). | | **Guardrails** | Explicit rules that constrain what a model is allowed to do or say. In medical writing, examples include "no new numbers", "no language stronger than the source", or "do not infer beyond the data". Usually enforced in the prompt or by a wrapping system, not by the model itself. | | **Hallucination** | AI output that reads plausibly but is factually wrong or invented — a fabricated reference, a misremembered statistic, or a claim with no basis in the source. A primary risk in medical writing. | | **Harness** | The software wrapper around a language model that turns it into a usable product — handling tool calls, file access, memory, retries, and the loop between the model and the outside world. Claude Code, Cursor, and ChatGPT are all harnesses around their underlying models. The capabilities of an AI tool depend as much on the harness as on the model. | | **HCP** | Healthcare professional. Includes physicians, nurses, pharmacists, and other qualified practitioners. | | **HEOR** | Health economics and outcomes research. The discipline focused on the economic value and real-world outcomes of healthcare interventions. | | **Human-in-the-loop (HITL)** | A workflow design where a human reviews, edits, or approves AI output before it is used. The default for medical writing content destined for external use. See [Human-in-the-Loop](/principles/human-in-the-loop). | | **HR** | Hazard ratio. A measure of relative risk over time, commonly used in survival analysis (e.g., HR 0.67 means 33% risk reduction). | | **IB** | Investigator's brochure. A regulatory document summarising the clinical and non-clinical data on a compound, provided to investigators conducting clinical trials. | | **ICH** | International Council for Harmonisation. Sets technical guidelines for pharmaceutical development and regulatory submissions (e.g., ICH E6 for GCP, ICH M4 for CTD structure). | | **IFPMA** | International Federation of Pharmaceutical Manufacturers & Associations. Global industry body with a Code of Practice for marketing. | | **IMRAD** | Introduction, Methods, Results, and Discussion. Standard structure for scientific manuscripts. | | **ITT** | Intention-to-treat. Analysis that includes all randomised participants regardless of whether they completed the study. The primary analysis in most RCTs. | | **KOL** | Key opinion leader. A recognised expert in a therapeutic area, often engaged for advisory boards and speaker programmes. | | **LLM** | Large language model. A statistical model trained on large volumes of text that generates language by predicting the next token. GPT, Claude, and Gemini are LLMs. | | **MCP** | Model Context Protocol. An open standard created by Anthropic that lets AI assistants call external tools securely. [PubCrawl](/tools/pubcrawl) is an MCP server. | | **MedDRA** | Medical Dictionary for Regulatory Activities. The standardised medical terminology used in regulatory reporting of adverse events. | | **MeSH** | Medical Subject Headings. The controlled vocabulary used by PubMed/MEDLINE to index biomedical literature. | | **mITT** | Modified intention-to-treat. A variation of ITT that excludes certain participants (e.g., those who never received treatment). Definition varies by study. | | **MLR** | Medical, Legal, Regulatory review. The formal review process for promotional and medical content before external use. | | **MOA** | Mechanism of action. How a drug produces its pharmacological effect. | | **MSL** | Medical science liaison. A field-based medical affairs professional who engages with HCPs on scientific and clinical matters. | | **Multimodal** | A model or system that can process more than one type of input — typically text plus images, audio, or video. In medical writing, useful for reading figures, tables, or scanned documents. | | **NMA** | Network meta-analysis. A statistical method for comparing multiple treatments indirectly through a network of studies. | | **OCR** | Optical character recognition. Converts scanned document images to searchable text. Poor OCR quality can cause errors in automated reference checking. | | **Open-loop AI** | An AI system that produces a single output and stops — a human decides what to do next. Contrasts with closed-loop AI. Most everyday LLM use is open-loop: ask, read, decide. | | **OR** | Odds ratio. A measure of association between an exposure and an outcome (e.g., OR 1.5 means 50% higher odds). | | **ORR** | Objective response rate (or overall response rate). The proportion of patients with a defined reduction in tumour size or disease activity. | | **OS** | Overall survival. Time from randomisation to death from any cause. A primary endpoint in many oncology trials. | | **PFS** | Progression-free survival. Time from randomisation to disease progression or death. A common endpoint in oncology. | | **PI** | Prescribing information. The approved product labelling. See also SmPC (EU) and USPI (US). | | **PICO** | Population, Intervention, Comparator, Outcomes. A framework for structuring clinical research questions. | | **PLS** | Plain language summary. A lay-friendly summary of clinical trial results, increasingly required by regulation. | | **PMCPA** | Prescription Medicines Code of Practice Authority. The UK body that administers the ABPI Code of Practice. | | **PMID** | PubMed identifier. A unique number assigned to each article indexed in PubMed. | | **PP** | Per-protocol. Analysis that includes only participants who completed the study as planned, without major protocol deviations. | | **PRISMA** | Preferred Reporting Items for Systematic Reviews and Meta-Analyses. A reporting guideline for systematic reviews. | | **Prompt** | The instruction given to a language model. The structure, context, and constraints of a prompt strongly influence output quality. | | **Prompt engineering** | The practice of designing prompts to produce reliable, useful output from a language model. Includes setting role, constraints, examples, and output format. | | **Prompt injection** | A safety risk where instructions hidden in external content (a PDF, a web page, a user upload) cause the model to do something it wasn't asked to do. Especially relevant for tools that ingest documents or browse the web on the user's behalf. | | **QALY** | Quality-adjusted life year. A measure of disease burden used in health economics, combining quantity and quality of life. | | **QC** | Quality control. The review and verification process applied to deliverables before submission or publication. | | **RAG** | Retrieval-augmented generation. A technique where a language model is given relevant documents to draw on when answering, rather than relying only on what it learned during training. Central to source-grounded medical writing systems. [MedCheckr](/tools/medcheckr) uses RAG to evaluate content against the ABPI Code of Practice. | | **RCT** | Randomised controlled trial. A study design where participants are randomly assigned to treatment or control groups. | | **Reasoning model** | A class of language model that explicitly "thinks" before answering — generating intermediate reasoning steps that improve performance on complex tasks. Examples: Claude with extended thinking, OpenAI's o-series. Useful for multi-step verification or planning, less necessary for simple drafting. | | **SAE** | Serious adverse event. An AE that results in death, hospitalisation, disability, or is otherwise medically significant. | | **SAP** | Statistical analysis plan. The document specifying the planned statistical analyses for a clinical trial, written before database lock. | | **Skill** | A self-contained, packaged capability an AI assistant can install and call on demand (e.g., Claude Skills, OpenClaw ClawHub skills). Skills bundle prompts, tools, and instructions for a specific job. [Patiently AI](/tools/patiently-ai) is published as a skill. | | **SLR** | Systematic literature review. A structured, reproducible search and analysis of published evidence, following a predefined protocol. | | **SmPC** | Summary of Product Characteristics. The EU equivalent of prescribing information. Approved by the EMA or national authority. | | **SOP** | Standard operating procedure. Documented internal processes that define how work is conducted within an organisation. | | **System prompt** | The persistent instructions given to a model that define its role, constraints, and behaviour, separate from the user's turn-by-turn input. Most of the "personality" and capabilities of a tool live in the system prompt, not the model. | | **TFL** | Tables, figures, and listings. The statistical outputs from a clinical trial used as source material for CSR drafting. | | **Token** | The unit of text a language model processes, roughly ¾ of a word in English. Input and output length — and API costs — are measured in tokens. | | **Tool use** | The mechanism by which a language model calls external functions — a search API, a database query, a file operation, a custom service. Also called *function calling*. Tool use turns a chatbot into an agent; MCP is one standard for declaring available tools. | | **USPI** | United States Prescribing Information. The FDA-approved product labelling. | | **Zero-shot / few-shot** | Prompting styles. Zero-shot gives the model a task with no examples; few-shot includes one or more worked examples. Few-shot often improves accuracy on structured tasks. | # Home Source: https://playbook.pharmatools.ai/index Free AI workflows for medical writing, from finding evidence to final review. Risk tiers, prompt patterns and review frameworks for med comms and pharma teams.
A free resource by PharmaTools.AI v2.8
Medical Writing AI Playbook. =========================

You’re expected to use AI. You’re still accountable for every claim. Here’s how to do both.

Start here → Download the quick guide ↓

— downloads so far

A growing resource for healthcare communications teams adopting AI workflows.

Each workflow explains: * what AI can help with * what the writer must verify * where mistakes commonly happen **AI for acceleration, not authority. Translation, not invention.** *** ## What's new * **v2.8** — [Choosing Your Model](/principles/choosing-your-model) now covers the energy and water behind AI use, and why picking a bigger model than the job needs wastes both. Check your own with the [AI Water and Energy Footprint Calculator](https://www.pharmatools.ai/water-consumption-calculator). [Agentic Workflows](/principles/agentic-workflows) has a matching note on when a multi-step AI process isn't worth the extra cost * **v2.7** — [AI Regulation in Pharma](/principles/ai-regulation) updated now the EU AI Act's transparency rules are in force (2 August 2026). AI companies have started marking their own output: Claude and Gemini add an invisible watermark to text, and AI-generated images carry hidden labels. Marking is their job, not yours — and it doesn't replace declaring that you used AI * **v2.6** — [Declaring AI Use](/principles/declaring-ai-use) and the [disclosure templates](/templates/disclosure-language) updated for JAMA's stricter policy (August 2026). Three things are now banned outright rather than simply declared: letting AI generate or format references, using AI to draft Opinion pieces and Letters, and AI-made clinical images [See the full changelog →](/changelog) *** ## The workflow lifecycle The medical writing AI workflow lifecycle: Evidence, Insight, Draft, Adapt, Validate, Deliver | Stage | Workflows | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Evidence** | [Find Evidence](/workflows/find-evidence) · [Summarise a Paper](/workflows/summarise-source-paper) · [Congress Summary](/workflows/prepare-congress-or-poster-summary) | | **Insight** | [Extract Study Data](/workflows/extract-study-data) · [Extract Key Messages](/workflows/extract-key-messages) | | **Draft** | [Build an Outline](/workflows/build-content-outline) · [Write a Manuscript](/workflows/write-a-manuscript) · [Regulatory Document](/workflows/draft-regulatory-document) · [Convert Stats to Narrative](/workflows/convert-stats-to-narrative) · [Create a Slide Deck](/workflows/create-medical-slide-deck) · [Concept Visuals](/workflows/generate-concept-visuals) | | **Adapt** | [Adapt for Audiences](/workflows/adapt-for-different-audiences) · [Plain Language Summary](/workflows/create-plain-language-summary) | | **Validate** | [Verify Claims](/workflows/verify-claims-against-references) · [Compliance Check](/workflows/check-promotional-compliance) · [Check Document Consistency](/workflows/check-document-consistency) | | **Deliver** | [Repurpose Content](/workflows/repurpose-content-across-channels) · [Final Review](/workflows/final-human-review) |

Most explored workflows

*** ## What do you need to do? Search biomedical databases and build a curated evidence set. Structured summary from a published paper or congress poster. Structured poster extractions for rapid congress turnaround. Pull endpoints, outcomes, and study details into evidence tables. Evidence-supported messages from clinical data, organised by theme. Structure a deliverable from key messages and source materials. Draft a scientific manuscript from study data and references. Draft CSR sections, IBs, or Module 2 summaries from source data. Convert statistical outputs and tables into neutral regulatory prose. Slides for MSL training, advisory boards, or medical education. AI image generation for concept figures, visual abstracts, and social graphics. Specialist content rewritten for GPs, nurses, payers, or patients. Clinical findings translated into language patients can understand. Systematic claim-to-reference checking before formal review. Pre-screen for compliance signals before MLR submission. Flag inconsistencies in values, terms, and cross-references. Approved content adapted across channels and formats. The QC gate before any AI-assisted deliverable ships. *** ## Principles The principles that shape every workflow in this playbook — what counts as appropriate AI use, how to verify it, what to disclose, and where the regulatory limits sit. AI drafts. A named professional verifies and signs off. No exceptions. Every claim traces to a cited source. Nothing enters from AI training data. Brief with rich context, evaluate for voice and accuracy, refine with specifics. Four levels define what AI can contribute and what review intensity is required. Sign-off protocols, audit trails, and clear ownership for every deliverable. What to disclose to journals, regulators, and clients when AI is part of the work. The EU AI Act, FDA, EMA, MHRA — and what counts as high-risk in medical writing. When to reach for a reasoning model and when a standard LLM is enough. When an agent earns its keep — and when it doesn't. What journals run on your manuscript before a human reviewer sees it. *** ## Risk tiers Not all tasks carry the same consequences. Four tiers define the AI role, the review process, and what sign-off is required. | Tier | AI role | Review required | Examples | | ------------ | -------------------------- | ------------------------------------ | ---------------------------------------------- | | **Low** | First draft, structuring | Standard review | Paper summaries, outlines, internal briefs | | **Medium** | Transformation, adaptation | Enhanced review + source cross-check | Key messages, audience adaptation, repurposing | | **High** | Limited drafting support | Expert review, full verification | Promotional claims, PLS, compliance checks | | **Critical** | Supporting role only | Full expert review, formal sign-off | Final QC before delivery or publication | Workflow-by-workflow risk tiers and review expectations *** ## Tools Purpose-built tools from [PharmaTools.AI](https://pharmatools.ai) for the workflow steps where general-purpose LLMs fall short. Literature search and evidence discovery. Closed-loop claim verification and rewrite. Promotional compliance screening. Clinical-to-patient language translation. Multi-audience content adaptation. Plain language summaries from clinical data. Structured extraction from scientific posters. *** Role-specific recommendations for medical writers, agency teams, and pharma stakeholders. *A free resource from [PharmaTools.AI](https://pharmatools.ai) · v2.8 · [Open source on GitHub](https://github.com/nickjlamb/medical-writing-ai-playbook)* # Agentic Workflows Source: https://playbook.pharmatools.ai/principles/agentic-workflows When an AI agent earns its keep, when it doesn't, and how to assess agentic workflows for medical writing — with RefCheckr as the worked example. ## Core principle An agent earns its keep when the task involves multiple steps that benefit from being orchestrated by AI — typically because the steps include verification, decision-making, or adaptation based on intermediate results. Single-step tasks rarely need an agent. Multi-step verification loops often do. The decision is never "agents are better" or "agents are dangerous". It is: does the loop add value for *this* task, against the cost, latency, and audit complexity it creates? *** ## Why this matters now Agentic AI moved from research curiosity to production-ready through 2024–2025. [RefCheckr](/tools/refcheckr) is one example: a verify-fix-recheck loop that closes itself on a claim. The pattern generalises — to systematic literature review conduct, compliance pre-screening with rewrite, evidence synthesis across studies, and more. Tool vendors and pharma innovation teams are increasingly pitching "agentic" solutions for systematic literature review, MLR triage, manuscript drafting, and evidence synthesis. Some are genuinely agentic; some are scripted pipelines marketed under the agent label. Medical writers are increasingly the people who have to assess these pitches — knowing what an agent should deliver, and what red flags to look for, is now part of the job. *** ## What "an agent" means here An agent, in the sense relevant to medical writing, is an AI system that: * **Plans** a sequence of steps for a goal * **Executes** each step (often by calling tools — search APIs, document retrievers, verification services) * **Observes** the result of each step * **Adapts** based on what it observed (re-tries, re-plans, escalates) * **Loops** until a goal condition is met or a limit is hit This is different from: * **A single-shot LLM prompt** (one input, one output, no adaptation) * **A scripted pipeline** (fixed steps, no decision-making between them) * **A human-orchestrated workflow** (the human chooses what happens between steps) The defining feature is that *the AI is making decisions about what to do next*, not just generating text in response to a single prompt. *** ## Agent patterns worth knowing The agent generates an output, checks it against a constraint, fixes the output if the check fails, then re-checks. Loops until the output passes or the limit is hit. RefCheckr's verify → fix → re-check is the canonical example. Useful anywhere there is a clear pass/fail signal: claim-vs-source verification, compliance signal pre-screening, style-rule conformance. The agent decomposes a task into steps, executes each, then verifies the whole. Useful for systematic literature review conduct, manuscript outline generation, and any task with clear sub-deliverables. The agent calls external services to do parts of its work — a search API for evidence retrieval, a calculator for statistics, a document store for source grounding. The reasoning is in the model; the answers come from the tools. PubCrawl, when called via [MCP](/glossary), is a tool an agent can use. The agent drafts, critiques its own draft, then refines. Useful for prose polishing under explicit constraints (style guide, audience adaptation, plain-language rewriting). Multiple specialised agents hand off — a "drafter" passes output to a "verifier", which passes to a "compliance reviewer". Useful when sub-tasks need different prompts, models, or tools. More complex to audit. *** ## When an agent earns its keep | Signal that an agent fits | Why | | ---------------------------------------------- | -------------------------------------------------------------------- | | The task has a natural verification gate | The loop has a place to close | | Errors compound across steps | Multi-step thinking outperforms single-shot | | The task is high-volume | Automation pays back the build cost | | Intermediate steps would benefit from tool use | Agent can route to the right tool per step | | You can audit each step | The agent's value is auditable, not just visible in the final output | **Concrete examples in medical writing:** | Application | Pattern | Status (mid-2026) | | -------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------- | | Claim verification ([RefCheckr](/tools/refcheckr)) | Verify-fix loop | Production | | Compliance pre-screen with rewrite | Verify-fix loop | Emerging | | Systematic literature review conduct | Plan-execute-verify with tool use | Emerging | | Evidence synthesis across multiple studies | Plan-execute-verify | Emerging | | Manuscript drafting with reference self-check | Iterative refinement | Emerging | | Plain-language summary with source verification | Verify-fix loop | Emerging | | Pharmacovigilance signal triage (high-risk) | Plan-execute-verify | Emerging — flag as [high-risk under EU AI Act](/principles/ai-regulation) | *** ## When an agent is the wrong tool "Draft a discussion paragraph from this finding" is a single-shot task. Wrapping it in an agent adds latency and cost without adding value. A board-bound regulatory document drafted once and reviewed by humans does not benefit from agentic decomposition. The cost of the loop exceeds its value when volume is low and stakes are high enough that humans must verify everything anyway. If checking the agent's output is more work than doing the task by hand, the agent is creating work, not saving it. This is common when the "verification" requires the same expert judgement as the original task. An agent whose decisions are opaque is an audit liability under [Review and Accountability](/principles/review-and-accountability) and the [EU AI Act](/principles/ai-regulation). If you cannot show what the agent did at each step, the loop is faster but also harder to defend. Agents take longer than single-shot prompts. For interactive use (turn-by-turn editing, live brainstorming), the latency makes them painful. Save the loop for back-end work. A single instruction to an agent becomes many model calls, so an agentic workflow consumes orders of magnitude more compute — and the energy and water behind it — than the equivalent chat-style prompt. On work that genuinely needs the loop this is money well spent. On work that does not, it is the same overkill as reaching for a reasoning model to rewrite a sentence, only multiplied. The [AI Water and Energy Footprint Calculator](https://www.pharmatools.ai/water-consumption-calculator) is one way to size the difference; the resource-cost axis in [Choosing Your Model](/principles/choosing-your-model) covers when it changes a decision. *** ## Failure modes specific to agents The [AI failure modes](/principles/ai-failure-modes) page covers the core risks. Agents add several patterns on top: * **Cascading errors:** One wrong intermediate step poisons every downstream step. The final output is fluent and confidently wrong. * **Reasoning chain fabrication:** The agent's "thinking" can include invented citations or fabricated checks that pass its own verification but fail real verification. Covered in [Choosing Your Model](/principles/choosing-your-model). * **Tool misuse:** Agents calling the wrong tool, or the right tool with wrong parameters. A claim sent to a literature search instead of a source-paper verifier looks like work but produces noise. * **Cost and latency runaway:** Loops that don't converge, or that keep retrying. Cap iterations explicitly. * **Prompt injection at any step:** Each step that ingests external content (a paper, a web result, a user upload) is a potential injection point. Defend at each. * **Audit-trail loss:** Multi-step agents are harder to log meaningfully than single-shot prompts. Plan logging upfront, not after the fact. *** ## Practical assessment for medical writing teams Before commissioning or using an agentic workflow: A fixed pipeline (always step 1 → step 2 → step 3, no branching) is not an agent and does not need agent infrastructure. Calling a fixed pipeline an "agent" is marketing, not architecture. Save the agent vocabulary for systems that adapt based on intermediate observations. Agents earn their value at verification gates. If you can't point to the moment "the agent checks itself", the loop is open and the system is just a longer pipeline. Ask: what is the pass/fail signal that ends the loop? Total cost = tokens per step × steps per run × runs. Reasoning models in agentic loops can be 10–100× the cost of equivalent single-shot prompts. Budget for it, and cap iterations. For each step, can you produce a record of: input, model used, tool called (if any), output, decision rule that led to the next step? If not, you don't have an audit trail; you have a black box. This affects [Review and Accountability](/principles/review-and-accountability) and [EU AI Act](/principles/ai-regulation) documentation. The playbook's [risk tier framework](/principles/risk-levels) applies to agentic workflows. High-risk and critical work requires more verification at every step, not less, regardless of how clever the agent is. *** ## Common mistakes "Drafting a paragraph" does not need an agent. Adding plan-execute-verify around it makes it slower, costlier, and harder to audit, with no quality benefit. A loop without a check at the end is just a pipeline that runs more steps. The closing check is the entire point. If there isn't one, redesign — or use a single-shot prompt. An agent saying "I verified this against the source" is not verification. Either run independent verification (a second model, a deterministic check) or treat the self-report as a hint, not an assurance. Always cap iterations. Three to five passes is typical. Beyond that, the loop is unlikely to converge and is burning budget. "We're using agents" is not an architecture statement. The pattern (verify-fix vs. plan-execute vs. multi-agent) determines the failure modes, the audit requirements, and the cost profile. Specify the pattern. *** ## How this connects to other playbook principles * **[Closed-loop AI](/glossary):** The verify-fix loop is the foundational agentic pattern. RefCheckr is the worked example. * **[Choosing Your Model](/principles/choosing-your-model):** Agents typically use reasoning models for the planning and verification steps; standard models for generation. Mixing classes is the cost-efficient default. * **[Source grounding](/principles/source-grounding):** Agents do not exempt content from source grounding. Each generation step still needs verifiable source attribution. * **[Review and accountability](/principles/review-and-accountability):** The audit-trail requirements apply per agent step, not per overall agent run. Plan logging upfront. * **[AI Regulation in Pharma](/principles/ai-regulation):** Some agentic uses (PV signal triage, clinical decision support) cross into high-risk territory under the EU AI Act. Map the use, not the technology. * **[AI failure modes](/principles/ai-failure-modes):** Agents inherit single-shot failure modes and add new ones (cascading errors, tool misuse, audit-trail loss). *** ## The bottom line Agents are not better or worse than single-shot prompts; they are different tools for different tasks. The pattern earns its keep on multi-step verification, high-volume work, and tasks with natural verification gates. It is the wrong tool for single-step generation, low-volume one-shots, and anywhere the loop cannot close audibly. Specify the pattern, cap the iterations, log every step — and verify the agent the same way you would verify any other AI output. *** *Last reviewed: 19 August 2026 · 8 min read* # AI Failure Modes in Medical Writing Source: https://playbook.pharmatools.ai/principles/ai-failure-modes Common ways AI can go wrong when working with scientific evidence, and how to catch them. AI can speed up drafting, summarising, and evidence handling. It can also fail in predictable ways. In regulated or scientific contexts, even small errors can matter. ## Why this page exists AI is a capable collaborator for medical writing. It is not an infallible one. The failures below are the ones that recur in real projects — not hypothetical risks, but the kinds of errors that show up in drafts, summaries, and decks when AI output is accepted without verification. Recognising these patterns is the first step in catching them. Pairing AI with source checking and human judgement is the second. *** ## The failure modes **What happens:** AI invents a plausible-looking reference — authors, journal, year, PMID — that does not exist. **Example:** A draft cites "Patel et al., *Lancet Oncol* 2022;23(4):512–521" to support a survival claim. The paper is not indexed in PubMed. The DOI resolves to nothing. **Why it matters:** A fabricated reference that survives into a manuscript, slide, or regulatory document undermines the credibility of every other citation in the deliverable. **How to catch it:** Resolve every reference against PubMed, the publisher site, or a DOI. Do not trust the citation because it "looks right." **What happens:** A numerical value is slightly wrong — a transposed digit, a wrong confidence interval, a p-value shifted by one decimal, a rounded sample size. **Example:** Source: HR 0.72 (95% CI 0.61–0.85). AI output: HR 0.72 (95% CI 0.61–0.58). **Why it matters:** Fluent prose makes numerical errors almost invisible on a read-through. Downstream documents inherit the wrong value. **How to catch it:** Verify every number against the source table or figure. Do not rely on re-reading the AI output alone. **What happens:** A result is assigned to the wrong arm, comparator, subgroup, or cohort. **Example:** A placebo-arm adverse event rate is described as the active treatment rate. A subgroup response is framed as the ITT result. **Why it matters:** The claim may read as scientifically sound while reversing the direction of the evidence. **How to catch it:** Cross-check attribution against the source table. Confirm the analysis population for every reported value. **What happens:** PFS is reported as OS. A secondary endpoint is presented as primary. A biomarker finding is framed as a clinical outcome. **Example:** AI writes "the trial demonstrated an overall survival benefit" when the reported result was progression-free survival. **Why it matters:** Endpoint confusion changes the clinical meaning of the finding, and in regulated materials it is a fair-balance and accuracy issue. **How to catch it:** Confirm endpoint definitions from the protocol or publication. Check primary vs. secondary status before paraphrasing. **What happens:** Cautious source language is upgraded to something stronger. "Suggests potential benefit" becomes "demonstrates superiority." "Numerically higher" becomes "significantly higher." **Example:** A non-significant trend (p=0.08) is summarised as "an improvement in response rate." **Why it matters:** The output still reads like scientific writing, but it no longer matches what the evidence supports. **How to catch it:** Compare verbs and qualifiers line by line with the source. Watch for the quiet loss of hedging language. **What happens:** The cited evidence supports one thing; the generated claim describes another. **Example:** The reference reports tumour response rate. The AI-written sentence references the same paper to support a survival or quality-of-life claim. **Why it matters:** The citation is real, but it does not support the claim. This is harder to spot than a fabricated reference because the reference exists. **How to catch it:** For each claim, confirm that the cited source actually supports *that specific statement* — not just the general topic. **What happens:** AI blends details from two or more papers or trials into a single clean-sounding summary. **Example:** A summary describes "a Phase 3 trial in 842 patients showing a 14-month median PFS" — but the patient number comes from one trial and the PFS from another. **Why it matters:** The resulting statement does not describe any real study. Every verification path leads somewhere partially correct, which makes the error easy to miss. **How to catch it:** Require one source per claim. If a sentence combines facts from multiple sources, split it. **What happens:** A finding in a specific subgroup or narrow population is rewritten as if it applies more broadly. **Example:** A result seen in PD-L1–high patients is described as "patients with advanced NSCLC." A second-line finding is framed as first-line evidence. **Why it matters:** The claim generalises beyond the evidence, which is a scientific accuracy issue and, in promotional contexts, a compliance issue. **How to catch it:** Confirm the analysis population and line of therapy for every claim. Flag any phrasing that widens the population. **What happens:** AI produces a tidy summary that drops caveats — small sample size, exploratory analysis, non-significance, immature data, indirect comparison, open-label design. **Example:** A summary of an exploratory post-hoc subgroup analysis reads like a pre-specified primary finding. **Why it matters:** Removing limitations changes how the evidence should be interpreted, even when every number is correct. **How to catch it:** Check whether the source flags the analysis as exploratory, post-hoc, or limited. If it does, the summary must too. **What happens:** Neutral scientific wording becomes promotional, absolute, unbalanced, or insufficiently qualified. **Example:** "Was associated with improved outcomes in this study" becomes "improves outcomes." Safety information shrinks while efficacy language expands. **Why it matters:** In regulated materials, phrasing drift can turn a defensible scientific statement into a claim that fails fair-balance or promotional-code review. **How to catch it:** Review output against the relevant code (ABPI, PhRMA, local equivalents). Watch for absolute verbs, superlatives, and reduced safety proportionality. *** ## Summary table A compact reference for reviewers and reviewers' reviewers. | Failure mode | Typical risk | Common context | Best check | | ----------------------------------- | ---------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------- | | Hallucinated citations | Fabricated reference enters the deliverable | Drafting from prompts without supplied sources | Resolve every reference via PubMed, DOI, or publisher | | Misquoted statistics | Wrong numerical value reads as fluent prose | Stats-to-narrative, results summaries | Verify each number against the source table | | Wrong trial arm attribution | Result assigned to the wrong arm or population | Multi-arm trials, subgroup results | Cross-check attribution against the source table | | Endpoint confusion | Secondary reported as primary; PFS as OS | Oncology summaries, congress content | Confirm endpoint definitions from protocol or publication | | Overstated conclusions | Hedged source language upgraded to certainty | Discussion sections, key messages | Line-by-line verb and qualifier check vs. source | | Data-claim mismatch | Real citation supporting a different claim | Manuscript drafting, claim libraries | Confirm the cited source supports *this* specific claim | | Source conflation | Details blended from multiple studies | Cross-trial summaries, landscape reviews | One source per claim; split blended sentences | | Population drift | Narrow finding framed as broad | Adaptation, repurposing, PLS | Confirm analysis population and line of therapy | | Missing limitations | Caveats stripped from a tidy summary | Summaries, plain language, slide decks | Check for exploratory, post-hoc, or immature data flags | | Compliance-sensitive phrasing drift | Scientific wording becomes promotional | Promotional review, MSL and brand materials | Review against applicable promotional code | *** ## What this does not mean These failure modes are not a reason to avoid AI in medical writing. They are a reason to pair AI with verification. The same tools that introduce these errors also make it possible to draft faster, summarise more consistently, and handle larger volumes of evidence than was previously practical. The value does not come from generation alone. It comes from connecting evidence, claims, and verification — keeping the AI inside a workflow where the source is always the ground truth and a human owns the sign-off. Verification is not an optional extra. In evidence-based medical writing, it is part of the workflow. *** ## Further reading Some of these failure patterns reflect broader behaviours of large language models under stress or ambiguous prompts. If you are interested in how LLMs fail at a more fundamental level, I explored this in more detail in [How to Break a Large Language Model](https://ai.gopubby.com/how-to-break-a-large-language-model-4a557b28581a) — published in AI Advances. *** ## Related principles * [Source Grounding](/principles/source-grounding) — every claim traces to a cited source * [Understanding AI Risk](/principles/risk-levels) — why risk varies across tasks * [AI Risk Framework](/principles/ai-risk-framework) — tier-based review expectations * [Review and Accountability](/principles/review-and-accountability) — sign-off protocols and audit trails ## Related workflows * [Verify Claims Against References](/workflows/verify-claims-against-references) — claim-by-claim verification * [Check Document Consistency](/workflows/check-document-consistency) — catching drift across a document * [Check Promotional Compliance](/workflows/check-promotional-compliance) — phrasing and fair-balance review * [Final Human Review](/workflows/final-human-review) — the human sign-off step *** *Last reviewed: 15 April 2026 · 8 min read* # AI in Peer Review Source: https://playbook.pharmatools.ai/principles/ai-in-peer-review What journals run on your manuscript before a human reviewer sees it — and what that means for pre-submission QC. ## Core principle Your manuscript is screened by AI tools before a human peer reviewer reads it. Major journals now run automated checks on every submission for plagiarism, image manipulation, statistical anomalies, reference integrity, and (variably) AI-generation detection. Errors that pass your internal QC will increasingly be caught at the journal's front door. The practical implication: pre-submission QC is no longer optional polishing. It is the gate before the gate. *** ## Why this matters now Large publishers — Springer Nature, Elsevier, Wiley, BMJ Group, PLOS, Sage, AAAS — rolled out automated screening tools across 2023–2025. By mid-2026 most major journals run a combined pre-review screen on every submission, with results visible to editors before any peer reviewer is invited. The same publishers also share image-integrity flags via shared databases, so a manipulated figure that has appeared in another paper is detectable on submission elsewhere. Desk rejections triggered by these screens have risen sharply. The biggest single category is reference fabrication, which has become a leading-indicator flag for AI-generated drafts that were not verified before submission. Journals have started responding upstream rather than only at the screen. In August 2026 JAMA Network moved AI-generated and AI-formatted references from "discouraged" to "not permitted", citing submissions arriving with inaccurate or non-existent citations. Expect the screen and the policy to tighten together: see [Declaring AI Use](/principles/declaring-ai-use) for the current position. *** ## What journals run on your manuscript A non-exhaustive list of the screens common in major medical and life-science journals: | Screen | What it does | Tools commonly used | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Plagiarism / similarity** | Detects substantial overlap with prior published work and the author's earlier output | [iThenticate](https://www.ithenticate.com/), [Crossref Similarity Check](https://www.crossref.org/services/similarity-check/) | | **Image manipulation** | Flags duplicated, spliced, or otherwise altered figures across the submission and against publisher databases | [Imagetwin](https://www.imagetwin.ai/), [Proofig](https://www.proofig.com/) | | **Statistical anomaly** | Detects impossible p-values, GRIM violations, decimal drift, and other statistical inconsistencies | [Statcheck](https://statcheck.io/), GRIM/SPRITE, internal publisher tools | | **Reference integrity** | Verifies cited references exist, checks DOI/PMID validity, sometimes checks claim-vs-source support | Crossref-based checkers, increasingly LLM-assisted | | **AI-generation detection** | Attempts to identify AI-drafted prose | Mixed publisher-internal and third-party (accuracy varies; see caveats below) | | **Methodology / reporting compliance** | Checks adherence to reporting guidelines (CONSORT, PRISMA, STROBE, etc.) | Tool-assisted; not yet routine across all journals | | **Authorship and affiliation** | Verifies author identity, affiliations, ORCID, conflicts | Identity verification services | Each major publisher uses a different combination, and the specific tools change. Treat the *categories* as durable; the *vendors* as a moving target. *** ## Where these tools work well, and where they don't **They work well at:** * Catching fabricated references (especially the kind AI hallucinates with plausible-looking but non-existent DOIs) * Detecting image duplications across the literature (the screens that exposed several high-profile retraction cases through 2022–2025) * Spotting impossible statistics — p-values that can't arise from the reported data, summary statistics that fail GRIM * Finding substantial verbatim plagiarism **They struggle at:** * **AI-generation detection.** False-positive rates on legitimate human-written academic prose remain high. False negatives on carefully edited AI-drafted prose are also common. Some journals have stopped using AI-detection tools as a standalone gate, treating them only as one signal among several. * **Subtle methodology issues.** Automated reporting-compliance checks find structural gaps; they miss substantive problems like underpowered analyses or post-hoc reframing. * **Sophisticated image manipulation.** Tools catch duplications and gross alterations; subtle splicing remains hard to detect automatically. * **Paraphrased plagiarism.** Tools flag verbatim overlap; reworded copying often passes. The reliable-detection categories are also the ones most exposed by AI-drafted manuscripts that haven't been carefully verified before submission. Reference fabrication is the most common. *** ## What this means for authors and medical writers The submission process used to assume editors and reviewers would catch errors. The screening layer means many errors are caught — and trigger desk rejection — before any human reviews the science. Pre-submission QC has shifted from polish to gate-keeping. A polished-looking AI draft with one fabricated citation is now likely to be flagged on submission. Closed-loop reference verification (e.g., [RefCheckr](/tools/refcheckr)) is the protective habit; reading-through-once is not. Run an image-integrity check on figures before submission, especially for re-used or composite figures. Publisher tools will run their own; catching it first is cheaper than responding to a flag. The same automated checks publishers run can be run by you. GRIM violations and impossible p-values are findable pre-submission. Catching them yourself is faster than the round-trip. Vague disclosure is a flag. Specific disclosure (per [Declaring AI Use](/principles/declaring-ai-use)) is harder to second-guess. Publishers do not penalise disclosed, reasonable AI use; they penalise undisclosed use that surfaces later. *** ## A pre-submission checklist Before submission, run the same kinds of checks the journal will run: * **References:** every cited reference exists, DOI/PMID resolves, and claims are supported by the cited source. [RefCheckr](/tools/refcheckr) closes this loop; the [Verify Claims Against References](/workflows/verify-claims-against-references) workflow gives the manual fallback. * **Plagiarism / similarity:** run an iThenticate or equivalent check on the final draft. Check both external and self-plagiarism (text reuse from your own prior work). * **Statistics:** spot-check the reported numbers against the underlying data or the statistical analysis plan. Run GRIM if relevant. The [Convert Stats to Narrative](/workflows/convert-stats-to-narrative) workflow includes verification steps. * **Images:** if figures include human bodies, gels, blots, or composite assemblies, audit them against an image-integrity tool before submission. * **AI disclosure:** the disclosure language matches the actual AI use, with tool, version, scope, and reviewer accountability per the [Declaring AI Use](/principles/declaring-ai-use) principle. * **Reporting guideline compliance:** for trials, CONSORT; for systematic reviews, PRISMA; etc. Check the journal's specific requirements. * **Authorship and affiliations:** ORCID for each author, affiliations verified, conflicts disclosed. The [Pre-submission QC Checklist](/templates/pre-submission-qc-checklist) operationalises all of the above into a directly-usable submission gate. *** ## Common mistakes AI-detection tools are inconsistent on AI-drafted prose. Reference checkers and image-integrity tools are not. Treating the whole category as unreliable conflates the weakest screen with the strongest ones. The single most common reason AI-assisted submissions are flagged is fabricated references. Verify every citation against its source before submission. This is the closed-loop pattern in [RefCheckr](/tools/refcheckr) applied to your own manuscript. Undisclosed AI use that surfaces post-publication is a retraction-grade issue. Disclosed AI use, with appropriate verification, is not. The asymmetry of consequences makes hiding the worse choice. Passing the publisher's screen does not mean the manuscript is correct — it means the automated layer found nothing. Peer review and your own [final human review](/workflows/final-human-review) still apply. Each journal has specific policies on AI use, reference accuracy expectations, and image-integrity requirements. The [Declaring AI Use](/principles/declaring-ai-use) page links to the major ones. Read the policy before drafting, not at submission. *** ## How this connects to other playbook principles * **[Source grounding](/principles/source-grounding):** Fabricated references — the most-detected AI-drafted error — fail every reference-integrity screen. Source-grounded writing protects against the most common flag. * **[Declaring AI Use](/principles/declaring-ai-use):** The journal policies covered there are the same policies that drive what their AI screens look for. Disclosure aligns with detection. * **[Review and accountability](/principles/review-and-accountability):** Pre-submission QC is the natural application of the audit-trail and named-reviewer expectations. The screen is the second checkpoint; your QC is the first. * **[Closed-loop AI](/glossary):** Tools like [RefCheckr](/tools/refcheckr) close the loop the journal screens are designed to detect. Passing the screen is what closed-loop verification produces as a side effect. * **[AI Regulation in Pharma](/principles/ai-regulation):** EU AI Act transparency obligations on AI-generated content align with what journals are also asking. Both pressures point in the same direction. *** ## The bottom line The submission gate now includes an AI screening layer. The screens reliably catch fabricated references, image duplications, and impossible statistics; they unreliably detect AI-drafted prose. The protective habit is the same set of practices the playbook recommends for production: source-grounded writing, closed-loop reference verification, accurate AI disclosure, and contemporaneous QC. Tighten those before submission and the screen becomes a non-event. Skip them and the screen becomes the desk rejection. *** *Last reviewed: 11 August 2026 · 7 min read* # AI Regulation in Pharma Source: https://playbook.pharmatools.ai/principles/ai-regulation How the EU AI Act and other regulatory frameworks shape AI use in medical writing — what counts as high-risk, what doesn't, and how to assess your tools. ## Core principle AI regulation is no longer optional or aspirational. It is an emerging compliance layer sitting on top of the existing GxP, MLR, and journal-disclosure expectations medical writers already work within. The practical question for any AI tool you use is: which regulatory tier does it sit in, and what obligations does that create? This page is informational, not legal advice. For specific compliance decisions affecting submissions, promotional content, or regulated workflows, escalate to your organisation's regulatory affairs and legal teams. *** ## Why this matters now The **[EU AI Act](https://artificialintelligenceact.eu/)** is the most far-reaching AI regulation currently in force. Adopted in 2024, it began phasing into effect from February 2025 and will be largely operational by August 2026, with high-risk AI provisions following in August 2027. It applies extraterritorially. EU-based pharma operations are obviously in scope, but so is any AI-assisted output that reaches EU patients, EU healthcare professionals, or EU regulatory submissions — which covers most globally distributed pharma communications. The standards the EU AI Act establishes are also increasingly being mirrored by other regulators (FDA, MHRA, EMA), so even non-EU-bound work tends to converge on the same expectations within 12–24 months. *** ## The EU AI Act tier system The Act categorises AI by the risk it poses, with corresponding obligations: | Tier | Definition | Typical examples in medical writing | | ---------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Prohibited** | Uses banned outright (manipulation, social scoring, real-time biometric ID) | Generally not applicable to medical writing | | **High-risk** | AI used in safety-critical decisions or as a medical device | AI in clinical decision support, pharmacovigilance signal triage, AI medical devices | | **Limited-risk** | AI subject to transparency obligations | **Most medical writing AI sits here** — drafting, summarising, translating, generating content | | **Minimal-risk** | Routine AI with no specific Act obligations | Spell-check, basic search, grammar correction | For medical writers, the practical takeaway is that almost all generative AI used in writing workflows falls under **limited-risk** transparency obligations, not high-risk obligations. But the boundary is real, and it matters: as soon as AI is making or directly informing a clinical or safety decision, it crosses into high-risk territory and a different compliance regime applies. *** ## Transparency obligations (Article 50) Limited-risk AI carries specific transparency duties that affect day-to-day medical writing: * **Users must know they're interacting with AI** — relevant for any chatbot or interactive AI tool deployed to HCPs or patients * **AI-generated content must be labelled** — text, images, audio, and video produced or substantially modified by AI must be marked as such, unless it has undergone meaningful human review and editorial responsibility * **Synthetic content must be machine-readable** — providers of generative AI are obliged to mark output so it is technically detectable as AI-generated This aligns closely with [Declaring AI Use](/principles/declaring-ai-use). If you are already complying with ICMJE-style journal disclosure expectations, you are most of the way to Article 50 compliance for your written outputs. The EU AI Act formalises what good practice already required. ### Provider-side content marking (live from August 2026) The detectability obligation is no longer theoretical. From August 2026, foundation model providers began marking their output at source: * **Text watermarking.** [Anthropic began watermarking Claude's text output globally](https://www.anthropic.com/news/claude-text-watermark) in August 2026 — a statistical pattern in word choice that is invisible to readers, does not change meaning, and can be verified with a key. Google's SynthID does the same for Gemini. OpenAI has built comparable technology but has not deployed it at scale. * **File provenance.** Generated image files (.png, .jpg, .svg) increasingly carry [C2PA content credentials](https://c2pa.org/) — industry-standard metadata recording that the file was AI-produced. Three practical implications for medical writers: **The marking obligation is not yours.** It sits on the model provider. You do not need to add anything to a deliverable because it was drafted with a watermarking model, and the watermark itself is not a disclosure. **Your duty is the deployer duty — and human review is an explicit defence.** Article 50(4) requires deployers publishing AI-generated text on matters of public interest to disclose it, but exempts text that has undergone a human editorial review process with a natural or legal person holding editorial responsibility for its publication. That is the named-reviewer model this playbook argues for throughout, written into the Act. A deliverable with a named accountable reviewer is not, in the Act's own terms, undisclosed synthetic content. **Detection is not yet something to rely on — in either direction.** Public tooling is limited: Anthropic has announced a detection API but not released it, Google's SynthID text detector has restricted access, and there is no cross-provider detector. The signal is weakest exactly where medical writing sits — short passages, factually constrained prose offering few genuine word choices, and text substantially rewritten through author review and MLR. Do not assume a journal can check. Equally, do not assume an absent watermark evidences human authorship. The net effect is that watermarking raises the practical cost of non-disclosure without changing what you owe. It does not replace declaration — see [Declaring AI Use](/principles/declaring-ai-use). *** ## What "high-risk" looks like in medical writing contexts Most generative AI used in writing workflows is *not* high-risk under the Act. But several adjacent uses are, and writers should be alert to them: * **AI used in adverse-event triaging or pharmacovigilance signal detection** — even if a writer is summarising the output, the upstream AI is high-risk * **AI components in software-as-a-medical-device (SaMD)** — content generated to support these systems carries higher documentation expectations * **AI used in patient-facing decision support** — including chatbots that triage symptoms or provide treatment guidance * **AI in regulatory decisions on benefit-risk** — generally human-decided, but AI inputs to these decisions are scrutinised If any of your work touches these categories, treat the compliance bar as substantially higher and involve regulatory affairs early. *** ## Foundation model obligations The Act distinguishes between AI systems (downstream applications) and **general-purpose AI models** (the foundation models like Claude, GPT, Gemini that underlie most AI tools). Providers of general-purpose models carry their own obligations, including: * Technical documentation and training-data summaries * Compliance with EU copyright law * For models with "systemic risk" (the most capable frontier models), additional safety, evaluation, and incident-reporting obligations For medical writers, the practical implication is that **the AI tool you choose carries its own compliance status**, and that status flows through to your work. When evaluating a tool, ask: * Which underlying model does it use? * Has the provider published the documentation required under the Act? * Does the provider's data-handling meet your sponsor's and the Act's requirements? *** ## Implementation timeline (mid-2026 status) | Date | Status | | ----------------- | ------------------------------------------------------------------- | | August 2024 | EU AI Act in force | | February 2025 | Prohibited AI uses banned | | August 2025 | Foundation model provider obligations apply | | **2 August 2026** | **Article 50 transparency obligations enforceable** — in force now | | 2 December 2026 | Grace period ends for machine-readable marking of synthetic content | | August 2027 | High-risk AI obligations fully apply | Transparency and governance obligations are now in force. The narrow grace period covering machine-readable marking of synthetic content runs to December 2026, which is why provider watermarking is arriving in stages rather than all at once. High-risk obligations remain in their compliance window, which is why guidance is still evolving for SaMD-adjacent uses. *** ## Other regulatory frameworks The EU AI Act is the most concrete, but it does not stand alone. Medical writers working in regulated communications should be aware of: | Body | Framework | Status | | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------- | | **[FDA](https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-aiml-enabled-medical-devices)** (US) | AI/ML-enabled medical device guidance; Good Machine Learning Practice (GMLP) framework | Evolving; final framework expected through 2026–27 | | **[EMA](https://www.ema.europa.eu/en/about-us/how-we-work/data-regulation-big-data-other-sources/artificial-intelligence)** (EU) | Reflection paper on AI in the medicinal product lifecycle | Published 2024; multi-annual workplan in implementation | | **[MHRA](https://www.gov.uk/government/publications/impact-of-ai-on-the-regulation-of-medical-products)** (UK) | AI Airlock; AI as a Medical Device programme | Active sandbox programme; guidance evolving | | **[WHO](https://www.who.int/publications/i/item/9789240029200)** | Ethics and governance of AI for health | Global ethical guidance, not regulation | | **PMDA** (Japan), **NMPA** (China) | Country-specific AI/SaMD guidance | Increasingly active | These don't replace the EU AI Act for EU-bound work; they layer on top, and they tend to converge on similar standards (transparency, accountability, validation, post-market surveillance). *** ## Practical assessment for your team For every AI tool in your medical writing workflow, identify which Act tier it falls into. Most will be limited-risk (transparency obligations). Flag any that touch high-risk territory (clinical decisions, pharmacovigilance, medical devices) for regulatory review. The audit-trail expectations in [Review and Accountability](/principles/review-and-accountability) cover most of what regulators will look for. Build the habit during the work, not when a compliance question arrives. Ask your AI tool providers for their EU AI Act compliance documentation. Reputable providers (foundation model vendors and downstream tool builders) are publishing this now. Absence of documentation is a flag. Existing pharma SOPs covering editorial assistance, third-party services, and content production should be reviewed to confirm they cover AI use specifically — labelling, disclosure, documentation, and tool vetting. Article 50 transparency obligations mean AI-generated content reaching the public must be labelled. This is now a compliance issue, not just a best practice. Train writers, editors, and reviewers on the labelling expectations for each deliverable type. *** ## Common mistakes The Act applies to any AI-assisted output that affects people in the EU. Globally distributed pharma materials, EU clinical trial documentation, EU regulatory submissions, and EU-distributed promotional content all bring work into scope, regardless of where the writer or sponsor sits. The Act's obligations are continuous (documentation, post-market monitoring, incident reporting for high-risk uses). One-time gap analyses are not enough; compliance is operational. Even minimal-risk AI use can trigger transparency obligations under Article 50 if the AI is generating content for external audiences. The tier determines the *kind* of obligation, not whether obligations exist. Your AI tool provider's compliance status is part of your compliance position. Choosing tools without verifying provider obligations leaves a gap in your audit trail. AI use questions on regulated submissions should be raised with regulatory affairs and legal at the project-planning stage, not at submission. Late escalation is the most common reason AI-assisted regulatory work gets reworked. *** ## How this connects to other playbook principles * **[Declaring AI Use](/principles/declaring-ai-use):** Article 50 transparency obligations align directly with journal disclosure expectations. Building good disclosure practice covers most of the Act's content-labelling requirements. * **[Review and Accountability](/principles/review-and-accountability):** The audit-trail and named-reviewer expectations are the documentation foundation regulators look for. * **[Source Grounding](/principles/source-grounding):** The Act doesn't replace evidence-based requirements. Both apply. * **[Risk Levels](/principles/risk-levels):** The playbook's internal risk tiers and the EU AI Act's tiers are different frameworks but complementary — the playbook tier tells you *how to review*, the Act tier tells you *what regulators expect*. *** ## The bottom line The EU AI Act has shifted AI compliance from "best practice" to "legal obligation" for any medical writing reaching the EU. Most generative writing AI sits in the limited-risk tier — meaning transparency, labelling, and documentation, not heavy validation. But the boundary with high-risk uses is real, and the implementation timeline is short. Build the habits now: label AI-generated content, document use contemporaneously, vet provider compliance, and escalate ambiguous cases to regulatory affairs early. *** *Last reviewed: 16 August 2026 · 9 min read* # AI Risk Framework for Medical Writing Source: https://playbook.pharmatools.ai/principles/ai-risk-framework A practical framework for deciding where AI can assist, where it needs stricter review, and where human authority must remain primary. AI can accelerate structured writing tasks. Clinical interpretation and regulatory judgement remain human responsibilities. ## Purpose This framework provides a practical model for deciding how much AI involvement is appropriate for a given task, and what review it requires. For an overview of *why* AI risk varies across medical writing tasks, common failure modes, and what makes a task higher risk, see [Understanding AI Risk](/principles/risk-levels). *** ## The framework Four tiers classify AI use by the impact of error and the degree of human judgement required. | Tier | Role of AI | Impact if wrong | Human involvement | | -------------------------------- | -------------------------------- | ----------------------------------------------------------- | -------------------------------------- | | **1. Assistive** | Structure, search, organise | Low — correctable in standard review | Writer reviews and refines | | **2. Structured transformation** | Adapt, convert, reformat | Medium — meaning can drift without detection | Detailed review against source | | **3. Evidence-critical** | Extract, verify, draft from data | High — incorrect data propagates downstream | Expert verification of every value | | **4. Human authority required** | Supporting role only | Very high — regulatory, clinical, or compliance consequence | Human controls the process; AI assists | ### How to read the tiers AI use becomes higher risk as either: * **the impact of being wrong increases** (a transposed HR in a CSR vs. a formatting error in an outline) * **the task requires more interpretation** (reporting a number vs. drawing a clinical conclusion from it) The same workflow can sit in different tiers depending on how AI is used. Outlining a manuscript (Tier 1) is not the same as drafting the Discussion section's interpretation of results (Tier 3–4). *** ## Workflow mapping Where each playbook workflow sits in the framework. Ranges indicate that the tier depends on how AI is used within the workflow. | Workflow | Tier | Notes | | ------------------------------------------------------------------- | ---- | ------------------------------------------------------------------------- | | [Find Evidence](/workflows/find-evidence) | 1 | AI supports search strategy; human selects sources | | [Summarise a Paper](/workflows/summarise-source-paper) | 1 | AI structures; human verifies data points | | [Congress Summary](/workflows/prepare-congress-or-poster-summary) | 1–2 | Extraction is Tier 1; contextualisation is Tier 2 | | [Extract Study Data](/workflows/extract-study-data) | 3 | Every extracted value must be verified against source | | [Extract Key Messages](/workflows/extract-key-messages) | 3 | Message framing and evidence strength require expert judgement | | [Build an Outline](/workflows/build-content-outline) | 1 | Structural task; low consequence if refined | | [Write a Manuscript](/workflows/write-a-manuscript) | 2–3 | Methods/Results drafting is Tier 2; Discussion interpretation is Tier 3–4 | | [Draft a Regulatory Document](/workflows/draft-regulatory-document) | 4 | Regulatory wording and interpretation require human authority | | [Convert Stats to Narrative](/workflows/convert-stats-to-narrative) | 2–3 | Mechanical conversion is Tier 2; verifying accuracy is Tier 3 | | [Create a Slide Deck](/workflows/create-medical-slide-deck) | 2 | Content reformatting with meaning-drift risk | | [Adapt for Audiences](/workflows/adapt-for-different-audiences) | 2 | Simplification can change meaning without visible errors | | [Plain Language Summary](/workflows/create-plain-language-summary) | 2 | Patient-facing; oversimplification risk | | [Verify Claims](/workflows/verify-claims-against-references) | 3 | Verification accuracy has direct downstream impact | | [Compliance Check](/workflows/check-promotional-compliance) | 4 | Compliance judgement cannot be delegated to AI | | [Check Document Consistency](/workflows/check-document-consistency) | 2 | AI flags candidates; human confirms true inconsistencies | | [Repurpose Content](/workflows/repurpose-content-across-channels) | 1–2 | Reformatting is Tier 1; channel-specific adaptation is Tier 2 | | [Final Review](/workflows/final-human-review) | 4 | The sign-off is a human responsibility | These mappings are not absolute. Risk depends on the source material, the context of use, the level of human review applied, and the consequences of error for the specific deliverable. *** ## Review expectations by tier What human review should look like at each level. ### Tier 1 — Assistive * Confirm relevance and completeness * Verify key data points against sources * Check that structure matches the deliverable purpose * Standard medical writing review is sufficient ### Tier 2 — Structured transformation * Detailed comparison between source and output * Check for meaning drift, dropped qualifiers, and shifted emphasis * Verify that safety information is preserved proportionately * Cross-check every clinical claim against the original ### Tier 3 — Evidence-critical * Expert verification of every numerical value against source data * Confirm analysis populations, endpoint definitions, and statistical measures are correctly attributed * Verify that no AI-generated interpretation has entered the output * Spot-check unflagged content as well as flagged items ### Tier 4 — Human authority required * Human controls the process from the start; AI assists with specific tasks (formatting, structuring, locating information) * Expert review of all wording, interpretation, and conclusions * No AI output enters the final deliverable without explicit human approval * Formal sign-off by a qualified professional *** ## Where AI should not be the deciding layer Regardless of tier, AI should not serve as the final authority for: * **Clinical interpretation** — whether a result is clinically meaningful * **Regulatory conclusions** — whether a document meets applicable guidance * **Benefit-risk assessment** — weighing efficacy against safety for a specific population * **Compliance sign-off** — whether content meets the requirements of a promotional code * **Final approval** — the decision that a deliverable is ready for submission, publication, or external use These decisions require human expertise, accountability, and professional judgement. AI can provide supporting information, but a human must own the conclusion. *** ## Using this framework in practice **For individual writers:** Before starting an AI-assisted task, identify which tier it falls into. Match your review effort to the tier. If you are unsure, default to the higher tier. **For team leads:** Use the tiers to set expectations for AI-assisted work across your team. Define which tiers require senior review, which require source cross-checks, and which require formal sign-off. **For client or stakeholder conversations:** The framework provides a clear, defensible answer to "how do you ensure AI-assisted content is accurate?" You can point to the tier, the review process, and the accountability structure. **When a task spans multiple tiers:** Many real-world deliverables involve tasks at different tiers. A manuscript has Tier 1 outlining, Tier 2 Methods drafting, and Tier 3–4 Discussion interpretation. Apply the appropriate review to each component, not a single blanket review to the whole document. *** ## Related principles * [Human-in-the-Loop Decision Making](/principles/human-in-the-loop) — every deliverable has a named owner * [Source Grounding](/principles/source-grounding) — every claim traces to a cited source * [Understanding AI Risk](/principles/risk-levels) — why risk varies across tasks, failure modes, and risk factors * [Review and Accountability](/principles/review-and-accountability) — sign-off protocols and audit trails ## Related workflows * [Verify Claims Against References](/workflows/verify-claims-against-references) — Tier 3 verification in practice * [Draft a Regulatory Document](/workflows/draft-regulatory-document) — Tier 4 drafting with human authority * [Convert Stats to Narrative](/workflows/convert-stats-to-narrative) — Tier 2–3 mechanical translation * [Final Human Review](/workflows/final-human-review) — the Tier 4 sign-off process *** *Last reviewed: 15 April 2026 · 6 min read* # Choosing Your Model Source: https://playbook.pharmatools.ai/principles/choosing-your-model When to reach for a reasoning model, when a standard LLM is enough, and how to match model choice to the task in front of you. ## Core principle Match the model to the cognitive demand of the task. The right choice is rarely "the most capable model available" — it is the model whose strengths fit the work, given the cost, latency, and verifiability you need. Most medical writing tasks are well-served by a standard general-purpose LLM. A small but important subset benefits materially from a reasoning model. A few are made worse by one. *** ## Why this matters now Through 2024–2025, the AI model landscape stopped being one-dimensional. Where "use ChatGPT" or "use Claude" was once a sufficient choice, medical writers now face a real selection question across at least three categories: * **Standard general-purpose LLMs** (Claude Sonnet, GPT-4-class, Gemini Pro) — fast, single-pass, well-suited to drafting, summarising, and editing * **Reasoning models** (Claude with extended thinking, OpenAI o-series, DeepSeek R1) — slower and more expensive, but explicitly "think" through problems before responding * **Frontier models** (the most capable models at any given time, e.g. Claude Opus 4.X) — highest quality, highest cost, longest latency The right choice depends on what the task actually demands. Defaulting to the most capable model wastes budget on tasks that don't need it, and defaulting to a cheap one fails on tasks that do. *** ## The three model classes (and where each shines) | Class | Strengths | Weaknesses | Best for | | ------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------- | | **Standard LLM** | Fast, low cost, good prose | Can miss multi-step errors; weaker at planning | Drafting, summarising, translation, editing | | **Reasoning model** | Explicit step-by-step reasoning; better at verification, planning, and complex synthesis | Higher cost, longer latency; can fabricate within reasoning chains | Multi-step verification, complex evidence synthesis, closed-loop workflows | | **Frontier model** | Highest output quality, broadest capability | Highest cost, slower, sometimes overkill | High-stakes deliverables where quality justifies the spend | These are not mutually exclusive — many real workflows mix model classes (a reasoning model for the hard step, a standard model for everything else). *** ## When to reach for a reasoning model Anywhere a task involves "do X, then check X against Y, then revise based on the check" — reasoning models materially outperform standard ones because they hold the steps and constraints in their working memory. The closed-loop pattern in [RefCheckr](/tools/refcheckr) is a clear example: verify a claim, rewrite if it doesn't match, re-verify the rewrite, check compliance. When you need to compare findings across multiple studies, reconcile conflicting data, or trace a claim through a chain of references, reasoning models do the bookkeeping more reliably. Useful for systematic literature review tasks, comparative effectiveness narratives, and benefit-risk assessments. Tasks like "given this brief, what sections does the deliverable need, what evidence does each section require, and what is the right order?" benefit from a model that can plan before writing. Useful at the outline stage, less useful at the draft stage. Statistical narratives, regulatory text, claim chains. If one wrong number cascades into wrong conclusions, the cost of an undetected error is high. Reasoning models reduce that risk; closed-loop workflows reduce it further. *** ## When a reasoning model is overkill (or worse) If the task is "rewrite this paragraph in publication style" or "draft a slide title from this finding", a standard model is faster, cheaper, and produces output of equivalent quality. Reasoning models add latency without adding value. Generating 50 social media variants, drafting 30 caption candidates, or producing a first pass on routine email copy. Standard model. Cost per output dominates here. Translating between languages, or adapting HCP content for patients, is a transformation task — not a reasoning task. Standard models handle it well; reasoning models tend to over-think and produce stilted output. Reasoning models can fabricate within their reasoning chains — citing fake papers in their internal "thinking" or building a plausible chain to a wrong conclusion. If you cannot verify the reasoning trace, the assurance a reasoning model offers is partly illusory. Pair reasoning models with explicit verification (closed-loop, source grounding) or use a standard model and verify the final output directly. *** ## The cost / quality / latency triangle | | Standard LLM | Reasoning model | Frontier model | | ---------------------------- | ------------------------------- | -------------------------- | ---------------------------- | | **Cost per output** | Low | High | Very high | | **Latency** | Seconds | Tens of seconds to minutes | Seconds to minutes | | **Quality on simple tasks** | High | High (overkill) | High (overkill) | | **Quality on complex tasks** | Variable | Higher | Highest | | **Best paired with** | Source grounding + human review | Closed-loop verification | High-stakes, low-volume work | You usually pick two of cost, quality, and latency — almost never all three. Knowing which two the task requires is the actual decision. ## The fourth axis: resource cost Cost, quality and latency are what you trade against on any single task. At team scale there is a fourth, and it moves in the same direction as the first: energy and water. Every query runs in a data centre that consumes electricity and — directly, and through the generation of that electricity — water. Per query the numbers are small; published vendor figures put a text prompt in the fraction-of-a-watt-hour range. The number that matters is the multiplier: a team of thirty writers, times daily use, times a year. And per task, agentic workflows run orders of magnitude above chat-style use, because one instruction becomes many model calls. The [AI Water and Energy Footprint Calculator](https://www.pharmatools.ai/water-consumption-calculator) sizes this for a given usage profile, using published vendor disclosures and letting you set the measurement boundary — onsite data centre use, or the fuller picture including electricity generation. Two reasons this belongs in a model-selection decision rather than in a sustainability policy: * **Over-powered model choice compounds.** Reaching for a reasoning model on a transformation task already costs latency and budget for no quality gain. It costs resources on the same basis. The tasks in the overkill list above are the ones where the saving is free — you lose nothing by choosing the smaller model. * **Clients are starting to ask.** Pharma sponsors reporting under CSRD and similar regimes are pushing environmental questions down into procurement, and agency RFPs are beginning to ask what the footprint of an AI-assisted process looks like. That answer is easier to give if you already choose models deliberately. This is a proportionality point, not an argument against using AI. A frontier model on a high-stakes regulatory document is a good use of resources. The same model generating fifty social captions is not. *** ## A practical decision matrix | Task | Suggested model | Why | | ----------------------------------------------------- | -------------------------------------------------------------------- | --------------------------------------------------------------------- | | Draft a Discussion section from study results | Standard | Single-pass prose generation | | Summarise a 30-page paper | Standard with long context | Transformation, not reasoning | | Convert a CSR section into a plain-language summary | Standard | Translation/adaptation task | | Verify claims against cited references | Reasoning (closed-loop) | Multi-step, errors compound | | Build an evidence narrative across 8 studies | Reasoning | Complex synthesis | | Generate slide titles from key messages | Standard | Routine generation | | Draft a regulatory document outline | Reasoning | Planning task | | Polish prose for journal style | Standard | Editing transformation | | Pre-screen promotional content for compliance signals | Standard with structured prompt or reasoning if findings are nuanced | Pattern-matching is single-pass; nuanced cases benefit from reasoning | | Run a closed-loop verify-fix-recheck workflow | Reasoning | The point of the loop is the multi-step thinking | *** ## Worked example: choosing a model for a manuscript workflow A typical manuscript project might use multiple model classes across its stages: | Stage | Model class | Reason | | ---------------------------------------------------------- | -------------------------- | --------------------------------------------------- | | Outline from key messages and source paper | Reasoning | Planning task; benefits from explicit decomposition | | Section-by-section drafting | Standard | Generation from clear instructions | | Reference verification (via [RefCheckr](/tools/refcheckr)) | Reasoning (in closed loop) | Multi-step verification | | Style polishing for journal | Standard | Editing transformation | | Final claim-vs-source check | Reasoning (in closed loop) | High stakes, errors compound | The same project does *not* require the same model for every step. Cost-efficient workflows mix classes deliberately. *** ## Common mistakes "Use the best model" is a heuristic that wastes budget and adds latency on tasks that don't need it. The best model for a slide title is rarely the same as the best model for a benefit-risk synthesis. A reasoning model's "thinking" is not a verification of correctness — it's a model of how the model reached its answer. The thinking can be fluent and wrong. Treat reasoning chains as useful introspection, not as proof. A reasoning model that takes 90 seconds to answer is fine for a back-end QC pipeline; it can be unworkable for an interactive tool a writer is using turn-by-turn. The model class has to match the workflow shape. Today's frontier model is next year's standard model. The decision framework is durable; the specific model names are not. Re-evaluate periodically. Most medical writing pipelines benefit from a mix: standard for drafting, reasoning for verification, standard for polishing. Single-class pipelines either underspend on the hard steps or overspend on the easy ones. *** ## How this connects to other playbook principles * **[Risk levels](/principles/risk-levels):** Higher-risk work generally justifies a more capable model, but not always — the playbook's risk tier tells you *how much review* is required; this principle tells you *which model* fits the task. * **[AI failure modes](/principles/ai-failure-modes):** Different model classes fail differently. Standard LLMs miss multi-step errors; reasoning models can fabricate within their chains. Knowing the failure mode helps the choice. * **[Source grounding](/principles/source-grounding):** Source grounding constrains what the model can claim; it does not change which model you choose. Both apply. * **[Review and accountability](/principles/review-and-accountability):** Document which model class was used for which step, the same way you document which workflow was followed. This is part of the audit trail. *** ## The bottom line The right model is the one whose strengths match the cognitive demand of the task — not the most capable model on offer. Standard LLMs handle most drafting, summarising, and editing. Reasoning models earn their keep on multi-step verification, complex synthesis, and planning. Frontier models are worth the cost on high-stakes, low-volume work. Most useful workflows mix classes deliberately. Default to the cheapest model that produces verifiable, correct output for the task; reach higher only when the task demands it. *** *Last reviewed: 19 August 2026 · 8 min read* # Declaring AI Use Source: https://playbook.pharmatools.ai/principles/declaring-ai-use What journals, regulators, and clients expect you to disclose when AI is part of the writing process, and what 'use' actually means. ## Core principle When AI is used in the production of a deliverable, that use must be declared — accurately, specifically, and in the right place. "We used ChatGPT a bit" is not a disclosure. Vague language fails under audit. The reviewer who signs off remains accountable; declaration does not transfer responsibility. *** ## Why this matters now Through 2024–2025, the major medical journals, scientific societies, and regulators all moved to require explicit disclosure of AI use in submitted work. The trend is clear: **non-disclosure is now the higher-risk position**. A retraction triggered by undisclosed AI use damages the writer, the author group, the sponsor, and (for agency work) the client relationship. Through 2026, a second shift is underway. Journals that started with "disclose it" are finding that disclosure alone does not fix the underlying problem — a fabricated reference is still fabricated when it is declared, and a formulaic Opinion piece is still formulaic. The leading edge of policy has moved from disclosure to **prohibition for specific uses**. Plan for both: know what you must declare, and know what you must not do at all. For pharma and medical-affairs teams, AI disclosure expectations now sit alongside the older expectations around financial disclosures, ghostwriting, and editorial assistance. The same principle applies: be specific, declare early, document as you go. *** ## The major policies (mid-2026 snapshot) | Body | Position | What to disclose | | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **[ICMJE](https://www.icmje.org/recommendations/browse/artificial-intelligence/)** | AI cannot be listed as an author. Authors must disclose AI use in methods or acknowledgments. Authors retain full responsibility for all content. | Tool name, what it was used for, who reviewed | | **[NEJM](https://ai.nejm.org/about/editorial-policies)** | Restrictive on substantive content generation. Editing/proofing typically permitted with disclosure. | Tool, scope of use, in methods | | **[The Lancet](https://www.thelancet.com/editorial-policies)** | Permits AI assistance; requires disclosure of how AI was used and confirmation that authors take responsibility. | Tool, scope of use, in methods or acknowledgments | | **[JAMA Network](https://jamanetwork.com/journals/jama/pages/instructions-for-authors#SecUseofAIinPublicationandResearch)** | Most restrictive of the major journals as of Aug 2026. Disclosure required for permitted uses. **Not permitted:** generating, formatting or managing references; drafting Opinion articles, Letters to the Editor or online Comments; AI-created or AI-manipulated clinical images, illustrations, video or audio (unless part of a disclosed research design); peer review; author responses to reviewers. | Tool name, version, manufacturer, dates of use, which portions, confirmation of author responsibility — in Acknowledgments (Methods for research use) | | **[BMJ](https://www.bmj.com/content/ai-use)** | Disclosure required for AI use beyond basic editing. | Tool, scope of use | | **[Nature](https://www.nature.com/nature-portfolio/editorial-policies/ai)** | Permits AI for editing/proofing without disclosure; disclosure required for content generation. | Tool, scope of use | | **[Science / AAAS](https://www.science.org/cms/asset/dfee6869-6d00-44b3-96c5-bd364cf36894/science_journals_guidelines_for_ai_use.pdf)** | Disclosure required for non-trivial AI use. | Tool, scope of use | | **[WAME](https://journals.lww.com/pajo/fulltext/2023/03270/wame_recommendations_on_chatgpt_and_chatbots_in.8.aspx)** | Cross-publication guidance: AI is not an author; disclosure required; authors responsible. | Refer to specific journal policy | **JAMA Network tightened its policy on 10 August 2026.** The updated editorial guidance moves three categories from "disclose" to "not permitted": AI-generated or AI-formatted **references** (use a standard reference manager instead), AI-drafted **Opinion articles, Letters to the Editor and online Comments**, and AI-created or AI-manipulated **clinical images, illustrations, video and audio**. Grammar, spelling and translation remain permitted, but only on text a human wrote first. Failure to disclose can result in rejection or post-publication corrective action. Source: [Updated Guidance for Author Use of AI in Medical Publication](https://jamanetwork.com/journals/jama/fullarticle/2852772), *JAMA*, 10 August 2026 (doi:10.1001/jama.2026.16613). Policies evolve, and the direction of travel is towards tighter restriction rather than looser. Always check the current author guidelines for the specific journal at the point of submission — and check them again if a manuscript has been in preparation for more than a few months. *** ## What counts as "AI use" Expectations vary by what AI was actually doing. The spectrum runs from routine and unremarkable through to outright prohibited: | Use | Typical expectation | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Spell-check, grammar correction (Grammarly-style) | Often not required, but increasingly noted | | Translation between languages | Required by most policies | | Editing existing human-written prose for clarity or tone | Required by most policies | | Ideation, brainstorming structure or angles | Often required | | Drafting sections of prose | Required by all major policies | | Generating tables, figures, or data summaries | Required, often with stronger restrictions | | Generating citations or reference lists | **Prohibited by JAMA Network**; high-risk and discouraged elsewhere. Use a reference manager; verify every citation regardless | | Drafting Opinion pieces, editorials, Letters to the Editor, online Comments | **Prohibited by JAMA Network.** Other journals expect disclosure; several are moving the same way | | Image generation (concept visuals, illustrations) | Required, often with explicit constraints. **Clinical images, illustrations, video and audio are prohibited by JAMA Network** unless part of a disclosed research design | | Adjusting existing scientific images (brightness, contrast, colour, background) | Permitted only if applied uniformly and non-deceptively; describe in the figure legend with software name and version, and retain originals for editorial review | | Statistical analysis or data extraction | Treated as analytical contribution; full methods disclosure | When in doubt, check whether it is permitted — then declare. *** ## What to declare, where, and how ### What to include * The specific tool used (name and version, where versioning is meaningful) * The manufacturer or developer, and the date(s) of use — now explicitly required by JAMA Network * What the tool was used for (drafting, editing, translation, etc.) * The scope (which sections, which deliverables) * How the output was reviewed and by whom, with an explicit statement that the author(s) take responsibility for accuracy and integrity ### Where to put it * **Manuscripts:** Methods section is the standard location for substantive use; acknowledgments for editorial assistance. * **Conference abstracts and posters:** Acknowledgments or footer. * **Regulatory documents:** Per the relevant agency guidance, which is rapidly evolving. * **Promotional materials:** Per the applicable code (ABPI, IFPMA) and client SOP. ### Wording Specific is better than vague. Compare: > "AI was used during writing." > "Claude (Anthropic, Opus 4.7) was used between 3 and 11 June 2026 to draft the Discussion section. Output was reviewed and edited by \[Author X], who takes responsibility for the accuracy and integrity of the final content." The second version names the tool and manufacturer, dates the use, scopes it to a section, makes a named human accountable, and could survive an audit. Note the sequencing point: disclosure only helps if the use was permitted in the first place. Check the prohibitions before you check the wording. For ready-to-adapt wording across the common scenarios — manuscripts, posters, regulatory documents, promotional materials — see the [Disclosure Language Template](/templates/disclosure-language). *** ## Common mistakes Universally rejected by major journals. AI cannot meet authorship criteria — it cannot take responsibility for the work or respond to post-publication queries. Listing it triggers immediate desk rejection or retraction. "AI tools were used" or "We used ChatGPT" without specifying scope leaves the reader (and any post-publication investigator) unable to assess what was actually AI-generated. Be specific. Trying to remember which sections used AI three months later is unreliable. Track AI use *as you write*: keep a brief log per section or per deliverable. The [review and accountability](/principles/review-and-accountability) audit-trail recommendations apply directly here. Several journals (BMJ, Nature, ICMJE-aligned) treat substantive editing — even on human-written drafts — as disclosable. The threshold isn't "AI wrote a paragraph"; it's "AI changed the meaning, structure, or strength of a claim." Disclosure and permission are two different tests. JAMA Network now prohibits AI-generated references, AI-drafted Opinion pieces and Letters, and AI-created clinical imagery outright — declaring them does not make them submittable. Check what the journal forbids before you draft, not after. The most consistently damaging failure mode, and now an explicit prohibition at JAMA Network. Frontier models produce references that look entirely real — correct author names, plausible titles, well-formed DOIs — for papers that do not exist. Build references in a reference manager and verify every one against the source record. Sponsor SOPs increasingly include AI use as a disclosable category in the same bucket as third-party editorial assistance. Check the client's SOP before any AI-assisted work begins, not at the disclosure stage. *** ## Beyond journals * **Conferences and societies (ISMPP, AMWA, EMWA):** Increasingly request AI disclosure on submitted abstracts, posters, and oral presentations. Disclosure conventions are converging on the journal model. * **Regulators:** FDA, EMA, MHRA, and PMDA have all issued guidance or reflection papers on AI use in regulated submissions through 2024–2025. Expectations are evolving fast; treat your client's regulatory affairs team as the source of truth for any submission-bound deliverable. * **Pharma sponsors and clients:** Many global pharma companies now require AI use to be declared in project briefs and final delivery documentation, regardless of journal or regulator requirements. The disclosure is internal, but the standard is the same: specific, contemporaneous, auditable. *** ## How this connects to other playbook principles * **[Human-in-the-loop](/principles/human-in-the-loop):** Disclosure does not reduce author responsibility. It documents the production process; the named human is still accountable. * **[Review and accountability](/principles/review-and-accountability):** The audit trail you maintain to support accountability is the same record you draw from for accurate disclosure. Build the habit once. * **[Source grounding](/principles/source-grounding):** Declaring AI use does not exempt AI-generated claims from full source verification. Both apply. *** ## The bottom line If you cannot specify what AI did, when, and who reviewed it, you do not have a disclosure — you have a defence. The standard now, across journals, regulators, and SOP-driven clients, is contemporaneous documentation. Build the habit during writing, not at submission. And ask the second question before the first: not only "how do I declare this?" but "is this use permitted at all?" For a growing list of tasks — references above all — the answer is now no. *** *Last reviewed: 11 August 2026 · 7 min read* # The Description–Discernment Loop Source: https://playbook.pharmatools.ai/principles/description-discernment AI output quality tracks the quality of your brief. Treat AI writing as a loop — describe with rich context, evaluate with expert judgement, refine with specific instructions. ## Core principle The quality of AI-assisted writing is set before the first draft appears — by how well you brief the model. And it is protected after the draft appears — by how rigorously you evaluate it. These two skills, **Description** and **Discernment**, form a loop: brief, draft, evaluate, refine, and feed what you learn back into the next brief. Most of this playbook covers the discernment half — verification, compliance screening, review, and sign-off. This page covers the half that gets less attention in regulated writing: the brief. A vague brief produces a generic draft, and a generic draft costs more review time than a good brief would have cost up front. This page applies concepts from the **AI Fluency Framework** developed by Prof. Rick Dakan (Ringling College of Art and Design) and Prof. Joseph Feller (University College Cork), as taught in Anthropic's AI Fluency courses. The framework describes four competencies — Delegation, Description, Discernment, and Diligence. Description and Discernment are the two with the most direct application to day-to-day medical writing; the playbook's [risk tiers](/principles/risk-levels) and [review protocols](/principles/review-and-accountability) map broadly to Delegation and Diligence. *** ## Description: brief AI like you'd brief a writer If you handed a deliverable to a freelance medical writer, you would never say "write a manuscript about this trial" and walk away. You would send the brief, the data, the journal requirements, examples of prior work, and the client's preferences. AI needs the same brief — and unlike the freelancer, it cannot ask around the office for what you forgot to include. ### Provide examples of approved work The fastest way to convey voice, structure, and register is to show, not describe. Where your organisation's policies permit, include in your prompt context: * A previously approved deliverable of the same type (an approved PLS, a past congress summary, a signed-off slide deck) * The house or client style guide, or the relevant extract * An approved messaging framework or claims matrix, where one exists * The target journal's author guidelines, congress abstract rules, or channel specifications A model given a strong prior example produces a first draft that already sits close to the expected structure and register. A model given none produces the average of everything it has read — which is precisely the generic voice reviewers then spend cycles editing out. **Confidentiality comes first.** Only upload materials you are permitted to share with the AI tool under your organisation's and your client's AI policies. Approved, published, or client-cleared examples are the safe starting point. Never paste unpublished data, patient-level information, or confidential commercial material into a tool that has not been approved for it. See [Declaring AI Use](/principles/declaring-ai-use) for the disclosure side of this. ### Inject what AI cannot know AI knows the published literature up to its training cutoff. It does not know: | What only you know | Why it changes the draft | | --------------------------------------------------- | ----------------------------------------------------------------------- | | The client's messaging priorities and sensitivities | Which endpoint leads, which comparisons are off-limits | | What MLR flagged on the last three submissions | The specific phrasings to avoid this time | | The audience's actual starting knowledge | A "GP audience" in one market is not the same as another | | Where the evidence is genuinely weak | The limitations the deliverable must acknowledge rather than paper over | | The project's history and context | Why the brief says what it says — the decisions already made | The single biggest upgrade to most prompts is not cleverer instructions — it is adding the two or three facts the model had no way of knowing. ### Describe the approach, not just the output Beyond what to produce, describe how to produce it: "work only from the attached sources; flag anything you cannot support rather than filling gaps" is an approach instruction, and it is the practical implementation of [source grounding](/principles/source-grounding). The [prompt patterns](/prompts/source-analysis-prompts) in this playbook are structured this way — output format, source constraints, and behavioural rules stated explicitly. *** ## Discernment: evaluate more than accuracy The playbook's [review checklists](/workflows/final-human-review) cover accuracy, completeness, and compliance in depth. Two further discernment questions are easy to skip because nothing "fails" when they go unasked: ### Does it sound like us? AI defaults to a recognisable register — fluent, balanced, slightly padded, fond of "moreover" and tidy triplets. For an internal summary, that may not matter. For a client deliverable, an authored manuscript, or patient-facing content, it does. Ask explicitly: * Would a reader familiar with our (or the client's) content recognise this as ours? * Does the phrasing match the approved lexicon — or has the model substituted near-synonyms that were deliberately avoided? * Is anything padded, hedged, or generically "professional" where the house style is direct? A [voice and authenticity check](/prompts/review-prompts#7-voice-and-authenticity-check) can support this review, but the judgement is the writer's: you know what your organisation sounds like. ### Is the process working — not just the output? Discernment applies to the collaboration itself, not only the draft in front of you. If every draft needs the same correction, the fix belongs in the brief, not in another round of edits. Signals worth acting on: * You keep re-explaining the same context → move it into a standing briefing block * The model keeps overreaching the sources → tighten the grounding rules in the prompt * Drafts are accurate but tonally wrong → add or improve the voice example *** ## Closing the loop: revise with specifics Vague feedback to AI produces vague revisions — the model guesses at what you meant, and its guess is usually "more adjectives." Specific feedback produces controlled revisions. | Instead of | Say | | ------------------------------- | -------------------------------------------------------------------------------------------------------- | | "Make this more compelling" | "Lead with the primary endpoint result; move the mechanism paragraph after the efficacy data" | | "This doesn't sound right" | "Replace 'groundbreaking' and 'robust' — use the neutral register of the attached example" | | "Tighten it up" | "Cut to 400 words; keep the safety paragraph unchanged" | | "The safety section is weak" | "Add discontinuation rates from Table 3 and retain the severity grading qualifiers" | | "Make it more patient-friendly" | "Target reading age 12; replace 'progression-free survival' with the approved plain-language definition" | Two rules keep iteration safe in medical writing: 1. **Pin what must not change.** When asking for a revision, state explicitly which sections, data points, and qualifiers must be preserved. Unconstrained revisions can quietly re-word verified content — which then needs re-verification. 2. **Re-verify what changed.** A revised draft is a new draft. Anything the model touched goes back through the applicable checks before sign-off. *** ## Build a briefing pack, not a prompt The course framing of a "cognitive environment" — context that accumulates across a collaboration — has a practical med comms translation: a reusable briefing pack per client, product, or project. A living document containing: * Approved voice examples and style rules * The standing context block (product, indication, audience definitions, off-limits territory) * Grounding and behavioural rules that have proven necessary * A running list of corrections that recur — each one a candidate for promotion into the standing brief After each deliverable, spend two minutes on the reflection the loop depends on: *what context did I have to add mid-project that should have been in the brief from the start?* Move it into the pack. Over a project's lifetime, first drafts get measurably closer to final, and the review effort concentrates where it belongs — on verification and judgement, not on fixing a brief that was never given. *** ## How this maps to the playbook | Loop stage | Where the playbook covers it | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Describe | [Prompt patterns](/prompts/source-analysis-prompts) · the Inputs section of every workflow card | | Draft | The 18 [workflow cards](/workflows/find-evidence) | | Discern | [Human-in-the-Loop](/principles/human-in-the-loop) · [Final Human Review](/workflows/final-human-review) · [AI Failure Modes](/principles/ai-failure-modes) | | Refine | This page · [Review prompts](/prompts/review-prompts) | | Own it | [Review and Accountability](/principles/review-and-accountability) — the person who signs off should be able to stand behind every word, however it was produced | *** *Concepts adapted from the AI Fluency Framework by Rick Dakan and Joseph Feller, as taught in Anthropic's AI Fluency courses (course materials © 2025 Anthropic and GivingTuesday, CC BY-NC-SA 4.0). The application to medical writing is the playbook's own.* *** *Last reviewed: 26 July 2026 · 7 min read* # Human-in-the-Loop Decision Making Source: https://playbook.pharmatools.ai/principles/human-in-the-loop Every deliverable has a named owner. AI produces working material; a qualified professional verifies, edits, and signs off. ## Core principle Every deliverable has a named owner. AI produces working material (structured drafts, candidate summaries, flagged issues) that a qualified professional reviews, edits, and approves. At no point in any workflow does AI output go directly into a deliverable without human verification. This is not a disclaimer appended to make AI use sound responsible. It is a structural requirement embedded in every workflow card: defined review points, specific verification steps, and documented sign-off. *** ## What this means in practice ### What AI handles well in med comms workflows * Producing a structured first-draft summary of a Phase III paper in 2 minutes instead of 45 * Generating a candidate content outline from a briefing document and key message set * Adapting a specialist-level summary for a GP or nurse audience * Scanning a 20-page detail aid for language patterns commonly flagged in MLR review * Extracting study design, endpoints, and results from a congress poster into a structured format ### What AI cannot do — and should never be trusted to do * Confirm that a hazard ratio, p-value, or confidence interval in a summary actually matches the source paper * Determine whether a key message crosses from scientific education into promotional territory * Decide which endpoints to foreground in a slide deck for a specific advisory board audience * Judge whether a plain language summary accurately represents the benefit-risk balance for patients * Bear accountability when a deliverable is signed off and sent to a client, regulator, or MLR committee *** ## Decision points in every workflow Each workflow card in this playbook includes explicit sections: * **Where AI helps** — bounded, specific tasks where AI adds value * **Where human judgement is essential** — points where a trained professional must review, verify, or decide * **Human review checklist** — a practical checklist for the review step These are not optional. Skipping the human review step turns an AI-assisted workflow into an AI-dependent one, which introduces unacceptable risk in medical communications. *** ## Why this matters for medical writing Medical writing operates in a space where: * **Accuracy is non-negotiable.** A misrepresented endpoint, an overstated efficacy claim, or an omitted safety finding can have real consequences — for patients, for prescribers, and for regulatory standing. * **Context is everything.** The same data point can be appropriate in a journal manuscript, misleading in a promotional piece, and incomprehensible in a patient leaflet. Only a trained professional can make that judgement. * **Accountability is personal.** When a document is signed off, a named individual is accountable for its accuracy and compliance. AI cannot bear that accountability. *** ## How to implement this principle 1. **Never submit AI-generated text without expert review.** This applies to every deliverable: an internal summary, a client-facing slide deck, a congress highlights report. No exceptions by risk tier. 2. **Document where AI was used.** Track which sections were AI-assisted in your project files. This is not bureaucracy; it tells the reviewer where to focus verification effort and supports client transparency. 3. **Review against sources, not just for readability.** AI output reads fluently. That is the danger. A summary that sounds authoritative can contain transposed data points, merged study arms, or conclusions the authors did not draw. Always verify claims against the original source materials. 4. **Treat AI output as a working draft.** The value is reaching a reviewable draft faster — getting from a blank page to a structured starting point. The review itself is not shortened; in some cases, it requires more attention, not less. 5. **Maintain clear sign-off protocols.** The person who approves the final deliverable owns its accuracy, compliance, and completeness. The fact that AI was involved in production does not change their accountability. *** ## Common failure modes | Failure | What it looks like in practice | How to prevent it | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Over-trust | A writer accepts an AI-generated summary without checking it against the paper. The summary transposes a primary and secondary endpoint result. The error enters a client slide deck. | Verify every data point against the source. Treat AI output the same way you would treat a junior writer's first draft — it needs line-by-line checking. | | Automation bias | MedCheckr flags no issues on a promotional piece. The writer assumes it is clean. MLR catches an unsubstantiated comparative claim the tool missed. | Automated screening is one input. It catches patterns, not context. The writer's own compliance review still applies. | | Accountability gap | An agency uses AI across multiple writers on a project. No one is clearly responsible for verifying the AI-assisted sections. A hallucinated data point reaches the client. | Assign a named reviewer to every AI-assisted deliverable. Document which sections used AI and who verified them. | | Review fatigue | A medical writer reviews five AI-generated summaries in a row. By the fourth, they are skimming. An incorrect sample size passes through. | Use the structured checklist for every review. Batch AI-assisted QC in manageable sets. Do not review more than three AI-generated documents without a break. | *** ## For agencies and teams If you are implementing AI workflows across a team or agency: * Establish minimum review standards for AI-assisted content at each risk tier and write them into your SOPs * Train writers and reviewers on the specific failure modes of AI in medical writing (hallucinated data, meaning drift, omitted qualifiers), not just generic "AI limitations" * Track AI use in project management systems so reviewers, account leads, and clients have visibility * Brief client services teams on how to discuss AI-assisted workflows with clients. Lead with the review framework and risk tiers, not the speed * Do not position AI as a way to reduce QC time or headcount. Position it as a way to produce more reviewable first drafts, improve consistency across deliverables, and free up writer time for the work that requires expert judgement *** *Last reviewed: 15 April 2026 · 6 min read* # Review and Accountability Source: https://playbook.pharmatools.ai/principles/review-and-accountability Structured sign-off protocols, audit trails, and documentation requirements for AI-assisted deliverables. ## Core principle Every AI-assisted deliverable must have a clear owner, a defined review process, and an auditable trail from source to final output. AI does not reduce accountability. It changes how work is produced, not who is responsible for it. *** ## Accountability structure ### Who is accountable? The person who signs off on a deliverable is accountable for its content, regardless of how it was produced. This is true whether the content was: * Written manually from scratch * Drafted with AI assistance and reviewed * Generated using AI tools and edited AI-assisted workflows do not create a new category of reduced accountability. They create a new set of review requirements. ### What are they accountable for? * **Accuracy:** Every factual claim is supported by the cited source * **Completeness:** No material omissions that would change the reader's understanding * **Appropriateness:** The content is suitable for its intended audience, channel, and regulatory context * **Compliance:** The content meets applicable promotional codes, regulatory requirements, and organisational standards * **Transparency:** The use of AI in the content development process is documented where required *** ## Review process framework ### For every AI-assisted deliverable 1. **Identify the risk tier.** Use the [risk levels framework](/principles/risk-levels) to determine the review intensity required 2. **Assign a named reviewer.** Every AI-assisted output must have a specific person responsible for reviewing it 3. **Review against sources.** Do not review AI output only for readability or flow. Verify claims, data, and interpretations against the original source materials 4. **Use structured checklists.** The [review checklist template](/templates/review-checklist-template) provides a starting point. Each workflow card includes a task-specific checklist 5. **Document the review.** Record what was reviewed, what was changed, and who approved the final version ### Review intensity by risk tier | Risk tier | Minimum review | Reviewer qualification | | --------- | --------------------------------------------------- | ----------------------------------------------------------------------------- | | Low | Standard review by medical writer | Experienced medical writer | | Medium | Enhanced review with source cross-check | Senior medical writer or subject matter expert | | High | Full expert review with formal sign-off | Medical advisor, regulatory reviewer, or compliance lead | | Critical | Full expert review — this IS the final quality gate | Qualified reviewer for the content type; the sign-off reviewer is accountable | *** ## What to review in AI-assisted content AI outputs have specific failure patterns that reviewers should watch for: ### Accuracy checks * All numerical data matches the source (endpoints, p-values, confidence intervals, sample sizes) * Study populations are correctly described (ITT, mITT, per-protocol, subgroups) * Timepoints and study phases are accurately represented * Statistical significance and clinical significance are not conflated * Conclusions match the source's stated conclusions ### Completeness checks * Safety data is included where relevant and not minimised * Limitations of the evidence are preserved * Relevant qualifiers (subgroup, post-hoc, exploratory) are retained * Comparator information is accurate and present ### Appropriateness checks * Language is suitable for the target audience * Claims are appropriate for the content type (promotional vs. scientific vs. educational) * Tone is consistent with the therapeutic area and context * No inappropriate certainty or hedging ### Compliance checks * Claims are within the approved messaging framework (if applicable) * References are correctly cited and support the claims made * No off-label implications * Balance of efficacy and safety information is appropriate *** ## Audit trails For AI-assisted workflows, maintain documentation that supports traceability: ### What to record * **Source materials used:** What was provided as input to the AI * **Workflow applied:** Which workflow card was followed * **AI tools used:** Which tools or models were used and for which steps * **Reviewer identity:** Who reviewed the AI-assisted output * **Changes made:** What was modified during review (tracked changes or documented edits) * **Final sign-off:** Who approved the final deliverable and when The [AI Audit-Trail Log Template](/templates/ai-audit-trail-log) provides a ready-to-use format for capturing all of the above contemporaneously. ### Why this matters * Supports internal quality processes * Provides transparency for clients and stakeholders * Enables retrospective analysis of AI workflow effectiveness * Meets emerging expectations around AI transparency in regulated industries *** ## For agencies implementing AI workflows ### Integrate with existing QC processes AI workflows should sit within your existing quality control framework, not outside it: * Add AI-specific checkpoints to your review SOPs * Include AI workflow documentation in project trackers * Train reviewers on AI-specific failure modes * Do not create separate, lighter review tracks for AI-assisted content ### Client transparency * Proactively brief clients on how AI is used in their projects. Do not wait for them to ask * Follow client-specific AI policies where they exist. Some pharma companies have explicit restrictions on AI use in specific deliverable types. * Document AI use in project files at a level of detail that would satisfy a client audit. As a minimum: which deliverables, which workflow steps, which tools, who reviewed. * If a client asks "Was AI used in this deliverable?", the project team should be able to answer immediately and specifically. ### Team training * Train every writer using AI workflows on the specific failure modes covered in this playbook, not generic "AI limitations" slides, but the actual patterns: hallucinated p-values, merged study arms, dropped qualifiers, promotional framing of non-promotional evidence * Train reviewers to approach AI-assisted content differently from human-written content. AI errors are fluent and plausible. The review mindset is verification, not editorial polish. * Run periodic calibration exercises: give reviewers an AI-generated summary with planted errors and assess detection rates. This builds the skill that matters most. *** ## The bottom line A client, an MLR committee, or a regulatory body does not see a lower standard because AI was involved in production. The deliverable either meets the required standard or it does not. AI changes how content is produced. It does not change what "correct" looks like. The reviewer's job is not easier because AI was involved — it is different, and in some cases it requires more vigilance, not less, because AI-generated errors are fluent, plausible, and easy to skim past. *** *Last reviewed: 15 April 2026 · 6 min read* # Understanding AI Risk in Medical Writing Source: https://playbook.pharmatools.ai/principles/risk-levels Why AI risk varies across medical writing tasks — failure modes, risk factors, and why some tasks demand more human oversight than others. ## Core principle A structured paper summary and a regulatory safety narrative are both "AI-assisted writing." But the consequences of an undetected error are entirely different. Understanding *why* risk varies is the foundation for knowing *how much* review to apply. For a practical model that maps specific workflows to risk tiers and review expectations, see the [AI Risk Framework](/principles/ai-risk-framework). *** ## Why AI risk varies Three factors determine how risky it is to use AI for a given medical writing task: ### 1. Consequence of error What happens if the AI output is wrong and nobody catches it? * A transposed figure in an internal briefing is correctable. The same transposition in a CSR results section or a regulatory submission has downstream consequences that are far harder to unwind. * An oversimplified statement in a training deck may mislead an MSL. The same oversimplification in a patient-facing plain language summary may mislead a patient about their treatment. The higher the consequence, the more the task demands expert human verification rather than surface-level review. ### 2. Degree of interpretation Is the task mechanical (converting a table into prose) or interpretive (drawing conclusions from the data)? * Mechanical tasks have a verifiable right answer. The hazard ratio in the narrative either matches the source table or it does not. AI is well-suited to this, and the writer can verify the output directly. * Interpretive tasks require judgement. Whether a secondary endpoint result is "clinically meaningful," whether a safety signal warrants a different framing in the Discussion, whether a promotional claim crosses from scientific education into promotional territory — these are not tasks AI can perform reliably. The more interpretation a task requires, the less AI should contribute to the final wording. ### 3. Downstream reach How far does this output travel, and who relies on it? * An internal draft seen by one writer carries low downstream risk. Errors are contained and corrected locally. * A key message set that feeds into a slide deck, a leave piece, and a website has high downstream reach. An error in the message set propagates into every deliverable built from it. * A regulatory document submitted to a health authority has the broadest reach. The consequences of error extend beyond the organisation. The wider the downstream reach, the more important it is that the original AI-assisted output is thoroughly verified at the source. *** ## Common AI failure modes in medical writing These are the specific ways AI gets things wrong in medical writing. Recognising them is the first step in preventing them. ### Data transposition AI swaps values between treatment arms, confuses primary and secondary endpoints, or attributes a result to the wrong study population. This is the most common and most dangerous failure mode because the output reads fluently. A transposed hazard ratio looks correct unless you check the source. ### Meaning drift When AI adapts content for a different audience, condenses text, or rephrases a statement, the meaning can shift subtly. "May provide benefit" becomes "provides benefit." "In patients with moderate-to-severe disease" disappears. The output reads naturally, but the evidence no longer supports it. ### Unsourced content AI adds background context, disease epidemiology, or mechanism-of-action information from its training data rather than from the source documents you provided. This content may be accurate, outdated, or wrong — and there is no way to tell without checking an external reference. In source-grounded medical writing, every statement must trace to a specific document. ### Safety minimisation AI produces efficacy-forward content and treats safety data as secondary. A 15-slide deck may devote 12 slides to efficacy and 1 to safety. A summary may describe adverse events as "manageable" when the source data does not use that word. This creates documents that fail fair balance review and misrepresent the benefit-risk profile. ### Interpretive overreach AI states conclusions the data does not support. A non-inferiority trial is described as showing superiority. A trend (p=0.06) is presented as a significant result. A post-hoc subgroup finding is framed as a primary result. The AI does not understand the distinction; it generates text that sounds like valid scientific writing. ### False confidence in verification An automated tool returns no flags, and the reviewer treats this as confirmation that the document is accurate. Automated verification checks claims against cited references, but it does not check whether the right references were cited, whether important findings were omitted, or whether the context changes the meaning of a technically supported claim. *** ## What makes a task higher risk Use these questions to assess the risk level of any AI-assisted task: 1. **What happens if this output is wrong?** Internal rework, or external consequence? 2. **Does the task require interpretation?** Reporting a number, or drawing a conclusion from it? 3. **Who sees this output downstream?** One reviewer, or an external audience? 4. **Is the content regulated?** Internal use, or subject to promotional codes or regulatory requirements? 5. **Can the output be verified against a source?** A number that can be checked, or a judgement that cannot? If the answer to any of these points toward higher risk, increase the review intensity. When in doubt, default to more review rather than less. *** ## Why source grounding is the primary safeguard Most AI failure modes in medical writing share a common root: the output includes content that cannot be traced to a specific source document. Unsourced claims, training-data context, interpretive conclusions — all enter the document because the AI generated text that was not grounded in the materials it was given. [Source grounding](/principles/source-grounding) is the single most effective control against these failures. If every statement in a deliverable traces to a specific source, the failure modes above become detectable during review. If statements enter the document without a source, they become invisible risks. *** ## How review intensity follows risk The higher the risk, the more the review process needs to change — not just in rigour, but in kind. | Risk level | Review approach | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Lower risk | Verify key data points, check structure, refine language. Standard medical writing review. | | Moderate risk | Cross-check every claim against the source. Look specifically for meaning drift, dropped qualifiers, and shifted emphasis. | | Higher risk | Expert line-by-line verification. Check every number, every qualifier, every conclusion. Verify that no unsourced content has entered the document. | | Highest risk | Human leads the process. AI assists with specific mechanical tasks. Expert review and formal sign-off required. | For a detailed operational model that maps each playbook workflow to a specific risk tier and review expectation, see the [AI Risk Framework](/principles/ai-risk-framework). *** ## Related principles * [Human-in-the-Loop Decision Making](/principles/human-in-the-loop) — every deliverable has a named owner * [Source Grounding](/principles/source-grounding) — every claim traces to a cited source * [AI Risk Framework](/principles/ai-risk-framework) — the practical tier model and workflow mapping * [Review and Accountability](/principles/review-and-accountability) — sign-off protocols and audit trails *** *Last reviewed: 15 April 2026 · 7 min read* # Source Grounding Source: https://playbook.pharmatools.ai/principles/source-grounding Every claim traces to a specific source document. No content enters a deliverable from AI training data. ## Core principle Every AI-assisted output must be traceable to specific source materials. No unsourced claims. No invented data. No extrapolation beyond what the evidence supports. > Translation, not invention. *** ## What source grounding means In medical writing, the source material is the foundation. Whether it is a clinical study report, a published paper, a summary of product characteristics, or a set of congress abstracts, the source defines what can and cannot be said. AI does not know what the source says unless you give it the source. And even when you do, AI can: * Paraphrase in ways that subtly shift meaning * Fill gaps with plausible-sounding but unsupported statements * Merge findings from different sources without distinguishing them * Present interpretations as facts Source grounding is the practice of ensuring that every AI-assisted output remains anchored to the materials it was given, and that a human can trace every claim back to its origin. *** ## How to implement source grounding ### 1. Always provide source materials as input Never ask an AI to write about a topic from general knowledge. Always provide: * The specific paper, CSR section, or data source * The relevant prescribing information or SmPC * The approved key messages or brand messaging framework If you do not have a source, you do not have an input for an AI workflow. ### 2. Instruct the AI to cite its sources When using prompt patterns from this playbook, you will see instructions like: > *"Base your output only on the provided source. Do not include information from outside the source material. Cite specific sections, tables, or figures where relevant."* This is not a suggestion — it is a structural requirement. AI models will generate plausible content from training data if not explicitly constrained to the provided source. ### 3. Verify every claim against the original After receiving AI output: * Check each factual claim against the source document * Confirm that numerical data (endpoints, p-values, confidence intervals, sample sizes) are accurately reproduced * Verify that the AI has not combined findings from different study arms, timepoints, or populations * Confirm that conclusions match the source's stated conclusions, not the AI's interpretation ### 4. Flag and remove unsourced content If the AI has included any statement that cannot be traced to the provided source: * Remove it, or * Source it from an appropriate reference, or * Flag it for expert review Do not leave unsourced claims in a deliverable on the assumption that they are "probably correct." *** ## Common source grounding failures | Failure | Example | Impact | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Hallucinated data | AI inserts a p-value of 0.003 when the source reports p=0.03, or generates a confidence interval that does not appear anywhere in the paper | Fabricated statistical evidence enters a slide deck or manuscript draft. If not caught in review, it propagates through all downstream deliverables. | | Merged populations | AI combines ITT results (n=450) with per-protocol results (n=380) into a single statement, blurring the analysis population | Misleading efficacy representation. An MLR reviewer or journal editor will catch this — but only after wasted review cycles. | | Extrapolated conclusions | Source reports non-inferiority (HR 0.95; 95% CI 0.82–1.10). AI summary states the treatment "demonstrated improved outcomes" | Overstated claim that could become a compliance issue if it enters promotional materials. | | Invented context | AI adds a sentence about disease prevalence or mechanism of action from its training data, not from the provided source | Unsourced claims enter the deliverable. The writer may not notice because the information sounds plausible and relevant. | | Omitted qualifiers | Source states efficacy "in patients with moderate-to-severe disease (PASI ≥12 at baseline)." AI summary drops the qualifier. | Claim appears to apply to the full study population. In a promotional context, this broadens the claim beyond what the reference supports. | *** ## Source grounding and risk tiers The importance of source grounding increases with risk: * **Low-risk tasks** (summarisation, structuring): Source grounding ensures accuracy of the draft * **Medium-risk tasks** (key message extraction, audience adaptation): Source grounding prevents meaning drift during transformation * **High-risk tasks** (claim verification, compliance review, patient-facing content): Source grounding is the primary defence against harmful output *** ## For regulated content In regulated contexts (promotional materials, prescribing information supplements, regulatory submissions): * Source grounding is not just good practice — it is a requirement * Every claim must be supportable by a specific, cited reference * AI-assisted drafts must go through the same referencing and verification process as manually written content * The use of AI does not change the standard of evidence required *** ## Tools that support source grounding * **[RefCheckr](/tools/refcheckr)** — Closed-loop AI that verifies claims against cited references, rewrites any that don't match, and re-checks the rewrites for ABPI compliance * **[PosterLens](/tools/posterlens)** — Extracts structured information from scientific posters, providing a clear source for subsequent summarisation These tools support source grounding but do not replace it. A human reviewer must still confirm that the source-to-claim mapping is accurate and complete. *** *Last reviewed: 15 April 2026 · 5 min read* # Adaptation Prompts Source: https://playbook.pharmatools.ai/prompts/adaptation-prompts Prompt patterns for adapting medical content across audience levels, channels, and formats. Prompt patterns for adapting reviewed medical content across audience levels (specialist → generalist → patient), channels (slide deck → leave piece → email → web), and stakeholder types (HCPs, payers, internal teams, patients). *** ## 1. Audience-Level Adaptation **Use with:** [Adapt for different audiences](/workflows/adapt-for-different-audiences) and LLMentor ``` You are a medical writing assistant specialising in audience adaptation. Source content: [INSERT REVIEWED CONTENT] Original audience: [SPECIFY] Target audience: [SPECIFY — be specific, e.g., "community pharmacists" not "HCPs"] Adapt the content by: - Adjusting language complexity for the target audience - Shifting emphasis to match audience priorities - Preserving all factual accuracy - Retaining safety information Rules: - Do not add information not in the source - Do not remove safety data - If simplifying a medical term, ensure the simplified version is accurate - Flag areas where simplification may change meaning with [REVIEW] - Retain data points unless the format explicitly excludes them ``` *** ## 2. Patient-Facing Adaptation **Use with:** [Create a plain language summary](/workflows/create-plain-language-summary), Patiently AI, and PLS Generator ``` You are a medical writing assistant specialising in patient communications. Source content (written for healthcare professionals): [INSERT HCP-LEVEL CONTENT] Create a patient-friendly version that: - Uses plain language (target: 8th grade reading level) - Explains medical terms in simple words - Uses short sentences (15–20 words average) - Uses short paragraphs (2–3 sentences) - Explains why things matter to the patient, not just what they are Rules: - Do not provide medical advice - Include side effects and safety information — do not omit them to simplify - Do not overstate benefits or understate risks - If the source says "statistically significant improvement," explain what this means for patients in practical terms - Do not add information not in the source - Flag any section where simplification was particularly difficult with [REVIEW — simplified] ``` *** ## 3. Channel Format Adaptation **Use with:** [Repurpose content across channels](/workflows/repurpose-content-across-channels) ``` You are a medical communications content adaptation assistant. Source content: [INSERT APPROVED CONTENT] Source format: [SPECIFY — e.g., 20-slide HCP deck] Target format: [SPECIFY — e.g., two-page leave piece] Target audience: [SPECIFY if different from source] Adapt the content to fit the target format: - Restructure for the target format's conventions - Adjust length to meet format requirements: [SPECIFY length/word count] - Prioritise key messages: [LIST priority order if needed] Rules: - Preserve all factual claims exactly - Retain safety information - Maintain reference citations - Do not add information not in the source - If significant content must be cut, flag with [REVIEW — content reduced] ``` *** ## 4. Complexity Reduction (Specialist to Generalist) **Use when:** Adapting specialist-level content for a broader HCP audience. ``` You are a medical writing assistant. Adapt the following specialist-level content for a general practitioner audience. Source content (written for [SPECIFY specialty]): [INSERT CONTENT] Target audience: General practitioners / primary care physicians Adaptation approach: - Replace specialist terminology with terms familiar to GPs where possible - Add brief explanations for specialist concepts that must be retained - Shift emphasis from mechanism and detailed pharmacology to practical clinical considerations - Highlight what is relevant for primary care decision-making - Maintain clinical accuracy throughout Rules: - Do not "dumb down" — GPs are medically trained, just not specialists - Retain key data that supports clinical decision-making - Preserve safety information in full - Do not add treatment recommendations not in the source - Note where referral to specialist care is relevant ``` *** ## 5. Executive / Stakeholder Briefing **Use when:** Creating a concise briefing for non-clinical stakeholders from detailed medical content. ``` You are a medical communications assistant. Create an executive briefing from the following detailed medical content. Source content: [INSERT DETAILED CONTENT] Target audience: [SPECIFY — e.g., brand team, senior leadership, commercial team, payer account manager] Target length: [SPECIFY — e.g., one page, 300 words, 5 bullet points] Structure: - Bottom line / key takeaway (one sentence) - What the evidence shows (3–5 bullet points) - What this means for [the brand / the strategy / the market] (2–3 sentences) - Key considerations or caveats (bullet points) Rules: - Accuracy is non-negotiable, even in a brief summary - Do not overstate findings to make them sound more impressive - Include relevant caveats or limitations - Do not add strategic recommendations that are not supported by the evidence - Clearly label any interpretation as distinct from the data itself ``` *** ## Customisation notes * **Regulatory context:** Always note when adaptation changes the regulatory classification of the content (e.g., scientific to promotional, HCP to patient) * **Therapeutic area:** Some TAs have specific terminology conventions at different audience levels — adjust accordingly * **Brand guidelines:** If a brand messaging framework exists, ensure adapted content aligns with approved messages *** **Related workflows:** * [Adapt for different audiences](/workflows/adapt-for-different-audiences) * [Create a plain language summary](/workflows/create-plain-language-summary) * [Repurpose content across channels](/workflows/repurpose-content-across-channels) # Outlining Prompts Source: https://playbook.pharmatools.ai/prompts/outlining-prompts Prompt patterns for building content outlines and structures for medical communications deliverables. Prompt patterns for building content outlines and structures for common med comms deliverables: slide decks, monographs, manuscripts, training modules, and multi-channel content plans. *** ## 1. Standard Content Outline **Use with:** [Build a content outline](/workflows/build-content-outline) ``` You are a medical writing assistant. Create a content outline for the following deliverable. Deliverable type: [e.g., HCP slide deck, monograph, manuscript draft, training module] Target audience: [SPECIFY] Purpose: [SPECIFY] Approximate length/scope: [SPECIFY] Key messages: [INSERT KEY MESSAGES] For each section, provide: - Section heading - One-sentence content description - Which key messages are covered - Suggested length (words, slides, or pages) Rules: - Every section must have a clear purpose - Include a safety/tolerability section unless explicitly excluded - Ensure logical narrative flow between sections - Flag sections where you are uncertain about placement ``` *** ## 2. Slide Deck Outline **Use when:** Building a presentation structure. ``` You are a medical writing assistant. Create a slide deck outline. Topic: [SPECIFY] Audience: [SPECIFY] Target slide count: [SPECIFY] Purpose: [e.g., advisory board discussion, sales training, medical education] Key messages to incorporate: [INSERT KEY MESSAGES] For each slide: - Slide number - Title (concise, action-oriented where appropriate) - Key content point (one sentence) - Supporting data or visual element (describe what would appear on the slide) - Notes for speaker (one sentence) Rules: - One key message per slide maximum - Include a clear narrative arc from problem to evidence to implications - Include safety data where relevant - Do not overload slides — each should have one main point - Include appropriate back-up slides for anticipated questions ``` *** ## 3. Publication Outline **Use when:** Structuring a manuscript or publication draft. ``` You are a medical writing assistant. Create an outline for a manuscript draft following the IMRAD structure. Study: [BRIEF DESCRIPTION] Target journal type: [SPECIFY — e.g., high-impact general, specialty, open access] Key findings: [BRIEF SUMMARY] Outline sections: - Title (draft, concise, informative) - Abstract structure (Background, Methods, Results, Conclusions) - Introduction (3–4 paragraphs: context, gap, rationale, objective) - Methods (key subsections based on the study design) - Results (ordered by primary, secondary, exploratory endpoints) - Discussion (key findings, context, strengths, limitations, conclusions) For each section: - Content scope (what to include) - Approximate word count - Key references or data to include Rules: - Follow reporting guidelines for the study type (e.g., CONSORT, STROBE, PRISMA) where applicable - Results should present data in the order of the study objectives - Discussion should address limitations honestly - Do not overinterpret results in the discussion outline ``` *** ## 4. Multi-Channel Content Plan **Use with:** [Repurpose content across channels](/workflows/repurpose-content-across-channels) ``` You are a medical communications planning assistant. Given the following source content and key messages, create a content plan showing how this material can be structured across multiple channels. Source content summary: [INSERT SUMMARY OF APPROVED SOURCE CONTENT] Key messages: [INSERT KEY MESSAGES] Channels to plan for: [LIST CHANNELS — e.g., HCP detail aid, medical education slide deck, patient website, congress booth materials, email newsletter] For each channel: - Recommended format and length - Which key messages to prioritise - Content structure outline - Specific considerations for the channel (regulatory, audience, format constraints) - What source content maps to this channel Rules: - All channel content must be traceable to the approved source - Note where different channels may require different regulatory treatment - Do not add messages that are not in the approved key message set - Identify channels where additional development or review will be needed ``` *** ## 5. Training Module Outline **Use when:** Creating educational or training content for internal teams or HCPs. ``` You are a medical education content developer. Create an outline for a training module. Topic: [SPECIFY] Audience: [SPECIFY — e.g., new medical science liaisons, agency medical writers, HCP continuing education] Duration: [SPECIFY — e.g., 30-minute e-learning, half-day workshop] Learning objectives: [LIST 3–5 OBJECTIVES] Structure the outline with: - Module sections (logical learning progression) - Content for each section (key concepts, data, examples) - Knowledge check points (where to assess understanding) - Key takeaways for each section Rules: - Build from foundational concepts to application - Include clinical context and real-world relevance - Do not include unsubstantiated claims in educational content - Reference source materials for all clinical data used ``` *** ## Customisation notes * **Therapeutic area:** Add TA-specific section requirements (e.g., mechanism of action for a new MOA, treatment landscape for a competitive market) * **Client preferences:** Adjust outline depth and structure to match client or agency conventions * **Regulatory context:** Flag sections that will require compliance review based on the content type and intended use *** **Related workflows:** * [Build a content outline](/workflows/build-content-outline) * [Repurpose content across channels](/workflows/repurpose-content-across-channels) # Review Prompts Source: https://playbook.pharmatools.ai/prompts/review-prompts Prompt patterns for QC, verification, and pre-submission review of medical communications content. Prompt patterns for QC, verification, and pre-submission review of medical communications content. Each pattern targets a specific review task: reference checking, compliance screening, source grounding, safety data completeness, cross-document consistency, readability assessment, and voice authenticity. These prompts are review support tools — they inform the reviewer's work, they do not substitute for it. *** ## 1. Claim-to-Reference Verification **Use with:** [Verify claims against references](/workflows/verify-claims-against-references) and RefCheckr ``` You are a medical writing QC assistant. Verify each claim in the document against its cited reference. For each claim: 1. Quote the claim 2. Identify the cited reference 3. Find the supporting evidence in the reference 4. Assess: SUPPORTED / PARTIALLY SUPPORTED / NOT SUPPORTED / CANNOT VERIFY 5. Explain any discrepancy 6. Flag numerical mismatches 7. Flag language that is stronger than the reference supports Document: [INSERT DOCUMENT WITH REFERENCE CITATIONS] References: [INSERT FULL TEXT OF EACH CITED REFERENCE, LABELLED] Rules: - Compare strictly against the cited reference, not general knowledge - If the reference does not contain relevant information, mark NOT SUPPORTED - Note missing qualifiers (subgroup, post-hoc, etc.) ``` *** ## 2. Promotional Compliance Pre-Screen **Use with:** [Check promotional compliance](/workflows/check-promotional-compliance) and MedCheckr ``` You are a medical communications compliance review assistant. Pre-screen the following content for potential promotional compliance issues. Content: [INSERT CONTENT] Product: [SPECIFY] Approved indication(s): [SPECIFY] Audience: [SPECIFY] Channel: [SPECIFY] Check for: 1. Superlative or comparative claims needing substantiation 2. Language implying efficacy beyond what references support 3. Off-label implications 4. Insufficient safety information relative to efficacy claims 5. Emotive or promotional language inappropriate for the content type 6. Claims beyond the approved indication For each issue: quote the text, describe the concern, suggest revision type, rate LOW / MEDIUM / HIGH. Note: This is pre-screening, not compliance clearance. Formal MLR review is still required. ``` *** ## 3. Source Grounding Check **Use when:** Verifying that AI-generated content stays within the bounds of provided source materials. ``` You are a medical writing QC assistant. Check whether the following content is fully grounded in the provided source material. Content to check: [INSERT AI-GENERATED OR AI-ASSISTED CONTENT] Source material: [INSERT SOURCE DOCUMENT] For each paragraph or claim in the content: 1. Is it supported by specific content in the source? (YES / NO / PARTIAL) 2. If YES, cite the relevant section of the source 3. If NO, flag as potentially unsourced — this may be AI-generated content from training data 4. If PARTIAL, explain what is supported and what is not Also check: - Are there any data points in the content that do not appear in the source? - Are there any conclusions in the content that go beyond the source's stated conclusions? - Has any context or background been added that is not from the source? Rules: - Be thorough. Flag anything that cannot be traced to the source. - It is better to over-flag than to miss unsourced content. ``` *** ## 4. Safety Information Completeness Check **Use when:** Verifying that safety information is adequately represented in a deliverable. ``` You are a medical writing QC assistant focused on safety data representation. Deliverable: [INSERT DELIVERABLE] Source safety data: [INSERT SAFETY SECTIONS FROM SOURCE DOCUMENTS] Check: 1. Are the most common adverse events reported in the source included in the deliverable? 2. Are serious adverse events included? 3. Are discontinuations due to adverse events mentioned? 4. Is the safety data proportionate to the efficacy content? (i.e., does the deliverable give fair representation to both benefits and risks?) 5. Are safety qualifiers preserved? (e.g., timing, severity grading, relationship to treatment) 6. For patient-facing content: is safety information presented in understandable language? Flag any: - Safety findings in the source that are absent from the deliverable - Safety information that appears minimised compared to its prominence in the source - Missing context that could affect how a reader understands the safety profile ``` *** ## 5. Consistency Check (Multi-Document) **Use when:** Checking consistency across multiple deliverables from the same evidence base. ``` You are a medical writing QC assistant. Check the following documents for consistency. Document A: [INSERT — e.g., slide deck] Document B: [INSERT — e.g., leave piece] Document C: [INSERT — e.g., website content] Check for: 1. Are the same data points reported consistently across documents? (same numbers, same phrasing of results) 2. Are key messages consistent across documents? 3. Are there any claims in one document that contradict or conflict with another? 4. Is safety information consistent across all documents? 5. Are references consistent? For each inconsistency found: - Quote the relevant text from each document - Describe the inconsistency - Note which document (if any) matches the source material Rules: - Flag all inconsistencies, even minor ones - Differences in emphasis or depth between channels are expected — flag only factual inconsistencies ``` *** ## 6. Plain Language Readability Check **Use with:** [Create a plain language summary](/workflows/create-plain-language-summary) ``` You are a health literacy specialist. Review the following plain language summary for readability and accessibility. Content: [INSERT PLAIN LANGUAGE SUMMARY] Target audience: [SPECIFY] Target reading level: [SPECIFY] Check: 1. Sentence length — average should be 15–20 words. Flag sentences over 25 words. 2. Medical jargon — flag any unexplained technical terms 3. Passive voice — flag and suggest active alternatives 4. Paragraph length — should be 2–3 sentences maximum 5. Structure — are headings clear and helpful? 6. Explanations — are medical concepts explained in terms the audience would understand? 7. Tone — is it respectful, clear, and non-condescending? For each issue: - Quote the text - Explain the readability concern - Suggest a revision Note: This checks readability, not medical accuracy. Accuracy must be verified separately against the source. ``` *** ## 7. Voice and Authenticity Check **Use when:** Reviewing AI-assisted content for generic AI register before it reaches a client or external audience. See [the Description–Discernment loop](/principles/description-discernment) for why this check matters. ``` You are an editorial reviewer. Compare the following draft against the reference example(s) of approved content and flag where the draft departs from the established voice. Draft: [INSERT DRAFT] Approved reference example(s): [INSERT ONE OR MORE APPROVED DELIVERABLES OF THE SAME TYPE] Style rules (if available): [INSERT HOUSE OR CLIENT STYLE RULES] Check for: 1. Generic AI register — filler transitions ("moreover", "furthermore"), tidy triplet constructions, padded hedging 2. Vocabulary drift — near-synonyms substituted for terminology the reference consistently uses 3. Register mismatch — more formal, more promotional, or more hedged than the reference 4. Sentence rhythm — noticeably longer or more uniform sentences than the reference 5. Empty emphasis — intensifiers ("robust", "significant" used non-statistically, "groundbreaking") absent from the reference For each issue: quote the draft text, quote or describe the reference pattern it departs from, and suggest a revision. Note: This checks voice, not accuracy. The reviewer decides which flags matter — the reference examples define "correct", not the model's own preferences. ``` *** ## Customisation notes * **Combine prompts as needed:** For a final review, you might run the source grounding check, safety completeness check, and compliance pre-screen in sequence * **Adjust rigour to risk tier:** Low-risk content may need only a source grounding check; high-risk content should use multiple review prompts * **Document the review:** Record which review prompts were used and what was found — this supports audit trails *** **Related workflows:** * [Verify claims against references](/workflows/verify-claims-against-references) * [Check promotional compliance](/workflows/check-promotional-compliance) * [Final human review](/workflows/final-human-review) * [The Description–Discernment loop](/principles/description-discernment) — briefing and iteration principles behind these review patterns # Source Analysis Prompts Source: https://playbook.pharmatools.ai/prompts/source-analysis-prompts Prompt patterns for extracting, structuring, and summarising clinical and scientific source materials. Prompt patterns for extracting, structuring, and summarising clinical and scientific source materials. Each pattern is designed for a specific source analysis task. Customise the therapeutic area, output format, and focus areas for your project. *** ## 1. Structured Paper Summary **Use with:** [Summarise a source paper](/workflows/summarise-source-paper) ``` You are a medical writing assistant. Summarise the following published paper into a structured format. Sections: - Citation - Study design and objective - Population (key criteria, sample size) - Primary endpoint and results - Key secondary endpoints and results - Safety findings - Authors' conclusions - Limitations Rules: - Use only information from the provided paper - Reproduce all data points exactly as stated - Label subgroup or post-hoc results explicitly - Do not interpret beyond the authors' stated conclusions - Flag uncertain data points with [VERIFY] Paper: [INSERT FULL TEXT] ``` *** ## 2. Focused Data Extraction **Use when:** You need specific data points from a paper, not a full summary. ``` You are a medical writing assistant. Extract the following specific data points from the provided paper. Data points needed: - Primary endpoint: definition, result, statistical significance - Key secondary endpoints: definitions, results, statistical significance - Safety: most common adverse events (≥5%), serious adverse events, discontinuations due to AEs - Population: total enrolled, total analysed (ITT and PP if applicable), key demographics Present the data in a table format where possible. Cite the specific section, table, or figure for each data point. Rules: - Extract only what is stated in the paper - If a requested data point is not reported, state "Not reported" - Distinguish between ITT, mITT, and per-protocol populations - Include confidence intervals where reported Paper: [INSERT FULL TEXT] ``` *** ## 3. Comparative Summary (Two Papers) **Use when:** Summarising two papers on the same topic or comparing study results. ``` You are a medical writing assistant. Create a comparative summary of the following two papers. Structure: - Brief summary of each study (design, population, primary endpoint) - Comparison table: key endpoints side by side - Key differences in design, population, or methodology - Key differences in results - Authors' conclusions compared Rules: - Present each study's results as reported. Do not make cross-study statistical comparisons. - Note differences in study design that make direct comparison difficult - Do not state that one study is "better" or "stronger" than the other - Flag any areas where comparison is not appropriate due to design differences Paper 1: [INSERT FULL TEXT] Paper 2: [INSERT FULL TEXT] ``` *** ## 4. Safety-Focused Extraction **Use when:** The project requires detailed safety data extraction. ``` You are a medical writing assistant specialising in safety data. Extract and summarise the safety findings from the following paper. Structure: - Overall safety population and exposure - Most common adverse events (present all reported, with frequencies) - Serious adverse events (with frequencies) - Adverse events leading to discontinuation - Deaths (if reported) - Adverse events of special interest (if identified in the study) - Authors' safety conclusions Rules: - Report all adverse event data as presented. Do not selectively report. - Include both treatment and comparator arm data - Include confidence intervals and p-values where reported - Note the timeframe for safety reporting - If safety data is limited (e.g., short follow-up), note this Paper: [INSERT FULL TEXT] ``` *** ## 5. Poster Content Extraction **Use with:** [Prepare a congress or poster summary](/workflows/prepare-congress-or-poster-summary) and PosterLens ``` You are a medical writing assistant. Extract and structure the key information from the following scientific poster. Structure: - Poster reference (authors, title, congress, number) - Background / rationale - Study design and objective - Population - Key results (efficacy) - Safety results (if presented) - Authors' conclusions Rules: - Extract only what is on the poster - If data is presented in figures, extract the key values and note they are from figures - If safety data is not on the poster, state "Safety data not presented on this poster" - Flag any data points that are unclear with [VERIFY] Poster content: [INSERT POSTER TEXT OR EXTRACTION] ``` *** ## Customisation notes * **Therapeutic area:** Add specific instructions for the relevant TA (e.g., "For oncology, include ORR, PFS, and OS if reported") * **Output length:** Specify target word count or format constraints * **Focus areas:** Add or remove sections based on what the project needs * **Multiple sources:** For literature reviews with many papers, use the Focused Data Extraction pattern for consistency across sources *** **Related workflows:** * [Summarise a source paper](/workflows/summarise-source-paper) * [Extract key messages](/workflows/extract-key-messages) * [Prepare a congress or poster summary](/workflows/prepare-congress-or-poster-summary) # Start Here Source: https://playbook.pharmatools.ai/start Where to begin based on your role — recommended reading order and starting workflows for medical writers, agencies, and pharma teams. The playbook covers workflows at different risk levels. Where you start depends on what you do. **Prefer to read offline?** [Download the playbook as a PDF](https://playbook-counter.pharmatools.workers.dev/download) — the principles in brief, a one-page card for every workflow, and the checklists, in about 40 pages, rebuilt automatically on each update. Every page of the site, including the prompt patterns and worked examples, is in the [complete reference PDF](https://github.com/nickjlamb/medical-writing-ai-playbook/releases/download/latest/Medical-Writing-AI-Playbook-Complete-Reference.pdf). ### Read first 1. [Understanding AI Risk](/principles/risk-levels): which of your deliverables fall into which tier 2. [Human-in-the-Loop](/principles/human-in-the-loop): the review framework that applies to every AI-assisted output ### Start with these workflows 1. [Summarise a Source Paper](/workflows/summarise-source-paper) (low risk, mirrors work you already do daily) 2. [Extract Key Messages](/workflows/extract-key-messages) (medium risk, accelerates early-stage content development) 3. [Build a Content Outline](/workflows/build-content-outline) (low risk, works for any deliverable type) ### Before anything leaves your desk [Final Human Review](/workflows/final-human-review): structured QC checklist for AI-assisted content ### Key tools * [RefCheckr](/tools/refcheckr) — closed-loop claim verification and rewrite for multi-reference documents * [PosterLens](/tools/posterlens) — rapid congress poster extraction * [PubCrawl](/tools/pubcrawl) — literature search and evidence discovery ### What this gives you A documented process you can stand behind. When a client asks how you used AI, you can show the workflow you followed, the review steps you completed, and the checklist you used, not just "I used AI to help draft this." ### Read first 1. All four [Principles](/principles/human-in-the-loop) — assess how they map to your SOPs and QC processes 2. [Review and Accountability](/principles/review-and-accountability) — sign-off protocols and audit trails ### Match workflows to your project types * **Publication support:** [Summarise a Paper](/workflows/summarise-source-paper) → [Key Messages](/workflows/extract-key-messages) → [Content Outline](/workflows/build-content-outline) * **Promotional content:** [Content Outline](/workflows/build-content-outline) → [Compliance Check](/workflows/check-promotional-compliance) → [Verify Claims](/workflows/verify-claims-against-references) * **Congress coverage:** [Poster Summary](/workflows/prepare-congress-or-poster-summary) → [Repurpose Across Channels](/workflows/repurpose-content-across-channels) * **Patient-facing:** [Plain Language Summary](/workflows/create-plain-language-summary) → [Final Review](/workflows/final-human-review) ### Key tools for your team * [RefCheckr](/tools/refcheckr) — closed-loop verification and rewrite of references across large documents * [MedCheckr](/tools/medcheckr) — compliance screening to reduce MLR rejection cycles * [LLMentor](/tools/llmentor) — multi-audience adaptation from a single approved source ### For client conversations The [Understanding AI Risk](/principles/risk-levels) framework and [Compliance Check](/workflows/check-promotional-compliance) workflow give you the credibility documents you need when briefing clients on AI-assisted work. ### Start here if you need to set expectations with agencies 1. [Understanding AI Risk](/principles/risk-levels) — the framework for evaluating what AI involvement is appropriate for your content types 2. [Review and Accountability](/principles/review-and-accountability) — maps to your existing content approval processes ### Key workflows to review * [Compliance Check](/workflows/check-promotional-compliance) — how compliance pre-screening works in AI-assisted workflows * [Verify Claims](/workflows/verify-claims-against-references) — how reference accuracy is maintained * [Final Review](/workflows/final-human-review) — the QC framework before deliverables reach your review queue ### Use this playbook to * Define what you expect to see documented when AI is involved in your content * Benchmark agency AI practices against a structured framework * Map review requirements by risk tier to your internal approval processes ### Key tools * [RefCheckr](/tools/refcheckr) — closed-loop claim-to-reference verification and rewrite * [MedCheckr](/tools/medcheckr) — compliance screening before formal review *** ## Reading order Regardless of role, this is a practical path through the playbook: Read [Human-in-the-Loop](/principles/human-in-the-loop) and [Source Grounding](/principles/source-grounding). These two principles define the boundaries for every workflow. Read [Understanding AI Risk](/principles/risk-levels). Every workflow has a tier. The tier determines what AI can do and what review is required. Start with [Summarise a Source Paper](/workflows/summarise-source-paper). It demonstrates the full workflow structure with the lowest stakes. Move to [Extract Key Messages](/workflows/extract-key-messages) and [Adapt for Audiences](/workflows/adapt-for-different-audiences). Medium risk, more editorial judgement required. Every AI-assisted deliverable goes through [Final Human Review](/workflows/final-human-review) before it ships. # AI Audit-Trail Log Template Source: https://playbook.pharmatools.ai/templates/ai-audit-trail-log Contemporaneous log of AI use across a project — supports disclosure, sponsor audits, and EU AI Act documentation. A contemporaneous log of AI use across a project. The same record feeds journal disclosure, sponsor audits, and EU AI Act documentation. Build it as you write — reconstruction at submission time is unreliable. For the principles behind this template, see [Review and Accountability](/principles/review-and-accountability) and [Declaring AI Use](/principles/declaring-ai-use). ## How to use this template * **Start the log at project kickoff,** not at submission. "What tool did I use in week 2?" three months later doesn't survive audit. * **One log per project, deliverable group, or workstream** — whatever your client or sponsor SOP defines as a unit. * **Log every non-trivial AI use.** Spell-check is generally exempt; everything else benefits from capture. * **Store the log in the shared project location,** not in a personal note. Audit trails that aren't shared aren't auditable. * **Retain per the longest applicable timeframe** (sponsor SOP, journal author guidelines, regulatory archiving). Default is the project's record-retention period. *** ## Project header Fill in once at kickoff. Update if scope or ownership changes. | Field | Value | | -------------------------- | ------------------------------------------------------------------------------ | | **Project name** | \[e.g., Drug X Phase 3 primary publication] | | **Deliverable type** | \[e.g., Primary publication / regulatory submission / promotional leave-piece] | | **Sponsor / client** | \[Sponsor or client name] | | **Agency (if applicable)** | \[Agency name] | | **SOP reference** | \[e.g., ABC-SOP-0042 v3.1] | | **Project lead / owner** | \[Name and role] | | **Accountable reviewer** | \[Name and role — the named human responsible for sign-off] | | **Log start date** | \[YYYY-MM-DD] | | **Log location** | \[Folder path or project file where this log is stored] | *** ## AI use entries One row per discrete AI use. Add rows as you go. | Date | Deliverable / section | Tool + version | Scope of use | Source inputs | Reviewer | Outcome | Notes | | ---------- | ----------------------------- | ----------------------- | ---------------------------------- | --------------------------------------------- | -------- | ---------------------------------- | ----------------------------------------------------------------- | | 2026-05-04 | Manuscript Discussion section | Claude Opus 4.7 | Drafting (initial) | Trial CSR sections 11–14; key messages doc v2 | A. Smith | Accepted with edits | Two paragraphs rewritten to add HR confidence intervals | | 2026-05-05 | Manuscript Methods section | Claude Sonnet 4.6 | Editing for clarity | Existing draft section | A. Smith | Accepted as-is | Light copy-edits only | | 2026-05-05 | All references (40) | RefCheckr (closed-loop) | Reference verification and rewrite | Source PDFs of all cited references | A. Smith | 3 rewrites accepted, 1 manual edit | Closed-loop output reviewed; one claim required manual rephrasing | | 2026-05-08 | Visual abstract | Nano Banana 2 | Concept image generation | Brief prompt + key messages | M. Jones | Accepted | Caption updated to flag conceptual nature | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add rows as needed. Keep entries one-line where possible; expand in the Notes column. ### Field guidance * **Date** — when the AI was used, not when the entry was written. * **Deliverable / section** — be specific enough that a reviewer can locate the work product. "Manuscript" alone is not specific; "Manuscript Discussion section" is. * **Tool + version** — always include both. "Claude" without a version is undefined when reviewed six months later. * **Scope of use** — one of: Drafting, Editing, Translation, Verification, Synthesis, Image generation, Other. Match the categories used in [Declaring AI Use](/principles/declaring-ai-use). * **Source inputs** — what was given to the AI? Source documents, prompts, prior drafts. * **Reviewer** — the named human who checked the AI output. A blank reviewer field means an unaccountable AI use; the row is not yet complete. * **Outcome** — Accepted as-is / Accepted with edits / Rejected / Pending review. Clear all pending entries before sign-off. * **Notes** — brief context: what changed, what didn't, what was flagged. *** ## Sign-off block Complete at deliverable finalisation. | Field | Value | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Final deliverable version** | \[Version number / file name] | | **All log entries reviewed** | \[Yes / No] | | **All pending entries cleared** | \[Yes / No] | | **Disclosure language drafted** | \[Yes / No — link to specific snippet from the [Disclosure Language Template](/templates/disclosure-language) if used] | | **Final reviewer name** | \[Name and role] | | **Sign-off date** | \[YYYY-MM-DD] | *** ## What this log supports A single log feeds four downstream uses: * **Journal disclosure** — entries become the basis for the AI-use statement, with the [Disclosure Language Template](/templates/disclosure-language) as the wording reference. * **Sponsor or client audit** — when asked "What AI was used on this deliverable?", the log is the answer. Without it, you reconstruct from memory under pressure. * **EU AI Act documentation** — the contemporaneous record of tool use, scope, and reviewer aligns with Article 50 transparency obligations and the general documentation expectations covered in [AI Regulation in Pharma](/principles/ai-regulation). * **Internal QC retrospectives** — patterns emerge across projects: which tools cause the most rework, which scope of use produces the cleanest output, where reviewers spend their time. *** ## Common mistakes * **Building the log at submission.** "I'll remember" is not a strategy. Weeks of AI use cannot be reconstructed reliably; entries get missed and the disclosure is weaker than it should be. * **Logging only successful uses.** Rejected and revised entries matter — they show review was active, not rubber-stamped. * **Vague tool names.** "ChatGPT" doesn't tell a reviewer in 18 months whether it was GPT-4 or GPT-5. Always include version. * **Missing the reviewer column.** A log entry without a reviewer name is an unaccountable AI use. Complete the row before treating the entry as logged. * **Storing the log in a personal note.** If a colleague needs the log during your absence and can't find it, the audit trail isn't auditable. Store in the shared project location. *** ## Related * [Review and Accountability](/principles/review-and-accountability) — the principle this log operationalises * [Declaring AI Use](/principles/declaring-ai-use) — the disclosure principle the log feeds * [Disclosure Language Template](/templates/disclosure-language) — ready-to-paste wording derived from the log * [AI Regulation in Pharma](/principles/ai-regulation) — the regulatory expectations this log helps meet *** *Last reviewed: 4 May 2026 · 6 min read* # Disclosure Language Template Source: https://playbook.pharmatools.ai/templates/disclosure-language Ready-to-use AI disclosure wording for manuscripts, posters, regulatory documents, and other medical writing deliverables. Each snippet below is a starting point, not a finished line. Edit the bracketed variables — tool name, version, manufacturer, dates, scope, reviewer name — to match your project before submitting. The wording aligns with current ICMJE-style expectations and most major journal policies; for the principle behind these templates, see [Declaring AI Use](/principles/declaring-ai-use). **Check permission before you check wording.** Some uses are now prohibited outright, not merely disclosable. As of August 2026, JAMA Network does not permit AI-generated or AI-formatted **references**, AI-drafted **Opinion articles, Letters to the Editor or online Comments**, or AI-created **clinical images, illustrations, video or audio**. A well-drafted disclosure does not make a prohibited use submittable. See [Declaring AI Use](/principles/declaring-ai-use) for the current policy table. ## How to use this page * **Check the prohibitions first.** Confirm the use is permitted at your target venue before you reach for wording. * **Pick the scenario** that matches your deliverable. * **Edit every bracketed variable.** A disclosure with `[Author X]` left in is a disclosure that doesn't survive contact with reality. * **Always name a human.** A disclosure without a named, accountable reviewer is not a disclosure — it is a description. * **Record dates and manufacturer.** JAMA Network now asks for the software name, version, manufacturer, dates of use, and which portions of the content were affected. Capture these as you work; reconstructing them later is unreliable. * **Match the venue.** Default snippets here align with current ICMJE-style standards. Always check the journal's, regulator's, or sponsor's specific policy at submission. * **When in doubt, declare more, not less.** Underdisclosure is the higher-risk position. *** ## Manuscript — AI drafted a section *Use in the Methods or Acknowledgments section, per the journal's policy.* > \[Tool name and version, e.g., Claude Opus 4.7] (\[Manufacturer, e.g., Anthropic]) was used on \[date(s) of use] to generate an initial draft of the \[section, e.g., Discussion]. The output was reviewed, edited, and verified against the cited sources by \[Author name(s)], who take full responsibility for the accuracy and integrity of the final content. The tool was not used to perform analyses, generate data, or generate, format, or select references. *** ## Manuscript — AI used for editing or proofing only *Use in the Acknowledgments section.* > \[Tool name and version, e.g., Claude Sonnet 4.6] (\[Manufacturer]) was used on \[date(s) of use] to assist with \[editing for clarity / proofreading / language polishing] of human-written drafts. No content was generated by the tool. \[Author name(s)] reviewed all suggestions and take full responsibility for the accuracy and integrity of the final manuscript. *Note: several journals, JAMA Network among them, permit grammar, spelling and language tools only on text a human wrote first. Basic spell-check and grammar correction generally needs no disclosure; substantive editing does.* *** ## Manuscript — AI used for translation *Use in the Methods section.* > The manuscript was originally drafted in \[source language] and translated into \[target language] using \[Tool name and version]. The translation was reviewed and corrected by \[Author name(s) or qualified translator], who confirm the translated content accurately reflects the original. *** ## Manuscript — AI used for reference verification *Use in the Methods or Acknowledgments section. Note the distinction: **verifying** existing references against sources is a QC activity and remains acceptable. **Generating or formatting** references with AI is prohibited by JAMA Network and discouraged elsewhere — build the reference list in a standard reference manager.* > The reference list was compiled in \[reference manager, e.g., EndNote / Zotero]. Cited references were subsequently verified against their source documents using \[Tool name and version, e.g., RefCheckr] on \[date(s) of use]. All claims and numerical data were cross-checked against the cited sources. No AI tool was used to generate or format references. \[Author name(s)] reviewed and confirmed the verification output and take responsibility for the completeness, accuracy, and integrity of the final reference set. *** ## Manuscript — AI used for figure or visual abstract generation *Use in the figure caption and the Methods section. Many journals restrict AI for scientific figures — check the journal's specific policy before use. JAMA Network does not permit AI-created or AI-manipulated **clinical** images, illustrations, video or audio unless they form part of a disclosed research design; this snippet covers conceptual visuals only.* > The \[visual abstract / concept figure / illustration] was generated using \[Tool name and version, e.g., Nano Banana 2] (\[Manufacturer]) on \[date(s) of use] from a prompt describing \[content]. The image was reviewed for accuracy by \[Author name(s)] and is intended as a conceptual illustration, not as a clinical image or primary scientific data. *** ## Manuscript — existing scientific image adjusted with software *Use in the figure legend. Adjustments must be applied uniformly to the whole image and must not selectively highlight, obscure, or misrepresent any clinical or scientific element. Retain the original unedited files for editorial review.* > \[Brightness / contrast / colour] was adjusted uniformly across the entire image using \[Software name and version]. \[Where applicable: non-clinically-relevant background was replaced with a solid colour.] No clinical or scientific elements were selectively enhanced, obscured, or removed. Original unedited images are available for editorial review. *** ## Conference abstract or poster *Use in the abstract footer or poster Acknowledgments.* > \[Tool name and version] was used to assist with \[drafting / editing / translation] of this \[abstract / poster]. The output was reviewed by \[Author name(s)], who take responsibility for the content. *** ## Plain language summary *Use in the PLS document, typically in a footer or methods note.* > This plain language summary was developed with assistance from \[Tool name and version, e.g., Patiently AI] to translate clinical findings into accessible language. The summary was reviewed for accuracy and clarity by \[Author name(s) / patient advisor / medical reviewer], who confirm the content reflects the source \[paper / trial results]. *** ## Regulatory document (CSR section, IB, Module 2 summary, etc.) *Use per the relevant agency guidance and your sponsor's SOP. Always route through regulatory affairs review before finalising.* > \[Tool name and version] was used to assist with drafting \[section / module]. The output was reviewed against \[source data / SAP / protocol] by \[Author name(s)] and approved by \[regulatory reviewer / responsible signatory] in accordance with \[sponsor SOP reference]. Tool use is documented in \[project audit log location]. *** ## Promotional or MLR-bound material *Use per the applicable code (ABPI, IFPMA, etc.) and your client's SOP. The disclosure may be internal-only depending on the deliverable.* > AI tool \[Tool name and version] was used to assist with \[drafting / editing / claim verification] of this material. All claims have been verified against approved references and the approved messaging framework. The content was reviewed for code compliance by \[reviewer name / role] before submission to MLR. *** ## Internal client deliverable (briefing doc, internal report, leave-piece copy) *Use in the document footer or AI-use log per client SOP.* > Drafted with assistance from \[Tool name and version], used for \[drafting / summarisation / editing]. Reviewed and finalised by \[Author name]. AI use logged per \[project SOP / agency SOP reference]. *** ## Where no snippet exists — because the use is not permitted There is deliberately no template on this page for the following. At JAMA Network these are prohibited outright, and other journals are moving the same way. If you need one of these done, it needs a human to do it. * **Drafting Opinion articles, editorials, Letters to the Editor, or online Comments.** Human insight is the point of the format. * **Generating or formatting references or bibliographies.** Use a reference manager. * **Creating or manipulating clinical images, illustrations, video, or audio** outside a disclosed research design. * **Peer review** — entering a manuscript, or your summary of one, into an external AI tool breaches reviewer confidentiality. See [AI in Peer Review](/principles/ai-in-peer-review). * **Drafting author responses to reviewer or editor comments.** *** ## Notes on adapting these snippets * **Be specific about scope.** "AI was used" is not specific enough. Name what the tool did and what it didn't do. * **Include the manufacturer and the dates.** Increasingly expected, and trivial to capture at the time — nearly impossible to reconstruct months later. * **State responsibility explicitly.** Several policies now want a positive confirmation that the authors take responsibility for accuracy and integrity, not just an account of what the tool did. * **Document contemporaneously.** Build the disclosure as you write, not at submission. The audit-trail expectations in [Review and Accountability](/principles/review-and-accountability) feed directly into the disclosure. * **Specify the version where it matters.** "Claude" alone is less defensible than "Claude Opus 4.7" if questions arise about a particular output six months later. * **Don't conflate categories.** If AI was used for both editing and translation, declare both explicitly. Don't roll them into a vague "language assistance" line. * **Mirror the journal's preferred format.** Some journals want a dedicated AI-use statement; others embed it in the Methods. Check before submission. *** ## Related * [Declaring AI Use](/principles/declaring-ai-use) — the principle behind these templates * [AI in Peer Review](/principles/ai-in-peer-review) — what journals run on submissions before peer review * [Review and Accountability](/principles/review-and-accountability) — the audit trail that supports disclosure * [AI Regulation in Pharma](/principles/ai-regulation) — regulatory expectations that overlap with journal disclosure *** *Last reviewed: 11 August 2026 · 6 min read* # MLR-with-AI Review Checklist Source: https://playbook.pharmatools.ai/templates/mlr-ai-review-checklist Structured MLR review checklist with AI-specific checks for promotional and scientific content where AI was used in drafting, editing, or verification. A structured MLR review checklist with AI-specific items for content where AI was used in any drafting, editing, verification, or generation step. Extends a standard MLR checklist; does not replace it. For the principles behind this checklist, see [Review and Accountability](/principles/review-and-accountability), [Source Grounding](/principles/source-grounding), and [Declaring AI Use](/principles/declaring-ai-use). ## How to use this checklist * **Run alongside your standard MLR checklist,** not in place of it. The AI-specific items are additive. * **Require every AI item to clear before sign-off.** A "skipped because it's AI" item is the failure mode this checklist exists to prevent. * **Match scrutiny to the risk tier.** Critical and high-risk content gets every item; lower-risk content can be more selective. Use the [risk-tier framework](/principles/risk-levels) to calibrate. * **Review the audit log before starting.** Without it, the AI-specific checks become best-guess. *** ## Before the review * [ ] The [AI audit-trail log](/templates/ai-audit-trail-log) for this deliverable is complete and accessible * [ ] All cited references are accessible as full text (not abstracts) * [ ] The approved messaging framework or claims matrix is to hand * [ ] The applicable code is identified (ABPI, IFPMA, FDA OPDP, etc.) * [ ] Risk tier of the deliverable is documented * [ ] Disclosure language for the deliverable is drafted (see [Disclosure Language Template](/templates/disclosure-language)) *** ## AI-specific checks The items most likely to fail review on AI-assisted content. Run these first. ### Reference and source integrity * [ ] **No fabricated references.** Every cited reference exists, has a working DOI/PMID, and supports the claim it's cited for. If closed-loop verification was run (e.g., [RefCheckr](/tools/refcheckr)), confirm the output was reviewed and accepted, not rubber-stamped. * [ ] **No fabricated data.** Numbers, percentages, p-values, hazard ratios in the deliverable match the source data exactly. Spot-check at least 20% manually — automated checks miss subtle mismatches. * [ ] **No merged findings.** AI sometimes blends results from different studies. Confirm each claim is attributed to the correct study, population, and analysis type. * [ ] **No drifted qualifiers.** Subgroup, post-hoc, exploratory, and secondary-endpoint markers present in the source are preserved in the deliverable. ### Claim integrity * [ ] **Claims fall within the approved messaging framework.** AI can drift toward stronger language; verify each claim against the framework before sign-off. * [ ] **No off-label implications.** Read each claim against the approved indication. AI is prone to subtle scope expansion ("can help with X" when only X in a narrow population is approved). * [ ] **Comparative claims are substantiated.** AI sometimes implies superiority where the trial was designed for non-inferiority. Confirm comparative claims have head-to-head substantiation. * [ ] **Language strength matches evidence strength.** "Significantly reduces" requires statistical significance in the source. AI rewrites can soften or strengthen language without adjusting the cited evidence. ### Safety and balance * [ ] **Fair balance is maintained.** AI-drafted content can over-emphasise efficacy. Safety information must be present, prominent, and proportionate. * [ ] **Safety claims verified with the same rigour as efficacy claims.** AI sometimes treats safety information as boilerplate. Verify against the SmPC or USPI. * [ ] **No minimised limitations.** Limitations of the evidence are visible, not buried. ### Compliance and documentation * [ ] **Code-specific signals checked.** ABPI Code, IFPMA Code, or relevant national code obligations have been pre-screened (e.g., via [MedCheckr](/tools/medcheckr)). * [ ] **Disclosure language is present.** The deliverable includes the AI-use disclosure appropriate for its venue (manuscript, abstract, regulatory submission, internal report). * [ ] **AI use is consistent with sponsor SOP.** Some sponsors restrict AI use for certain deliverable types — confirm compatibility before sign-off. * [ ] **Audit log is contemporaneous.** Entries dated alongside the work, not reconstructed at submission. ### AI-generated visuals * [ ] **AI-generated figures are not presented as primary scientific data.** Concept visuals, visual abstracts, and illustrations are clearly labelled as conceptual. * [ ] **Patient depictions don't imply outcomes.** AI image tools can render scenes that suggest treatment results — check for unintended implications. * [ ] **No identifiable real people or recognisable products** unless explicitly licensed. *** ## Standard MLR checks (with an AI lens) These exist on every MLR checklist; the notes flag where AI-assisted content needs different attention. * [ ] **All claims substantiated.** Same standard as for human-written content; verify against cited evidence. * [ ] **References numbered, formatted, and accessible.** AI-fabricated references will trip here if missed earlier. * [ ] **Prescribing information present and current.** Confirm no AI-hallucinated PI content. * [ ] **Approval workflow followed.** AI-assisted content used the standard review path, not a shortcut. *** ## Sign-off block | Field | Value | | ---------------------------------- | ---------------------- | | **Deliverable version reviewed** | \[Version / file name] | | **All AI-specific items cleared** | \[Yes / No] | | **All standard MLR items cleared** | \[Yes / No] | | **Audit log reviewed** | \[Yes / No] | | **Disclosure language confirmed** | \[Yes / No] | | **Reviewer name and role** | \[Name, role] | | **Sign-off date** | \[YYYY-MM-DD] | *** ## Common failure patterns Reviewers sometimes apply less scrutiny to "AI-edited" content than to "AI-drafted" content, on the assumption editing is low-risk. AI editing can rephrase claims in ways that subtly drift from the source. Apply the same checks regardless of stated scope. The audit log answers "what did the AI actually do?" Without reviewing it, the AI-specific checks become best-guess. Always review the log before sign-off. Closed-loop tools like [RefCheckr](/tools/refcheckr) and [MedCheckr](/tools/medcheckr) reduce drift; they don't eliminate it. A "passed" closed-loop output still needs human verification on the high-stakes items. The AI-specific items are not optional adjuncts. They cover failure modes that don't appear in standard checklists. Skipping them is a common pathway to desk rejection or, in promotional contexts, to MLR rework. The reviewer has the abstract but not the full paper. They cannot verify a subgroup result. They pass it. AI-assisted content amplifies this risk because plausible-sounding claims about subgroups are common AI outputs. Confirm full-text access before review. *** ## Related * [Review and Accountability](/principles/review-and-accountability) — the principle this checklist operationalises * [Source Grounding](/principles/source-grounding) — the underlying claim-to-source principle * [Declaring AI Use](/principles/declaring-ai-use) — the disclosure principle this checklist confirms * [AI Failure Modes](/principles/ai-failure-modes) — the failure patterns this checklist guards against * [AI Audit-Trail Log Template](/templates/ai-audit-trail-log) — feeds the "before the review" prep * [Disclosure Language Template](/templates/disclosure-language) — pairs with the disclosure-confirmed item * [Check Promotional Compliance](/workflows/check-promotional-compliance) — workflow this checklist supports * [Final Human Review](/workflows/final-human-review) — broader review workflow for any AI-assisted deliverable *** *Last reviewed: 4 May 2026 · 7 min read* # Pre-submission QC Checklist Source: https://playbook.pharmatools.ai/templates/pre-submission-qc-checklist Final-gate quality control for AI-assisted manuscripts, abstracts, and regulatory submissions — covers the same checks publishers run on receipt. A final-gate quality-control checklist for AI-assisted deliverables before they leave your desk. Covers the categories major publishers and regulators now screen for automatically — reference integrity, image integrity, statistical accuracy, AI disclosure, methodology compliance, plagiarism. Catching these yourself is faster than the round-trip from a desk rejection. For the principle behind this checklist, see [AI in Peer Review](/principles/ai-in-peer-review). Use after [Final Human Review](/workflows/final-human-review), as the last step before submission. ## How to use this checklist * **Run on the final, submission-ready version** — not on a working draft. * **Run yourself; don't outsource the gate.** The reviewer signing off is accountable for what passes through. * **Match scrutiny to the venue.** A high-impact journal submission gets every item; an internal report needs only the relevant subset. * **Document outcomes** — the [AI Audit-Trail Log Template](/templates/ai-audit-trail-log) supports the trace from "checked" to "actually verified". * **When something fails, fix it before submitting.** "We'll catch it in revisions" is the cycle this checklist is designed to break. *** ## Reference integrity The single most-detected failure mode on AI-assisted submissions. * [ ] References were compiled in a standard reference manager, **not** generated or formatted by an AI tool. (Prohibited by JAMA Network as of August 2026; discouraged elsewhere.) * [ ] Every cited reference exists. DOI or PMID resolves to the actual paper. * [ ] Claims are supported by the cited source. Closed-loop verification (e.g., [RefCheckr](/tools/refcheckr)) was run and outputs reviewed. * [ ] No "borrowed" findings — claims attributed to the wrong study, population, or analysis type. * [ ] Subgroup, post-hoc, exploratory qualifiers preserved where present in the source. * [ ] Self-citation is appropriate and not over-used. *** ## Data and statistical accuracy * [ ] Numbers in the deliverable match the source data exactly (p-values, hazard ratios, percentages, sample sizes). * [ ] Confidence intervals reported where the source reports them. * [ ] No impossible statistics (GRIM violations, p-values inconsistent with reported test statistics, decimal drift). * [ ] ITT vs. mITT vs. per-protocol analyses correctly labelled. * [ ] Endpoints correctly identified as primary, secondary, exploratory. *** ## Image and figure integrity * [ ] No image duplications across this submission or prior published work. * [ ] No splicing, cropping, or contrast adjustments that could be challenged. * [ ] Image-integrity check run (e.g., Imagetwin, Proofig) for any submission with figures from human bodies, gels, blots, or composite assemblies. * [ ] No clinical images, illustrations, video, or audio were created or manipulated by AI. (Prohibited by JAMA Network as of August 2026 unless part of a disclosed research design.) * [ ] Any brightness, contrast, or colour adjustment was applied uniformly to the whole image and is described in the figure legend with software name and version. * [ ] Original unedited images retained and available for editorial review. * [ ] AI-generated images (concept visuals, visual abstracts) are explicitly labelled as conceptual, not as primary data. * [ ] Figure captions match the figure content and the underlying source. *** ## AI use and disclosure * [ ] AI disclosure language drafted using the [Disclosure Language Template](/templates/disclosure-language) and customised to this deliverable. * [ ] Disclosure specifies tool name, version, scope, and named reviewer. * [ ] Disclosure placed in the location the journal or venue requires (Methods, Acknowledgments, dedicated AI-use statement, footer). * [ ] [AI audit-trail log](/templates/ai-audit-trail-log) is complete and accessible — every AI use captured with reviewer. * [ ] No undisclosed AI use that would appear in the audit log. *** ## Methodology and reporting compliance * [ ] Reporting guideline followed for the study type (CONSORT for trials, PRISMA for systematic reviews, STROBE for observational, etc.). * [ ] Methods section is complete enough for reproducibility. * [ ] Pre-registration referenced where applicable. * [ ] Limitations clearly stated. *** ## Plagiarism and originality * [ ] iThenticate or equivalent similarity check run on the final draft. * [ ] No verbatim text reuse from prior published work without proper attribution. * [ ] Self-plagiarism (text reuse from author's own prior publications) flagged where significant. * [ ] Quotation marks and citation used correctly for all directly reproduced passages. *** ## Authorship and affiliations * [ ] All authors listed meet authorship criteria (ICMJE or journal-specific). * [ ] No "courtesy" or "gift" authorship. * [ ] Each author's affiliation is current and accurate. * [ ] ORCID iDs included for each author. * [ ] Conflicts of interest disclosed in full. * [ ] AI is *not* listed as an author. (Universally rejected by major journals; immediate desk rejection.) *** ## Venue-specific checks * [ ] Journal's specific AI-use policy reviewed (see [Declaring AI Use](/principles/declaring-ai-use) for links). * [ ] **Prohibited uses checked, not just disclosable ones.** Confirm no AI was used for anything the target journal forbids — commonly references, Opinion/Letters/Comments, and clinical imagery. * [ ] For Opinion articles, editorials, Letters to the Editor, or online Comments: drafted entirely by the named human authors, with no AI drafting assistance. * [ ] Disclosure includes tool name, version, manufacturer, dates of use, affected portions, and an explicit statement of author responsibility. * [ ] Word, figure, and table limits respected. * [ ] Required sections present (e.g., data availability statement, ethics approval, funding). * [ ] File formats and naming conventions match the submission system requirements. * [ ] Cover letter aligns with the submitted content. *** ## Sign-off block | Field | Value | | --------------------------------------------- | -------------------------------- | | **Deliverable version** | \[Version / file name] | | **Submission target** | \[Journal / regulator / sponsor] | | **All reference integrity items cleared** | \[Yes / No] | | **No prohibited AI uses at the target venue** | \[Yes / No] | | **All data and statistical items cleared** | \[Yes / No] | | **All image integrity items cleared** | \[Yes / No] | | **AI disclosure and audit log complete** | \[Yes / No] | | **Methodology and reporting items cleared** | \[Yes / No] | | **Plagiarism check passed** | \[Yes / No] | | **Authorship and affiliations confirmed** | \[Yes / No] | | **Venue-specific items cleared** | \[Yes / No] | | **Final reviewer name and role** | \[Name, role] | | **Sign-off date** | \[YYYY-MM-DD] | *** ## Common gaps that trigger desk rejection The single most common failure on AI-assisted submissions. The reference list looks plausible, the DOIs are formatted correctly, but the papers don't exist or don't say what's claimed. Always run reference verification before submission. "AI tools were used" is vague enough to draw editor questions. Specific, named, scoped disclosure (with reviewer accountability) is what publishers expect. The [Disclosure Language Template](/templates/disclosure-language) gives a starting point per scenario. Publisher-side image-integrity tools share databases. A figure flagged elsewhere will likely flag here. Run an integrity check before submission, not after. Means and standard deviations that can't arise from the reported sample sizes. AI-drafted summaries sometimes invent or paraphrase statistics that fail this check. Verify against source data. Universally rejected: AI as author. Increasingly checked: ORCID for each author, transparent contribution statements, no honorary authorship. Confirm before submission. *** ## Related * [AI in Peer Review](/principles/ai-in-peer-review) — the principle this checklist operationalises * [Declaring AI Use](/principles/declaring-ai-use) — the disclosure principle * [Source Grounding](/principles/source-grounding) — the underlying claim-to-source principle * [Disclosure Language Template](/templates/disclosure-language) — pairs with the disclosure-confirmed item * [AI Audit-Trail Log Template](/templates/ai-audit-trail-log) — pairs with the audit-log-complete item * [MLR-with-AI Review Checklist](/templates/mlr-ai-review-checklist) — for promotional content; this checklist is for publication and regulatory submissions * [Verify Claims Against References](/workflows/verify-claims-against-references) — workflow that produces the reference integrity outputs * [Final Human Review](/workflows/final-human-review) — workflow that precedes this gate *** *Last reviewed: 11 August 2026 · 7 min read* # Which tool when Source: https://playbook.pharmatools.ai/tools/decision-tree A decision guide for choosing the right AI tool for a medical writing task. ## What this page is A quick decision aid for picking the right tool for a given medical writing task. It maps common jobs-to-be-done to the tool best suited to them, drawing on both third-party tools and the PharmaTools.AI suite. Use it as a starting point, not a prescription. Tool choice also depends on your organisation's policies, the sensitivity of the data involved, and your own familiarity with the tool. The writer remains responsible for verifying outputs against the source. > Choose the tool based on the job to be done, not the model. ## What are you trying to do? You have papers or internal documents and need to explore, extract, synthesise, or draft from them. You are writing new text, building slides, creating figures, or transcribing spoken content. You need to verify claims, check MLR compliance, generate a plain language summary, or use another MW-specific tool. ## Working with sources | Job | Recommended tool | Why | Alternative | | -------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Explore or question a paper | [NotebookLM](/tools/ecosystem#notebooklm) | Source-grounded Q\&A with inline citations back to the document | [Claude](/tools/ecosystem#claude-chatgpt) with uploaded PDFs | | Synthesise and draft across multiple sources | [Claude Cowork](/tools/ecosystem#claude-cowork) | Persistent project workspace; strong at cross-document synthesis and outlining | NotebookLM (for Q\&A), ChatGPT Projects | | Structured extraction and comparison across papers | [Elicit](/tools/ecosystem#elicit) | Extracts predefined fields (population, intervention, outcomes) in a consistent table | Manual extraction in Claude Cowork | | Quick research-question framing | [Consensus](/tools/ecosystem#consensus) | Fast sense of what the literature says on a focused question | [Perplexity](/tools/ecosystem#perplexity) | | Citation context and sentiment | [Scite.ai](/tools/ecosystem#scite-ai) | Shows whether a paper is supported, contrasted, or mentioned by later work | — | | Literature search (MCP-enabled) | [PubCrawl](/tools/pubcrawl) | Structured PubMed search callable from Claude or ChatGPT via MCP | Direct PubMed, Google Scholar | ## Drafting from scratch | Job | Recommended tool | Why | Alternative | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | General text drafting and rewriting | [Claude or ChatGPT](/tools/ecosystem#claude-chatgpt) | Strong writing quality, flexible prompting, long context | Gemini | | Enterprise Word and PowerPoint drafting | [Microsoft Copilot](/tools/ecosystem#microsoft-copilot) | In-suite integration that respects M365 tenant boundaries | Claude/ChatGPT with copy-paste | | Publication-quality scientific figures | [BioRender](/tools/ecosystem#biorender) | Purpose-built biological illustration library | Adobe Illustrator, PowerPoint | | Conceptual diagrams or AI-generated slides | [Napkin](/tools/ecosystem#napkin) or [Gamma](/tools/ecosystem#gamma) | Fast visualisation of concepts or draft decks from text | PowerPoint + Copilot | | Brand concepts, leavepieces, ad mockups, pitch deck visuals | [Claude Design](/tools/ecosystem#claude-design) | Conversational design surface for non-designers; reads brand assets and exports to PPTX, PDF, or Canva | Designer brief from scratch | | Concept images, visual abstracts, slide visuals, social graphics | [Nano Banana 2](/tools/ecosystem#nano-banana-2) or [Midjourney](/tools/ecosystem#midjourney) | Fast generation of conceptual imagery — see [Generate Concept Visuals](/workflows/generate-concept-visuals) for prompting patterns and reality check | Licensed stock imagery, Adobe Firefly | | Transcription of calls, ad boards, KOL interviews | [Otter.ai](/tools/ecosystem#otter-ai) or [Fireflies.ai](/tools/ecosystem#fireflies-ai) | Accurate transcripts with speaker separation and searchable archive | Microsoft Teams native transcription | ## Medical-writing-specific tasks | Job | Recommended tool | Why | | ---------------------------------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Verify claims against references | [RefCheckr](/tools/refcheckr) | Closed-loop: verifies each claim against the source, rewrites mismatches, and re-checks the rewrite for ABPI compliance | | MLR compliance check | [MedCheckr](/tools/medcheckr) | Reviews copy against promotional compliance expectations before MLR submission | | Plain language summaries | [PLS Generator](/tools/pls-generator) | Converts clinical content into compliant, readable lay summaries | | Poster and congress Q\&A prep | [PosterLens](/tools/posterlens) | Generates anticipated questions and responses from a poster or abstract | | Patient-facing content | [Patiently AI](/tools/patiently-ai) | Tailors content to patient audiences with appropriate tone and reading level | | Tailor text to different audiences | [LLMentor](/tools/llmentor) | Adapts draft content across HCP, patient, payer, and internal audiences | ## A note on overlap Several tools overlap. Claude and ChatGPT are largely interchangeable for drafting; Consensus, Perplexity, and Elicit all help with literature exploration; Napkin and Gamma both generate visual slides. The tables recommend one starting point per job — switch to an alternative if your organisation already has a preferred tool or a licence in place. The most important decision is usually *not* which tool you use, but whether you are applying AI to the right stage of the task. See [Risk levels](/principles/risk-levels) and [Human in the loop](/principles/human-in-the-loop) for the principles that should guide that choice. # Tool ecosystem Source: https://playbook.pharmatools.ai/tools/ecosystem Third-party tools referenced throughout the playbook, organised by the job they help you do. ## What this page is Across the playbook, the workflow and tool pages point to a number of third-party tools as alternatives, complements, or adjacent options. This page consolidates them in one place so you can see the full ecosystem at a glance, understand where each one fits, and find the right tool for the job without scanning every workflow. The tools listed here are **not** PharmaTools.AI products and we have no commercial relationship with their vendors. They are included because they appear in the playbook as practical options medical writers may already be using. The PharmaTools.AI tools — [PubCrawl](/tools/pubcrawl), [RefCheckr](/tools/refcheckr), [MedCheckr](/tools/medcheckr), [Patiently AI](/tools/patiently-ai), [LLMentor](/tools/llmentor), [PLS Generator](/tools/pls-generator), and [PosterLens](/tools/posterlens) — are documented on their own pages above. ## How to read this page Tools are grouped by the job they help you do, not by vendor. Each entry covers what the tool is, when to reach for it, and which playbook pages already point to it. Inclusion here is not an endorsement — the writer is always responsible for verifying outputs, checking compliance with their organisation's policies, and confirming the tool is appropriate for the task and the data involved. ## Multi-document workflows ### Claude Cowork [claude.ai →](https://claude.ai) A structured project workspace where you can drop multiple source documents (papers, protocols, statistical outputs, prior drafts) and work with them together. Reach for it when you need to synthesise or draft across multiple sources rather than analyse a single document. Distinct from inline Claude/ChatGPT (which works from pasted text) and from NotebookLM (which is optimised for single-paper exploration). ![Claude Cowork multi-document workflow](https://cdn.prod.website-files.com/66d49e8555a289120a81ec3e/69de801b8f28796fc55f7ca4_99FchZs5DJe6_iNj1967n_nh0BVLXX.png) #### Why this workflow matters Medical writing often begins with multiple background materials: a creative brief, publications, internal messaging documents, and previous presentations. Synthesising these inputs is one of the most time-consuming steps in the writing process. Multi-document AI workspaces can accelerate this stage by helping writers extract key findings and organise the material before drafting begins. The writer remains responsible for verifying interpretation, ensuring claims are supported by the sources, and confirming alignment with the brief. #### Example workflow A medical writer receives a creative brief together with several background materials: * two clinical publications * a previous slide deck * a messaging document from the brand team By uploading these sources into a shared workspace (such as Claude Cowork), the writer can ask the AI to synthesise the materials and generate a structured outline grounded in those documents. This can significantly reduce the time needed to organise and synthesise multiple inputs before drafting begins. Human review remains essential to verify interpretation, confirm that claims are supported by the sources, and ensure alignment with the brief. #### Example prompt > Using the uploaded documents (creative brief, two publications, and the brand messaging deck), extract the key evidence and draft a structured outline for a medical affairs presentation. Ensure all claims are supported by the provided sources. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Extract Study Data](/workflows/extract-study-data), [Extract Key Messages](/workflows/extract-key-messages), [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [PubCrawl](/tools/pubcrawl) ## Single-paper exploration ### NotebookLM [notebooklm.google.com →](https://notebooklm.google.com) Upload a paper (or a small set) and ask questions grounded in the source text. Useful for familiarising yourself with a complex publication, identifying key themes, and preparing for downstream writing — but the writer must still verify study design, endpoints, limitations, and interpretation against the source. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Summarise a Source Paper](/workflows/summarise-source-paper), [Extract Study Data](/workflows/extract-study-data), [Extract Key Messages](/workflows/extract-key-messages), [Write a Manuscript](/workflows/write-a-manuscript), [PubCrawl](/tools/pubcrawl) ## Literature search and synthesis ### Elicit [elicit.com →](https://elicit.com) Structured paper extraction and cross-paper synthesis. Useful during exploratory research, when comparing findings across multiple papers, or when building an evidence base before writing begins. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Summarise a Source Paper](/workflows/summarise-source-paper), [Extract Study Data](/workflows/extract-study-data), [Extract Key Messages](/workflows/extract-key-messages), [PubCrawl](/tools/pubcrawl), [RefCheckr](/tools/refcheckr) ### Consensus [consensus.app →](https://consensus.app) Fast research-question exploration across the published literature. Useful for early framing — getting a sense of what the evidence says on a question — before committing to a structured search. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [PubCrawl](/tools/pubcrawl) ### Perplexity [perplexity.ai →](https://www.perplexity.ai) AI-powered search with cited sources. Useful for quick fact-checking, background research, and locating specific claims in the literature when you need an answer faster than a structured search would deliver. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Summarise a Source Paper](/workflows/summarise-source-paper), [Verify Claims Against References](/workflows/verify-claims-against-references), [PubCrawl](/tools/pubcrawl) ### Scite.ai [scite.ai →](https://scite.ai) Citation context analysis. Shows whether a citation supports, contrasts, or merely mentions a claim — useful as a second layer alongside claim-level verification when you need to understand how a paper has been received in the literature. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Verify Claims Against References](/workflows/verify-claims-against-references), [RefCheckr](/tools/refcheckr) ## Reference management ### Zotero [zotero.org →](https://www.zotero.org) Open-source reference library management. Store, organise, tag, and cite the papers your evidence base contains. Plays well with most word processors via a citation plugin. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [Verify Claims Against References](/workflows/verify-claims-against-references), [PubCrawl](/tools/pubcrawl), [RefCheckr](/tools/refcheckr) ### EndNote [endnote.com →](https://endnote.com) Commercial reference library management, common in pharma and academic environments. Same job as Zotero — store, organise, and cite — but with broader institutional adoption and Word integration. **Referenced in these workflows:** [Find Evidence](/workflows/find-evidence), [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [Verify Claims Against References](/workflows/verify-claims-against-references), [PubCrawl](/tools/pubcrawl), [RefCheckr](/tools/refcheckr) ## General-purpose AI assistants ### Claude [claude.ai →](https://claude.ai) General-purpose conversational AI from Anthropic. The playbook references it as a baseline option for drafting, summarisation, simplification, audience adaptation, outline generation, and consistency scanning when working from pasted text. Best treated as a flexible assistant for exploratory or low-risk tasks — not as a substitute for evidence-grounded tooling on regulated or compliance-critical work. **Referenced in these workflows:** Most drafting, adaptation, and review workflows — including [Build Content Outline](/workflows/build-content-outline), [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [Convert Stats to Narrative](/workflows/convert-stats-to-narrative), [Adapt for Different Audiences](/workflows/adapt-for-different-audiences), [Create a Plain Language Summary](/workflows/create-plain-language-summary), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels), [Check Document Consistency](/workflows/check-document-consistency) ### ChatGPT [chatgpt.com →](https://chatgpt.com) General-purpose conversational AI from OpenAI. Functionally interchangeable with Claude for most of the tasks the playbook references — choose based on your organisation's enterprise contracts, data-handling policies, and your own experience with each model. The same caveats apply: fine for exploratory and low-risk work, not a substitute for evidence-grounded tooling on regulated content. **Referenced in these workflows:** Same workflows as Claude (paired throughout the playbook as alternatives). ## Enterprise productivity ### Microsoft Copilot [microsoft.com/microsoft-copilot →](https://www.microsoft.com/en-us/microsoft-copilot) In-document AI inside Word and PowerPoint, available in many enterprise pharma environments through existing Microsoft 365 contracts. Reach for it when your organisation's compliance and data-handling rules favour staying inside Microsoft 365 over external tools, or when you want drafting assistance directly in the document you are editing. **Referenced in these workflows:** [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck) ## Figures, diagrams, and visuals ### BioRender [biorender.com →](https://www.biorender.com) Publication-quality biological and mechanism-of-action figures, with a large library of pre-built scientific icons and templates. Standard tool in many pharma and academic environments for figure creation in manuscripts, slides, and posters. **Referenced in these workflows:** [Write a Manuscript](/workflows/write-a-manuscript), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck) ### Napkin [napkin.ai →](https://napkin.ai) Generates concept diagrams and visual summaries from text. Useful during early planning (visual concept mapping), when repurposing content into shareable visuals, or when summarising poster data for internal distribution. Not a substitute for figures that need to meet publication standards — that is BioRender's territory. **Referenced in these workflows:** [Build Content Outline](/workflows/build-content-outline), [Prepare a Congress or Poster Summary](/workflows/prepare-congress-or-poster-summary), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels) ## Presentation generation ### Gamma [gamma.app →](https://gamma.app) Converts structured content (outlines, prose, bullet lists) into presentation decks. Useful when you have the content and need a first-pass slide structure, or when repurposing existing material into a deck format. The writer is responsible for clinical accuracy, visual standards, and final review before any deck leaves the desk. **Referenced in these workflows:** [Build Content Outline](/workflows/build-content-outline), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels) ## AI image generation Generative image tools for **concept** visuals only — illustrative imagery, visual abstracts, slide backgrounds, and social graphics where the picture sets tone or communicates an idea. Not for scientific figures, data visualisations, or regulatory-facing content without full review. See [Generate Concept Visuals](/workflows/generate-concept-visuals) for the workflow, prompting patterns, and reality check. ### Nano Banana 2 [gemini.google.com →](https://gemini.google.com) Google's image generation model (successor to the original Nano Banana / Gemini 2.5 Flash Image). Strong prompt adherence, reliable in-image text rendering, and native edit-by-prompt refinement. Reach for it when you need legible text inside the image, iterative refinement, or a free tier for quick concepting. **Referenced in these workflows:** [Generate Concept Visuals](/workflows/generate-concept-visuals), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels) ### Midjourney [midjourney.com →](https://midjourney.com) Distinctive aesthetic quality, particularly strong on illustration, editorial, and mood-led imagery with deep control over style parameters. Reach for it when the image needs to look like finished creative work, or when exploring a visual direction rather than a literal scene. Weaker than Nano Banana 2 on in-image text. **Referenced in these workflows:** [Generate Concept Visuals](/workflows/generate-concept-visuals), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels) ## Design and brand concepting ### Claude Design [anthropic.com/news/claude-design-anthropic-labs →](https://www.anthropic.com/news/claude-design-anthropic-labs) Anthropic Labs' design surface for collaborative visual creation — pitch decks, leavepieces, marketing collateral, wireframes, and interactive prototypes. Accepts text prompts, uploaded DOCX/PPTX/XLSX, reference code, or captured website elements; reads brand assets to apply colours, typography, and components consistently; and exports to Canva, PDF, PPTX, or HTML. Available to Claude Pro, Max, Team, and Enterprise subscribers. #### Why this matters for medical writers Medical writers are increasingly expected to bring concepts to the table earlier in the brand process — a rough leavepiece mockup, a slide-deck visual treatment, or an ad campaign concept that gets the conversation moving before a designer takes over. Tools like Claude Design make that feasible without graphic design training. A medical writer might use it to: * mock up a **leavepiece concept** to brief a designer before the agency cycle begins * generate a **first-pass visual treatment** for a slide deck or congress booth panel * sketch an **ad concept or pull-through asset** alongside the messaging that supports it * produce a **pitch deck visual** for a new business proposal or internal alignment meeting The writer remains responsible for clinical accuracy, on-brand language, regulatory compliance, and the final designer or studio handoff. Claude Design accelerates the visual mockup; it does not replace the designer who tightens it for production, nor the MLR review that any externally facing material still requires. **Referenced in these workflows:** [Build Content Outline](/workflows/build-content-outline), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels) ## Transcription ### Otter.ai [otter.ai →](https://otter.ai) Meeting and interview transcription with speaker identification. Useful for capturing advisory boards, KOL interviews, and focus groups when key messages need to come from spoken insight rather than published sources. Check your organisation's data-handling and consent rules before recording any HCP or patient interaction. **Referenced in these workflows:** [Extract Key Messages](/workflows/extract-key-messages) ### Fireflies.ai [fireflies.ai →](https://fireflies.ai) Same job as Otter.ai — automated meeting transcription, with broader integrations into common conferencing platforms. Choose between the two based on which integrates with your team's existing meeting stack and which meets your organisation's compliance requirements. **Referenced in these workflows:** [Extract Key Messages](/workflows/extract-key-messages) ## What's not on this list This page covers third-party tools the playbook actively references in its workflows. It does not attempt to catalogue the full landscape of medical writing software. Notable categories deliberately left out: * **Pharma-specific commercial platforms** (Veeva, IQVIA, Datavision, etc.) — these are typically procured at the organisation level and out of scope for a playbook focused on day-to-day AI tooling. * **Regulatory submission and publishing tools** — covered indirectly in the regulatory workflow, but the platforms themselves are environment-specific. * **General productivity tools** (Notion, Slack, Jira, etc.) — assumed but not relevant to the AI-specific guidance in the playbook. * **AI image generators for scientific figures** — AI image models are not a substitute for [BioRender](#biorender) or a medical illustrator when biological accuracy matters. Only concept-appropriate generative tools are included above. If you think a tool belongs here and isn't, the [feedback widget](/) at the bottom of any page is the fastest route to flag it. *** [Explore PharmaTools.AI →](https://pharmatools.ai) # LLMentor Source: https://playbook.pharmatools.ai/tools/llmentor Adapt medical and scientific content across audience levels while preserving accuracy. ## What it does LLMentor adapts medical and scientific content for different audience levels. It takes a piece of content written for one audience and transforms it for another, adjusting language complexity, assumed knowledge, emphasis, and framing while preserving factual accuracy. ## The problem it solves A single set of Phase III results may need to reach oncologists, GPs, payers, nurses, and patients, each needing different language, different emphasis, and different levels of clinical detail. Manually rewriting the same content for five audiences is repetitive and slow. Worse, maintaining factual consistency across five versions is where errors creep in: a data point changes in the GP version but not the specialist version, or a qualifier gets dropped in the payer summary. LLMentor produces first-draft audience adaptations from a single reviewed source. The writer then verifies accuracy, checks for meaning drift, and ensures consistency across versions: the editorial work that requires human judgement, not the reformatting work that does not. ## Where it fits in the playbook | Workflow | Role | | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | [Adapt for different audiences](/workflows/adapt-for-different-audiences) | Primary tool — audience-specific content adaptation | | [Repurpose content across channels](/workflows/repurpose-content-across-channels) | Supporting tool — adapting content as part of cross-channel repurposing | ## How to use it in a workflow 1. **Provide the source content** — The original, approved or reviewed content 2. **Specify the target audience** — Be specific about who the adapted content is for (e.g., "community pharmacists" not just "healthcare professionals") 3. **Run LLMentor** — Generate the audience-adapted version 4. **Review for accuracy** — Ensure adaptation has not changed the meaning or introduced unsupported claims 5. **Review for appropriateness** — Confirm the output genuinely matches the target audience's needs and knowledge level 6. **Cross-check against original** — Verify consistency between the adapted version and the source content ## What it does well * Adjusts language complexity and terminology for different professional levels * Shifts emphasis and framing to match audience priorities * Maintains core factual content while changing presentation * Handles common audience pairs (specialist to generalist, clinical to lay) ## What it does not do * **Does not determine what the audience needs to know.** Content selection is a human decision. * **Does not guarantee regulatory appropriateness.** Different audiences may have different regulatory requirements (e.g., patient vs. HCP materials). * **Does not replace audience-specific expertise.** A medical writer with experience in patient communications will catch issues that a general adaptation tool may miss. ## Risk tier Audience adaptation is **low-to-medium risk** depending on the target audience. Adaptations for healthcare professionals are generally lower risk. Adaptations for patients, payers, or the public carry higher risk due to the potential for oversimplification or misinterpretation. [Try LLMentor at PharmaTools.AI →](https://www.pharmatools.ai/llmentor) # MedCheckr Source: https://playbook.pharmatools.ai/tools/medcheckr Pre-screen medical communications content for promotional compliance signals. ## What it does MedCheckr reviews medical communications content for signals that may indicate promotional compliance issues. It scans text for language patterns, claim structures, and framing that could raise concerns under pharmaceutical advertising codes and regulatory guidelines. ## The problem it solves Every MLR rejection cycle costs time, budget, and credibility. Common rejection reasons (unsubstantiated superlatives, insufficient fair balance, language that implies off-label use, comparative claims without adequate substantiation) are pattern-based issues that can be caught before submission. MedCheckr runs a pre-MLR scan that flags these patterns in near-final content, giving writers and reviewers a structured list of items to check before the document enters the formal approval queue. The goal is cleaner submissions, fewer rejection cycles, and more productive MLR review sessions, not to replace the committee's judgement. ## Where it fits in the playbook | Workflow | Role | | ----------------------------------------------------------------------- | ---------------------------------------------------- | | [Check promotional compliance](/workflows/check-promotional-compliance) | Primary tool — automated compliance signal detection | | [Final human review](/workflows/final-human-review) | Supporting tool — compliance layer in final QC | ## How to use it in a workflow 1. **Prepare a near-final draft** — MedCheckr is most useful on content that is close to submission, not rough first drafts 2. **Run MedCheckr** — Submit the content for compliance signal scanning 3. **Review flagged items** — Assess each flag in context. Not every flag is an actual issue, and some may be appropriate for the content type 4. **Revise as needed** — Address genuine compliance concerns in the content 5. **Proceed to formal review** — MedCheckr does not replace MLR review. Submit the revised content through your standard approval process ## What it does well * Flags superlative and comparative language that may require substantiation * Identifies potential off-label implications * Highlights areas where fair balance may be insufficient * Detects language patterns commonly flagged in MLR review * Helps writers self-check before submitting to formal review ## What it does not do * **Does not provide legal or regulatory approval.** MedCheckr is a pre-screening tool. It does not replace MLR review, legal counsel, or regulatory affairs assessment. * **Does not interpret specific national regulations.** Promotional codes vary by market. MedCheckr flags general patterns, and market-specific compliance requires specialist review. * **Does not guarantee compliance.** A clean MedCheckr scan does not mean the content is compliant. It means the automated scan found no flagged patterns. * **Does not assess the scientific accuracy of claims.** Use [RefCheckr](/tools/refcheckr) for closed-loop claim verification and rewrite. ## Risk tier MedCheckr is used in **high-risk** workflows. Its outputs are compliance support inputs, not compliance determinations. Every MedCheckr result, whether flagged or clean, requires expert review before the content is approved for use. ## Important note on compliance This playbook does not provide regulatory or legal advice. MedCheckr and the compliance workflows in this playbook are designed to help medical writers identify potential issues earlier in the content development process. They do not replace the judgement of qualified compliance, legal, or regulatory professionals. [Try MedCheckr at PharmaTools.AI →](https://www.pharmatools.ai/medcheckr-ai) # Patiently AI Source: https://playbook.pharmatools.ai/tools/patiently-ai Translate clinical content into patient-friendly language for accessible medical communications. ## What it does Patiently AI simplifies medical information into patient-friendly language. It takes clinical or technical medical content and produces clear, accessible explanations suitable for patients and non-specialist readers. ## The problem it solves A discharge summary, clinic letter, or study results document written for HCPs is largely unreadable for the patients it concerns. Translating this content into language a patient can genuinely understand, without losing medical accuracy or creating false reassurance, is one of the most skilled tasks in medical writing. It is also time-consuming, because the writer must simultaneously hold the clinical meaning and the patient's reading level in mind. Patiently AI produces a structured first draft of patient-friendly content from clinical source material. The writer then reviews for accuracy (has simplification changed the meaning?), readability (would the target patient actually understand this?), and tone (is it reassuring without being misleading?). ## Where it fits in the playbook | Workflow | Role | | --------------------------------------------------------------------------- | ------------------------------------------------------------ | | [Create a plain language summary](/workflows/create-plain-language-summary) | Primary tool — generating patient-friendly first drafts | | [Adapt for different audiences](/workflows/adapt-for-different-audiences) | Supporting tool — when the target audience includes patients | ## How to use it in a workflow 1. **Provide the source material** — Clinical text, medical notes, or technical content that needs simplification 2. **Run Patiently AI** — Generate a patient-friendly version of the content 3. **Review for accuracy** — Ensure simplification has not changed the medical meaning 4. **Review for readability** — Confirm the output is genuinely accessible to the target audience 5. **Expert review** — Patient-facing medical content should be reviewed by a qualified medical professional before use ## What it does well * Translates medical jargon into plain language * Maintains the core meaning of clinical information while making it accessible * Produces structured, readable output suitable for patient communications * Handles common medical terminology and procedural descriptions ## What it does not do * **Does not provide medical advice.** Patiently AI simplifies existing medical information; it does not generate medical recommendations. * **Does not replace patient communication specialists.** The output requires review by someone with expertise in patient-facing medical content. * **Does not guarantee health literacy compliance.** Output should be assessed against relevant health literacy standards (e.g., reading level, structure, formatting) by a qualified reviewer. * **Does not assess whether the source information is appropriate for patients.** A human must decide what information is suitable for a patient audience. ## Risk tier Patient-facing content is **medium-to-high risk**. Simplification can inadvertently change medical meaning, omit important safety information, or create false reassurance. All Patiently AI output must be reviewed by a medical professional before it reaches patients. ## Using Patiently AI with OpenClaw Patiently AI is available as a skill on [ClawHub](https://clawhub.ai/), the skills marketplace for [OpenClaw](https://github.com/openclaw/openclaw). If you are building with OpenClaw, you can add it now: ```bash theme={null} clawhub install patiently-ai ``` Or search for "patiently-ai" on ClawHub. *** [Try Patiently AI at PharmaTools.AI →](https://www.pharmatools.ai/patiently-ai) # PLS Generator Source: https://playbook.pharmatools.ai/tools/pls-generator Generate plain language summaries from clinical and scientific source materials. ## What it does PLS Generator creates plain language summaries from technical medical and scientific content. It is specifically designed for producing lay-friendly summaries of clinical trial results, study findings, and medical information. ## The problem it solves Plain language summaries are now a regulatory requirement, not an optional nice-to-have. The EU Clinical Trials Regulation requires lay-friendly summaries of clinical trial results. Sponsors are increasingly publishing PLS for transparency and patient engagement. But writing an effective PLS is one of the hardest tasks in medical writing: it requires translating complex study designs, statistical results, and safety profiles into language that a non-specialist adult can genuinely understand, without distorting the science or creating false reassurance. PLS Generator produces first-draft plain language summaries from clinical source materials, structured to common PLS frameworks. The writer then verifies medical accuracy, checks readability, ensures balanced representation of benefits and risks, and confirms compliance with any applicable regulatory template requirements. ## Where it fits in the playbook | Workflow | Role | | --------------------------------------------------------------------------- | ----------------------------------------------- | | [Create a plain language summary](/workflows/create-plain-language-summary) | Primary tool — generating structured PLS drafts | ## How to use it in a workflow 1. **Provide the source material** — Clinical study report, published paper, or results summary 2. **Specify the PLS requirements** — Format, structure, reading level, any regulatory template requirements 3. **Run PLS Generator** — Generate a first-draft plain language summary 4. **Review for accuracy** — Ensure all data points, findings, and conclusions are accurately represented 5. **Review for readability** — Confirm the output meets the target reading level and is genuinely accessible 6. **Expert review** — PLS for regulatory submission or public disclosure must be reviewed by qualified professionals 7. **Patient/lay review** — Where possible, test the summary with representative readers from the target audience ## What it does well * Translates clinical trial results into structured, accessible language * Follows common PLS frameworks and structures * Handles standard clinical trial terminology and endpoint descriptions * Produces content at an appropriate reading level for lay audiences ## What it does not do * **Does not guarantee regulatory compliance.** PLS for clinical trial disclosure must meet specific regulatory requirements. PLS Generator produces drafts, and compliance is the responsibility of the review team. * **Does not replace patient testing.** Best practice for PLS includes review by patient representatives or lay readers. AI cannot replicate this feedback. * **Does not determine what to include or exclude.** Decisions about which results, endpoints, or findings to include in a PLS are made by the study team and medical writer. * **Does not provide translations.** PLS may need to be produced in multiple languages. Translation is a separate process requiring qualified medical translators. ## Risk tier Plain language summaries are **medium-to-high risk**, particularly when they are: * Required for regulatory disclosure (e.g., EU CTR lay summaries) * Intended for direct patient or public consumption * Summarising safety data or adverse event information All PLS Generator output requires expert review and, where applicable, patient/lay reader testing. [Try PLS Generator at PharmaTools.AI →](https://www.pharmatools.ai/plsease) # PosterLens Source: https://playbook.pharmatools.ai/tools/posterlens Extract structured data from scientific posters for congress coverage and summarisation. ## What it does PosterLens explores and extracts structured information from scientific posters. It reads poster content and produces organised summaries, data extractions, and key findings in a format that can be used as input for further medical writing workflows. ## The problem it solves Congress coverage is one of the highest-pressure, fastest-turnaround workflows in med comms. A medical writer at ASCO, ESMO, or AAN may need to review 20–40 relevant posters in 2–3 days and deliver structured summaries to clients before the congress ends. Each poster is information-dense, visually complex, and contains data in text, tables, figures, and footnotes that all need to be captured accurately. Manually reading, extracting, and structuring this information under time pressure is where errors happen: a misread Kaplan-Meier curve, a transposed sample size from a subgroup table, a missed safety panel. PosterLens provides structured extractions from poster content, giving the writer a verified starting point rather than a blank page for each summary. ## Where it fits in the playbook | Workflow | Role | | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | [Prepare a congress or poster summary](/workflows/prepare-congress-or-poster-summary) | Primary tool — extracting and structuring poster content | | [Summarise a source paper](/workflows/summarise-source-paper) | Supporting tool — when the source is a poster rather than a paper | ## How to use it in a workflow 1. **Provide the poster** — Upload or provide access to the scientific poster 2. **Run PosterLens** — Extract structured information from the poster content 3. **Review the extraction** — Verify that data points, findings, and conclusions are accurately captured 4. **Use as source material** — Feed the structured extraction into subsequent workflows (summarisation, key message extraction, outline building) 5. **Cite appropriately** — Ensure that the poster is properly cited as the source in any downstream content ## What it does well * Extracts structured data from visually complex poster layouts * Identifies and organises study design, endpoints, results, and conclusions * Handles standard scientific poster formats across therapeutic areas * Produces output that can be used as input for other playbook workflows ## What it does not do * **Does not interpret the data.** PosterLens extracts what the poster presents; it does not assess study quality, interpret results, or draw conclusions beyond what the authors state. * **Does not replace reading the poster.** The extraction is a structured aid, not a substitute for a medical writer reviewing the original poster. * **Does not access unpublished data.** PosterLens works with the content presented in the poster. It cannot verify whether additional analyses or data exist. ## Risk tier Poster extraction is **low risk** as a data extraction task. The risk increases when extracted information is used in downstream workflows (summarisation, messaging, client communications). Review requirements should be set based on the downstream use case, not just the extraction step. [Try PosterLens at PharmaTools.AI →](https://www.pharmatools.ai/posterlens) # PubCrawl Source: https://playbook.pharmatools.ai/tools/pubcrawl Search and explore published literature, clinical trials, and prescribing information to find the evidence that informs your medical writing. ## What it does PubCrawl searches published literature, clinical trial registries, and prescribing information to help medical writers find, explore, and evaluate the evidence base for a project. It supports structured searches across PubMed, trial databases, SmPCs, and USPIs, and can retrieve abstracts, full texts, and citation details for the papers you need. ## The problem it solves Before a medical writer can summarise a paper, extract key messages, or build a content outline, they need to find the right sources. Literature discovery is often the first step in a project, and one of the most time-consuming. Searching PubMed, filtering results, cross-referencing trial registries, and tracking down prescribing information across multiple databases is manual, repetitive work. PubCrawl consolidates this into a single search workflow. The writer defines what they are looking for (by indication, compound, trial ID, or research question) and PubCrawl returns structured results they can evaluate and feed into downstream workflows. ## How it differs from RefCheckr PubCrawl and RefCheckr serve different stages of the content development pipeline: | | PubCrawl | RefCheckr | | ----------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------ | | **When** | Before writing — finding and selecting sources | After writing — verifying and rewriting claims against cited sources | | **Purpose** | Literature discovery and evidence exploration | Closed-loop claim verification, rewrite, and ABPI compliance check | | **Input** | A search query, indication, or compound name | A document with claims and cited references | | **Output** | Papers, abstracts, trial records, prescribing information | A verified, rewritten claim with citations — or pass-through if the original held up | PubCrawl helps you find the evidence. RefCheckr proves you cited it accurately. ## Where it fits in the playbook PubCrawl is most relevant at the start of a project, before the core writing workflows begin: | Workflow | Role | | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | [Summarise a source paper](/workflows/summarise-source-paper) | Supporting tool — find and retrieve the paper before summarising it | | [Extract key messages](/workflows/extract-key-messages) | Supporting tool — identify the evidence base and find related publications | | [Congress / poster summary](/workflows/prepare-congress-or-poster-summary) | Supporting tool — find related publications and trial data alongside poster content | ## How to use it in a workflow 1. **Define your search** — Specify the indication, compound, trial, or research question 2. **Run PubCrawl** — Search across PubMed, trial registries, and prescribing information databases 3. **Review results** — Evaluate the returned papers, abstracts, and records for relevance 4. **Select your sources** — Choose the publications that will serve as source materials for the project 5. **Proceed to the writing workflow** — Feed the selected sources into [Summarise a Source Paper](/workflows/summarise-source-paper), [Extract Key Messages](/workflows/extract-key-messages), or another downstream workflow ## What it does well * Searches PubMed and returns structured citation data and abstracts * Retrieves full-text articles where available * Searches clinical trial registries for trial records and results * Retrieves SmPCs and USPIs for prescribing information * Finds related papers from a starting reference * Supports indication-based and compound-based searches ## How it works PubCrawl is a [Model Context Protocol (MCP)](https://modelcontextprotocol.io) server. MCP is an open standard created by Anthropic that lets AI assistants call external tools securely. In practice, this means PubCrawl connects directly to your AI assistant (Claude Desktop, Cursor, or any MCP-compatible client) and gives it real-time access to PubMed, clinical trial registries, prescribing information databases, and more. When you ask a question about a compound, indication, or trial, the AI calls PubCrawl, which queries the live databases and returns structured, verified results with real PMIDs and DOIs. No API keys required. Install with `npm install -g @pharmatools/pubcrawl` and add it to your client configuration. ## What it does not do * **Does not assess study quality.** PubCrawl finds publications; it does not appraise their methodology or assess risk of bias. * **Does not replace a systematic literature review.** For formal SLRs, PubCrawl can support the search phase but does not replace the structured methodology, screening, or reporting required. * **Does not select your sources for you.** The writer decides which papers are relevant, appropriate, and sufficient for the project. ## Risk tier PubCrawl is used in **low-risk** workflows. It supports the evidence discovery phase, which is a preparatory step before content development begins. The risk sits in what you do with the sources you find, not in finding them. ## Complementary tools PubCrawl is designed for structured biomedical evidence retrieval within a medical writing workflow. Other tools serve different parts of the research process: * [NotebookLM](https://notebooklm.google.com) — upload papers and ask questions grounded in the source text. Useful for familiarising yourself with complex papers, identifying key themes, and preparing for downstream writing. The writer must still verify study design, endpoints, limitations, and interpretation. * [Claude Cowork](https://claude.ai) — work with multiple source documents (papers, protocols, statistical outputs) in a structured project workspace. Useful for analysing several papers together, comparing trial results, and drafting structured sections from supplied sources. The writer remains responsible for verifying that all relevant details were captured. * [Elicit](https://elicit.com) — structured paper extraction and synthesis. Useful during exploratory research or when comparing findings across multiple papers. * [Consensus](https://consensus.app) — fast research question exploration across published literature. Useful for early framing before a structured search. * [Perplexity](https://www.perplexity.ai) — AI-powered search with cited sources. Useful for quick fact-checking, background research, and locating specific claims in the literature. * [Zotero](https://www.zotero.org) / [EndNote](https://endnote.com) — reference library management. Store, organise, and cite the papers PubCrawl helps you find. *** [Try PubCrawl at PharmaTools.AI →](https://www.pharmatools.ai/pubcrawl) # RefCheckr Source: https://playbook.pharmatools.ai/tools/refcheckr Closed-loop AI that verifies, rewrites, and re-checks claims against the source paper. ## What it does RefCheckr is a closed-loop AI system for evidence-supported, ABPI-compliant claims. It verifies claims against the cited source paper, rewrites any that don't match, then re-verifies the rewrite and checks it for ABPI compliance — looping again if anything fails. The output is a claim that has been proven against the paper, not just generated. ## The problem it solves A 20-page detail aid with 40 references takes a senior medical writer 2–3 hours to reference-check manually. After three rounds of revision, accuracy drifts: a hazard ratio gets loosely paraphrased as a percentage reduction, a p-value changes in the text but not in the table, a claim is reworded and now extends beyond what the source actually says. These are among the most common MLR rejection reasons and the most time-consuming to fix late in the approval cycle. RefCheckr doesn't just flag problems — it works the claim until it is supported by the source and aligned with the ABPI Code, then hands a verified claim back for human review. ## How the closed loop works | Step | What happens | Built on | | --------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | **1. Verify** | Checks the claim against the source paper. Detects mismatches in magnitude, endpoint, or population. | Perplexity | | **2. Fix** | Rewrites the claim using only evidence from the paper. Guardrails: no new numbers, no new endpoints, no stronger language. | Claude | | **3. Re-check** | Re-verifies the rewrite against the same paper, then checks ABPI compliance. If anything fails, the loop runs again. | Perplexity + [MedCheckr](/tools/medcheckr) | ## Where it fits in the playbook RefCheckr is most relevant in these workflows: | Workflow | Role | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | [Verify claims against references](/workflows/verify-claims-against-references) | Primary tool — closed-loop claim verification and rewrite | | [Extract key messages](/workflows/extract-key-messages) | Supporting tool — verify and rewrite extracted messages against the source | | [Final human review](/workflows/final-human-review) | Supporting tool — reference accuracy and compliance check as part of final QC | ## How to use it in a workflow 1. **Prepare your content** — Provide the claim and the source paper (or DOI, PMID, or uploaded file) 2. **Run RefCheckr** — The loop runs automatically: verify, fix, re-verify, ABPI compliance check 3. **Review the output** — RefCheckr returns the rewritten, verified, compliance-checked claim with the supporting evidence cited 4. **Decide what to keep** — A human reviewer accepts, edits, or rejects the rewrite before it enters MLR ## What it does well * Verifies claims against the source paper, detecting mismatches in magnitude, endpoint, or population * Rewrites claims using only evidence from the paper, with guardrails against new numbers, new endpoints, or stronger language * Re-verifies the rewrite and checks it for ABPI compliance before returning it * Returns claims that are both evidence-supported and code-aligned, with citations back to the source ## What it does not do * **Does not provide final regulatory or compliance clearance.** RefCheckr is a verification and rewrite tool, not a regulatory approval system. MLR review is still required. * **Does not assess whether the right references were chosen.** It checks claims against the references provided, not whether better or more appropriate references exist. * **Does not replace a trained medical writer's review.** A human must still assess context, appropriateness, and editorial judgement on the rewritten claim. ## Risk tier RefCheckr is used in **high-risk** workflows. A clean closed-loop output does not mean the document is approved — it means the AI has produced a claim that passed its own verification and compliance checks. Manual review by a qualified medical writer or reviewer remains essential. ## Complementary tools RefCheckr focuses on a specific task: producing a claim that is verified against the source and aligned with the ABPI Code. Other tools serve different parts of the reference workflow: * [Scite.ai](https://scite.ai) — citation context analysis. Shows whether a citation supports, contrasts, or merely mentions a claim. Useful as a second layer alongside RefCheckr's claim verification. * [Zotero](https://www.zotero.org) / [EndNote](https://endnote.com) — store, organise, and cite references. Use these to manage your reference library; use RefCheckr to verify claims against those references. * [Elicit](https://elicit.com) — extract and compare findings across papers. Useful when building the evidence base before writing, while RefCheckr is used after writing to verify and rewrite for accuracy. [Try RefCheckr at PharmaTools.AI →](https://www.pharmatools.ai/refcheckr) # Adapt Content for Different Audiences Source: https://playbook.pharmatools.ai/workflows/adapt-for-different-audiences Transform reviewed medical content from one audience level to another while preserving factual accuracy. \~15 min with AI, \~60 min without Enhanced review with source cross-check; higher scrutiny for patient or regulatory content. Reviewed source → AI audience adaptation → Accuracy cross-check → Adapted version ## Best for * Repurposing approved specialist content for GPs, nurses, payers, or patients * Preparing multi-audience materials from a single evidence base * Adapting a technical manuscript summary into a client-facing or internal briefing * Creating tiered stakeholder content from the same core data * Shifting emphasis (e.g., efficacy-led to practical-considerations-led) for a different reader ## Inputs * Source content: reviewed, accurate, with clear references * Target audience specification: be specific (e.g., "community pharmacists in primary care," not just "HCPs") * Context on the target audience's knowledge level, priorities, and information needs * Format or length requirements for the adapted version * Regulatory context for the adapted version (promotional, non-promotional, educational, patient-facing) ## Steps Only adapt content that has already been reviewed for accuracy. This workflow transforms — it does not create. If the source has not been through QC, do that first. Generic audience labels produce generic adaptations. Specify who will read this, what they already know, and what they need from it. Paste the source content along with clear instructions about the target audience, format, and any regulatory context. Use the prompt pattern below. Run the prompt in LLMentor (or Patiently AI for patient audiences). Request multiple options if you are unsure of the right framing. The highest-priority check. Read each clinical claim in the adapted version and confirm it says the same thing as the source — not just something that sounds similar. List every qualifier in the source and verify each is preserved or appropriately rephrased. Confirm safety information has not been compressed out. Check all numbers. If the adapted version has different regulatory requirements from the original (e.g., scientific to promotional, HCP to patient), ensure it meets those requirements before release. ## Output A well-adapted document reads naturally for its target audience, not like a mechanical word substitution of the original. It preserves all essential factual content including safety information, adjusts emphasis to match what the target audience needs most, and contains no claims that cannot be traced to the source content. ## Prompt pattern ``` You are a medical writing assistant specialising in audience adaptation. Your task is to adapt the following content for a different audience. Source content: [INSERT REVIEWED SOURCE CONTENT] Original audience: [SPECIFY — e.g., oncologists, clinical researchers] Target audience: [SPECIFY — e.g., general practitioners, primary care nurses, patients with moderate health literacy] Adaptation requirements: - Adjust language complexity and terminology for the target audience - Maintain all factual accuracy — do not change what the content says, only how it says it - Preserve key data points and findings - Adjust emphasis to reflect the target audience's priorities and information needs - [SPECIFY any format or length requirements] Rules: - Do not add information that is not in the source content - Do not remove safety information or important limitations - If a medical term is simplified, ensure the simplified version is medically accurate - If the source includes specific data (numbers, statistics), retain them unless the adaptation format explicitly calls for a non-data summary - Flag any areas where simplification may have changed the meaning with [REVIEW] ``` **Customisation:** Swap the original and target audience fields to adapt in any direction. For patient-facing adaptations, add explicit instructions about reading level and tone sensitivity. ## Why this works AI handles the mechanical work of adjusting vocabulary, restructuring paragraphs, and shifting emphasis — tasks that are time-consuming but low-risk when done from verified source content. The human writer retains the high-judgement decisions: what the audience needs to know, whether simplified claims still mean the same thing, and whether the adapted version meets its regulatory requirements. ## Common mistakes Source says "Treatment X demonstrated non-inferior efficacy to Treatment Y." The GP-facing adaptation reads "Treatment X works as well as Treatment Y." These are not the same claim. Cross-check every clinical claim line-by-line against the source, reading for meaning rather than surface similarity. Source states efficacy "in patients with moderate-to-severe disease (PASI ≥12)." The adapted version drops the qualifier, making the claim appear to cover all patients. List every qualifier in the source and confirm each one survives the adaptation. Source uses "may provide benefit" or "showed a trend toward improvement." The adaptation writes "provides benefit" or "improved outcomes." Compare certainty levels claim by claim between source and output. A 2-page GP summary drops the safety section to save space, leaving a one-sided efficacy narrative. Safety information must appear in every adapted version. If space is limited, compress — do not remove. AI adds a sentence about mechanism of action or treatment guidelines drawn from its training data rather than the source. Verify that every statement in the output traces to the source content. Flag any sentence that sounds like background context; this is where training data leaks in. ## Tool stack | Tool | Role | | ----------------------------------- | ---------------------------------------------- | | [LLMentor](/tools/llmentor) | Primary tool for audience-level adaptation | | [Patiently AI](/tools/patiently-ai) | When the target audience is patients or carers | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for general-purpose audience rewriting. LLMentor differs in that it is shaped specifically for medical communications audience adaptation, not general text simplification. ## Review checklist * All factual claims in the adapted version match the source content * No new information has been introduced that is not in the source * Safety information is preserved and appropriately represented * Qualifiers and limitations are retained * Language is genuinely appropriate for the target audience (not just slightly simplified) * Medical terms that have been simplified remain accurate * Data points are correctly reproduced * The adapted version meets any regulatory or compliance requirements for the target audience/channel * Emphasis and framing are appropriate for the target audience's priorities * The adapted version would make sense to a reader from the target audience without access to the original *** **Next steps:** If your target audience is patients or carers, use [Create a Plain Language Summary](/workflows/create-plain-language-summary). Once adapted, run [Final Human Review](/workflows/final-human-review) before release, or [Repurpose Across Channels](/workflows/repurpose-content-across-channels) to adapt for different channel formats. *** *Last reviewed: 15 April 2026* # Build a First Content Outline Source: https://playbook.pharmatools.ai/workflows/build-content-outline Organise key messages and source materials into a structured content outline ready for draft development. \~10 min with AI, \~30 min without Standard review; the outline is a planning document, not a final deliverable. Key messages + sources → AI draft outline → Writer refinement → Final outline ## Best for * Starting a new deliverable (slide deck, monograph, manuscript, training material) and establishing structure before writing * Translating a briefing document or messaging framework into a content plan * Organising multiple source documents into a coherent narrative * Preparing an outline for client or internal review before committing to a full draft ## Inputs * Key messages or messaging framework (ideally from the [Extract key messages](/workflows/extract-key-messages) workflow) * Source materials (papers, data packages, briefing documents) * Deliverable specifications: format, audience, channel, and length requirements * Any existing templates or structural requirements for the deliverable type * Client or internal briefing document (if available) ## Steps Confirm the format, audience, purpose, and any structural constraints before generating an outline. If the deliverable has a mandated template (e.g., CSR, regulatory submission), use that directly instead of this workflow. Assemble key messages, source materials, and any approved messaging framework. If you have not yet extracted key messages, complete the [Extract Key Messages](/workflows/extract-key-messages) workflow first. Include the key messages, audience specification, format requirements, and approximate scope. The more context you provide, the more relevant the structure. Use the prompt pattern below. Consider requesting two structural options (e.g., disease-first vs. product-first) so the team can compare approaches. Assess whether the outline matches the deliverable type and narrative strategy. A slide deck for an advisory board needs a different architecture than a monograph. Read the outline as a narrative sequence and check that the audience can follow it without backtracking. Adjust section order, add or remove sections, and annotate with specific content notes or source references. Match section count to the deliverable scope — a 10-slide deck needs 5–7 content sections, not 15. Present the outline to the project team or client for review before proceeding to a full draft. ## Output A structured outline with 5–12 main sections (depending on deliverable type), each with clear headings, a one-sentence content description, mapped key messages, and approximate length guidance. The outline follows a logical narrative progression and includes a defined safety/tolerability section. Any sections with insufficient source evidence are flagged. ## Prompt pattern ``` You are a medical writing assistant. Your task is to create a content outline for the following deliverable. Deliverable type: [SPECIFY — e.g., HCP slide deck, medical education monograph, publication manuscript, training module] Target audience: [SPECIFY] Purpose: [SPECIFY — e.g., communicate Phase III results to oncologists, support payer value discussions] Approximate length/scope: [SPECIFY] Key messages to incorporate: [INSERT KEY MESSAGES] Structure the outline with: - Section headings and subheadings - A one-sentence description of what each section should cover - Notes on which key messages map to which sections - Suggested approximate length or number of slides per section (if applicable) Rules: - Every section should have a clear purpose. Do not include sections that are structural filler. - Ensure the outline flows logically — the reader should be able to follow the narrative from section to section. - Include a section for safety and tolerability unless the deliverable explicitly excludes it. - Flag any sections where you are uncertain about placement or content. ``` **Customisation:** Request multiple structural options (e.g., story-led vs. data-led) when the narrative approach is not yet decided. Add specific structural constraints ("no more than 10 slides", "must include a competitive context section") directly in the prompt. ## Why this works AI generates a logical structure and organises multiple key messages into a coherent sequence in minutes, producing a working framework the writer can evaluate and reshape. The human writer then applies the strategic and editorial judgement (narrative approach, audience-appropriate depth, source allocation, and alignment with the broader communications plan) that turns a generic structure into a fit-for-purpose outline. ## Common mistakes AI defaults to "Background - Methods - Results - Conclusions" when the deliverable needs a story-led flow (unmet need - evidence - clinical impact). Assess whether the structure matches the deliverable type and narrative strategy before accepting it. The outline omits a safety section or skips a competitive context section that the brief requires. Cross-check every requirement in the project brief against the outline and verify all key messages are allocated to at least one section. Evidence sections appear before clinical context is established, or the mechanism section follows efficacy data instead of preceding it. Read the outline as a sequence and ask: would the audience follow this without backtracking? AI generates 15 subsections for a 10-slide deck. Match section count to deliverable scope. If it does not translate to the final format, it is not a useful outline. Key messages from the brief or messaging framework are missing from the outline entirely. Check that every message is mapped to at least one section before signing off. ## Tool stack | Tool | Role | | ------------------------------------------------------------ | ---------------------------------------------------------------------------- | | [Claude](https://claude.ai) / [ChatGPT](https://chatgpt.com) | Generate candidate outline structures from key messages and source materials | **Alternatives:** [Gamma](https://gamma.app) for presentation-specific outlines and slide structuring. [Napkin](https://napkin.ai) for visual concept mapping during early planning. ## Review checklist * Every key message from the brief or messaging framework is allocated to at least one section * No key messages are duplicated across multiple sections without purpose * The narrative arc makes sense for the target audience (e.g., disease burden → unmet need → evidence → clinical implications for an HCP audience) * The structure matches the deliverable format (e.g., slide count for a deck, page allocation for a monograph, module structure for a website) * Safety and tolerability have a defined section — not appended as an afterthought * No sections exist purely as structural filler (e.g., a "Background" section with no defined content scope) * The outline is consistent with the project brief, brand guidelines, and any communications strategy * Section lengths are realistic: a 3-slide section in a 10-slide deck should not contain 5 key messages * Source materials are sufficient to populate each section; flag any section where evidence gaps exist *** **Next steps:** From your outline, proceed to [Write a Manuscript](/workflows/write-a-manuscript), [Draft a Regulatory Document](/workflows/draft-regulatory-document), [Create a Medical Slide Deck](/workflows/create-medical-slide-deck), or [Adapt for Different Audiences](/workflows/adapt-for-different-audiences). Run the completed deliverable through [Final Human Review](/workflows/final-human-review). *** *Last reviewed: 15 April 2026* # Check Document Consistency Source: https://playbook.pharmatools.ai/workflows/check-document-consistency Use AI to flag inconsistencies in patient numbers, endpoint wording, terminology, and cross-references across long documents. \~15 min with AI, \~60 min without AI flags candidate issues. A qualified reviewer must verify each flag and confirm true inconsistencies. Document → Extract key variables → Compare across sections → Flag discrepancies → Manual verification ## Best for * Reviewing CSR drafts for inconsistent patient counts across Methods, Results, and tables * Checking whether endpoint names and definitions are used consistently throughout a document * Verifying table and figure numbering, cross-references, and callouts * Identifying mismatches in treatment arm names or population definitions across sections * Supporting QC on any long document (manuscript, regulatory submission, monograph) before formal review * Catching values that differ between the abstract, body text, and tables ## Inputs * The full document to review (complete draft, not excerpts) * A list of critical variables to check (patient numbers, endpoint definitions, treatment arm names, key data values) * Any reference documents for comparison (protocol, SAP, source tables) ## Steps Before running the check, define what matters most. Common candidates: randomised patient count (N), primary endpoint definition, treatment arm names, key efficacy values (HR, ORR, OS), safety population size, and study duration. The more specific your list, the more useful the check. Use AI to find every instance where each critical variable appears in the document. For example: "Find every mention of the number of patients randomised, the primary endpoint name, and the hazard ratio for overall survival." Review the extracted mentions side by side. Look for numerical mismatches (the abstract says N=450 but Section 9 says N=448), wording inconsistencies (Methods says "progression-free survival" but Results says "time to progression"), and missing qualifiers. Verify that every table and figure callout in the text points to the correct table or figure, and that table/figure numbering is sequential and complete. AI can list all callouts and compare them against the actual table/figure inventory. AI will flag candidate inconsistencies, but not all flags are true issues. A different N in the safety population versus the efficacy population is expected, not an error. Review each flag in context before making changes. Record what was checked, what was flagged, and how each flag was resolved. This creates an audit trail for the QC process and supports the [Final Human Review](/workflows/final-human-review). ## Output A consistency report listing every checked variable, where it appears in the document, and any discrepancies found. Each flag includes the specific text from each location so the reviewer can compare directly. The report distinguishes between confirmed inconsistencies (errors to fix) and expected differences (different populations, different analysis timepoints). ## Prompt pattern ``` You are a medical writing QC assistant. Check the following document for internal consistency. For each variable listed below, find every mention in the document and compare them. Flag any discrepancies in values, wording, or definitions. Variables to check: 1. Number of patients randomised (N) 2. Primary endpoint name and definition 3. Primary endpoint result (HR, CI, p-value) 4. Treatment arm names 5. Safety population size 6. Study duration / follow-up period 7. [ADD ANY PROJECT-SPECIFIC VARIABLES] For each variable: - List every location where it appears (section, page, table) - Quote the exact text at each location - Flag any differences between locations - Note whether the difference appears to be an error or an expected variation (e.g., different analysis populations) Document: [INSERT FULL DOCUMENT TEXT] ``` **Customisation:** For long documents, check one variable category at a time (all patient numbers, then all endpoint mentions, then all key values). For manuscripts, add: "Check that the Abstract results match the Results section exactly." For regulatory documents, add: "Check that section cross-references and table/figure callouts are correct." ## Why this works Long documents develop inconsistencies as they move through drafts, revisions, and contributions from multiple authors. A value corrected in the Results may not be updated in the Abstract. An endpoint name changed in the protocol may persist in its old form in one section. AI scans the entire document and surfaces candidate mismatches far faster than manual reading. The human reviewer then applies the context AI lacks: distinguishing genuine errors from expected differences, and deciding how to resolve each issue. ## Common mistakes The document reports N=450 in the efficacy section and N=448 in the safety section. AI flags this as inconsistent. In reality, 2 patients were excluded from the safety population for valid reasons. Review each flag in context before changing anything. The patient count matches everywhere, but the primary endpoint is defined as "overall survival" in the Methods and "time to death from any cause" in the Results. Both are correct, but inconsistent wording creates confusion. Check definitions and terminology, not just values. The text references "Table 5" but the actual table is numbered Table 6 after a table was added during revision. Cross-reference checks are easy to automate but easy to forget. The abstract is often written first or last and may contain values from an earlier data cut. Always check abstract values against the final body text and tables. AI may miss context-dependent inconsistencies or flag false positives. This workflow supports QC; it does not replace it. Every flagged item must be verified by a qualified reviewer. ## Tool stack | Tool | Role | | ----------------------------- | ------------------------------------------------------------------------------------ | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check document claims against source references | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for document-wide consistency scanning when provided with full text. ## Review checklist * Critical variables (patient counts, endpoint names, key values) have been checked across all sections * Every flagged discrepancy has been reviewed in context * True inconsistencies have been corrected * Expected differences (different populations, analysis types) have been noted and confirmed * Table and figure numbering is sequential and all callouts are correct * Treatment arm names and population definitions are consistent throughout * The abstract matches the body text and tables * Terminology is consistent with the protocol and SAP * The consistency check is documented for audit *** **Next steps:** After resolving inconsistencies, run [Verify Claims Against References](/workflows/verify-claims-against-references) if the document cites external sources. Complete [Final Human Review](/workflows/final-human-review) before submission. *** *Last reviewed: 15 April 2026* # Check Promotional Compliance Source: https://playbook.pharmatools.ai/workflows/check-promotional-compliance Pre-screen content for promotional compliance signals before formal MLR review. \~15 min with AI, \~60 min without Expert compliance-qualified review and formal MLR review required before use. Near-final draft → MedCheckr pre-screen → Expert compliance review → Corrections → MLR-ready content ## Best for * Pre-screening promotional or semi-promotional content before MLR submission * Self-checking a draft for compliance-sensitive language before internal review * Reviewing repurposed content that may have introduced promotional language * Onboarding writers who are building familiarity with advertising code requirements * Catching common MLR rejection triggers early in the content development cycle ## Inputs * The document or content to be reviewed (near-final draft) * The applicable regulatory or advertising code (e.g., ABPI Code, IFPMA Code, FDA promotional regulations) * The approved prescribing information, SmPC, or USPI for the product * Any approved messaging framework or claims matrix * The intended channel and audience for the content ## Steps Compliance pre-screening works best on content close to submission. Running it on rough drafts generates noise and wastes review effort. Determine which advertising code or regulatory framework applies. Different markets, audiences, and content types have different requirements. Submit the content to MedCheckr for automated compliance signal detection. Include the product, indication, and channel context. Assess each flag against the applicable code and approved messaging framework. Not every flag is a genuine issue — a superlative may be appropriate if substantiated. Use the [Verify Claims Against References](/workflows/verify-claims-against-references) workflow or RefCheckr to verify and, where needed, rewrite flagged claims so they align with the cited evidence. Address genuine compliance concerns. Record what was flagged, what was changed, and the rationale for each decision. Submit the revised content through your standard approval process. This pre-screening supports MLR; it does not replace it. ## Output Good output identifies 3–15 potential issues per typical promotional piece, each with the relevant text quoted, a clear description of the concern, and actionable guidance on what revision may be needed. Issues are rated by severity (low/medium/high), and the output explicitly states that formal MLR review is still required. ## Prompt pattern ``` You are a medical communications compliance review assistant. Your task is to pre-screen the following content for potential promotional compliance issues. Content to review: [INSERT CONTENT] Product: [SPECIFY] Approved indication(s): [SPECIFY] Target audience: [SPECIFY — e.g., oncologists, general practitioners] Intended channel: [SPECIFY — e.g., detail aid, leave piece, HCP website, conference stand] Review the content for: 1. Superlative or comparative claims that may require substantiation 2. Language that implies efficacy or outcomes beyond what is supported by the cited references 3. Potential off-label implications or suggestions 4. Areas where safety information may be insufficient relative to efficacy claims (fair balance) 5. Emotive or promotional language that may not be appropriate for the content type 6. Claims that appear to extend beyond the approved indication 7. Unqualified statements that may need hedging or qualification based on the evidence For each issue found: - Quote the relevant text - Describe the potential concern - Suggest what type of revision may be needed - Rate the concern: LOW / MEDIUM / HIGH Rules: - Flag potential issues for human review. Do not make definitive compliance determinations. - Consider the content type and audience when assessing — language appropriate for a scientific publication may not be appropriate for a promotional piece. - If you cannot determine whether something is an issue without access to the full reference, flag it for verification. ``` **Customisation:** Adjust the review criteria based on your market's specific advertising code. For US content, add FDA-specific requirements (e.g., fair balance under 21 CFR 202.1). For UK content, reference the relevant ABPI Code clauses. ## Why this works AI excels at pattern-matching across text — scanning for superlatives, comparative language, emotive phrasing, and other signals that commonly trigger MLR flags. Humans then interpret each flag in context, applying knowledge of the applicable code, the approved messaging, and the clinical evidence. This division catches issues earlier without replacing the qualified compliance judgement that only MLR professionals can provide. ## Common mistakes A clean MedCheckr result means the tool found nothing, not that nothing is there. Teams that reduce their own compliance review effort after a clean scan lose credibility when MLR catches contextual issues the tool was never designed to detect. Always complete your own read-through after pre-screening. MedCheckr may flag 20 items on a leave piece, including appropriate uses of "demonstrated" and "significant" that are fully substantiated. Calibrate expectations: a flag is a prompt to check, not a finding. With experience, reviewers learn which flag types to prioritise. Content intended for a market governed by the PMCPA Code may pass general screening but miss UK-specific fair balance requirements. Always specify the applicable code and have a reviewer with market-specific expertise assess the results. A new ABPI Code clause may have taken effect recently. If the pre-screening tool does not reflect the update, a recently prohibited phrasing could pass undetected. Check results against the current published code, not against the tool's training data. Flagged claims need verification against the cited references, not just assessment of the language itself. A claim may sound promotional but be fully substantiated, or sound neutral but extend beyond what the reference supports. Always cross-check. ## Tool stack | Tool | Role | | ----------------------------- | -------------------------------------------------------------------------------------------------------- | | [MedCheckr](/tools/medcheckr) | Automated compliance signal detection and pre-screening | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check promotional claims against cited references and the ABPI Code | General-purpose models like [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) can support early drafting, but are not sufficient for formal compliance pre-screening. MedCheckr is built specifically for pharmaceutical code-based compliance signal detection. For MLR review of AI-assisted promotional content, the [MLR-with-AI Review Checklist](/templates/mlr-ai-review-checklist) extends a standard MLR checklist with the AI-specific checks (reference integrity, claim drift, fair balance, audit-log review) most likely to fail review. ## Review checklist * All flagged items have been assessed in context by a qualified reviewer * Superlative and comparative claims are substantiated by cited references * Fair balance of efficacy and safety information is appropriate for the content type and audience * No off-label implications or suggestions are present * Claims are consistent with the approved indication(s) * Language is appropriate for the content type and channel * Prescribing information or SmPC references are included where required * The content is consistent with any approved messaging framework or claims matrix * Changes made during pre-screening are documented * The content is ready for formal MLR review *** **Next steps:** [Verify Claims Against References](/workflows/verify-claims-against-references) to confirm claims are supported before MLR submission, then [Final Human Review](/workflows/final-human-review) for QC before the deliverable enters the approval queue. *** *Last reviewed: 15 April 2026* # Convert Statistical Outputs to Narrative Source: https://playbook.pharmatools.ai/workflows/convert-stats-to-narrative Turn tables, figures, and statistical outputs into neutral, regulatory-style prose with exact value preservation. \~10 min with AI per table, \~30 min without Every generated statement must be verified against the source output. No exceptions. Statistical output → Variable extraction → Draft narrative → Value-by-value verification → Final text ## Best for * Drafting CSR results text from TFL (tables, figures, and listings) outputs * Converting adverse event incidence tables into safety narrative summaries * Writing efficacy summaries from primary and secondary endpoint tables * Preparing neutral data narratives for subgroup analyses * Drafting Module 2 summary text from CSR-level statistical outputs * Any task where a table of numbers needs to become a paragraph of text without interpretation ## Inputs * The statistical output, table, or figure to convert (complete, not excerpted) * Context on the analysis population (ITT, mITT, PP) and analysis type * Any formatting or style requirements (MedDRA terms for AEs, decimal precision, CI format) * The section of the document where this text will appear (for context on appropriate detail level) ## Steps Select the specific table, figure, or listing you need to convert. Confirm it is the final, validated output. Drafting from interim or unvalidated tables creates rework when values change. Before generating text, identify what the output contains: treatment arms, endpoints, effect sizes, confidence intervals, p-values, incidence rates, sample sizes. This list becomes your verification checklist. Use AI to convert the output into neutral prose. The instruction is translation, not interpretation: the narrative should say exactly what the table says, in sentence form, without adding meaning or emphasis. Check each number in the generated text against the source output. AI commonly transposes treatment arms, rounds values, omits confidence intervals, or changes "median" to "mean." Every value must match exactly. Ensure the generated text uses consistent phrasing across sections. If the efficacy section says "a statistically significant difference was observed," the safety section should not say "the drug showed a significant effect." Align language with the protocol and SAP. Place the verified narrative into the target section. Check that it flows with surrounding text, that cross-references to the source table are correct, and that the level of detail matches the document section. ## Output Neutral, regulatory-style prose that reports the contents of a statistical output without interpretation. Every value in the text matches the source exactly. The narrative uses consistent terminology, appropriate precision, and language suitable for a regulatory submission. ## Prompt pattern ``` You are a regulatory medical writing assistant. Convert the following statistical output into neutral regulatory-style narrative text. Output type: [INSERT: e.g., "primary efficacy endpoint table" or "adverse event incidence table"] Analysis population: [INSERT: e.g., "ITT population" or "safety population"] Document section: [INSERT: e.g., "CSR Section 11.4.1 — Primary Endpoint"] Statistical output: [INSERT TABLE OR DATA] Rules: - Report the data exactly as presented. Do not round, convert, or reformat values. - Do not interpret the results. Do not use words like "promising," "encouraging," or "demonstrated benefit." - Use neutral language: "was observed," "was reported," "occurred in." - Report effect sizes with confidence intervals and p-values where provided. - For adverse events, use MedDRA preferred terms and report as n (%) by treatment group. - If a result is from a subgroup or post-hoc analysis, state this explicitly. - Flag any value you are uncertain about with [VERIFY]. ``` **Customisation:** For safety tables with many AE terms, add: "Report only AEs occurring in ≥5% of patients in any treatment group, then add a summary line for less common events." For subgroup analyses, add: "Note that subgroup analyses were exploratory and not powered for statistical testing." ## Why this works Converting tables to text is one of the most repetitive tasks in regulatory writing. The content is entirely determined by the source output; the writer's job is accurate translation, not interpretation. AI handles the mechanical conversion at speed while the writer focuses on the verification work that matters most: confirming every value is correct, the language is neutral, and the narrative is consistent with the rest of the document. ## Common mistakes The efficacy table shows Drug X at 42% and placebo at 18%. AI writes "placebo showed a response rate of 42%." This is the single most dangerous error in stats-to-narrative conversion. Verify each value is attributed to the correct arm. The source reports a hazard ratio of 0.683 (95% CI: 0.552–0.845). AI rounds to 0.68 (95% CI: 0.55–0.85). Regulatory documents must reproduce values at the precision reported in the validated output. AI writes "Treatment X showed a clinically meaningful improvement" when the source table only presents numerical results. Remove any language that interprets, characterises, or editorialises the data. AI reports the point estimate but drops the CI or p-value. If the source provides them, the narrative should include them. The efficacy narrative uses "overall survival" but the safety narrative uses "survival time" for the same endpoint. Use the protocol-defined term throughout the document. ## Tool stack | Tool | Role | | ----------------------------- | ---------------------------------------------------------------------------- | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check the narrative against source data | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for table-to-text conversion from pasted statistical outputs. ## Review checklist * Every numerical value matches the source output exactly, at the reported precision * Values are attributed to the correct treatment arm and population * The analysis population (ITT, mITT, PP, safety) is correctly identified * No interpretive or promotional language is present * Confidence intervals and p-values are included where reported in the source * MedDRA preferred terms are used correctly for adverse events * Subgroup and post-hoc results are labelled as such * Terminology is consistent with the protocol, SAP, and other document sections * Cross-references to the source table or figure are correct *** **Next steps:** Integrate the narrative into a [Regulatory Document](/workflows/draft-regulatory-document) or [Manuscript](/workflows/write-a-manuscript). Run [Check Document Consistency](/workflows/check-document-consistency) to verify values match across sections. *** *Last reviewed: 15 April 2026* # Create a Medical Slide Deck Source: https://playbook.pharmatools.ai/workflows/create-medical-slide-deck Structure and draft slide-based content for MSL training, advisory boards, congress updates, or medical education. \~20 min with AI per deck, \~90 min without Enhanced review required. Compliance review needed for external-facing decks. Source materials → Key messages → Slide structure → Draft slide content → Review ## Best for * MSL training decks on new data or therapeutic area updates * Advisory board background and discussion slides * Congress highlights or data update presentations * Internal medical education and training materials * Medical affairs slide sets for field teams * Repackaging published evidence into presentation format ## Inputs * Source materials (published papers, data summaries, approved key messages) * Target audience and setting (e.g., "MSL training on Phase III results" or "advisory board on unmet need in NASH") * Slide count and format requirements * Any existing slide templates or brand guidelines * Regulatory context (internal use only, or external-facing requiring compliance review) ## Steps A deck for MSL training needs depth and nuance. A deck for an advisory board needs discussion prompts. A congress highlights deck needs speed and clarity. The audience determines the structure, depth, and tone of every slide. Gather the evidence that will support the deck. Verify key data points before building slides around them. Correcting a data error propagated across 15 slides is far more work than verifying it once up front. Use AI to generate a candidate slide structure from your key messages and source materials. Specify the slide count. Review the narrative flow: does the audience follow the logic from slide 1 to slide N without backtracking? Generate draft content for each slide: a clear headline, 3–5 bullet points or a concise data summary, and speaker notes where needed. AI handles the mechanical conversion of evidence into slide-ready text; you handle the editorial decisions about emphasis and framing. Check every data point against the source. Confirm that slide headlines do not overstate findings. Verify that safety and limitations are included, not just efficacy highlights. A slide deck that foregrounds efficacy without safety context will fail compliance or scientific review. Ensure the content works as slides, not as compressed paragraphs. Each slide should make one clear point. If a slide needs more than 5 bullets or 3 data points, it probably needs to be split. ## Output A structured slide deck outline with draft content for each slide: headline, body content (bullets, data, or narrative), and speaker notes where applicable. The content is sourced, accurate, and balanced. The deck follows a logical narrative arc appropriate for the target audience and setting. ## Prompt pattern ``` You are a medical writing assistant. Create a slide deck outline and draft content from the following source materials. Audience: [INSERT, e.g., "MSLs being trained on new Phase III data"] Objective: [INSERT, e.g., "understand the study design, key results, and clinical implications"] Slide count: [INSERT, e.g., "12–15 slides"] For each slide, provide: 1. Slide number 2. Headline (one clear statement, not a topic label) 3. Body content (3–5 bullets or a concise data summary) 4. Speaker notes (key talking points for the presenter) Rules: - Base all content on the provided source materials only. - Reproduce data points exactly as stated in the source. - Include at least one slide on safety/tolerability and one on limitations. - Use statement headlines ("Drug X reduced MACE by 24%") not topic labels ("Efficacy Results"). - Flag any content you are uncertain about with [VERIFY]. Source materials: [INSERT SOURCE TEXT] ``` **Customisation:** For advisory board decks, add "Include 2–3 discussion questions per section." For congress highlights, add "Keep each slide to one key finding with the data point and clinical implication." For training decks, add "Include a knowledge-check slide at the end." ## Why this works AI converts dense source materials into slide-structured content quickly, handling the mechanical work of reformatting evidence into headlines, bullets, and speaker notes. The human writer makes the decisions AI cannot: which findings matter most for this audience, whether the narrative builds logically, whether the balance between efficacy and safety is appropriate, and whether the slides will actually work in a presentation setting. ## Common mistakes AI defaults to "Efficacy Results" or "Safety Profile" as slide headlines. These tell the audience what category they are looking at, not what they should take away. Replace with statements: "Drug X met the primary endpoint of PFS at 12 months" or "Most common AEs were manageable and rarely led to discontinuation." AI packs 8 bullets and 3 data tables onto a single slide. If a presenter cannot deliver the slide's message in 60–90 seconds, it has too much content. Split dense slides and prioritise clarity over completeness. A 15-slide deck with 10 slides on efficacy and no safety slide will not pass scientific or compliance review. Include safety and limitations proportionate to their importance in the source data. AI sometimes produces slide content that is a shortened version of a paper paragraph rather than content designed for visual presentation. Slide content should be scannable, with clear data points and short phrases, not miniature essays. A hazard ratio on slide 7 was correct in the source paper but AI rounded it from 0.73 to 0.7 for the slide. Rounding clinical data changes the evidence. Reproduce values exactly as published. ## Tool stack | Tool | Role | | ----------------------------- | ----------------------------------------------------------------------------- | | [LLMentor](/tools/llmentor) | Adapt content depth and complexity for different presentation audiences | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check slide claims against cited sources | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for drafting slide content from source text. [Microsoft Copilot](https://www.microsoft.com/en-us/microsoft-copilot) for in-PowerPoint drafting and structuring. [Gamma](https://gamma.app) for converting structured content into presentation format. [BioRender](https://www.biorender.com) for creating publication-quality biological and mechanism-of-action figures. [Napkin](https://napkin.ai) for concept diagrams. ## Review checklist * Every data point on every slide matches the source exactly * Slide headlines are statements, not topic labels * The narrative arc follows a logical progression for the target audience * Safety and tolerability are included proportionate to the source data * Limitations are noted * No slide contains unsourced claims or AI-generated context * Slide count matches the brief or format requirements * Speaker notes are accurate and add value beyond the slide content * Content is appropriate for the regulatory context (internal vs. external use) * The deck works as a presentation, not as a compressed document *** **Next steps:** For external-facing decks, run [Check Promotional Compliance](/workflows/check-promotional-compliance) and [Verify Claims Against References](/workflows/verify-claims-against-references). For audience-specific versions, use [Adapt for Different Audiences](/workflows/adapt-for-different-audiences). *** *Last reviewed: 15 April 2026* # Create a Plain Language Summary Source: https://playbook.pharmatools.ai/workflows/create-plain-language-summary Draft accessible patient-facing summaries from clinical study reports and published research. \~20 min with AI, \~90 min without Expert review by a medical writer and medical professional required; lay reader testing recommended. Clinical source → AI plain language draft → Expert review → Lay reader testing → Final PLS ## Best for * Developing lay summaries of clinical trial results for EU CTR compliance or sponsor transparency * Creating patient-facing summaries of published studies for disease awareness or education * Preparing plain language content for patient advocacy organisations or support groups * Translating medical information into accessible formats for health literacy purposes ## Inputs * Source document: published paper, clinical study report, results summary, or approved technical summary * Target reading level or health literacy standard (if specified) * PLS format requirements (structure, length, required sections) * Any regulatory or sponsor-specific template requirements (e.g., EU CTR, ICH E6) * Context on the target audience (e.g., patients with the condition, general public, carers) ## Steps Determine the structure, reading level, required sections, and any regulatory template requirements before generating anything. If a specific template is mandated, start from that template. Understand the findings — including safety data and limitations — before generating a draft. You cannot review AI output for accuracy if you have not read the source. Use PLS Generator, Patiently AI, or the prompt pattern below. Provide the full source text, target audience, reading level, and format requirements. The highest-priority step. For each simplified statement, ask: is this still true? Does it preserve the scope and certainty of the original? Check all numbers, percentages, and timeframes. Read the PLS as if you have no medical training. Every technical term should be explained or replaced. Confirm safety information, limitations, and balanced representation of results are all present. A qualified medical professional must review the PLS before it is used. This is not optional. Where possible, test the summary with representative members of the target audience. This catches jargon and framing issues that experts miss. ## Output A good PLS is 500–1500 words, uses short sentences (average 15–20 words) and short paragraphs, and follows the specified structure with clear headings. It presents results in simple terms with both numbers and plain language descriptions, includes safety information in a clearly labelled section, and states what the results mean and what they do not mean. A patient or carer should be able to read and understand it without medical training. ## Prompt pattern ``` You are a medical writing assistant specialising in plain language summaries. Your task is to create a plain language summary of the following clinical study for a non-specialist audience. Target audience: [SPECIFY — e.g., patients with Type 2 diabetes, general public, carers of patients with Alzheimer's disease] Reading level: [SPECIFY — e.g., 8th grade reading level, suitable for adults with average health literacy] Format: [SPECIFY — e.g., structured with headings: Why was this study done? Who took part? What happened during the study? What were the results? What do the results mean?] Source document: [INSERT SOURCE TEXT] Rules: - Write in clear, simple language. Avoid medical jargon. Where a medical term must be used, explain it in plain language. - Accurately represent the study findings. Do not overstate or understate results. - Include information about side effects and safety findings. Do not focus only on positive results. - Include the study limitations as described by the authors. - Do not provide medical advice or recommendations. - Do not include information that is not in the source document. - Use short sentences and short paragraphs. - Explain what the study measured and why, not just the results. ``` **Customisation:** Adjust the Format field to match your regulatory template (e.g., EU CTR required sections). For condition-specific PLS, add audience context such as "patients who have been living with this condition for several years and are familiar with basic treatment options." ## Why this works AI rapidly translates dense clinical language into plain terms and structures content into standard PLS formats, the most time-consuming part of PLS drafting. The human writer retains the decisions that matter most: whether simplified claims are still accurate, whether the benefit-risk balance is fairly represented, and whether the tone is appropriate for patients reading about their own condition. ## Common mistakes Source states "Treatment X met the primary endpoint of ACR20 response at Week 24 (p\<0.001 vs placebo)." The PLS says "The treatment worked." These have different meanings. The patient reads unwarranted certainty. Review every clinical claim and confirm the simplified version preserves scope and certainty. The PLS devotes 400 words to efficacy and two sentences to side effects. A patient reading this gets a distorted benefit-risk picture. Safety should be a clearly labelled, substantive section — not a footnote. Count the proportion of safety content relative to efficacy content. Source measured a biomarker endpoint. The PLS states "Most patients felt better on the treatment." Patients conflate a lab result with how they will feel. Do not translate biomarker endpoints into patient-experience language unless the data supports it. Terms like "randomised," "placebo-controlled," or "hazard ratio" appear without explanation. Read the PLS as a patient with no medical training. Every technical term should be explained or replaced. A PLS intended for EU CTR disclosure omits the required "Why was this study done?" section or fails to include the EudraCT number. Cross-check every section heading and required element against the applicable regulatory template before submission. ## Tool stack | Tool | Role | | ------------------------------------- | -------------------------------------------------------------------- | | [PLS Generator](/tools/pls-generator) | Primary tool for generating structured plain language summary drafts | | [Patiently AI](/tools/patiently-ai) | Simplifying specific medical explanations within the PLS | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for general-purpose simplification. PLS Generator and Patiently AI are built specifically for clinical-to-patient translation, including structured PLS formats and regulatory template support. ## Frequently asked questions Oversimplification usually happens when AI drops qualifiers — "in patients with moderate-to-severe disease," "when added to standard care," "in a subgroup." Prompt the model to preserve every population and context qualifier, then compare the simplified text against the source claim by claim. If meaning has drifted, the simplification has gone too far. Most PLS guidance targets a reading age of 12–14 years (Flesch-Kincaid grade 6–8). Regulatory PLS templates (EMA, sponsor-specific) may specify a level explicitly. AI tools can report reading level, but automated scores miss context — a grade-6 sentence can still be confusing if the concept is unfamiliar. AI can produce a starting draft in another language, but patient-facing translation requires back-translation, cultural review, and health-literacy checks by a native speaker familiar with patient communication norms. Do not publish a machine-translated PLS without that review. Safety is the most common casualty of simplification. Check that the PLS keeps safety information proportionate to the source, names the most important risks using patient-friendly language, and does not relegate safety to a single line at the end. If the source gives safety equal weight to efficacy, the PLS should too. Yes, for many contexts. EU Clinical Trials Regulation requires a lay summary for trials conducted in the EU. Many journals and sponsors require a PLS alongside publications. Requirements vary on length, structure, language, and review process — always check the applicable template before drafting. ## Review checklist * All clinical claims are accurate when compared against the source document * Data points (numbers, percentages, timeframes) are correctly represented * Safety information is included and fairly represents the data * Study limitations are noted * Language is genuinely accessible to the target audience * Medical terms are explained or avoided * No medical advice or treatment recommendations are given * No unsourced information has been added * The PLS is balanced and does not read as promotional or overly positive * Format meets any regulatory or sponsor-specific requirements * Reading level is appropriate (consider using readability testing tools) * Tone is respectful and sensitive to the audience *** **Next steps:** Run [Verify Claims Against References](/workflows/verify-claims-against-references) to confirm simplified claims still match the source, then complete [Final Human Review](/workflows/final-human-review) before the PLS is published or submitted. *** *Last reviewed: 15 April 2026* # Draft a Regulatory Document Source: https://playbook.pharmatools.ai/workflows/draft-regulatory-document Structure and draft regulatory documents from source materials, with AI support for organisation, summarisation, and first-pass text. \~30 min with AI per section, \~2–3 hours without Expert regulatory review required. All content must be verified against source data and applicable guidance. Source documents → Document structure → Section drafting → Source verification → Expert review ## Best for * Drafting CSR sections from study reports and statistical outputs * Structuring investigator brochure updates from accumulated safety and efficacy data * Preparing first-pass protocol summary narratives * Converting study data into Module 2 summary-style text * Drafting safety narrative sections from adverse event listings and summaries * Supporting repetitive regulatory drafting tasks where the source data is well-defined ## Inputs * Source documents (CSR, protocol, statistical outputs, safety data, prior submissions) * Applicable document template or regulatory guidance (ICH structure, sponsor template) * Section-specific requirements (word limits, required content, cross-reference expectations) * Any prior versions or related documents for consistency reference ## Steps Assemble all source documents for the section you are drafting. For a CSR efficacy section, this means the relevant TFL outputs, the SAP, and the protocol. Incomplete source materials produce incomplete drafts. Confirm the template, guidance, or sponsor-specific structure for the document. Regulatory documents follow prescribed formats. AI can help map source content to required sections, but the writer must confirm the structure matches applicable guidance. Provide the relevant source data for each section and use AI to generate a first-pass draft. Work one section at a time. AI handles the mechanical conversion of source data into structured narrative; you verify accuracy, completeness, and appropriate wording. Every statement in the draft must trace to a specific source document, table, or listing. If a sentence cannot be traced, it should be flagged and either sourced or removed. AI-generated regulatory text that sounds authoritative but lacks a source is a submission risk. Regulatory prose must be neutral, precise, and consistent with the source data. Check that AI has not introduced interpretation, softened safety language, or used wording inconsistent with other sections of the same document. Cross-check terminology against the protocol and SAP. A qualified regulatory writer or reviewer verifies the draft against source documents, applicable guidance, and the overall submission strategy. AI-assisted drafts require the same level of review as manually drafted content. ## Output A structured regulatory document section (or full document draft) with neutral, evidence-based prose that follows the required template and can be traced to specific source documents. The output is a working draft ready for expert review and revision, not a submission-ready document. ## Prompt pattern ``` You are a regulatory medical writing assistant. Draft the [SECTION] of a [DOCUMENT TYPE] based on the following source materials. Document type: [INSERT: CSR / Investigator Brochure / Protocol Summary / Module 2 Summary] Section to draft: [INSERT: e.g., "Section 11.4 — Efficacy Results"] Template/guidance: [INSERT any structural requirements] Source materials: [INSERT RELEVANT SOURCE DATA — tables, listings, protocol excerpts] Rules: - Use neutral, regulatory-appropriate language. Do not use promotional or interpretive phrasing. - Reproduce all numerical values exactly as stated in the source. - Do not infer or interpret beyond what the data shows. - If a finding is from a subgroup or post-hoc analysis, state this explicitly. - Maintain consistent terminology with the protocol and SAP. - Flag any content you are uncertain about with [VERIFY]. - If a statement needs a source reference you do not have, insert [SOURCE NEEDED]. ``` **Customisation:** For safety narratives, add: "Present adverse events using MedDRA preferred terms. Report incidence as n (%) for each treatment group." For Module 2 summaries, add: "Summarise at a higher level than the CSR. Focus on clinical significance, not exhaustive detail." ## Why this works Regulatory documents are highly structured and data-driven. Much of the drafting work involves converting source data (tables, listings, study reports) into prescribed narrative formats. AI handles this mechanical conversion efficiently, producing a structured first draft in minutes instead of hours. The regulatory writer then applies the expertise AI lacks: ensuring the wording meets applicable guidance, the data is interpreted appropriately (or not interpreted at all, where neutrality is required), and the document is internally consistent and traceable. ## Common mistakes The source table shows a p-value of 0.06 for a secondary endpoint. AI writes "there was a trend toward improvement." Regulatory prose should report the result and let the data speak. Check every sentence for interpretation that was not in the source. AI describes a serious adverse event as "generally manageable" when the source data does not use that characterisation. Safety sections must reflect the data without editorial softening. Verify safety language against the source listings and tables. The protocol uses "progression-free survival (PFS)" but AI switches between "PFS," "time to progression," and "disease-free survival" within the same section. Use the protocol-defined term consistently throughout. AI adds a sentence about the mechanism of action or disease epidemiology that is not in the source documents. Every statement must trace to a specific source. Flag and remove any content that cannot be sourced. AI generates a logical narrative structure, but it does not follow the required ICH or sponsor template. Always draft into the prescribed structure, not a structure AI invents. Confirm section headings, numbering, and content requirements against the template before drafting. ## Tool stack | Tool | Role | | ----------------------------- | ---------------------------------------------------------------------------------- | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check document statements against source data | **Alternatives:** [Claude Cowork](https://claude.ai) for drafting from multiple source documents (CSR sections, protocols, statistical outputs) in a structured workspace. [Microsoft Copilot](https://www.microsoft.com/en-us/microsoft-copilot) for in-Word drafting in enterprise pharma environments. [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for section drafting from pasted source materials. [Zotero](https://www.zotero.org) or [EndNote](https://endnote.com) for reference management in documents with literature citations. ## Review checklist * Every numerical value matches the source document exactly * Every statement can be traced to a specific source (table, listing, protocol, or report) * No AI-generated interpretation or editorial language is present * Safety data is reported neutrally without softening or minimisation * Terminology is consistent with the protocol and SAP throughout * The document structure follows the required template or guidance * Cross-references to other sections, tables, and figures are correct * No content from AI training data has entered the document * The draft is ready for expert regulatory review, not for direct submission *** **Next steps:** Use [Convert Statistical Outputs to Narrative](/workflows/convert-stats-to-narrative) for data-dense sections. Run [Check Document Consistency](/workflows/check-document-consistency) before final review. Complete [Final Human Review](/workflows/final-human-review) before submission. *** *Last reviewed: 15 April 2026* # Extract Key Messages from Evidence Source: https://playbook.pharmatools.ai/workflows/extract-key-messages Pull evidence-supported key messages from clinical sources, structured for content development and stakeholder communications. \~15 min with AI, \~60 min without Enhanced review with source cross-check required. Source evidence → AI candidate messages → Source cross-check → Verified message set ## Best for * Developing a messaging framework or key message platform for a product or therapeutic area * Preparing for content planning meetings where you need to articulate what the evidence supports * Building briefing documents that connect evidence to communication objectives * Reviewing new data to identify what it adds to the existing evidence story ## Inputs * Full text of the source paper, CSR summary, or data package * Context on intended use of the key messages (e.g., HCP communications, internal briefing, payer value story) * Any existing messaging framework or approved claims for reference * Therapeutic area context and competitive landscape (if relevant to message framing) ## Steps Read the paper or data source yourself. Understand the study design, its strengths, and its limitations before asking AI to extract messages. Give the AI the complete source material together with the intended audience and purpose for the messages. Partial inputs produce incomplete or misframed messages. Use the prompt pattern below to produce a first set of evidence-based messages, organised by category (efficacy, safety, PROs, etc.). Verify that every key message is directly supported by the evidence. Check for overstatement, selective emphasis, missing qualifiers, and conflated endpoints. Edit for accuracy, clarity, and relevance to project objectives. Remove or flag any messages that go beyond what the evidence supports. If an approved messaging framework exists, check alignment and identify genuinely new messages versus restatements of existing ones. Run final messages through RefCheckr — it verifies each message against the cited source, rewrites any that don't match, and re-checks the rewrites for ABPI compliance, looping until each message passes. ## Output A set of 5–15 key messages organised by category (efficacy, safety, PROs, practical considerations), each paired with the specific data point that supports it, the evidence strength (primary endpoint, secondary, subgroup, post-hoc), and any required qualifiers or limitations. Messages use professional, evidence-based language — not promotional superlatives. **Source data (from paper):** > MACE occurred in 8.7% of Drug Y patients vs 11.2% of placebo patients (HR 0.76, 95% CI: 0.63–0.92; p=0.005). CV death occurred in 3.1% vs 4.4% (HR 0.71, p=0.02). Hospitalisation for heart failure occurred in 2.8% vs 4.1% (HR 0.67, p=0.008). Hypotension requiring treatment discontinuation occurred in 2.3% of Drug Y patients vs 0.8% of placebo patients. Renal impairment (eGFR decline ≥40%) was reported in 5.1% vs 3.8%. **AI-generated messages (before review):** 1. Drug Y significantly reduced cardiovascular events by 24% 2. Drug Y demonstrated a major benefit in reducing heart failure hospitalisations 3. Drug Y showed a strong safety profile in cardiovascular patients **Issues caught in review:** * ❌ Message 1: "reduced cardiovascular events by 24%" — should specify MACE, state it's a relative risk reduction, and include the absolute rates and CI * ❌ Message 2: "major benefit" — promotional language not supported by the source; the source presents the data without this characterisation * ❌ Message 3: "strong safety profile" — contradicted by the source data showing higher rates of hypotension requiring discontinuation and renal impairment vs placebo * ❌ No safety messages at all — the set is unbalanced **Reviewed messages (final):** 1. **Efficacy — primary endpoint:** Drug Y reduced the risk of MACE compared to placebo (8.7% vs 11.2%; HR 0.76, 95% CI: 0.63–0.92; p=0.005) 2. **Efficacy — heart failure:** Hospitalisation for heart failure occurred in 2.8% of Drug Y patients vs 4.1% of placebo patients (HR 0.67, p=0.008) 3. **Safety — hypotension:** Hypotension requiring treatment discontinuation was more frequent with Drug Y (2.3% vs 0.8%) 4. **Safety — renal:** eGFR decline ≥40% was reported in 5.1% of Drug Y patients vs 3.8% of placebo patients ## Prompt pattern ``` You are a medical writing assistant specialising in evidence-based messaging. Your task is to extract key messages from the following source document. For each key message: 1. State the message clearly in one sentence 2. Cite the specific data point or finding that supports it (include numbers, endpoints, and statistical results) 3. Note the strength of the supporting evidence (e.g., primary endpoint, secondary endpoint, subgroup analysis, post-hoc) 4. Flag any qualifiers or limitations that should accompany the message Organise messages into these categories where applicable: - Efficacy - Safety and tolerability - Patient-reported outcomes / quality of life - Mechanism / pharmacology - Practical considerations (dosing, administration, etc.) Rules: - Base messages only on the provided source. Do not include information from outside the source material. - Do not overstate findings. If the data shows non-inferiority, do not frame it as superiority. If a result is from a subgroup, say so. - Include relevant safety messages, not just efficacy highlights. - Flag any message where the supporting evidence is exploratory or hypothesis-generating. Source document: [INSERT FULL TEXT] Intended use for these messages: [SPECIFY — e.g., HCP slide deck, internal briefing, messaging framework development] ``` **Customisation:** Add a "Comparator context:" section to the prompt when you need messages framed against a specific competitor. For payer audiences, add an instruction to include any health economic or resource-use data points. ## Why this works AI pulls candidate messages from a dense 15-page paper in minutes, drafting each in a consistent format (message + data point + evidence strength + qualifiers) and organising them by theme. This gives the writer and strategy team a structured starting set to evaluate, rather than starting from scratch, freeing human effort for the judgement calls: which messages matter, how strong the evidence is, and how to frame findings for the specific audience. ## Common mistakes AI states "Treatment X demonstrated superior efficacy" when the trial was designed and powered for non-inferiority. If this enters a messaging framework, it contaminates every downstream deliverable. Review every message against the specific data point cited and ask: does the evidence actually say this? AI foregrounds a striking subgroup result (e.g., 40% improvement in patients \<65) while omitting that the overall population result was modest. Require at least one safety/tolerability message and one limitations message for every set of efficacy messages. AI merges a primary and secondary endpoint into a single message, making both sound like primary results. Verify each message is attributed to the correct endpoint, analysis type, and population. A message about response rates omits that this was in treatment-experienced patients, making it sound like a first-line result. Check every message for population, subgroup, comparator, and analysis-type qualifiers. AI uses language like "best-in-class" or "transformative" that would immediately be flagged in MLR review. Review language for promotional signals before messages are shared with brand or strategy teams. ## Tool stack | Tool | Role | | ----------------------------- | ------------------------------------------------------------------------------------------ | | [PubCrawl](/tools/pubcrawl) | Identify related publications and build the evidence base before extracting messages | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check extracted key messages against the cited source | **Alternatives:** [Claude Cowork](https://claude.ai) for synthesising messages across multiple source documents in a structured workspace. [NotebookLM](https://notebooklm.google.com) for identifying key themes across uploaded papers. [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for initial message brainstorming. [Elicit](https://elicit.com) for cross-paper evidence synthesis. [Otter.ai](https://otter.ai) or [Fireflies.ai](https://fireflies.ai) for transcribing advisory boards, KOL interviews, and focus groups when messages need to come from spoken insight. ## Review checklist * Every key message is directly supported by a specific, cited finding in the source * No message overstates the evidence (e.g., non-inferiority framed as superiority) * Subgroup and post-hoc findings are clearly identified as such * Safety and tolerability messages are included and fairly represent the data * Limitations and qualifiers are noted for each message * Messages are appropriate for the stated intended use * No messages introduce information not present in the source * Messages do not use promotional language unless intended for a promotional context and subject to MLR review * If an existing messaging framework exists, new messages are consistent or flagged as additions *** **Next steps:** Use your key messages to [Build a Content Outline](/workflows/build-content-outline) for a manuscript, slide deck, or other deliverable. Run messages through [Verify Claims Against References](/workflows/verify-claims-against-references) to confirm source support. *** *Last reviewed: 15 April 2026* # Extract Study Data Source: https://playbook.pharmatools.ai/workflows/extract-study-data Pull endpoints, outcomes, and study details from clinical papers into structured evidence tables or data summaries. \~15 min with AI per paper, \~45 min without Enhanced review with source cross-check required for every extracted value. Source papers → AI data extraction → Value-by-value verification → Structured evidence table ## Best for * Building evidence tables for publications, HEOR submissions, or regulatory documents * Extracting endpoints, outcomes, and safety data from multiple papers for cross-study comparison * Creating competitor or landscape summaries from published trial data * Preparing structured data summaries for slide decks, advisory boards, or internal briefings * Supporting systematic literature review data extraction (non-regulatory SLRs) ## Inputs * Full text of the source paper(s) (PDF or pasted text, not abstracts alone) * A defined extraction template specifying which data points to capture (study design, population, endpoints, results, safety) * Context on the intended use (evidence table format, comparison framework, or specific data needs) ## Steps Decide which data points you need before starting. Common fields: study name/acronym, design, population (N, key criteria), primary endpoint, primary result, key secondary results, safety summary, and follow-up duration. Match the template to the downstream deliverable. Paste or upload the complete text. Do not extract from abstracts alone. Abstracts omit subgroup details, secondary endpoints, and safety data that the full paper contains. Use the prompt pattern below to extract structured data into your template format. For posters, use PosterLens first to convert visual content into structured text before extracting. Open the paper's results tables and check every extracted number side by side. AI commonly transposes values between study arms, confuses ITT and per-protocol populations, or rounds numbers differently from the source. Every value must match exactly. Confirm that all required fields are populated and that no key findings have been omitted. Safety data is frequently under-extracted. If the paper reports it, your extraction should capture it. When extracting across multiple papers, maintain consistent terminology and units. A hazard ratio in one paper and a relative risk in another need to be labelled accurately, not treated as interchangeable. ## Output A structured data table or summary with one row per study, containing the specified data fields with exact values from the source papers. Every cell should be traceable to a specific location in the source text. The output uses consistent units, terminology, and formatting across all studies. ## Prompt pattern ``` You are a medical writing data extraction assistant. Extract the following data points from the provided paper into a structured table format. Data points to extract: - Study name / acronym - Study design (phase, randomisation, blinding, control) - Population (N randomised, key inclusion criteria, demographics) - Primary endpoint (definition and result with statistical test, CI, and p-value) - Key secondary endpoints (up to 3, with results) - Safety summary (overall AE rate, grade ≥3 AE rate, most common AEs, discontinuations due to AEs) - Follow-up duration - Authors' conclusions Rules: - Extract values exactly as stated in the paper. Do not round, convert, or interpret. - If a value is not reported, enter "Not reported." - If a result is from a subgroup or post-hoc analysis, label it clearly. - Distinguish between ITT, mITT, and per-protocol populations. - Flag any value you are uncertain about with [VERIFY]. Paper text: [INSERT FULL TEXT] ``` **Customisation:** Adjust the data point list for HEOR extractions (add cost, QALY, resource use), safety-focused extractions (expand AE categories), or competitive landscape summaries (add comparator details and head-to-head data). ## Why this works AI extracts and structures data from dense clinical papers in minutes, consistently applying the same template across multiple studies. This handles the mechanical work of locating values in results sections, tables, and figures. The human writer verifies every value against the source, resolves ambiguities (which population? which analysis?), and makes the judgement calls about completeness and relevance that the extraction template cannot capture. ## Common mistakes AI assigns the treatment arm's result to the placebo arm, or swaps the hazard ratio direction. This is the most common extraction error and the hardest to catch by reading alone. Verify each value against the specific table or figure in the source paper. A paper reports both ITT and per-protocol results. AI extracts the per-protocol result but labels it as ITT. If the paper reports multiple analysis populations, confirm which one your extraction captures and label it explicitly. AI extracts the efficacy endpoints in full detail but reduces safety to "adverse events were consistent with the known safety profile." If the paper reports specific AE rates, grade ≥3 events, and discontinuation rates, your extraction should capture these numbers. One paper reports median OS in months; another reports it in weeks. AI may not flag this inconsistency. When extracting across multiple papers, standardise units or clearly label them to prevent miscomparison. Abstracts are often written before final analysis and may contain rounded or preliminary values that differ from the full paper. Always extract from the full publication, not the abstract. ## Tool stack | Tool | Role | | ------------------------------- | ------------------------------------------------------------------------- | | [PosterLens](/tools/posterlens) | Extract structured content from scientific posters before data extraction | | [PubCrawl](/tools/pubcrawl) | Find source papers if starting from an indication or research question | **Alternatives:** [Claude Cowork](https://claude.ai) for analysing multiple papers or protocols together and extracting structured information across documents. [NotebookLM](https://notebooklm.google.com) for questioning uploaded papers about specific endpoints or results. [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for structured extraction from pasted text. [Elicit](https://elicit.com) for extracting and comparing findings across multiple papers. ## Review checklist * Every numerical value matches the source paper exactly * Values are attributed to the correct study arm and population * The analysis population (ITT, mITT, PP) is correctly identified for each result * Safety data is extracted with the same detail as efficacy data * Subgroup and post-hoc results are clearly labelled * Units are consistent across studies (or clearly labelled where they differ) * All required template fields are populated * "Not reported" is used where data is genuinely absent, not where extraction missed it * The extraction is traceable to specific sections of the source paper *** **Next steps:** Use extracted data to [Extract Key Messages](/workflows/extract-key-messages), build a [Content Outline](/workflows/build-content-outline), or feed into a [Manuscript](/workflows/write-a-manuscript), [Regulatory Document](/workflows/draft-regulatory-document), or [Slide Deck](/workflows/create-medical-slide-deck). For table-to-text conversion, see [Convert Stats to Narrative](/workflows/convert-stats-to-narrative). *** *Last reviewed: 15 April 2026* # Final Human Review Before Use Source: https://playbook.pharmatools.ai/workflows/final-human-review Structured final review process for AI-assisted deliverables before submission or publication. \~30 min with AI support, \~45 min without The reviewer must be qualified for the content type and risk tier. Deliverable → Source verification → Compliance screen → Review checklist → Sign-off ## Best for * Final QC of any AI-assisted deliverable nearing completion * Signing off content that has been through development workflows * Preparing content for MLR review, client submission, or publication * Reviewing content as the named reviewer accountable for quality ## Inputs * The deliverable to be reviewed (near-final version) * All source materials used in its development * Workflow documentation showing how the content was developed (which AI tools and workflows were used) * Any approved messaging framework, claims matrix, or brief * The applicable review checklist (from the workflow card or the [review checklist template](/templates/review-checklist-template)) ## Steps Before checking details, read the entire piece to assess overall quality, flow, and coherence. Note anything that feels off — then verify systematically. Review which workflows and AI tools were used. This tells you where to focus your verification effort, since AI-generated sections need closer scrutiny. Use RefCheckr and manual checking to confirm that every claim, data point, and conclusion is supported by the cited sources. Confirm the right references are cited, not just that claims match their cited references. For promotional or compliance-sensitive content, use MedCheckr as one input to your compliance assessment. This supplements but does not replace your own compliance read. Work through the applicable checklist systematically. Do not skip sections. Check specifically for hallucinated content, meaning drift, unsourced claims, and merged findings from different sources. Fix any issues found and document changes. If the deliverable meets all requirements, sign off with reviewer name and date. If not, return for revision with specific, actionable feedback. ## Output The output is a review decision: Approved, Approved with minor changes (corrections documented), Returned for revision (specific feedback provided), or Rejected (fundamental issues requiring full rework). Good final review produces documented evidence that the deliverable was systematically checked against sources, reviewed for compliance where applicable, and assessed for quality, with a named individual accountable for the outcome. ## Prompt pattern The final human review workflow is primarily manual. However, AI can support the process: ``` You are a medical writing QC assistant. Your task is to help me review the following deliverable against its source materials. Deliverable: [INSERT DELIVERABLE TEXT] Source materials: [INSERT SOURCE TEXTS] Please check: 1. Does every factual claim in the deliverable have support in the source materials? 2. Are all data points (numbers, statistics, endpoints) accurately reproduced? 3. Are there any statements in the deliverable that appear to go beyond what the sources support? 4. Are qualifiers present in the sources (subgroup, post-hoc, exploratory, specific population) preserved in the deliverable? 5. Is safety information present and proportionate to the efficacy content? For each issue found, quote the relevant text from the deliverable and explain the concern. Note: This is a support tool for my review. I will verify all findings manually. ``` **Customisation:** Adjust the checklist emphasis based on content type. Promotional content needs heavier compliance focus; publication summaries need heavier accuracy focus. Limit AI-assisted QC to 3 documents per session to avoid review fatigue. ## Why this works Final review is fundamentally a human activity — AI supports it but cannot replace the judgement calls involved. Automated tools like RefCheckr and MedCheckr catch pattern-level issues at scale, freeing the human reviewer to focus on what AI cannot assess: contextual accuracy, completeness (what is absent, not just what is present), appropriateness of tone and framing, and the accountability that comes with a named sign-off. ## Common mistakes A reviewer QCs five AI-generated summaries in one session. By the fourth, they scan for flow rather than verifying data points. An incorrect confidence interval passes through into a client slide deck. Use the structured checklist for every review and limit AI-assisted QC to 3 documents per session. RefCheckr passes a manuscript summary with no rewrites needed. The reviewer concludes reference accuracy is confirmed. But one claim cites the wrong reference entirely: a mismatch the tool did not detect because it checks claims against cited references, not whether the right reference was cited. Automated tools are one layer, not the whole review. The reviewer has the paper's abstract but not the full text. They cannot verify a subgroup result cited in the deliverable. They pass it, assuming it is correct. It is not. Before starting, confirm full-text access to every cited reference. The reviewer wrote the brief and has been involved for weeks. They expect the content to be correct and read to confirm rather than to challenge. AI-generated errors that "look right" pass through unchallenged. Approach final review as adversarial verification — assume errors are present. A deliverable was AI-assisted by one writer, edited by another, and reviewed by a third. No one is clearly accountable. Document the reviewer name, review date, and review outcome. The sign-off reviewer is accountable regardless of who produced the draft. ## Tool stack | Tool | Role | | ----------------------------- | ------------------------------------------------------------------------------------------- | | [RefCheckr](/tools/refcheckr) | Closed-loop reference accuracy check (verify, rewrite, re-check) as one input to the review | | [MedCheckr](/tools/medcheckr) | Automated compliance signal scan for promotional content | ## Review checklist ### Accuracy * Every factual claim is supported by the cited source * All numerical data matches the source exactly * Study design, populations, and endpoints are correctly described * Conclusions match the authors' stated conclusions * No hallucinated content, data, or citations ### Completeness * All key messages from the brief are addressed * Safety information is present and proportionate * Limitations are noted where appropriate * Qualifiers are preserved (subgroup, post-hoc, exploratory) ### Compliance (where applicable) * Claims are within the approved messaging framework * Fair balance is maintained * No off-label implications * References are correctly cited * Prescribing information requirements are met ### Quality * Language is appropriate for the specific audience and channel (not just generically "professional") * Structure and narrative flow support the deliverable's objective — a reader should follow the logic without needing to backtrack * Length meets the brief requirements and is proportionate across sections (efficacy does not dominate at the expense of safety or context) * Medical terminology is used correctly, consistently, and at the right level for the audience * No grammatical, spelling, or formatting errors — including reference numbering, table formatting, and figure callouts ### AI-specific checks * Sections that used AI assistance are identified and specifically reviewed * No unsourced content from AI training data * No meaning drift from AI transformation or adaptation * No merged findings from different sources or study arms * Automated verification results (RefCheckr, MedCheckr) have been reviewed and acted on * The content reads in your organisation's (or the client's) voice, not in generic AI register — no residual padding, hedging, or substituted near-synonyms for deliberately chosen terminology (see [the Description–Discernment loop](/principles/description-discernment)) ### Documentation * AI tools and workflows used are documented * Changes made during review are tracked * Review outcome is recorded * Reviewer identity and date are documented *** **Next steps:** This review workflow applies to every AI-assisted deliverable. Common preceding workflows include [Verify Claims Against References](/workflows/verify-claims-against-references), [Check Promotional Compliance](/workflows/check-promotional-compliance), and [Create a Plain Language Summary](/workflows/create-plain-language-summary). *** *Last reviewed: 15 April 2026* # Find Evidence Source: https://playbook.pharmatools.ai/workflows/find-evidence Search biomedical databases, screen results, and build an evidence set to support a medical writing project. \~15 min with AI, \~2–3 hours without Standard review of search strategy and selected sources. Research question → Search strategy → Database search → Screen results → Evidence set ## Best for * Starting a new publication or medical affairs project that needs a defined evidence base * Background research for advisory board materials, slide decks, or training content * Identifying key papers for a literature review or competitive landscape analysis * Building an evidence set to support key message development or publication planning * Screening a large set of abstracts to find the most relevant sources quickly ## Inputs * A clearly defined research question, indication, compound, or topic area * Any known key references or authors to use as starting points * Inclusion/exclusion criteria for the evidence you need (publication date, study type, population) * The intended use of the evidence (informs how broad or narrow the search should be) ## Steps Be specific. "What is the efficacy and safety of Drug X in moderate-to-severe plaque psoriasis?" will produce better results than "Drug X psoriasis." Specify the population, intervention, comparator, and outcomes you need (PICO framework). Use AI to generate candidate search terms, MeSH headings, and Boolean combinations. Review and refine these manually. A poorly constructed search returns noise; a well-constructed one saves hours of screening. Execute the search across relevant databases (PubMed, Embase, trial registries, prescribing information). Use PubCrawl for structured biomedical searches or Perplexity for quick exploratory queries with cited sources. Review titles and abstracts against your inclusion criteria. AI can help flag likely relevant results, but the decision to include or exclude a paper is yours. Pay attention to study design, population, and recency. Read the full text of shortlisted papers. Assess relevance, quality, and how each paper fits the project's evidence needs. This is where editorial and scientific judgement matters most. Structure your selected sources for downstream use. Note each paper's key contribution to the project (primary efficacy data, safety profile, comparator data, real-world evidence). Store and cite references using a reference manager. ## Output A curated set of 5–30 source documents (depending on project scope) organised by relevance, with a brief note on each paper's contribution to the project. The evidence set should be traceable back to the search strategy and inclusion criteria, and sufficient to support the downstream writing workflows. ## Prompt pattern ``` You are a medical writing research assistant. Help me build a search strategy for the following research question. Research question: [INSERT RESEARCH QUESTION] Please provide: 1. Suggested PubMed search terms and MeSH headings 2. A Boolean search string combining key concepts 3. Suggested filters (date range, study type, language) 4. Related search terms I may not have considered 5. Key authors or research groups likely to have published in this area Context: - Therapeutic area: [INSERT] - Intended use of evidence: [INSERT, e.g., "publication planning for a review article" or "background research for an advisory board slide deck"] - Any known key references: [INSERT OR "none"] ``` **Customisation:** For systematic-style searches, add a PRISMA-aligned instruction. For competitive landscape work, add comparator compounds and ask for head-to-head trial search terms. ## Why this works AI generates comprehensive search strategies in minutes, surfacing MeSH terms, author names, and Boolean combinations that a manual approach might miss. The human writer retains the decisions that determine evidence quality: defining the research question, setting inclusion criteria, evaluating study relevance, and judging whether the evidence set is sufficient for the project. ## Common mistakes "What is known about Drug X?" returns hundreds of results across indications, populations, and study types. Narrow the question before searching. A 30-second refinement saves an hour of screening. AI can rank and flag abstracts, but it cannot judge whether a particular study design is appropriate for your project, whether the population matches your target, or whether the journal is credible. Source selection is a human decision. PubMed does not index everything. For certain therapeutic areas, Embase, Cochrane, or trial registries (ClinicalTrials.gov, EU CTR) may contain essential evidence that PubMed misses. Match your database selection to the project requirements. An abstract may suggest a paper is relevant, but the full text may reveal a different population, a post-hoc analysis, or an endpoint that does not match your needs. Always read the full text of shortlisted papers before including them in your evidence set. If someone asks how you found your evidence, you should be able to show the search terms, databases, date range, and inclusion criteria. Undocumented evidence gathering cannot be audited or reproduced. ## Tool stack | Tool | Role | | --------------------------- | ---------------------------------------------------------------------------------------------------- | | [PubCrawl](/tools/pubcrawl) | Structured biomedical literature search across PubMed, trial registries, and prescribing information | **Alternatives:** [Claude Cowork](https://claude.ai) for analysing multiple papers together once your evidence set is assembled. [NotebookLM](https://notebooklm.google.com) for exploring and questioning uploaded papers. [Elicit](https://elicit.com) for structured paper extraction and synthesis. [Consensus](https://consensus.app) for fast research question exploration. [Perplexity](https://www.perplexity.ai) for quick fact-checking with cited sources. [Scite.ai](https://scite.ai) for citation context across the literature. [Zotero](https://www.zotero.org) or [EndNote](https://endnote.com) for storing and organising the evidence you find. ## Frequently asked questions Yes — AI is well-suited to generating candidate MeSH headings, Boolean combinations, and related search terms. Treat the output as a first draft. Review every term, confirm the logic maps to your research question, and run the final search in PubMed or Embase directly rather than relying on AI to execute it. It depends on the tool. Many chat interfaces only see the abstract unless you upload the full PDF. For medical writing work, always provide the full text. An abstract summary is not a substitute for the Methods, Results, and Limitations sections that actually determine whether the paper is suitable. AI can flag likely relevant abstracts faster than a manual pass, but the decision to include or exclude a paper is yours. Use it as a ranking aid, not a filter. Always verify that flagged papers match your inclusion criteria by reading the abstract yourself, and spot-check the rejected pile. Completeness depends on project scope. For a review or publication, the set should cover the primary endpoints, key comparators, safety profile, and relevant real-world or landscape context. If a senior reviewer could name an obvious paper you have missed, the set is not complete. Embase, Cochrane, and trial registries (ClinicalTrials.gov, EU CTR) for most therapeutic areas. For health economics or real-world evidence, add HEOR-specific sources. Congress abstracts may only appear on society websites. Match database selection to the deliverable, not to convenience. ## Review checklist * The research question is clearly defined and specific enough for the project * Search terms and Boolean strategy are appropriate and comprehensive * Relevant databases have been searched (not just PubMed) * Inclusion and exclusion criteria are documented * Abstracts have been screened against the criteria * Full texts of shortlisted papers have been reviewed * The evidence set is sufficient for the project's scope and objectives * Key papers in the therapeutic area have not been missed * The search strategy and results are documented for audit *** ## Further reading For a conceptual example of how multiple AI technologies — RAG, generative AI, multimodal systems, and AI agents — can support pharmaceutical workflows, see [A Day in the Life of an MSL Powered by AI: Combining AI Technologies to Transform Training](https://jngr5.com/jngr/article/view/70/53) — published in *Journal of Next-Generation Research 5.0*. *** **Next steps:** Use your evidence set to [Summarise a Source Paper](/workflows/summarise-source-paper), [Prepare a Congress Summary](/workflows/prepare-congress-or-poster-summary), or [Extract Study Data](/workflows/extract-study-data), then [Extract Key Messages](/workflows/extract-key-messages) for content development. *** *Last reviewed: 15 April 2026* # Generate Concept Visuals with AI Source: https://playbook.pharmatools.ai/workflows/generate-concept-visuals Use AI image generation for conceptual figures, visual abstracts, slide visuals, and social graphics — with the guardrails medical content requires. \~5–15 min per visual with AI vs. \~hours with a designer (for early concept mockups) Enhanced review required. Compliance and brand review needed for anything external-facing. Concept brief → Prompt → Generate → Select and refine → Review for accuracy and compliance ## What this is Generative image tools — **Nano Banana 2** (Google), **Midjourney**, and similar — can produce finished-looking imagery from text prompts in seconds. For medical writers, that opens up four practical uses: * **Conceptual figures** that illustrate an idea (mechanism framing, patient journey moments, abstract metaphors) where a literal scientific figure is not required * **Visual abstracts** for social and internal sharing where the graphic supports messaging rather than carries the primary data * **Slide visuals** — background imagery, section dividers, opening-slide hero images, unbranded placeholder visuals * **Social graphics** for internal comms, congress teaser posts, or brand-led awareness content It is not a replacement for BioRender, a medical illustrator, or a qualified designer on regulated deliverables. It is a way to get from "I can picture what this should feel like" to "here is a version we can brief against" without a full design cycle. ## Best for * Early-stage concept mockups before a designer or illustrator is engaged * Internal presentations, town halls, and training material where imagery sets tone rather than conveys data * Visual abstracts on social platforms that foreground messaging, not mechanism detail * Brainstorming visual directions for a campaign or launch * Pitch decks and new business proposals * Stock-image replacement where licensed imagery is too generic or too expensive ## Inputs * A clear concept brief: what should the image communicate, to whom, in what setting * Tone and style references (realistic, illustrative, abstract, photographic, editorial) * Brand parameters where they apply: palette, mood, any visual do-not-use list * Format and aspect ratio (social square, 16:9 slide, 4:5 portrait for LinkedIn, etc.) * A working list of what the image must **not** show (specific drug names, patient likenesses, logos, any element that would imply a regulated claim) ## Tools | Tool | Strengths | When to reach for it | | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | [**Nano Banana 2**](https://gemini.google.com) (Google) | Strong prompt adherence, in-image text rendering, native editing, tight integration with Gemini workflows | When you need text inside the image (labels, teaser copy), iterative refinement, or a free tier for quick concepting | | [**Midjourney**](https://midjourney.com) | Distinctive aesthetic quality, strong on illustration and editorial imagery, deep control over style | When the image needs to look like finished creative work, or when you are exploring a visual direction rather than a literal scene | | [**ChatGPT image generation**](https://chatgpt.com) | Conversational iteration, decent text rendering, integrates directly into a writing workflow | When you want to stay in one tool across text and image | | [**Adobe Firefly**](https://firefly.adobe.com) | Trained on licensed content, commercial-use friendly in many pharma environments | When your organisation's legal or procurement team restricts AI image tools to commercially-safe sources | **A note on rights and provenance.** Check your organisation's policy before using any AI-generated image externally. Some tools offer indemnification; others do not. Some output includes C2PA provenance metadata; most does not yet. ## Prompting patterns AI image prompts do not work like text prompts. Short descriptive phrases, stacked modifiers, and explicit style cues outperform long paragraphs. ### Pattern 1 — Conceptual figure ``` A clean, editorial illustration of [concept, e.g., "a patient journey across three care settings"]. Flat vector style, muted medical palette (teal, slate, warm off-white), no text, centred composition, generous white space, 16:9 aspect. ``` ### Pattern 2 — Visual abstract hero ``` Soft, photographic image evoking [concept, e.g., "early detection and reassurance"]. Natural light, shallow depth of field, calm tone, no people's faces visible, no medical devices, no logos or text. Editorial health-tech feel. 4:5 portrait. ``` ### Pattern 3 — Slide divider or section opener ``` Abstract geometric background suggesting [concept, e.g., "data flowing through a pathway"]. Minimalist, brand-palette-friendly (deep teal, cream accents), low contrast so text can overlay, 16:9. ``` ### Pattern 4 — Social graphic with in-image text (Nano Banana 2, ChatGPT, and Firefly handle in-image text better than Midjourney.) ``` Square social graphic for LinkedIn. Headline text: "What does remission really mean?" Small subhead: "A series on long-term outcomes". Editorial illustration style, off-white background, muted accent colour, no stock-photo look. ``` ### Refinement tips * Name what you want to **exclude** (`no text`, `no people`, `no medical devices`) — it helps more than listing only what you want to include * Iterate in pairs: generate two variants, pick the closer one, refine from there * Use reference images where the tool supports them — a mood board beats a paragraph of adjectives * Keep a "prompt log" alongside the image so you can reproduce, audit, or hand it off ## Reality check AI-generated images look polished, which is exactly what makes them risky in medical content. A plausible-looking image is not a verified one. AI-generated images are useful for **concept communication**. They must not be used as: * **Exact scientific figures** — mechanism of action diagrams, anatomy, molecular structures, dose-response curves, or anything where biological accuracy matters. AI will invent plausible-looking but wrong anatomy, receptor placement, cell types, and molecular geometry. Use [BioRender](https://www.biorender.com) or a medical illustrator. * **Data visualisations** without verification — AI can generate chart-shaped images that are not built from real data. If a number or trend is visible in the image, it is not a data visualisation, it is a decorative graphic that looks like one. Build real charts from real data. * **Anything submitted to a journal as a clinical image or illustration** — as of August 2026, JAMA Network does not permit AI-created or AI-manipulated clinical images, illustrations, video, or audio unless they form part of a formal, disclosed research design. Other journals are moving the same way. Concept visuals for internal use, decks, and briefs are a different matter; check the target journal's policy before anything AI-made goes near a submission. See [Declaring AI Use](/principles/declaring-ai-use). * **Regulatory-facing materials** without review — any image attached to regulatory correspondence, labelling, promotional material subject to MLR, or patient-facing content subject to health literacy review, must go through the same review process as the text it accompanies. Compliance and brand approvers need to see the final image, not the concept. * **Patient depictions implying clinical outcomes** — an AI-generated "happy patient" image in a treatment context can imply benefit. Treat patient imagery in regulated contexts with the same care as a claim. * **Real people, real places, real products** — do not prompt with named HCPs, identifiable patients, competitor branding, or specific-product likenesses. This is a rights and compliance issue before it is an accuracy one. ## Review checklist * The image communicates a concept, not a scientific claim * No invented anatomy, biology, or molecular detail is visible * Any in-image text is spelled correctly and says what was intended * No real people, patients, HCPs, or identifiable locations appear * No competitor or unauthorised logos, packaging, or trade dress * Brand palette, tone, and style guidelines are met * For anything external: MLR, compliance, and brand have reviewed the final image * For patient-facing: health literacy review has seen the final image in context * Rights, licensing, and AI-disclosure requirements for the destination channel are met * The prompt, tool, and date of generation are logged alongside the asset ## Why this works Image generation collapses the cost of the first visual draft to near zero. That changes what a medical writer can bring to a kickoff, a brief, or a concepting meeting — a rough but coherent visual alongside the messaging, rather than a text-only brief that a designer must decode. The designer still owns production; the writer gets to propose. What it does not change is accountability. The writer, the designer, and the review chain remain responsible for every image that leaves the desk. AI shortens the path to the concept; it does not shorten the path through review. ## Common mistakes The most common failure. An editorial-looking "cell signalling" image gets dropped into a slide because it looks good and time is short. A reviewer catches it — or worse, does not. If the image depicts biology, it needs a medical illustrator or BioRender, not a generative model. The AI generates something that looks like a bar chart or Kaplan-Meier curve, and the numbers are invented. The moment an image implies data, it needs to be rebuilt from a real source. Decorative graphs are worse than no graph at all. Visuals in regulated material are in scope for MLR the same way copy is. An image that implies efficacy, safety, or a patient benefit is a claim, even without text. Route it through review. A stakeholder asks "where did this come from?" six months later and there is no answer. Log the tool, prompt, date, and any reference images. The review trail applies to visuals too. A quick "make this look like \[named HCP] presenting at ASCO" prompt is a rights problem before it is a compliance one. Prompt abstractly; keep identifiable people, places, and products out. AI-generated text inside images has improved but still misspells, duplicates letters, or mangles punctuation. Always zoom in and proofread every character before sharing. ## Tool stack | Tool | Role | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | [Nano Banana 2](https://gemini.google.com) | Concept images and visuals with in-image text | | [Midjourney](https://midjourney.com) | Editorial and illustrative concept imagery | | [BioRender](https://www.biorender.com) | Publication-quality biological and mechanism figures (not AI image generation — the right tool when accuracy matters) | | [Claude Design](/tools/ecosystem#claude-design) | Assembling generated imagery into leavepieces, slides, and pitch deck layouts | **Alternatives:** [ChatGPT image generation](https://chatgpt.com) for in-flow generation alongside writing. [Adobe Firefly](https://firefly.adobe.com) where commercial-use provenance is required by procurement or legal. *** **Next steps:** For external-facing concepts, route the final image through [Check Promotional Compliance](/workflows/check-promotional-compliance). For assembling generated imagery into layouts, see [Claude Design](/tools/ecosystem#claude-design). For repurposing across channels, see [Repurpose Content Across Channels](/workflows/repurpose-content-across-channels). *** *Last reviewed: 11 August 2026* # Prepare a Congress or Poster Summary Source: https://playbook.pharmatools.ai/workflows/prepare-congress-or-poster-summary Create structured summaries from scientific posters and congress presentations. \~10 min with AI per poster, \~30 min without Standard to enhanced review; verify all data points against the original poster. Poster → PosterLens extraction → Data verification → Structured summary ## Best for * Producing rapid summaries of relevant presentations during congress coverage * Summarising multiple posters into a congress highlights report * Creating structured extractions from posters as source material for further med comms work * Preparing quick-turnaround congress debriefs for clients or internal stakeholders ## Inputs * The scientific poster (image, PDF, or text extraction) * Any accompanying abstract or oral presentation slides * Context on the therapeutic area and why this poster is relevant * Target format for the summary (e.g., one-page brief, structured extraction, bullet-point format) * Audience for the summary (e.g., medical affairs team, client account lead, publications group) ## Steps Ensure you have access to the complete poster content, not just the abstract. Check that any embargoed data has been cleared for processing. Use PosterLens to extract key information (study design, endpoints, results, conclusions) into a structured format. Verify that PosterLens has accurately captured the poster content. Pay special attention to data from figures, tables, and footnotes, as visual elements are the most common source of extraction errors. Using the structured extraction as source material, draft the summary in the required format. Match the depth and framing to the target audience. Confirm every number, endpoint, and finding in the summary matches the original poster exactly. Check Kaplan-Meier curves, forest plots, and waterfall plots manually. If required, add brief therapeutic area context. Clearly distinguish between information from the poster and contextual information you have added. Confirm the summary is appropriate for the target audience. ## Output A good poster summary runs 200–500 words for a single poster, follows a consistent structure (poster reference, study design, population, primary results, secondary results, safety, conclusions, significance), and contains exact data points from the poster. It distinguishes between presented results and the authors' interpretation, and explicitly notes whether safety data was or was not presented. ## Prompt pattern ``` You are a medical writing assistant. Your task is to create a summary of the following scientific poster presentation. Format the summary with these sections: - Poster reference (authors, title, congress, poster number) - Study design and objective - Key population characteristics - Primary results - Secondary / additional results - Safety findings (if presented) - Authors' conclusions - Relevance / significance (brief — what this adds to the field) Source material: [INSERT POSTER CONTENT OR POSTERLENS EXTRACTION] Target audience for this summary: [SPECIFY] Target length: [SPECIFY — e.g., 300 words, one page, bullet-point format] Rules: - Base the summary only on what is presented in the poster. Do not add data from other sources. - Reproduce data points exactly as presented. - If safety data is not presented on the poster, note this explicitly rather than omitting the safety section. - Flag any data points that are unclear or difficult to read in the source with [VERIFY]. - Do not interpret results beyond what the authors state in their conclusions. ``` **Customisation:** For congress coverage of multiple posters, use a consistent template across all summaries so stakeholders can compare them easily. Adjust the target length and detail level based on whether the summary is for a highlights report (shorter) or detailed briefing document (longer). ## Why this works AI rapidly extracts and organises structured data from visually complex poster layouts, handling the mechanical work of pulling study design, results, and conclusions into a consistent format. The human writer then verifies data accuracy (especially from figures), selects what to emphasise for the audience, and contextualises the findings within the broader congress and evidence landscape. This enables same-day congress coverage at a quality level that manual-only approaches struggle to match. ## Common mistakes A Kaplan-Meier curve shows median PFS of 11.2 months, but the extraction reads it as 12.1 months from the figure. This incorrect number enters a congress highlights report sent to 30 stakeholders. Verify every data point from figures and tables against the original poster manually. Waterfall plots, forest plots, and complex tables contain key results that extraction tools miss because the data is encoded visually rather than as text. Open the original poster and manually check all figures, tables, and footnotes. The poster reports "a numerical trend toward improvement (not statistically significant)." The summary states "improvement was observed." The qualifier vanishes. Compare every result statement against the poster's Results and Conclusions sections. A safety table in a lower panel gets missed by the extraction. The summary reports no safety data when data was in fact presented. Explicitly scan the full poster for AE tables, safety narratives, discontinuation data, and deaths. When summarising 15 posters from a congress, data from Poster #7 leaks into the summary of Poster #8 because AI processes them in sequence. Summarise one poster at a time in separate sessions and verify each against its specific poster. ## Tool stack | Tool | Role | | ------------------------------- | --------------------------------------------------------------------- | | [PosterLens](/tools/posterlens) | Structured extraction of poster content from images and PDFs | | [PubCrawl](/tools/pubcrawl) | Find related publications or trial registry data alongside the poster | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for drafting summaries from extracted poster content. [Napkin](https://napkin.ai) for creating visual summaries of poster data for internal distribution. ## Review checklist * Poster reference (authors, title, congress, poster number) is correct * Study design is accurately described * Population characteristics match the poster * All data points are verified against the original poster * Results from figures and tables are accurately captured * Safety data is included (or noted as not presented) * Authors' conclusions are correctly represented * No data from other posters or sources has been mixed in * Summary format and length meet the project requirements * Summary is appropriate for the target audience *** **Next steps:** Use the summary to [Extract Study Data](/workflows/extract-study-data) or [Extract Key Messages](/workflows/extract-key-messages), then [Repurpose Across Channels](/workflows/repurpose-content-across-channels) for different deliverable formats. *** *Last reviewed: 15 April 2026* # Repurpose Content Across Channels Source: https://playbook.pharmatools.ai/workflows/repurpose-content-across-channels Adapt approved content from one format or channel to another while maintaining accuracy and references. \~15 min with AI per channel, \~45 min without Enhanced review with source cross-check; compliance review if channel changes regulatory context. Approved source → AI channel adaptation → Source cross-check → Channel-ready content ## Best for * Adapting an approved slide deck into a leave piece, email, or website module * Generating consistent content across formats from a single approved source for a multi-channel campaign * Repurposing a publication summary into a client briefing, social media content plan, or training material * Adapting congress highlights into multiple deliverable formats ## Inputs * Source content (reviewed and approved for at least one channel) * Target channel specification (format, length, structure, audience) * Channel-specific requirements (e.g., character limits, module structure, slide-count limits) * Regulatory context for the target channel (promotional, non-promotional, educational) * Any channel-specific style guides or templates ## Steps The foundation must be verified. Repurposing amplifies accuracy — and amplifies errors. Only repurpose from stable, reviewed versions. Specify format, length, structure, audience, and any constraints. A vague brief produces a vague adaptation. Determine what needs to adapt (length, structure, depth, visual emphasis) and what must stay the same (claims, data points, references, safety information). Use LLMentor or the prompt pattern below. Provide the full source content and explicit target channel requirements. Verify that every clinical claim in the repurposed version matches the approved source exactly. Condensing is where meaning drift is most likely and hardest to catch. Confirm the output works natively for the target channel — not just a shortened or lengthened version of the original. If the target channel has different regulatory requirements, run a [compliance check](/workflows/check-promotional-compliance). ## Output Good repurposed content derives clearly from the source but feels native to the target channel. It preserves all key messages, safety information, and reference citations while meeting the structural and length requirements of the target format. It should be immediately usable as a near-final draft after review. ## Prompt pattern ``` You are a medical communications content adaptation assistant. Your task is to repurpose the following content for a different channel. Source content: [INSERT APPROVED SOURCE CONTENT] Source channel: [SPECIFY — e.g., HCP slide deck, 20 slides] Target channel: [SPECIFY — e.g., two-page leave piece, email newsletter for HCPs, website content module] Target channel requirements: - Format: [SPECIFY] - Length: [SPECIFY] - Structure: [SPECIFY any required sections or format constraints] - Audience: [SPECIFY if different from source] Rules: - Preserve all factual claims exactly as they appear in the source. Do not rephrase in ways that change the meaning. - Retain all safety information present in the source. Do not cut safety content to save space. - Maintain reference citations for all claims. - If the target format requires condensing, prioritise: key efficacy messages, safety information, and the study context. - Do not add information that is not in the source content. - Flag any areas where condensing has required significant content reduction with [REVIEW — content reduced]. ``` **Customisation:** Adjust the target channel requirements section to match your organisation's specific format templates. For social media adaptations, add platform-specific constraints (character counts, hashtag conventions, visual ratio requirements). ## Why this works AI is fast at reformatting and condensing content across structures, generating multiple channel versions from a single source for comparison. The human writer then makes the editorial decisions that AI cannot: what to cut when condensing, whether the narrative works in the new format, and whether the regulatory context has changed. This produces channel-native content far faster than writing from scratch, while the source cross-check catches the meaning drift that smooth-reading AI output can mask. ## Common mistakes A 20-slide deck states "Treatment X met the primary endpoint of ACR50 at Week 12 (p\<0.001)." The condensed leave piece reads "Treatment X showed significant improvement in joint symptoms." The specific endpoint, timepoint, and statistical threshold are lost. Cross-check every clinical claim against the approved source. A 2-page leave piece derived from a 20-slide deck drops the 3 safety slides entirely. The result is an efficacy-only document that fails fair balance review. Safety information must be present in every repurposed version. Compress it if needed, but never remove it. AI converts slide deck bullet points into prose, but the result reads like expanded bullet points rather than a cohesive narrative suitable for a print piece. Have someone familiar with the target channel review the output. AI adds a sentence about mechanism of action or treatment guidelines that was not in the approved source. Every statement in the repurposed version must trace to the approved source content. New information requires new approval. Reference superscripts are dropped during reformatting, leaving claims unreferenced. Unreferenced claims in promotional content are an MLR rejection risk. Check that every referenced claim retains its citation in the repurposed version. ## Tool stack | Tool | Role | | --------------------------- | ------------------------------------------------------------------ | | [LLMentor](/tools/llmentor) | Adapt content depth and complexity for different channel audiences | **Alternatives:** [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for channel-specific rewriting. [Gamma](https://gamma.app) for converting content into presentation format. [Napkin](https://napkin.ai) for creating visual summaries or diagrams from text content. ## Review checklist * All factual claims in the repurposed version match the approved source content * Safety information is present and proportionate * Reference citations are retained for all claims * No new information or claims have been introduced * The content genuinely fits the target channel format (not just a shortened/lengthened version) * Length and structure meet the target channel requirements * Regulatory and compliance requirements for the target channel are met * The repurposed version is consistent with the broader campaign or programme * Any significant content reductions are flagged for review *** **Next steps:** Run [Check Promotional Compliance](/workflows/check-promotional-compliance) if the target channel changes the regulatory context, then [Verify Claims Against References](/workflows/verify-claims-against-references) and [Final Human Review](/workflows/final-human-review) before use. *** *Last reviewed: 15 April 2026* # Summarise a Source Paper Source: https://playbook.pharmatools.ai/workflows/summarise-source-paper Turn a published clinical paper into a structured, verified summary ready for downstream medical writing. \~10 min with AI, \~45 min without Standard medical writing review required. Full paper → AI structured summary → Data verification → Final reviewed summary ## Best for * Rapidly digesting source literature at the start of a new project * Preparing evidence summaries or briefing documents for account teams or clients * Building a reference library across a therapeutic area * Creating a foundation summary to feed into content outlines or messaging work * Summarising unfamiliar papers before a project kick-off ## Inputs * Full text of the published paper (PDF or pasted text; do not rely on AI training data) * Any specific focus areas (e.g., "primary endpoint only", "focus on safety results") * Target summary length and format (structured abstract, narrative summary, or bullet-point overview) ## Steps At minimum, read the abstract, results, and conclusions. You need to understand the paper before you can evaluate an AI-generated summary of it. Paste or upload the complete paper. Do not rely on the AI's training data. It may have an incomplete or outdated version of the publication. Use the prompt below, specifying your required output format and any focus areas. Adjust the section structure if the paper type demands it (e.g., a case series vs. an RCT). Open the source paper's results tables and check every numerical value (p-values, CIs, HRs, sample sizes) side by side against the summary. Check that each result is attributed to the correct study arm, population, and analysis type. Fix inaccuracies, add missing safety data, adjust the balance between efficacy and safety, and refine language for your specific audience and purpose. Confirm the summary is accurate, complete for its intended use, appropriately sourced, and contains no unsourced AI-generated context. ## Output A 400–800 word structured summary that follows the specified section format, reproduces numerical data exactly as stated in the source, and clearly distinguishes between primary, secondary, and exploratory endpoints. Any areas of uncertainty are flagged with \[VERIFY] markers. The summary uses professional medical writing language without promotional framing. **Source paper excerpt (results section):** > In the ITT population (n=450), patients receiving Drug X demonstrated a statistically significant improvement in overall survival compared to placebo (median OS: 14.7 months vs 10.3 months; HR 0.68, 95% CI: 0.55–0.84; p=0.0003). The ORR was 42% in the Drug X arm vs 18% in the placebo arm. Grade ≥3 treatment-emergent adverse events occurred in 67% of patients receiving Drug X vs 48% receiving placebo. The most common grade ≥3 AEs were neutropenia (23%), fatigue (12%), and diarrhoea (9%). **AI-generated summary (before review):** > **Primary endpoint:** Drug X significantly improved overall survival in the ITT population, with a median OS of 14.7 months vs 10.3 months for placebo (HR 0.68, 95% CI: 0.55–0.84; p=0.0003). **Response:** The objective response rate was 42% vs 18%. **Safety:** Treatment-related adverse events were manageable, with neutropenia being the most common. **Issues caught in review:** * ❌ "Treatment-related adverse events were manageable": AI editorialised. The source says "treatment-emergent" not "treatment-related", and does not characterise them as "manageable" * ❌ Safety data is incomplete — grade ≥3 AE rate (67% vs 48%), fatigue (12%), and diarrhoea (9%) are omitted * ❌ Missing the qualifier that these results are from the ITT population **Reviewed summary (final):** > **Primary endpoint:** In the ITT population (n=450), Drug X demonstrated a statistically significant improvement in overall survival compared to placebo (median OS: 14.7 months vs 10.3 months; HR 0.68, 95% CI: 0.55–0.84; p=0.0003). **Response:** The ORR was 42% in the Drug X arm vs 18% in the placebo arm. **Safety:** Grade ≥3 treatment-emergent AEs occurred in 67% of patients receiving Drug X vs 48% receiving placebo. The most common grade ≥3 AEs were neutropenia (23%), fatigue (12%), and diarrhoea (9%). ## Prompt pattern ``` You are a medical writing assistant. Your task is to summarise the following published paper into a structured summary. Structure your summary with these sections: - Citation (authors, journal, year) - Study design and objective - Population (key inclusion criteria, sample size) - Primary endpoint and results - Key secondary endpoints and results - Safety findings - Authors' conclusions - Limitations noted by the authors Rules: - Base your summary only on the content of the provided paper. Do not add information from other sources. - Reproduce data points (p-values, confidence intervals, hazard ratios, percentages) exactly as stated in the paper. - If a finding is from a subgroup or post-hoc analysis, state this explicitly. - Do not interpret the results beyond what the authors state. - If you are uncertain about any data point, flag it with [VERIFY]. Paper text: [INSERT FULL TEXT] ``` **Customisation:** Adjust the section headings for non-RCT study types (e.g., replace "Primary endpoint" with "Main findings" for observational studies). Add a "Focus on:" instruction at the top of the prompt if you only need specific sections summarised. ## Why this works AI compresses a 12-page paper into a structured 500-word draft in minutes, consistently extracting standard elements (design, population, endpoints, results, conclusions) even across papers with different reporting structures. The human writer then focuses on the high-value work — verification, emphasis, and contextualisation — rather than blank-page drafting. ## Common mistakes AI can swap hazard ratios (0.67 vs. 0.76), misattribute p-values, or confuse confidence intervals between study arms. Always verify every numerical value against the source paper's results tables before using the summary downstream. AI sometimes combines drug arm and comparator results, or merges ITT and per-protocol populations into a single statement. Check that each result is attributed to the correct arm, population, and analysis type. Summaries that foreground efficacy and omit adverse event data create an unbalanced picture that carries through to every deliverable built from the summary. Cross-check that safety findings are present and proportionate. AI may state the drug "significantly improved outcomes" when the paper reports a trend or a secondary endpoint result. Compare every conclusion statement against the authors' own Discussion and Conclusions sections. AI sometimes adds background information (disease prevalence, standard of care) from training data rather than from the paper. Read the summary with the paper's Introduction open and flag any context not sourced from the provided text. ## Tool stack | Tool | Role | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | [PubCrawl](/tools/pubcrawl) | Find and retrieve the source paper if starting from an indication or research question rather than a specific reference | | [PosterLens](/tools/posterlens) | Extract structured content from scientific posters before summarising | **Alternatives:** [NotebookLM](https://notebooklm.google.com) for source-grounded summarisation and Q\&A across uploaded papers. [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for general-purpose summarisation. [Elicit](https://elicit.com) for finding and comparing related papers. [Perplexity](https://www.perplexity.ai) for quick context checks with cited sources. ## Frequently asked questions Yes, for working drafts — provided you are using an account and model that does not train on your inputs, and that sharing the content is permitted under your organisation's policy. For published papers, copyright still applies. For unpublished CSRs or embargoed content, use an enterprise tool with appropriate data handling. Prompt the model to use only the text you provide and to mark any gap as "not reported." Ask for verbatim quotes for key numerical findings. On review, check that nothing in the summary describes disease background, mechanism, or context that did not appear in the source itself. Match the deliverable. A one-page summary for a content outline needs 300–500 words. A briefing for a senior reviewer may need 1,000+ words with study design, results tables, and limitations. Ask for structured sections (Design, Population, Results, Safety, Limitations) so length follows content, not filler. It can, but the summary will inherit the abstract's blind spots — no Methods detail, no Limitations, no subgroup results. Treat abstract-only summaries as screening tools, not working summaries. If the paper is going to inform a deliverable, summarise from the full text. Every numerical value (sample size, HR, CI, p-value), the analysis population for each result, endpoint definitions, and any stated limitations. Also check that safety is represented proportionately to the source, not minimised in favour of efficacy. ## Review checklist * All data points (p-values, CIs, HRs, ORs, percentages, sample sizes) match the source paper * Study design is correctly described * Population and key inclusion/exclusion criteria are accurate * Primary endpoint result is correct and attributed to the right analysis (ITT, mITT, PP) * Secondary endpoints are accurately summarised * Safety data is present and not minimised * Conclusions match the authors' stated conclusions * No unsourced claims or AI-generated background information * Subgroup and post-hoc results are clearly labelled as such * Summary length and format meet the project requirements *** **Next steps:** Use your summary to [Extract Study Data](/workflows/extract-study-data) or [Extract Key Messages](/workflows/extract-key-messages), then [Build a Content Outline](/workflows/build-content-outline) for your deliverable. *** *Last reviewed: 15 April 2026* # Verify Claims Against References Source: https://playbook.pharmatools.ai/workflows/verify-claims-against-references Systematically check whether document claims are accurately supported by their cited references. \~20 min with AI, \~2–3 hours without Expert review required; verification results must be assessed by a qualified reviewer. Document + references → RefCheckr verify-rewrite-recheck loop → Human review of rewrites → Spot-check unflagged → Corrected document ## Best for * Pre-checking referencing accuracy before MLR (Medical, Legal, Regulatory) review * Reviewing documents that cite multiple references across many claims * Catching reference drift in documents that have been through several revision rounds * Conducting QC on a deliverable before client or internal review ## Inputs * The document to be verified, with clear claim-to-reference mapping * Full text of all cited references (not abstracts alone — partial verification creates a false sense of security) * Any approved messaging framework or key message platform for context on intended claims ## Steps Ensure every verifiable claim has a clear reference citation. Number or label claims if the document does not already do so. Obtain the full text of every cited reference. Use high-quality, text-searchable PDFs. Scanned PDFs with OCR errors cause false flags. Use RefCheckr to verify each claim against its cited reference, rewrite any that don't match, and re-check the rewrites for ABPI compliance — RefCheckr closes that loop automatically. If you don't have RefCheckr, the prompt pattern below produces a verify-only first pass that catches numerical mismatches, language strength discrepancies, and missing qualifiers at scale, leaving the rewrite to you. For each rewrite or pass-through that RefCheckr returns, open the cited reference and confirm the AI's verdict. Do not accept rewrites without checking the source — the closed-loop reduces drift, but a wrong rewrite that passes its own re-check still needs human judgement on context and editorial fit. Automated tools do not catch everything. Manually spot-check 20–30% of unflagged claims, prioritising those with specific numerical data, comparative language, or endpoint results. Apply the rewrites you accepted, fix anything the AI missed, update references, and document the verification outcome. If you made further changes after RefCheckr's closed-loop output, run the loop again to confirm corrections still hold. ## Output A structured verification report covering every verifiable claim, with a clear verdict for each (SUPPORTED, PARTIALLY SUPPORTED, NOT SUPPORTED, CANNOT VERIFY). The report flags numerical discrepancies with exact values from both the document and the reference, highlights language strength mismatches, and notes missing qualifiers — formatted so a reviewer can work through it systematically. **Document claim:** > "Drug Z reduced the risk of disease progression by 45% compared to standard of care (HR 0.55, p=0.002)."¹ **Reference 1 (published paper) states:** > In the per-protocol population, Drug Z was associated with a 38% reduction in the risk of disease progression compared to standard of care (HR 0.62, 95% CI: 0.44–0.87; p=0.006). **Verification output:** | Check | Finding | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Verdict** | NOT SUPPORTED | | **Numerical mismatch** | Document states HR 0.55 and 45% reduction. Reference states HR 0.62 and 38% reduction. | | **p-value mismatch** | Document states p=0.002. Reference states p=0.006. | | **Missing qualifier** | Reference specifies per-protocol population. Document implies ITT by omitting this qualifier. | | **Action required** | Correct HR to 0.62, risk reduction to 38%, p-value to 0.006. Add "in the per-protocol population" qualifier. Confirm with study team whether ITT results are available. | This type of multi-error claim is common after several revision rounds — each edit drifts the numbers slightly further from the source. ## Prompt pattern ``` You are a medical writing QC assistant. Your task is to verify the following claims against their cited references. For each claim: 1. State the claim exactly as it appears in the document 2. Identify the cited reference 3. Find the relevant section of the reference that should support the claim 4. Assess whether the reference supports the claim: SUPPORTED / PARTIALLY SUPPORTED / NOT SUPPORTED / CANNOT VERIFY 5. If partially supported or not supported, explain the discrepancy 6. Flag any numerical mismatches (different p-values, percentages, sample sizes, etc.) 7. Flag any claims where the document uses stronger language than the reference Document claims: [INSERT DOCUMENT TEXT OR CLAIM LIST WITH REFERENCE NUMBERS] Reference materials: [INSERT REFERENCE TEXTS — one per reference, clearly labelled] Rules: - Compare claims strictly against the cited reference. Do not use your general knowledge to fill gaps. - If a reference does not contain information relevant to the claim, mark it as NOT SUPPORTED by this reference. - Note any qualifiers in the reference that are missing from the claim (e.g., subgroup, post-hoc, exploratory). ``` **Customisation:** For large documents, break claims into batches of 10–15 to keep AI output focused. For promotional materials, add a rule to flag any claim that implies superiority without a head-to-head comparison in the reference. ## Why this works AI excels at the mechanical comparison work — scanning dozens of claim-reference pairs for numerical mismatches, language strength discrepancies, and missing qualifiers far faster than manual review. The human reviewer handles what AI cannot: assessing whether a technically supported claim is used in a misleading context, judging whether partial support is sufficient, and catching important omissions from the references. ## Common mistakes A detail aid states "Treatment X reduced hospitalisations by 35%" citing Reference 3. The actual figure is 25%. Automated verification misses it because the reference does mention hospitalisations — just with different numbers. Always spot-check 20–30% of unflagged claims, especially those with specific numerical data. A claim is flagged as unsupported because the tool could not match paraphrased language to the reference text. The claim is actually fine. Review every flag against the source before making changes — false positives create unnecessary rework. A scanned PDF has OCR errors in a results table, and the tool reads "p=0.0O3" instead of "p=0.003" and flags a mismatch. Ensure reference PDFs are high-quality, text-searchable copies. Re-scan or obtain publisher PDFs where possible. A claim about response rates is technically supported by the reference, but the document uses it in a comparative context the reference does not support. The tool sees support; the context is misleading. Assess each claim in the context of the full document narrative, not just as isolated pairs. Verification confirms that claims are supported by cited references. It does not check whether the cited reference is the best available evidence or whether newer data exists. Reference selection quality is a separate editorial and scientific judgement. ## Tool stack | Tool | Role | | ----------------------------- | -------------------------------------------------------------------- | | [RefCheckr](/tools/refcheckr) | Primary tool — closed-loop claim verification, rewrite, and re-check | **Complements:** [Scite.ai](https://scite.ai) for citation context analysis (whether a citation supports, contrasts, or merely mentions a claim). [Perplexity](https://www.perplexity.ai) for quick fact-checking and finding source material to verify against. [Zotero](https://www.zotero.org) or [EndNote](https://endnote.com) for managing and organising the reference library. RefCheckr runs a closed loop — it verifies claims against cited evidence, rewrites any that don't match, and re-checks the rewrites for ABPI compliance; Scite adds context on how that evidence treats the claim; Perplexity can help locate evidence; Zotero/EndNote store and organise it. ## Frequently asked questions AI can flag likely mismatches at scale, which is valuable for long or multi-reference documents. It cannot confirm that a reference genuinely supports a claim — that still requires a human read of the cited passage. Treat AI verification as a triage layer, not a sign-off. A real reference can still be cited in the wrong context. The paper may discuss the same topic but report a different outcome, a different population, or contradict the claim. Verification means confirming the cited passage says *this specific thing*, not that the paper exists. Check each reference independently against the specific part of the claim it is cited for. If two references are cited together, confirm that each one supports the claim on its own, or that together they cover it without gaps. Unclear attribution is a common source of drift. No. AI verification catches a substantial share of mismatches quickly, but it does not replace the human fact-check required before sign-off. Use it to make the human review shorter and more focused, not to remove it. Sometimes. AI can flag when the cited passage reports a different endpoint, population, or outcome than the claim describes. Subtle context errors — a pooled analysis cited for a single-study claim, a post-hoc finding cited as primary — are harder to catch and benefit from expert review. ## Review checklist * All flagged claims have been manually reviewed against the cited reference * A sample of unflagged claims has been spot-checked for accuracy * Numerical data (p-values, CIs, percentages, sample sizes) has been verified against source * Claims use language consistent with the strength of evidence in the source (no overstatement) * Qualifiers present in the source are preserved in the claims (subgroup, post-hoc, exploratory, etc.) * Safety claims are verified with the same rigour as efficacy claims * Any "NOT SUPPORTED" or "PARTIALLY SUPPORTED" flags have been resolved * Changes made during verification have been documented * The document is ready for formal review with reference accuracy confirmed *** **Next steps:** After verifying references, run [Check Promotional Compliance](/workflows/check-promotional-compliance) for promotional content or [Check Document Consistency](/workflows/check-document-consistency) for long documents, then complete [Final Human Review](/workflows/final-human-review) before submission. *** *Last reviewed: 15 April 2026* # Write a Manuscript Source: https://playbook.pharmatools.ai/workflows/write-a-manuscript Draft a scientific manuscript from study data and references, with AI support for structure, section drafting, and synthesis. \~30 min with AI per section, \~2–3 hours without Expert review required. All claims must be verified against source data before submission. Study data + references → Outline → Section drafting → Synthesis and review → Submission-ready manuscript ## Best for * Drafting original research manuscripts from clinical study data * Writing review articles or narrative reviews from a defined evidence base * Preparing conference papers or short communications * Publication support drafting where the medical writer works from a data package and author input * Creating first-draft sections (Introduction, Discussion) to accelerate the authoring timeline ## Inputs * Study data (CSR, data tables, statistical outputs, or published results) * Reference library (full text of key citations) * Author guidance on narrative direction, key messages, and target journal * Target journal author guidelines (word limits, section structure, reference style) * Any existing outline or messaging framework ## Steps Start from an approved outline or build one using the [Build a Content Outline](/workflows/build-content-outline) workflow. The outline should define what each section covers, which data supports it, and the overall narrative arc. Do not start drafting without an agreed structure. Methods is the most mechanical section and the safest starting point for AI. Provide the study design details and let AI structure them into standard reporting format. Verify against the protocol or CSR, not just the data tables. Provide the statistical outputs and data tables. AI structures the results into text, tables, and figure legends. Verify every number. This section has the highest density of values that can be transposed, rounded, or misattributed. Provide the key references and context. AI generates a structured introduction that positions the study within the existing evidence. Check that every contextual claim cites a specific reference and that no background information comes from AI training data. This is the section requiring the most human input. AI can structure the discussion around key findings, but the interpretation, clinical implications, and limitations require author and medical writer judgement. Use AI for a structural first pass, then rewrite substantially. Assemble all sections. Run [Verify Claims Against References](/workflows/verify-claims-against-references) on the full manuscript. Check internal consistency (do the Results match the Abstract? do the Discussion conclusions match the data?). Confirm the manuscript meets the target journal's guidelines. ## Output A complete manuscript draft in IMRaD format (or journal-specified structure) with all sections populated, data accurately represented, references correctly cited, and internal consistency maintained. The draft is ready for author review and revision, not for submission. No manuscript drafted with AI support should be submitted without thorough author review and sign-off. ## Prompt pattern ``` You are a medical writing assistant supporting manuscript development. Draft the [SECTION] of a manuscript based on the following materials. Section to draft: [INSERT: Introduction / Methods / Results / Discussion] Target journal: [INSERT journal name and any specific formatting requirements] Word limit for this section: [INSERT] Key points this section should cover: [INSERT OUTLINE POINTS FOR THIS SECTION] Source materials: [INSERT RELEVANT DATA, REFERENCES, OR STUDY DETAILS] Rules: - Base all content on the provided source materials only. - Reproduce data points exactly as stated in the source. - Cite references using numbered superscripts [1], [2], etc. - Do not add background information from your training data. - If a contextual claim needs a reference you do not have, insert [REF NEEDED]. - Use formal scientific writing style appropriate for peer-reviewed publication. - Flag any content you are uncertain about with [VERIFY]. ``` **Customisation:** Draft one section at a time for better control. For the Discussion, provide a list of key findings to address and any author-specified interpretation points. For review articles, adjust the prompt to synthesise across multiple sources rather than reporting a single study. ## Why this works AI accelerates the mechanical parts of manuscript drafting: structuring Methods from a protocol, converting statistical tables into Results text, and organising Introduction references into a coherent narrative. These are time-consuming tasks where the content is largely determined by the source data. The human writer and authors handle the parts that require scientific judgement: interpreting results, contextualising findings, acknowledging limitations honestly, and ensuring the manuscript tells a coherent story that the data actually supports. ## Common mistakes AI adds a sentence about disease prevalence or standard of care from its training data, not from a cited reference. Every factual statement in the Introduction must cite a specific source. Insert \[REF NEEDED] for any claim that lacks a citation, then find the reference or remove the claim. AI converts a data table into prose and transposes the treatment and placebo arm results. The Results section has the highest error density in AI-assisted drafts. Verify every number against the original statistical output or data table. AI writes "This study demonstrates that Drug X is superior to standard of care" when the study was powered for non-inferiority. The Discussion must reflect exactly what the data shows, using the same language the statistical analysis supports. The Abstract reports a different p-value than the Results. The Discussion references a secondary endpoint that is not mentioned in the Results. After assembling all sections, read the manuscript end-to-end and cross-check key values across sections. A manuscript drafted with AI support is a working draft, not a finished paper. Authors must review the scientific content, interpretation, and conclusions. The medical writer's role is to produce an accurate, well-structured draft that gives authors a strong starting point for their review. ## Tool stack | Tool | Role | | ----------------------------- | ------------------------------------------------------------------------------------- | | [RefCheckr](/tools/refcheckr) | Closed-loop: verify, rewrite, and re-check manuscript claims against cited references | | [PubCrawl](/tools/pubcrawl) | Find references for the Introduction and Discussion | **Alternatives:** [Claude Cowork](https://claude.ai) for working with multiple references and source documents in a structured project workspace. [Microsoft Copilot](https://www.microsoft.com/en-us/microsoft-copilot) for in-Word drafting and editing in enterprise environments. [NotebookLM](https://notebooklm.google.com) for familiarising yourself with source papers before drafting. [Claude](https://claude.ai) or [ChatGPT](https://chatgpt.com) for section drafting from pasted source materials. [BioRender](https://www.biorender.com) for figure creation. [Zotero](https://www.zotero.org) or [EndNote](https://endnote.com) for reference management and citation formatting. ## Frequently asked questions No — not to a standard suitable for submission. AI can draft sections from source material you provide, but the scientific judgement that holds a manuscript together (what to include, how to frame it, how cautiously to interpret findings) is a human responsibility. Use AI as a drafting tool, not an author. Methods and Results are the lowest-risk targets — both are largely mechanical translations of the protocol and output tables into prose. Introduction and Discussion carry more interpretive weight and should be drafted with tighter prompts, grounded in specific references, and reviewed line by line. The Discussion is where interpretive overreach and overstated conclusions appear most often. Draft it from a structured outline that states each point you want to make, the reference supporting it, and the hedging language to use. Expect to rewrite AI-generated Discussion text more heavily than any other section. Instruct the model to use the verbs in the source. Ban a specific list of overclaims ("demonstrates," "proves," "superior," "breakthrough") unless they appear in the original paper. On review, compare each results sentence with its source and check that no hedging has been quietly removed. Most journals now permit AI-assisted drafting if it is disclosed and if humans are listed as authors. Check the specific journal's policy — many require a statement describing how AI was used. AI is not an author; the humans who verified and approved the text are. ## Review checklist * Every data point in Results matches the source data exactly * Every factual claim in the Introduction cites a specific reference * No background information has been added from AI training data * The Discussion accurately reflects the strength of the evidence (no overstatement) * Limitations are discussed honestly and proportionately * Internal consistency across Abstract, Results, and Discussion is confirmed * The manuscript meets the target journal's author guidelines (word count, structure, reference format) * Author review and input has been obtained on interpretation and conclusions * All \[VERIFY] and \[REF NEEDED] flags have been resolved * The manuscript is ready for author sign-off, not just AI-complete *** **Next steps:** Run [Check Document Consistency](/workflows/check-document-consistency) to catch internal mismatches, then [Verify Claims Against References](/workflows/verify-claims-against-references). For regulatory submissions, see [Draft a Regulatory Document](/workflows/draft-regulatory-document). Complete [Final Human Review](/workflows/final-human-review) before submission. *** *Last reviewed: 15 April 2026*