Clinical Trial Evidence Ranking Prompt Template

This prompt is designed for pharma and clinical research platform builders who need to synthesize and prioritize evidence from multiple clinical trials before generating an answer or recommendation. The core job-to-be-done is transforming a flat list of retrieved trial results into a ranked, weighted synthesis where the most clinically significant evidence surfaces first. Use this prompt when your retrieval system returns structured trial metadata—including phase, endpoints, population demographics, and comparator arms—and you need to determine which evidence carries the most weight for a specific clinical question. The ideal user is an engineering lead or AI architect embedding this ranking step into a RAG pipeline for medical affairs, clinical development, or regulatory intelligence workflows.

This prompt requires specific inputs to function correctly. Your retrieval system must provide structured trial records containing at minimum: trial phase (I-IV), primary and secondary endpoint results with statistical significance, study population size and demographics, comparator or standard-of-care details, and publication date. Without this structured metadata, the model cannot perform reliable ranking and will default to superficial heuristics. The prompt expects a clinical question or context statement that defines what matters—for example, a question about efficacy in elderly populations requires different weighting than a question about pediatric safety. You must also provide an output schema specifying the ranking format, such as an ordered list with rank justification, evidence strength tags, and population-match scores.

Do not use this prompt for general medical Q&A, patient-facing advice, or workflows that lack a retrieval step with structured trial metadata. This prompt is not a substitute for systematic literature review and should never be the sole basis for clinical decisions without human review. It is also unsuitable for ranking non-trial evidence such as case reports, expert opinions, or preclinical studies unless you explicitly extend the ranking criteria. The prompt assumes trials are the primary evidence unit; if your workflow mixes trial and real-world evidence, you will need additional ranking dimensions for data source type and confounding control. Always pair this prompt with evaluation checks that detect post-hoc subgroup analysis, unregistered outcome switching, and selective endpoint reporting—failure modes that can make ranked results misleading even when the prompt performs as designed.

This prompt template is designed to be dropped directly into an AI workflow that has already retrieved clinical trial data for a specific question. It forces the model to act as a structured evidence analyst, applying explicit, weighted scoring criteria rather than producing a vague summary. The output is a strict JSON object suitable for downstream processing, UI rendering, or further automated checks. Before using this template, ensure your retrieval pipeline has already gathered the relevant trial records and formatted them into the [RETRIEVED_TRIALS] placeholder. This prompt does not perform search; it only ranks what it is given.

textCopy
You are a clinical evidence analyst. Your task is to rank retrieved clinical trial evidence by strength, relevance, and reliability for a specific clinical question. Follow the ranking criteria strictly. Do not invent trial data. Flag any evidence gaps, post-hoc subgroup analyses, or unregistered outcome switching.

## CLINICAL QUESTION
[CLINICAL_QUESTION]

## TARGET POPULATION (OPTIONAL)
[TARGET_POPULATION]

## PREFERRED COMPARATOR (OPTIONAL)
[PREFERRED_COMPARATOR]

## RETRIEVED TRIAL EVIDENCE
[RETRIEVED_TRIALS]

## RANKING CRITERIA
Rank each trial on a 1-10 scale for each dimension, then compute a weighted total score:
1. Trial Phase (weight 0.20): Phase 3 = 10, Phase 2 = 6, Phase 4 = 8, Phase 1 = 2
2. Endpoint Significance (weight 0.30): Primary endpoint met with p<0.05 = 10, secondary only = 5, exploratory = 2, not significant = 0
3. Population Match (weight 0.25): Exact match to target = 10, partial overlap = 5, different population = 1
4. Comparator Relevance (weight 0.15): Head-to-head against preferred comparator = 10, placebo-controlled = 5, no comparator = 1
5. Recency (weight 0.10): Published within 5 years = 10, 5-10 years = 6, >10 years = 3

## FLAGGING RULES
- Flag any post-hoc subgroup analysis with [POST-HOC SUBGROUP]
- Flag any unregistered outcome switching with [UNREGISTERED OUTCOME]
- Flag trials with incomplete endpoint reporting with [INCOMPLETE REPORTING]
- Flag trials terminated early without prespecified stopping rules with [EARLY TERMINATION]

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "clinical_question": "string",
  "ranked_evidence": [
    {
      "trial_id": "string",
      "phase_scores": { "phase": number, "endpoint_significance": number, "population_match": number, "comparator_relevance": number, "recency": number },
      "weighted_total": number,
      "rank": number,
      "flags": ["string"],
      "rationale": "string"
    }
  ],
  "evidence_gaps": ["string"],
  "synthesis_notes": "string"
}

To adapt this template for your application, start by populating the [RETRIEVED_TRIALS] placeholder with structured data from your search pipeline. Each trial record should include at minimum a unique ID, phase, endpoint results with p-values, population description, comparator details, and publication date. If your retrieval system returns unstructured abstracts, you must pre-process them into this schema before passing them to the prompt. The [TARGET_POPULATION] and [PREFERRED_COMPARATOR] fields are optional but significantly improve ranking accuracy when provided. If omitted, the model will score population match and comparator relevance based on general applicability, which may dilute the ranking's clinical usefulness. Always validate the output JSON against the expected schema before surfacing results to users or storing them in a database.

This prompt is high-stakes by nature. Clinical decisions should never be made solely on AI-ranked evidence. The output must be treated as a decision-support artifact, not a final recommendation. Implement a post-processing validation step that checks for missing trial_id values, non-numeric scores, and empty rationale strings. If the model fails to return valid JSON, implement a retry with a stronger format reminder or fall back to a simpler structured output. Log every ranking output alongside the input trial data for auditability. For regulated environments, route all outputs through a human reviewer before they reach clinicians or researchers.

This prompt is designed to operate as the scoring and ranking step within a retrieval-augmented generation (RAG) pipeline. The retrieval step that precedes this prompt must return structured trial objects containing all fields listed in the variables table: trial_id, registration_id, publication_year, phase, population_match_score, endpoint_significance, comparator_relevance, sample_size, and any other domain-specific metadata required for scoring. Before the LLM is called, a pre-processing validator must confirm that every retrieved trial has a non-null registration_id and a valid publication_year. Trials missing these fields should be either discarded or flagged and routed to a human operator for manual enrichment before scoring.

After the LLM returns the ranked output, run a post-processing validator that enforces the output schema contract. This validator must confirm that every trial in the ranked list includes the required flags—such as [POST-HOC SUBGROUP] and [UNREGISTERED OUTCOME]—and that the weighted total scores sum correctly according to the scoring formula defined in the prompt. Log every ranking decision with the trial_id, individual component scores, applied flags, and final weighted total for auditability. For regulated use cases, any output flagged with [POST-HOC SUBGROUP] or [UNREGISTERED OUTCOME] must be routed to a human reviewer before the evidence synthesis is used downstream in clinical, regulatory, or safety decisions. This gate should be enforced in the application layer, not left to the model's discretion.

Set the model temperature to 0 to ensure deterministic, reproducible scoring across runs. Use structured output mode if your model provider supports it (e.g., OpenAI's response_format with a JSON schema, or equivalent constrained generation APIs). If the output fails JSON schema validation, implement a retry with exponential backoff—start at 1 second, double on each failure, cap at 3 retries before escalating to a human operator or logging the failure for offline inspection. Do not silently fall back to an unvalidated ranking. For high-throughput production deployments, consider batching multiple evidence sets into a single request if your context window permits, but always validate each set independently.