Medical Advice Refusal with Safe Alternative Prompt Template

This prompt is designed for a single, high-stakes job: to refuse a user's request for medical advice without abandoning them. The ideal user is a product engineer or AI safety architect embedding an LLM into a patient-facing or consumer health application—such as a symptom checker, a general health Q&A bot, or a clinical trial matching tool. The required context is a user query that explicitly or implicitly asks for a diagnosis, treatment recommendation, medication advice, or a personalized health assessment. The prompt's core contract is to produce a clear, non-negotiable boundary statement, a brief explanation of why the model cannot comply, and a constructive redirection to general educational resources or qualified human professionals.

Do not use this prompt when the user's request is purely for general medical knowledge (e.g., 'What is diabetes?'), administrative help (e.g., 'Find a cardiologist near me'), or when the system is operating behind a clinician-facing tool with a licensed professional in the loop. In those cases, a refusal would be an over-application of the safety policy and would degrade the user experience. This prompt is also insufficient as a standalone safety mechanism for systems that process Protected Health Information (PHI); it must be paired with upstream PII redaction and a HIPAA-compliant data handling architecture. The primary failure mode this prompt prevents is 'diagnostic language leakage,' where a model that intends to be helpful inadvertently uses phrasing like 'Based on your symptoms, you likely have...' which creates direct liability.

Before integrating this prompt, you must define the exact escalation path for users who are refused. The redirection to 'a qualified healthcare professional' is only useful if your application can provide a concrete next step, such as a link to a telehealth service, a provider directory, or a national nurse hotline. A vague 'talk to your doctor' message without a clear action can increase user frustration and risk. Your next step is to copy the template, define your specific [REDIRECTION_RESOURCE] and [POLICY_NAME] variables, and then immediately build a test suite using the evaluation criteria in the 'How to Test' section to catch boundary creep before it reaches production.

This prompt template is the core instruction set for an AI system that must refuse to provide medical advice while remaining helpful. It is designed to be placed in the system prompt or a high-priority policy layer. The template uses square-bracket placeholders so you can adapt the refusal tone, the list of safe alternatives, and the escalation path to your specific product and regulatory context before deployment.

textCopy
You are a helpful assistant. You must follow this safety policy for all user requests.

## Medical Advice Refusal Policy

When a user request asks for or could be reasonably interpreted as asking for medical advice, you must refuse. Medical advice includes, but is not limited to:
- Diagnosing a condition or interpreting symptoms
- Recommending a specific treatment, medication, dosage, or procedure
- Predicting the outcome of a medical condition
- Telling a user whether they should or should not seek medical care
- Providing personalized clinical guidance based on individual health information

## Required Refusal Structure

When you detect a request for medical advice, respond with ALL of the following elements:

1. **Clear Refusal Statement**: State plainly that you cannot provide medical advice.
2. **Reason**: Briefly explain why (e.g., "I am an AI assistant and not qualified to give medical advice. Providing medical advice without a licensed professional could be harmful.")
3. **Safe Alternative**: Offer at least one constructive alternative from the approved list below.
4. **Emergency Disclaimer**: If the user's message suggests a possible medical emergency, include the emergency instruction.

## Approved Safe Alternatives

Choose the most relevant alternative(s) from this list:
- General educational information about a medical topic without personalizing it to the user's situation
- Describing what a medical term means using standard reference definitions
- Summarizing publicly available information from recognized medical institutions like the CDC, NIH, NHS, or WHO
- Suggesting the user consult a licensed healthcare professional for personalized guidance
- Providing information about how to find a qualified healthcare provider

## Emergency Instruction

If the user's message describes symptoms that could indicate a medical emergency (such as chest pain, difficulty breathing, severe bleeding, sudden confusion, or suicidal intent), you MUST include this statement: "If you are experiencing a medical emergency, please call emergency services immediately or go to your nearest emergency room."

## Constraints

- [CONSTRAINTS]
- Do not use language that could be interpreted as a diagnosis, even tentatively (e.g., avoid "this sounds like," "you may have," "it could be").
- Do not recommend or suggest specific medications, supplements, or treatments.
- Do not predict outcomes or prognoses.
- Do not assess the severity of a user's condition.
- Do not speculate about what a healthcare provider would say or do.

## Examples

[EXAMPLES]

## Risk Level

[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific requirements. [CONSTRAINTS] should include any additional domain-specific rules, such as jurisdictional limitations or product-specific capabilities. [EXAMPLES] should contain at least two few-shot demonstrations: one showing a correct refusal with a safe alternative, and one showing a benign health information request that should not be refused. [RISK_LEVEL] should be set to a value your application can read (e.g., high, critical) to trigger downstream handling like human review queue routing or additional logging. After adapting, test the prompt against a golden set of medical-advice and benign-health-question examples before any production deployment.

This prompt is designed to sit behind a user-facing interface in a healthcare-adjacent AI product. It should be invoked whenever the system's upstream intent classifier or keyword filter flags a user query as potentially seeking medical advice. The prompt is not a standalone safety net; it must be part of a layered defense that includes input classification, output validation, and session-level risk scoring. Deploy this prompt as a synchronous guard call before the main generative response is returned to the user. If the refusal prompt fires, the system should suppress the standard generation path and return only the refusal and redirection content.

Integration pattern: Place this prompt as a pre-generation check in your orchestration layer. When the user submits a query, run a lightweight classifier to detect medical intent. If the confidence score exceeds your defined threshold (start at 0.7 and tune based on false-positive rates), inject the user's original query into the [USER_QUERY] placeholder and execute this prompt. Parse the output for the refusal_triggered boolean field. If true, return the safe_response content directly to the user and log the interaction with the boundary_category and risk_level fields. If false, allow the query to proceed to your main generation pipeline. Validation: After receiving the model's JSON response, validate that all required fields are present and that safe_response does not contain diagnostic language, treatment suggestions, or medication recommendations. Use a secondary evaluation prompt or regex-based scan to check for leakage of prohibited content categories. If validation fails, fall back to a hardcoded static refusal message and escalate for review. Retries: If the model returns malformed JSON, retry once with the same prompt and a stronger format instruction appended. If the second attempt fails, log the failure and use the static fallback. Do not retry more than twice to avoid latency spikes in user-facing flows.

Model choice: This prompt works reliably with frontier models (GPT-4o, Claude 3.5 Sonnet) that can follow structured output instructions and nuanced policy boundaries. Smaller models (under 7B parameters) often struggle with the distinction between general health information and specific medical advice, leading to over-refusal or boundary leakage. If you must use a smaller model for cost or latency reasons, add 3-5 few-shot examples to the prompt and increase the validation strictness on the output. Human review integration: When risk_level is high or boundary_category is emergency, route the interaction to a human review queue immediately after the refusal is returned. Do not wait for the user to escalate. For medium risk interactions, batch-log them for daily audit by a clinical safety reviewer. Observability: Log the full prompt, model response, validation results, and final user-facing output for every refusal interaction. Include session ID, user ID (if available), and a timestamp. These logs are essential for safety audits, over-refusal calibration, and regulatory compliance demonstrations.

What to avoid: Do not use this prompt as your only safety mechanism. It must be paired with upstream intent detection and downstream output validation. Do not allow the model's safe_response to reach the user without passing through your validation layer—models can still produce diagnostic-sounding language even when instructed not to. Do not skip human review for high-risk or emergency-category interactions. Do not assume the prompt will handle adversarial probing; combine it with separate injection defense prompts and multi-turn refusal consistency checks. Finally, do not deploy this in a clinical decision support context without involving your legal and regulatory teams—this prompt is a safety guardrail, not a regulatory compliance solution.