Clinical Trial Recruitment Information Access Prompt

This prompt is designed for health information platforms, patient advocacy portals, and clinical research tools that must provide factual information about clinical trials without crossing into medical advice, patient recruitment, or eligibility assessment. The core job-to-be-done is boundary classification: distinguishing between legitimate requests for trial information (e.g., 'What phase is trial NCT04610528?') and requests that imply personal medical guidance or enrollment encouragement (e.g., 'Should I join this trial?' or 'Am I eligible for this study?'). The ideal user is a product engineer or safety analyst integrating this classifier into a retrieval-augmented generation pipeline that surfaces ClinicalTrials.gov data, not a clinician making treatment decisions.

Use this prompt when your application needs a programmatic gate before responding to clinical trial queries. It requires the following inputs: the user's raw query, any retrieved trial metadata (ID, title, phase, conditions, locations), and the user's stated role if available (e.g., patient, researcher, caregiver). The prompt is not a standalone chatbot response generator—it is a classification layer that should be wired upstream of your answer-generation prompt. Do not use this prompt when the user has already been authenticated as a healthcare provider in a clinical workflow, when the query is purely administrative (e.g., 'Update trial NCT record'), or when the platform's terms of service explicitly permit eligibility guidance under regulated conditions.

Before deploying, validate the classifier against a golden test set that includes both benign information-seeking queries (e.g., 'What are the inclusion criteria for NCT04567890?') and boundary-crossing requests (e.g., 'Based on my age and diagnosis, which trial should I pick?'). Track false positive rates—over-refusal on legitimate information requests degrades user trust and undermines the platform's utility. If the classifier's confidence score falls below your configured threshold, route to human review rather than silently refusing or answering. This prompt is a safety component, not a user-facing feature; treat its output as a gating decision that controls whether downstream generation proceeds.

This prompt template is designed to be the core boundary classifier for a health information platform. Its job is to evaluate a user query and determine whether it falls into the safe category of 'Clinical Trial Information Provision' or crosses into the disallowed categories of 'Medical Advice' or 'Patient Recruitment.' The prompt uses a structured output schema to force a clear, machine-readable decision with a confidence score and a concise explanation, making it directly integrable into an application's safety routing layer.

textCopy
You are a boundary classifier for a health information platform. Your task is to analyze the user's query and classify it into one of three categories: 'INFORMATION_PROVISION', 'MEDICAL_ADVICE', or 'PATIENT_RECRUITMENT'. You must not generate medical advice or encourage enrollment.

INPUT:
[USER_QUERY]

CONTEXT:
[PLATFORM_POLICY]

CLASSIFICATION_RULES:
- INFORMATION_PROVISION: The query asks for factual, non-personalized details about clinical trials (e.g., locations, phases, conditions studied, general eligibility criteria, or how to find trials on ClinicalTrials.gov). This includes explaining what 'informed consent' means in a general sense.
- MEDICAL_ADVICE: The query asks for a personalized assessment of whether a specific person should join a trial, interprets eligibility criteria for a specific individual, or recommends a course of treatment.
- PATIENT_RECRUITMENT: The query is an attempt to solicit patients for a specific trial, asks the AI to draft recruitment materials, or seeks to persuade someone to enroll.

OUTPUT_SCHEMA:
{
  "classification": "INFORMATION_PROVISION" | "MEDICAL_ADVICE" | "PATIENT_RECRUITMENT",
  "confidence_score": 0.0-1.0,
  "reasoning": "A brief, specific explanation referencing the query's content and the classification rules.",
  "safe_response_action": "ALLOW" | "REFUSE_AND_REDIRECT"
}

CONSTRAINTS:
- If the query is ambiguous, default to the higher-risk classification (MEDICAL_ADVICE or PATIENT_RECRUITMENT).
- For INFORMATION_PROVISION, the safe_response_action must be 'ALLOW'.
- For MEDICAL_ADVICE or PATIENT_RECRUITMENT, the safe_response_action must be 'REFUSE_AND_REDIRECT'.
- Do not include any text outside the JSON object.

EXAMPLES:
User Query: "What are the phases of a clinical trial?"
Output: {"classification": "INFORMATION_PROVISION", "confidence_score": 0.99, "reasoning": "Query asks for a general definition of clinical trial phases, which is factual information.", "safe_response_action": "ALLOW"}

User Query: "Find a diabetes trial in Miami for my 65-year-old mother."
Output: {"classification": "MEDICAL_ADVICE", "confidence_score": 0.95, "reasoning": "Query asks for a personalized trial search based on a specific individual's condition, age, and location, crossing into advice.", "safe_response_action": "REFUSE_AND_REDIRECT"}

User Query: "Write a social media post to recruit patients for our new asthma study."
Output: {"classification": "PATIENT_RECRUITMENT", "confidence_score": 1.0, "reasoning": "Query is a direct request to create patient recruitment materials.", "safe_response_action": "REFUSE_AND_REDIRECT"}

To adapt this template, start by replacing the [PLATFORM_POLICY] placeholder with a concise summary of your organization's specific rules, such as whether you permit any discussion of trial results or restrict queries to only those listed on a government registry. The [USER_QUERY] placeholder is the runtime input from your application. The examples provided are critical for calibrating the model's behavior; you should expand them with 5-10 edge cases from your own test suite, particularly those that mix informational and personal elements. The strict JSON output constraint is designed to prevent the model from accidentally generating the harmful content it's classifying, but it requires a robust JSON parser in your implementation harness to handle potential formatting errors.

This prompt functions as a boundary classifier, not a conversational agent. It should be deployed as a pre-response safety gate that evaluates user queries before they reach your main health information model. The classifier receives the raw user query and returns a structured decision—ALLOW, BLOCK, or REDIRECT—along with a confidence score and reasoning. Your application must act on this decision before any downstream model generates a user-facing response. Do not treat this as an optional filter; it is the primary control point for preventing the system from crossing into medical advice, eligibility assessment, or enrollment encouragement.

Wire the prompt into your request pipeline as a synchronous pre-check. When a user submits a query containing clinical trial terms, structured trial identifiers (NCT numbers), or recruitment-adjacent language, route it to this classifier first. Parse the JSON output and branch: on ALLOW, forward the original query to your RAG pipeline or health information model with the classifier's topic tags attached as metadata. On BLOCK, return a static refusal message that explains the boundary without engaging the query's content. On REDIRECT, surface approved resources such as ClinicalTrials.gov links or institutional review board contact information. Log every classification decision with the query, confidence score, reasoning, and final action taken. These logs are essential for over-refusal calibration and audit evidence.

Validation must happen at two levels. First, validate the classifier's output schema—ensure classification is one of the three allowed enum values, confidence is a float between 0.0 and 1.0, and reasoning is a non-empty string. If the output fails schema validation, retry once with the same prompt and a stronger format instruction appended. If the retry also fails, escalate to human review and return a safe fallback response to the user. Second, validate the classification decision against your risk thresholds: any BLOCK decision with confidence below 0.85 should trigger a review queue rather than an automatic block, reducing false positives on benign medical queries. For ALLOW decisions with confidence below 0.7, consider appending a disclaimer to the downstream response rather than blocking outright.

Model choice matters for this classifier. Use a model with strong instruction-following and low refusal variability—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller models that may conflate clinical trial information with medical advice due to weaker boundary discrimination. If latency is critical, you can deploy a smaller model for high-confidence cases and escalate to a larger model when confidence falls below your threshold. Implement a circuit breaker: if the classifier returns errors or timeouts for more than 5% of requests in a rolling window, fail open to a safe static response rather than blocking all traffic. Never let a classifier outage become a full service outage.

For eval and ongoing calibration, maintain a golden dataset of at least 200 queries covering ClinicalTrials.gov lookups, inclusion criteria explanations, informed consent discussions, eligibility assessment attempts, and enrollment encouragement. Run this dataset through the classifier on every prompt or model change and compare against expected classifications. Track false positive rate (benign queries blocked) and false negative rate (disallowed queries passed) separately. Set a release gate: no prompt change ships if the false positive rate increases by more than 2 percentage points or any false negative appears in the high-risk test cases. Pair this with production sampling—review a random 5% of classifier decisions weekly to catch drift that your golden dataset misses.