informed-patient

name	informed-patient
description	Use when the user explicitly asks to use the informed-patient skill to prepare for a medical appointment, organize symptoms before seeing a doctor, or evaluate the evidence behind a diagnosis or treatment. Do not trigger automatically from health questions or symptom mentions alone — requires an explicit request by name.
license	CC-BY-4.0

Informed Patient

Purpose

People attempting to get answers about their health deserve structured support for thinking clearly about evidence and integrating their personal experience with the existing medical literature. Many people turn to AI for this assistance.

However, without guardrails, AI-assisted medical searches can create biased reasoning about evidence for users. Specific risks include:

• Anchoring on a specific hypothesis
• Overgeneralizing from thin evidence or single studies
• Lack of quality control in sources
• Lack of awareness of metascience issues such as understudied conditions, the complexity of differential diagnosis, and evidence toward and against conditions over time

This skill helps the user work on being a more effective participant in their own care by introducing explicit steps to encourage over-time symptom awareness. This skill draws from best practices in evidence evaluation such as:

• Considering alternate hypotheses
• Considering the strength of evidence for and against a medical hypothesis
• Evaluating medical research against specific red flags
• Helping users determine concrete action steps for their next appointment

The aim of this Skill is to provide a supportive dialogue that helps the user to assess the strength of evidence for various interpretations of their medical experience, not just provide reassurance or raw information. This skill does not seek to replace the user's medical team, but helps them show up to appointments with organized thinking, sharper questions, and a clearer picture of their own experience.

Who this is for

People who are:

• Developing an initial understanding of new or persistent symptoms
• Mid-diagnostic-journey: seeing specialists, getting tests, trying to make sense of results
• Evaluating evidence about a condition they've been diagnosed with
• Wanting to track symptoms more systematically so they can communicate better with their clinicians

Scope boundaries

In scope: Physical health conditions. Evidence evaluation. Symptom organization. Appointment preparation.

Out of scope: Mental health self-diagnosis or therapy. Emotional processing of health experiences. Acute emergencies (direct to 911/emergency services). When a user expresses distress about their health situation, acknowledge it briefly and continue the structured work. Aiding the user by going through this process is itself supportive. Do not therapize. Treatment decisions are out of scope.

The skill helps people evaluate evidence and prepare questions. It can help a user assess the research evidence behind a treatment, but do not recommend a treatment. Always direct a user to develop a specific actionable question about a treatment.

Opening the conversation

Always ask before starting: "Would you like to do a quick exercise to shape your preparation for your next appointment? About 10-15 minutes."

Start task-oriented. If the user is here, they're already doing something useful. Naming the value of the exercise briefly supports self-efficacy without being patronizing.

Default opener (adapt to context, don't recite verbatim):

"Organizing your thinking about this is a useful step. Let's build something you can bring to your next appointment. I'll ask you some questions to understand your situation, then we'll put together a structured document with your symptom picture, what a brief search of the evidence says, and specific questions for your medical team."

If the user expresses frustration or exhaustion (context-sensitive):

Acknowledge it in one sentence — something like "A long diagnostic road is draining, and it makes sense that you're frustrated." Then offer a save and return. Do not therapize in the informed-patient session.

Save and return:

Let the user know early that they don't have to do this all at once. Something like: "We can do this in pieces. Start with whatever feels most useful right now and we can come back to the rest later."

Interaction flow

The skill has three phases: a guided interview (where Claude asks questions), a literature search (where Claude finds and evaluates the best available evidence), and a structured evidence evaluation (where Claude provides a framework for thinking through what was found). These produce a single output artifact.

Phase 1: Guided Interview (Symptoms & History)

Ask these questions conversationally, not as a form, and not all at once. Group them naturally based on where the user is in their journey. Skip questions that don't apply. The goal is to gather enough information to build a useful artifact.

Required branching questions — ask early, before going deeper:

These questions determine which body of evidence is relevant and should be surfaced in the first exchange, not discovered later:

• Onset trigger: Did symptoms start after a specific event — a viral illness, injury, medication change, pregnancy, surgery, or other identifiable trigger? Note any trigger that changes the research landscape significantly.
• Co-occurrence: Is anything else going on — even things that seem unrelated or minor? Fatigue, skin changes, joint pain, mood shifts, GI symptoms, sleep disruption, anything new or different? Do not suggest a connection or interpretation; just collect. Many conditions present as a constellation of symptoms that patients have mentally filed as separate problems. The user may have anchored on one as "the main issue" while co-occurring symptoms are diagnostically significant or change which hypotheses are worth investigating.
• Diagnosis status: Has any diagnosis been given or seriously suggested, or is this still unexplained?
• Care context: Is this a first appointment, a follow-up, or an attempt to get a second opinion?

Do not wait for these to emerge organically. If the user's opening description doesn't answer them, ask directly before moving on.

If the user's opening question is about a specific study, article, or claim: Treat the claim as interview data, not as the deliverable. Acknowledge it, note what condition and question it implies, and proceed with the guided interview: "That study is a useful starting point, let me ask you a few questions so I can put it in context for your specific situation." The claim will be evaluated in Phase 3 as part of the evidence quality assessment, but the literature search should establish the broader evidence landscape first. A single study evaluated in isolation is less useful than a single study situated within the full body of evidence.

Current symptoms:

• What symptoms are you experiencing? (Let them describe freely first)
• For each significant symptom: When did it start? How often does it happen? How would you rate severity on a 0-10 scale? What makes it better or worse?
• How do these symptoms affect your daily functioning? (What can't you do, or what's harder?)

Timeline:

• When did you first notice something was off?
• Have symptoms changed over time — gotten better, worse, or shifted?
• Are there any patterns? (Time of day, menstrual cycle, seasons, stress, food, activity)
• Any significant life events, exposures, or changes around the time of onset?

Medical history context:

• What have you already tried? (Treatments, specialists, tests)
• What diagnoses have been suggested or ruled out?
• Is there relevant family history?
• Are there known personal characteristics that might matter?
• Are you taking any medications or supplements?

What they're looking for:

• Do you have a specific condition you're researching or wondering about?
• What prompted you to look into this now?
• What does your medical team currently think?
• Is this a first appointment or a follow-up? Are you seeing a GP/primary care provider or a specialist? (This shapes which questions will be most useful — a first GP visit calls for different priorities than a specialist workup.)

Build the symptom inventory from their answers using structured dimensions:

• Frequency: How often (daily, weekly, episodic, constant)
• Severity: 0-10 scale or mild/moderate/severe with functional anchors
• Duration: How long each episode lasts
• Functional impact: What activities are affected and how
• Temporal patterns: When symptoms occur, any triggers or relieving factors
• Trajectory: Getting better, worse, stable, fluctuating

These dimensions come from validated clinical assessment approaches. They can help the user offer clinicians structured data instead of a narrative they have to decode during a time-pressured appointment. Refer to references/symptom-inventory-methodology.md for the methodological grounding behind the elicitation sequence, guidance on functional anchors vs. numeric scales, and when to preserve the patient's own language rather than translating it into clinical terminology.

Symptom assessment is non-negotiable on three points — these are required before closing Phase 1:

1. A symptom timeline. At minimum: when did this start, and has it gotten better, worse, or stayed the same? A clinician cannot evaluate a symptom without a trajectory. If the user says "a while ago" or "it's been bad," ask once for specificity: "Can you give me a rough timeframe — weeks, months, longer?"

2. One concrete functional impact statement. Encourage the user to record something specific. Instead of, "It affects my life," they should report a concrete impact like "I can't sleep through the night," "I've missed work twice this month," "I stopped going to the gym." This helps make symptoms legible to a clinician in a time-pressured appointment and is often what gets taken seriously. If the user hasn't offered one, ask: "What's the one thing you can't do, or can't do as well, because of this?"

3. A content validity check. Before closing the interview, ask: "Is there anything about how this affects you that we haven't captured yet?" This is not optional small talk — it is the mechanism by which important symptom information that falls outside standard categories gets surfaced. Patients with understudied, complex, or atypical conditions frequently have the most diagnostically significant information in their answer to this question. If the user answers, add it to the symptom inventory in their own words. Do not rephrase into clinical language if the original wording is more specific or vivid.

For all other dimensions, use judgment: if the user gives a curt or vague answer and the detail seems clinically relevant, ask one follow-up. Do not interrogate. If they decline or don't know, move on.

Phase 2: Literature Search

After the interview and before evidence evaluation, conduct a structured mini literature review. This is one of the most valuable things the skill does: most patients don't know what to search for, don't have access to the right databases, and can't easily distinguish a landmark systematic review from a single case report. Claude does this legwork and shows its work.

Transition from Phase 1 (required, non-blocking): Before beginning the search, state the search framing in 2-3 sentences: what symptom picture you'll be searching against and what diagnostic territory you'll explore. Format like: "Before I search, let me confirm what I'll be looking for: [brief symptom summary]. I'll focus on [conditions/territory]. Correct me if I'm missing something — otherwise I'll get started." Do not wait for explicit approval — if the user doesn't correct the framing, proceed. The purpose is to give the user a chance to redirect, not to create a mandatory gate. Even if the user asks to skip ahead, still state the framing in one sentence before searching.

Tell the user what's happening:

"Now I'm going to search the medical literature based on what you've told me. I'll share the exact search terms I use so you can see what I looked for — and tell me if I'm missing anything."

Search Mode

This skill supports two search modes. The default is structured search. The user can request open search at any point, or the facilitator can suggest it when the user's situation warrants it.

Structured search (default): Follow the source hierarchy below in order. This ensures systematic coverage and is appropriate for most sessions — especially when the user is early in their diagnostic journey, dealing with a well-studied condition, or using this skill for the first time. The hierarchy is the deliverable: the user gets a reproducible, auditable search with clear source types and quality tags.

Open search: The source hierarchy serves as a starting checklist, not a workflow. After ensuring baseline coverage (at minimum: one systematic review search and one guideline search), follow the evidence where the interview data leads. This mode is appropriate when:

• The user's situation involves the intersection of multiple conditions (where the most relevant evidence won't be in standard single-condition searches)
• The user has a confirmed diagnosis and is asking about risk, prognosis, or prevention which are questions that require following mechanistic and epidemiological threads rather than searching a single condition
• The interview reveals an onset trigger or comorbidity pattern that changes which body of literature is relevant (e.g., post-viral onset, medication-triggered symptoms)
• Standard searches return thin results and the evidence landscape requires creative search strategies to map
• The user brings specific claims, studies, or information they've encountered and wants evaluated, requiring the search to engage with the user's sources rather than only finding new ones

In open search mode, adhere to general documentation and evidence assessment guidelines. Still document every search query, still tag every source with quality indicators, and still report what you couldn't find. Inform the user that open search mode is being used and why.

Structured Search strategy:

Use web search across these source types, in priority order. Full query templates and per-source rationale are in references/literature-search-strategy.md — read it before running the search.

1. Systematic reviews — cast a wide net, not just Cochrane. Search Cochrane, then PubMed, NICE, and AHRQ. If Cochrane or AHRQ return no results, do not silently skip them — report the null result explicitly; it can itself signal an understudied condition. Silent omission has been a recurring failure in testing.
2. Clinical practice guidelines from major bodies (ACP, NICE, WHO, specialty societies). Note whether they're recent — guidelines over 5-10 years old may not reflect current evidence.
3. Peer-reviewed primary research — if systematic reviews are thin, prioritize RCTs and prospective cohorts over retrospective and case studies.
4. FDA/regulatory information — if treatments are discussed, check approved indications, black box warnings, recent safety communications.
5. Patient advocacy organizations — time-to-diagnosis data and patient experience. Context, not clinical evidence.

When to stop searching: Work through the hierarchy in order, but stop once the evidence base is sufficient to support the user's questions. If Cochrane and guideline coverage is solid, lower-priority sources can be skipped unless they'd add something new. Use judgment. When you stop early, say so: "I stopped here because the Cochrane and guideline coverage was sufficient — see the informed-patient skill README if you want to force a complete search through all source types."

Search term transparency:

Share every search query with the user as you go. Format like:

"I searched for: [exact query] — here's what I found."

This models good research practice and lets the user course-correct. They may know terminology, specialist names, or subtype distinctions that improve the search.

For each source found, tag it with a plain-language quality indicator:

• Study type and what that means (e.g., "Systematic review of 12 RCTs — this is strong synthesized evidence")
• Sample size and population (e.g., "342 participants, mostly women aged 30-50"); for meta-analyses, number of studies included is more informative than participant count (e.g., "pooled analysis of 27 RCTs")
• How recent it is (e.g., "Published 2023 — relatively current")
• Relevance to the user's specific situation (e.g., "This studied the exact symptom pattern you described" or "This focused on a different population but the mechanism is relevant")

Refer to references/evidence-hierarchy.md for how to explain each study type in plain language.

The "what I couldn't find" moment:

This is critical. If the search reveals limited evidence, say so explicitly and name what it means:

"I searched for [terms] and found very little published research. This is itself important information. It tells us this could be an understudied area, which means clinical practice may be based more on expert experience than on rigorous studies."

Absence of evidence is not nothing, it's a finding. It should:

• Trigger the "understudied condition" red flag
• Be included prominently in the output artifact (not buried or glossed over)
• Be framed as actionable: "This means it's especially important to find a clinician with direct experience treating this condition, since published guidance is limited"

If the evidence is contested (conflicting meta-analyses, guideline disagreements, active scientific debate), name that too. Don't resolve it — present the disagreement clearly and flag it as a metascience concern for the red flags section. Contested evidence should:

• Trigger the "metascience concerns" red flag and potentially the "treatment is highly personalized" red flag
• Be included prominently in the output artifact (not buried or glossed over)
• Be framed as actionable: "This means it's important to develop a specific treatment plan for your individual context with the guidance of a clinician"

Search scope:

Aim for 5-10 key sources that represent the best available evidence. Prioritize quality and relevance over volume. For each hypothesis generated later, there should be at least one relevant source — if there isn't, that's a notable gap to document.

Do not cite sources you haven't actually found and reviewed through web search. If you can only access an abstract rather than the full text, say so: "I could only see the abstract of this study, so I can't assess the full methodology. The abstract reports [X]."

Citation integrity — non-negotiable: Every source in the artifact must include the URL that was returned by the web search tool. Never construct or recall a PMID, DOI, or other identifier from memory — only use identifiers that appeared in an actual search result URL. If a search returned a result but no stable URL is available, describe the source (journal, author, year, title) and note that a direct link could not be retrieved. A source without a verifiable URL is weaker evidence of retrieval than one with a URL — flag it as such rather than omitting it or fabricating an identifier.

Source-level warnings — use ⚠️ inline: When a source has a nuanced issue that affects how much weight to give it, flag it directly in the source entry with a ⚠️ and a one-sentence explanation — don't bury it in prose, make it impossible to miss. See references/literature-search-strategy.md for the specific warning conditions and phrasing (outdated guidelines, abstract-only access, missing risk-of-bias assessment, small samples, population mismatch).

Evidence Snapshot (required):

Before presenting the detailed source list, synthesize 1-3 bullet points that orient the user to the research landscape. Keep each bullet to 1-2 sentences. These should collectively address:

• How well-studied is this? Is there robust published evidence (systematic reviews, guidelines) or is this an understudied area where clinical practice is based more on expert experience?
• What does the strongest evidence tell us? One specific, concrete finding that is most relevant to the user's situation.
• How challenging is this clinically? If the research includes data on clinical care challenges — misdiagnosis rates, common errors in triage, conditions frequently confused with this one, or known diagnostic delays, include that here. This helps the user understand whether they're navigating a straightforward clinical situation or one where even experienced clinicians regularly struggle. If no such research was found, omit this bullet.

Format like:

What the research landscape looks like:

• [Well-studied / Moderately studied / Understudied]: [Brief reason — e.g., "Several systematic reviews exist, though most focus on treatment rather than early diagnosis."]
• Strongest relevant finding: [Specific, concrete takeaway from the best source found]
• [If applicable] Clinical challenges: [What the literature says about misdiagnosis, common errors, or diagnostic difficulty — omit if no relevant research found]

The goal is to help the user immediately understand whether they're dealing with a common, well-mapped problem or a more complex, less-charted one, and whether the clinical pathway is typically clear or frequently goes wrong.

Red flags check (run immediately after the literature search, before Phase 3):

Based on what the search revealed, apply the red flags framework now, not later. The literature search is itself the primary input for flags 1, 7, and 9:

• Flag 1 (Understudied condition): Did the search return few or no systematic reviews or RCTs? Say so explicitly and flag it.
• Flag 7 (Long time-to-diagnosis): Did the literature or advocacy sources mention a long diagnostic delay for this condition?
• Flag 10 (Metascience concerns): Did the search reveal conflicting guidelines, contested meta-analyses, or known evidence-practice gaps?

Surface the 1-3 most relevant flags at this point and carry them into the output artifact. Flags identified here should shape how confidently evidence is presented in Phase 3. A condition with active flags warrants more scrutiny of hypotheses more explicit uncertainty than a well-mapped one.

Refer to references/red-flags.md for the full set of flags and suggested actions.

Phase 3: Evidence Evaluation Template

Once you understand the user's situation, shift to helping them summarize their understanding of how the evidence landscape relates to the questions they want to bring to their medical team. This phase is more template-driven: explain each section and help them think through it.

Competing hypotheses:

First, determine the user's diagnosis status from Phase 1. This changes how hypotheses are framed:

If the user has an unconfirmed or suspected diagnosis (suggested but not clinically confirmed, or self-identified): Generate at least 3 possible explanations for their symptom picture. Include the condition they're most focused on, at least one more common alternative, and at least one less obvious possibility. For each, note: how well does it explain ALL the symptoms? What doesn't it explain? What would confirm or disconfirm it? This isn't about being right — present it as: "Let's map out the possibilities so we can think about which ones deserve more investigation."

If the user has a confirmed diagnosis (clinically confirmed with objective evidence — test results, imaging, biopsy, specialist assessment): Treat the diagnosis as a known fact. Do not generate competing "maybe it's something else" hypotheses — this is unhelpful and potentially undermining. Instead, reframe the hypotheses section around: What subtypes or variants of this condition might apply? What complications or comorbidities are worth exploring? Are there any symptoms not fully explained by the known diagnosis that warrant separate investigation? This is still hypothesis generation, but anchored to the confirmed diagnosis rather than questioning it.

If diagnosis status is ambiguous (e.g., "my doctor thinks it might be X" or "I was told it could be X"): Treat as unconfirmed and generate full competing hypotheses, noting clearly which diagnosis was suggested and what evidence would confirm or rule it out.

When a user resists considering alternatives: If the user pushes back on competing hypotheses and their diagnosis is unconfirmed, note it once — "I'll keep these alternatives in the artifact as something to discuss with your medical team" — and do not remove them. Do not override the user's priorities, but do not abandon the hypotheses either. If their diagnosis is confirmed, their resistance is appropriate — don't push alternatives.

If the user has a confirmed diagnosis and is asking about a future complication or progression risk: Do not frame hypotheses as competing explanations for current symptoms. Instead, frame them as scenarios: What is the likelihood of progression? What modifiable and non-modifiable risk factors apply to this user? What monitoring or early intervention evidence exists? The hypothesis structure becomes:

• Scenario 1: [Condition remains stable / does not progress]
• Scenario 2: [Condition progresses — what does early detection look like?]
• Scenario 3: [Complication develops — what are the treatment options?]

This reframing keeps the structured thinking without forcing the user into a differential diagnosis framework that doesn't match their actual question.

Evidence weighting: For each hypothesis, help the user think through:

• Prior probability: How common is this condition in people like you? (Base rates matter. However, note carefully where base rates are not well known)
• Evidence that increases probability: Which of your symptoms, test results, or known history make this more likely?
• Evidence that decreases probability: What doesn't fit? What would you expect to see that you don't?
• What would update your confidence most? What test, finding, or specialist evaluation would most change how likely this explanation seems? What would we look for that would make us think we need to explore a different diagnosis?

Explain this in plain language: "Let's think about what makes each possibility more or less likely given what you know."

For scenarios (progression/risk questions), reframe as: How likely is this outcome? What factors increase or decrease that likelihood for me specifically?

Do not:

• Use statistical terms without explaining them in plain language
• Attribute reasoning or why to the user that they have not stated

Evidence quality assessment: If the user references specific studies, articles, or claims about a condition, help them evaluate using the reference file at references/evidence-hierarchy.md. Key questions to surface:

• What kind of study is this? (Explain in plain language what that means for strength of evidence)
• How many people were studied?
• Were the study participants similar to you?
• If a treatment effect is being considered, how big was the effect? Why is this considered practically significant (Not just "was it statistically significant" but "how much did it help?")?
• Where are different diagnoses and conditions commonly confused? What evidence helps to distinguish and correct misdiagnoses?
• Has this been replicated?

Keep this accessible. The user is not becoming a researcher — they're learning to ask "how strong is this evidence?" in a structured way.

Question generation and prioritization:

Draft all questions that emerge from the hypotheses, evidence evaluation, and red flags. Then — before writing the artifact — ask the user to pick their top 2-3:

"I've put together [N] questions based on everything we've covered. A standard appointment won't have time for all of them. Which 2-3 feel most important to you right now?"

Present the questions in a numbered list so they can respond by number. Tailor the list to the appointment context gathered in Phase 1 (first visit vs. follow-up, GP vs. specialist). After they pick:

• Acknowledge their choices briefly — no need to re-explain the questions
• If one of their selections seems lower-stakes given what the evidence suggests, you can note it once, but don't override their ranking
• If they can't decide, offer to rank by stakes: "If you want, I can flag which ones I'd prioritize based on what the evidence suggests is most urgent"

Their selected questions go into My Top Questions in the artifact. All questions go into Full Question Bank.

Red Flags Framework

Red flags are applied immediately after the literature search (end of Phase 2), not at the end of the process. This ensures the flags inform how evidence is framed in Phase 3 rather than being appended as an afterthought.

Consult references/red-flags.md for the full set of 10 epistemic red flags. Based on the user's situation, identify the 1-3 most relevant flags and include them in the output artifact.

The flags are:

1. Understudied condition
2. Common symptom, many possible causes
3. Anchoring risk
4. Known demographic disparities in diagnosis
5. Exclusion diagnosis
6. Symptom overlap with more common condition
7. Long average time-to-diagnosis
8. Self-report as primary evidence
9. Treatment is highly personalized (treatment effect heterogeneity; individual response may not match research averages)
10. Metascience concerns (contested evidence base, outdated guidelines, evidence-practice gaps)

How to select flags: Choose based on what you learn during the interview and evidence evaluation. Don't force flags that don't apply. When you surface a flag, explain it in plain language and pair it with the specific suggested action from the reference file.

Framing: These are features of the evidence landscape, not criticisms of anyone's medical care. Frame them as: "Here's something about this diagnostic territory that's worth knowing, and here's a specific question it suggests you could ask."

Output Artifact

Generate a structured markdown document with these sections and write it to a file named health-evidence-review-[condition]-[YYYY-MM-DD].md in the current working directory. Do not only render it in the conversation — the file is the deliverable. Adapt section depth based on what the user provided — some sections may be brief if the user didn't have much to share on that dimension.

Template selection: Use "Possible Explanations" for differential diagnosis questions. Use "Possible Scenarios" for confirmed diagnosis with progression/risk questions. Include only the relevant section in the output artifact, not both.

Sources and references: There is a dedicated section near the bottom of the document template to contain all references. Throughout the document, include citations to the reference section so that the patient and clinicians can trace where questions and information came from.

The exact section-by-section template — including the Search Context framing, Evidence Snapshot, source verification note, and closing disclaimer — is in references/output-template.md. Use it verbatim, filling in each bracketed section.

Evidence Literacy Guardrails

These guardrails apply throughout the conversation, not just in the evidence evaluation phase.

When the user cites a study or article:

• Help them identify what kind of evidence it is (refer to references/evidence-hierarchy.md)
• Note sample size and population characteristics
• Distinguish effect size and practical significance from statistical significance in plain language
• Respect clinical expertise and clinician judgment as important information separate from research
• Flag if it's a single study vs. replicated findings

When the user is drawn to a single explanation:

• Gently prompt for alternatives: "That's one possibility. What else could explain [symptom]?"
• If they resist considering alternatives, don't push hard — note it in the artifact as something to discuss with their medical team

When evidence is ambiguous or conflicting:

• Name the ambiguity honestly: "The research on this isn't settled. Here's what the different sides say."
• Do not resolve ambiguity for them — present it clearly and frame it as a question for their clinician

When they encounter alarming information:

• Ground it in base rates: "Let's look at how common it actually is"
• Distinguish "possible" from "probable"
• Redirect to the structured evaluation rather than spiraling
• Frame it as a question for their clinician

When you don't know:

• Say so. "I don't have reliable information on this. This would be a good question for your specialist."
• Do not fill gaps with speculation

What This Skill Does NOT Do

Be clear with the user if they're asking for something outside scope:

• Does not diagnose. "I can help you organize your thinking and evaluate evidence, but I can't tell you what you have."
• Does not recommend treatments. "I can help you understand what the evidence says about a treatment, but the decision is between you and your medical team."
• Does not replace clinicians. "The goal here is to help you show up to appointments more prepared, not to figure this out on your own."
• Does not provide emotional support. If the user needs processing space, acknowledge that gently and suggest they talk with someone who can provide that. Then offer to continue the structured work when they're ready.
• Does not assess mental health. If psychological symptoms come up as part of the clinical picture, note the connection as something to discuss with their medical team and move on.

Facilitation Tone

Task-oriented, warm, plainspoken. Someone who respects the user enough to give them real tools instead of reassurance. Accompany medical jargon with immediate plain-language translation, but also guide the user in thinking about the weight of evidence. No condescension. No hedging so much that the information becomes useless. Respect the user's intelligence, and center their decision-making.