IRB lay summary generation

If by “IRB-ready lay summary” you mean a protocol → participant-facing summary that is accurate enough to survive IRB review with minimal investigator editing, my current pick is:

Best overall: GPT-5.6 + a constrained, source-grounded workflow

I would not choose a model solely on prose quality. The critical problem is factual drift: a 2026 study specifically evaluating LLM-generated lay-language protocols found that even the best-performing model could introduce critical factual errors when prompted to improve the language.www.jmir.org

For the model itself, GPT-5.6 is my first choice, particularly in an appropriately governed healthcare/enterprise environment. Recent medical-model benchmarking found GPT particularly strong on clinician-rated health reasoning and handling uncertainty, although this isn't an IRB-specific benchmark.www.nature.com

The bigger advantage is the workflow:

1. Extract protocol facts first — population, purpose, procedures, duration, randomization, risks, benefits, alternatives, compensation, privacy, contacts.
2. Generate the lay summary only from that extracted fact set, with explicit instructions not to infer or embellish.
3. Run a second-pass “protocol concordance” audit sentence-by-sentence against the source protocol.
4. Run a plain-language/readability pass targeting roughly Grade 6–8.
5. Flag unresolved discrepancies for human review rather than guessing.
6. Produce a source-to-summary traceability table so an investigator can verify every substantive claim.

That structure matters because OHRP explicitly emphasizes understandable language, ordinary words instead of technical terminology, short/conversational sentences, and review by someone unfamiliar with the study. www.hhs.gov NIH's own IRB guidance recommends approximately Grade 6–8 for consent materials.irbo.nih.gov

My ranking

There is interesting evidence for Claude in particular: Anthropic reports strong performance on protocol QA, and it now has dedicated life-sciences/healthcare offerings. www.anthropic.com But the direct 2026 lay-protocol study is a warning against assuming that a model's scientific/protocol performance automatically translates into safe participant-facing summaries.www.jmir.org

If you're handling actual protocols/PHI

Don't put identifiable protocols into a consumer chatbot simply because the model writes well. Use an institutional deployment with the appropriate contractual/privacy controls.

For example, OpenAI currently offers ChatGPT for Healthcare, enterprise controls, no-training-on-customer-data commitments, and BAA-covered configurations for eligible healthcare products. openai.com Anthropic and Google likewise have enterprise healthcare/compliance offerings.trust.anthropic.com

Bottom line: If I were building this today, I'd choose GPT-5.6 as the generation/reasoning engine, but the “system” would actually be a two-pass protocol-grounded pipeline with mandatory factual reconciliation and human sign-off. That's substantially safer and more IRB-defensible than asking any model, “Summarize this protocol for the IRB.”

If you tell me whether you mean (a) an investigator's IRB protocol summary, (b) the participant-facing consent “key information” section, or (c) a plain-language study synopsis for an IRB application, I can give you a concrete prompt + validation rubric + output schema for the strongest setup.

Best system for generating lay-language clinical protocols for IRB review

My recommendation is a source-grounded AI drafting workflow with a standardized prompt, a protocol-to-summary verification checklist, and human review—not an AI tool operating on its own.

If you want a ready-to-use system today, I would start with an approved enterprise version of an LLM such as ChatGPT, Claude, or an institutionally supported equivalent. If your institution has access to the NIH's Research Optimizer, its ConsentCrafter tool is an especially relevant option because it is designed to draft informed consent documents from clinical protocols and can generate a lay summary.irbo.nih.gov

The important distinction is whether you need a short lay summary of a protocol for an IRB submission or a complete lay-language version of the protocol for participants. These are different documents, and the best workflow should support both without confusing them.

1. The strongest options

• 

1. NIH/NCI ConsentCrafter

(Best purpose-built starting point)

Generates a draft informed consent document directly from a protocol using an NIH-approved consent template and can also produce a lay summary. NIH explicitly warns that investigators must review and correct the draft before IRB submission. Access is restricted to people with an NIH login using NIH Wi-Fi or VPN, according to the published guidance.irbo.nih.gov

Official tool information and access instructions

---

• 

2. Institution-approved enterprise LLM

(Best flexible workflow)

A configured LLM can transform a protocol into a lay summary, a participant-facing study overview, or a plain-language explanation of procedures. It can also produce a section-by-section traceability table so that study facts can be checked against the source protocol.

This is my preferred general-purpose approach when the institution does not have a dedicated tool. Use only an environment approved for the sensitivity of the documents being processed.

---

• 

3. NIH protocol templates plus a controlled review workflow

(Best for standardization)

NIH provides templates for certain clinical trials and behavioral or social science research. These are useful for standardizing the source documents, but they do not by themselves convert technical protocols into lay language.www.grants.nih.gov+1

NIH clinical trial protocol templates

2. The most effective workflow

I would build the system around five steps, with the same process used for every protocol.

Step 1 — Establish a source of truth

Provide the approved or current protocol, investigator synopsis, schedule of events, and relevant consent or recruitment templates. Designate the protocol version and date. The AI must not fill gaps by guessing.

---

Step 2 — Generate a structured lay version

Convert technical terminology into everyday language, explain why procedures are performed, and organize content around the questions a participant or nonscientist reviewer would ask.

---

Step 3 — Verify scientific and ethical fidelity

Independently compare the generated text against the source for study design, eligibility, sample size, intervention, procedures, risks, benefits, alternatives, and data handling. Flag missing or conflicting information instead of silently resolving it.

---

Step 4 — Test readability and understanding

Use a readability measure as a screening tool, then have a nonspecialist or representative participant review the document. A sixth- to eighth-grade reading level can be a useful initial target, but comprehension matters more than a score alone. Published feasibility research on AI-generated healthcare summaries found meaningful errors even when readability targets were specified.pmc.ncbi.nlm.nih.gov+1

---

Step 5 — Obtain investigator and IRB review

A qualified study-team member approves the content, resolves flagged discrepancies, and confirms that the final document follows the institution's submission requirements. AI-generated text is a draft, not evidence of IRB approval.

3. A reusable master prompt

This is the prompt I would standardize across studies. It is designed to produce both a lay-language document and an auditable quality-control report.

:::writing{variant="document" id="58214"}

Task: Convert a clinical research protocol into plain language for IRB review

You are an expert clinical research communicator assisting an investigator in preparing a plain-language version of a clinical research protocol.

Objective

Create a clear, accurate, nontechnical description of the study for an audience without medical, scientific, or research training. The output is a draft for investigator review and IRB submission, not a replacement for the technical protocol or an approved informed consent form.

Source requirements

• Treat the supplied protocol as the authoritative source.
• Do not invent, infer, or silently resolve missing or contradictory information.
• Preserve all study-specific facts, numerical values, time periods, procedures, and qualifications.
• If a fact is unclear, mark it [INVESTIGATOR CLARIFICATION REQUIRED].
• Cite the relevant source section or page for each substantive study detail in a separate verification table.

Writing requirements

• Use everyday language, short sentences, active voice, and descriptive headings.
• Define necessary medical or scientific terms at first use.
• Expand acronyms before using them.
• Avoid unexplained jargon, promotional language, and unsupported claims.
• Aim initially for a sixth- to eighth-grade reading level, while preserving scientific accuracy.
• Explain what participants will experience, why each major procedure is performed, and how study participation differs from routine clinical care.
• Distinguish research procedures from usual care.
• Describe uncertainty honestly. Do not imply that participation guarantees a direct benefit.
• Use inclusive, respectful language appropriate to the intended audience.

Required output

1. Plain-language study title.
2. Brief overview of the study and its purpose.
3. Why the study is being conducted.
4. Who may be eligible and who cannot participate, using the supplied criteria.
5. What participation involves, in chronological order.
6. Study duration, visits, tests, treatments, and follow-up.
7. Reasonably foreseeable risks, discomforts, and burdens.
8. Potential benefits and the absence of guaranteed personal benefit, as applicable.
9. Alternatives to participation, if specified.
10. How privacy, confidentiality, and research data are handled, as specified.
11. Voluntary participation and withdrawal, using the applicable source language.
12. Costs, compensation, injury information, and contact details only when provided.
13. A section titled "Questions for the Study Team" listing unresolved information.

Quality-control report

Create a table with:

• Required study element
• Information stated in the source
• Corresponding plain-language wording
• Source section/page
• Status: verified, missing, or requires investigator review

Check especially study design, randomization, placebo or control groups, sample size, eligibility, intervention, procedures, timing, risks, benefits, and data handling.

Finish with: A. A list of all unresolved discrepancies and missing details. B. A readability estimate, if a validated readability tool is available. C. A statement that scientific accuracy, participant comprehension, and institutional IRB requirements still require human review.

Do not claim that the document is IRB-approved or fully compliant. :::

4. How to decide whether the system is working

Do not judge effectiveness solely by how quickly the AI produces a document. Evaluate it against a small set of measurable outcomes.

For a pilot, test the workflow on 10–20 representative protocols, if available. Have clinical experts independently score accuracy and have nonspecialists assess comprehension. Compare the results with your existing manual process before adopting the system institution-wide.

5. Important safeguards for IRB use

• Privacy: Do not upload identifiable patient information, confidential protocols, or restricted research data to a public AI service unless your institution has explicitly approved that use.
• Risk fidelity: Never let simplification minimize serious risks, exaggerate potential benefits, or remove uncertainty.
• Version control: Record the source protocol version, date, AI model or tool, reviewer, and final approval.
• Local requirements: Confirm whether your IRB has a required lay-summary format, word limit, reading-level expectation, or policy on AI-assisted document preparation.

My final recommendation

Start by testing NIH ConsentCrafter if you have eligible NIH access and your primary output is a consent document or study lay summary. Otherwise, use an institution-approved enterprise LLM with the master prompt above and a mandatory source-verification workflow. The available evidence supports AI as a useful drafting aid, but not as a substitute for human verification.pmc.ncbi.nlm.nih.gov+2

One question would help me narrow this to the best actual system for your use case: Are you primarily generating (1) short lay summaries for the IRB application, (2) full plain-language versions of clinical protocols, or (3) patient-facing informed consent forms?

For turning clinical trial protocols into plain-language summaries suitable for IRB workflows, the most effective tools tend to be those that combine protocol extraction, health-literacy rewriting, traceability/audit trails, and human review. There is not yet a universally accepted “best” platform, but these are among the stronger options depending on your needs:

What tends to work best for IRB submissions

For IRB use, I would prioritize:

1. Protocol-grounded generation

   • The tool should pull directly from the approved protocol rather than rely on free-form rewriting.
   • It should preserve endpoints, eligibility criteria, risks, procedures, and visit schedules.

2. Traceability

   • Ability to show where each summary statement came from in the protocol.
   • Version control when amendments occur.

3. Readability controls

   • Target reading level (often around 6th–8th grade for participant materials).
   • Plain-language checks beyond simple word replacement. Research suggests automated health-literacy tools can improve simplification quality when used appropriately.pmc.ncbi.nlm.nih.gov

4. Human review gates

   • AI-generated text should be reviewed by the study team before IRB submission. Even NIH’s own ConsentCrafter guidance emphasizes that generated drafts require careful review for accuracy and completeness.irbo.nih.gov

My shortlist by scenario

• University medical center / investigator-initiated trials: NCI ConsentCrafter (if eligible) + institutional review workflow.irbo.nih.gov
• Pharma/CRO with many protocols: Trelice or Clinials-style platforms with document lifecycle controls.www.trelice.com+1
• Need the highest-quality patient language rather than automation: CISCRP or similar specialized medical communication services.www.trelice.com+3
• Building an internal workflow: a secure LLM deployment with protocol ingestion, structured templates, readability checks, and mandatory medical/regulatory review may outperform generic summarizers.

If you tell me your setting (academic IRB, pharma sponsor, CRO, hospital system) and whether you need only lay summaries or also ICFs, recruitment materials, and IRB forms, I can narrow this to the best-fit tools.