Create a 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

1. Identify format and regulatory requirements

   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.

2. Read the source material yourself

   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.

3. Generate a first draft

   Use PLS Generator, Patiently AI, or the prompt pattern below. Provide the full source text, target audience, reading level, and format requirements.

4. Review every clinical claim for accuracy

   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.

5. Review for readability and completeness

   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.

6. Expert review

   A qualified medical professional must review the PLS before it is used. This is not optional.

7. Lay reader testing

   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

Oversimplified claims that change meaning

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.

Safety data minimised or buried

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.

Biomarker results described as patient experience

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.

Jargon persists without explanation

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.

Missing regulatory template elements

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	Primary tool for generating structured plain language summary drafts
Patiently AI	Simplifying specific medical explanations within the PLS

Alternatives: Claude or ChatGPT 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

How do I stop AI from oversimplifying clinical findings?

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.

What reading level should a plain language summary target?

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.

Can AI translate a PLS between languages?

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.

How do I preserve safety information in a plain language summary?

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.

Are there regulatory requirements for plain language summaries?

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

Human 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 to confirm simplified claims still match the source, then complete Final Human Review before the PLS is published or submitted.

---

Last reviewed: 15 April 2026