Clinical Evidence Synthesis Prompt with Uncertainty Language

This prompt is designed for healthcare AI builders who need to synthesize answers from clinical evidence while communicating uncertainty with appropriate calibration. The core job-to-be-done is generating a response that not only answers a clinical question from provided source material but also grades the quality of the underlying evidence, notes study design limitations, and attaches explicit clinical caveats. The ideal user is an engineering lead or AI architect integrating a retrieval-augmented generation (RAG) system into a clinical decision support, medical literature review, or patient-facing information product where factual accuracy and appropriate uncertainty expression are non-negotiable safety requirements.

Use this prompt when the system must operate over a curated set of clinical documents—such as trial reports, guidelines, or systematic reviews—and the generated answer must be strictly grounded in that evidence. It is appropriate when the cost of a confident-sounding but incorrect answer is high, and the system's credibility depends on transparently communicating what is known, what is uncertain, and why. The prompt requires several structured inputs to function correctly: a clinical question, a set of retrieved evidence passages with source metadata (author, date, study type), and a defined risk level that controls how aggressively the model should abstain or escalate uncertainty. It is not a general-purpose medical chatbot prompt and should not be used without a retrieval step providing the specific evidence to synthesize.

Do not use this prompt when the system needs to generate differential diagnoses, prescribe treatments, or provide individualized medical advice—those workflows require licensed clinical oversight and are outside the scope of evidence synthesis. Avoid this prompt when the source material is absent, uncurated, or consists of general web search results rather than identifiable clinical documents. The prompt's value lies in its structured uncertainty language and evidence grading, which become meaningless or misleading if applied to low-quality or unattributed sources. Before implementing, ensure your retrieval pipeline can supply the required evidence metadata, and plan for human review of outputs in any patient-facing or clinical workflow context.

This template is the core instruction set for a clinical evidence synthesis task. It is designed to be placed in the system prompt of a capable LLM, with the user turn providing the clinical question and retrieved evidence. The prompt enforces strict grounding: every claim must be traceable to a source, and the quality of that source must be graded. The output is a structured assessment, not a definitive diagnosis, making it suitable for clinical decision support workflows where a human clinician always makes the final call.

textCopy
You are a clinical evidence synthesis assistant. Your purpose is to analyze provided clinical evidence and answer a user's question with calibrated, useful, and strictly grounded information. You do not provide medical advice. You are a tool for a licensed clinician.

## INPUT
You will receive the following inputs:
- [CLINICAL_QUESTION]: The specific clinical query to address.
- [RETRIEVED_EVIDENCE]: A collection of text passages from clinical literature, guidelines, or patient records. Each passage is preceded by a unique source ID in brackets, like [SRC-1].
- [PATIENT_CONTEXT]: Optional. De-identified patient-specific information, such as demographics, history, or current medications.

## CORE RULES
1.  **Strict Grounding:** Every factual claim in your answer must be directly supported by at least one passage in [RETRIEVED_EVIDENCE]. If no evidence supports a statement, you must not say it.
2.  **Explicit Abstention:** If the [RETRIEVED_EVIDENCE] is insufficient to answer the [CLINICAL_QUESTION], state this clearly. Do not guess or use internal knowledge. Your primary response in this case should be: "The provided evidence is insufficient to answer this question." You may then provide a summary of what the evidence *does* say about related topics, clearly separated.
3.  **Calibrated Uncertainty:** For every major claim, you must communicate the certainty of the evidence. Use the following language:
    *   **High Certainty:** "The evidence strongly suggests..." (Supported by multiple high-quality sources like RCTs or meta-analyses).
    *   **Moderate Certainty:** "The evidence suggests..." (Supported by well-designed non-randomized studies or a single high-quality source).
    *   **Low Certainty:** "There is limited evidence suggesting..." (Supported by case reports, expert opinion, or studies with significant limitations).
4.  **Evidence Quality Grading:** For each source you cite, you must include a brief quality note in parentheses. Use these categories:
    *   `(High Quality: Meta-analysis/RCT)`
    *   `(Moderate Quality: Cohort/Case-Control Study)`
    *   `(Low Quality: Case Series/Expert Opinion)`
    *   `(Unclear Quality: Source type not identifiable)`
5.  **Source Conflict Handling:** If sources contradict each other, you must explicitly describe the conflict. State the competing claims, cite the conflicting sources, and grade the quality of each. Do not try to resolve the conflict yourself.

## OUTPUT FORMAT
Your response must be a JSON object with the following schema. Do not include any text outside the JSON.

```json
{
  "answer_summary": "A concise, 1-3 sentence summary of the findings, incorporating uncertainty language.",
  "detailed_assessment": [
    {
      "claim": "A single, specific clinical claim.",
      "certainty_level": "high | moderate | low",
      "supporting_sources": [
        {
          "source_id": "SRC-1",
          "quality_grade": "High Quality: Meta-analysis/RCT",
          "supporting_quote": "A short, verbatim quote from the source."
        }
      ]
    }
  ],
  "source_conflicts": [
    {
      "topic": "The clinical topic of the conflict.",
      "claim_a": "The first competing claim.",
      "source_a": "SRC-2",
      "quality_a": "High Quality: Meta-analysis/RCT",
      "claim_b": "The second competing claim.",
      "source_b": "SRC-5",
      "quality_b": "Low Quality: Case Series/Expert Opinion"
    }
  ],
  "evidence_gaps": [
    "A list of specific questions raised by the [CLINICAL_QUESTION] that are not addressed by the [RETRIEVED_EVIDENCE]."
  ],
  "abstention": "A boolean (true/false) indicating if the core question could not be answered at all."
}

CONSTRAINTS

• [CONSTRAINTS]: Optional. Any additional instructions, such as "Limit the detailed_assessment to the top 3 most impactful claims" or "Prioritize evidence from the last 5 years."

To adapt this template, start by removing or modifying the [CONSTRAINTS] block to fit your specific use case. For a real-time application, the [RETRIEVED_EVIDENCE] placeholder would be populated by your RAG pipeline's retrieval step. The [PATIENT_CONTEXT] is optional but critical for personalization; if used, ensure it is fully de-identified before it reaches the model. The JSON output schema is the contract your application will parse. You must implement a post-generation validation step to ensure the JSON is valid and that every source_id in the output actually exists in the input evidence to prevent a common hallucination pattern where the model invents plausible-looking citations.

This prompt is designed to be the final synthesis step in a clinical RAG pipeline, not a standalone chat interface. The implementation harness must enforce strict input validation before the prompt is assembled: verify that [RETRIEVED_EVIDENCE] contains non-empty passages with source metadata (study design, publication date, sample size), that [CLINICAL_QUESTION] has been classified as a medical inquiry within scope, and that [UNCERTAINTY_THRESHOLD] is set to an explicit value (e.g., 'low', 'moderate', 'high') rather than defaulting. The prompt should never execute without these three inputs validated at the application layer. Additionally, implement a pre-flight check that counts evidence passages and warns if fewer than three distinct sources are provided, as single-source synthesis risks overstating certainty.

Wire the prompt into a structured output pipeline using a JSON schema validator immediately after model response. The expected output shape includes answer_summary, evidence_quality_assessment (with fields for study design, sample size adequacy, recency, and conflict flags), uncertainty_statement, clinical_caveats (array of explicit limitations), and source_map (mapping each factual claim to its source passage ID). Configure your application to retry once with a repair prompt if the JSON schema validation fails, but escalate to a human review queue if the second attempt also fails or if the evidence_quality_assessment.conflict_flag is set to true. For model selection, prefer models with strong medical knowledge grounding and low hallucination rates on clinical benchmarks; avoid models known to fabricate citations or overstate confidence. Implement logging that captures the full prompt assembly, the raw model output, the validation result, and any retry attempts for audit trails.

The highest-risk failure mode in production is the model generating plausible-sounding clinical claims that are not actually supported by the provided evidence. To guard against this, implement a post-synthesis grounding verification step: extract each factual claim from the answer_summary, run it against the original evidence passages using an NLI (natural language inference) model or a secondary LLM judge prompt, and flag any claim with a grounding score below your threshold. If any claim fails grounding verification, route the entire response to human review rather than delivering it to the user. Do not attempt automated self-correction for clinical content without human oversight. Finally, ensure your observability stack tracks the rate of human escalations, grounding verification failures, and abstention decisions so you can tune the [UNCERTAINTY_THRESHOLD] parameter over time based on real-world safety data.