Regulatory Boundary Triage Prompt for Healthcare Inputs

This prompt is a pre-processing gate for healthcare AI builders who need to classify whether a clinical query falls within regulated medical device or clinical decision support (CDS) boundaries. It is designed to sit at the ingress layer of your application—before any generative model, retrieval system, or agent workflow touches the user's input. The primary job-to-be-done is risk-aware routing: the prompt analyzes the input and produces a structured classification that your application can use to decide whether to proceed normally, proceed with a disclaimer, escalate for human review, or block the request entirely. The ideal user is an engineering lead or AI architect integrating a clinical-facing feature into a product where HIPAA compliance and FDA regulatory awareness are non-negotiable requirements.

Deploy this prompt when your application accepts free-text clinical queries and you need a deterministic, auditable triage step that prevents unregulated advice from reaching end users. For example, a patient-facing symptom checker should use this prompt to distinguish between general wellness information (low risk) and specific treatment recommendations (high risk). A clinical documentation tool might use it to flag inputs that request diagnostic interpretations rather than simple transcription. The prompt requires several inputs to function correctly: the raw user query, a defined risk taxonomy that maps to your organization's regulatory exposure, and a clear output schema that your routing middleware can parse. Without these, the prompt will produce inconsistent classifications that undermine its value as a safety control.

Do not use this prompt as a substitute for legal review or a formal regulatory assessment. It is a triage tool, not a compliance certification. It will not catch every edge case, and its classifications should be treated as signals for your routing logic, not final legal determinations. Do not use this prompt if your application already has a hardcoded rule engine that can deterministically classify inputs based on keywords or structured data—the prompt adds latency and cost that may be unnecessary for simple cases. Do not use this prompt for post-generation review; it is designed to gate inputs, not to audit outputs that have already been produced. For output auditing, pair this with a separate fact-checking or claims verification prompt. Finally, do not deploy this prompt without building the surrounding harness: you need logging for every classification decision, a human review queue for high-risk or ambiguous cases, and monitoring that tracks the rate of escalations and blocks over time to detect drift in your user population or the model's behavior.

The prompt below is designed to be pasted directly into your system. It instructs the model to act as a regulatory triage classifier for healthcare inputs. The model's job is not to answer the clinical question, but to determine whether the query falls within regulated medical device or clinical decision support (CDS) boundaries, and to produce a structured classification that your application can act on. Replace every square-bracket placeholder with your application's specific values before sending the prompt to the model. The placeholders control the risk taxonomy, the output schema, and the escalation rules your system will enforce.

textCopy
You are a regulatory boundary triage classifier for a healthcare AI system. Your only job is to classify user inputs by their regulatory risk level under FDA and HIPAA frameworks. You do not answer clinical questions, provide medical advice, or generate any clinical content.

## INPUT
[USER_QUERY]

## RISK TAXONOMY
Classify the input into exactly one of the following categories:
- **REGULATED_CDS**: The query requests analysis, interpretation, or recommendations that could drive clinical decisions about a specific patient. This includes diagnostic suggestions, treatment recommendations, medication dosing, risk stratification for an individual, or interpretation of patient-specific lab results or imaging.
- **REGULATED_MEDICAL_DEVICE**: The query implies the system is functioning as a medical device under FDA definition, including monitoring, diagnosing, or treating disease in a way that would require 510(k) or PMA clearance.
- **INFORMATIONAL_ONLY**: The query requests general medical information, educational content, or reference material without applying it to a specific patient's clinical situation.
- **OUT_OF_SCOPE_SAFE**: The query is not clinical in nature and poses no regulatory risk.
- **AMBIGUOUS_HIGH_RISK**: The query is ambiguous but could reasonably be interpreted as requesting regulated CDS or medical device functionality. When in doubt, classify here.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "classification": "REGULATED_CDS | REGULATED_MEDICAL_DEVICE | INFORMATIONAL_ONLY | OUT_OF_SCOPE_SAFE | AMBIGUOUS_HIGH_RISK",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of why this classification was chosen, citing specific phrases from the input.",
  "requires_human_review": true/false,
  "required_disclaimer": "Exact disclaimer text to show the user, or null if none required.",
  "escalation_path": "NEXT_STEP: [ESCALATION_QUEUE_NAME] | ALLOW | BLOCK"
}

## CLASSIFICATION RULES
1. If the query mentions a specific patient, specific symptoms, or requests a clinical recommendation, classify as REGULATED_CDS.
2. If the query asks the system to diagnose, treat, monitor, or predict disease for an individual, classify as REGULATED_MEDICAL_DEVICE.
3. If the query asks for general information ("What is diabetes?") without patient context, classify as INFORMATIONAL_ONLY.
4. If you are uncertain between REGULATED_CDS and INFORMATIONAL_ONLY, classify as AMBIGUOUS_HIGH_RISK.
5. Set requires_human_review to true for any classification other than OUT_OF_SCOPE_SAFE and INFORMATIONAL_ONLY.

## REQUIRED DISCLAIMERS
- For REGULATED_CDS: "[REGULATED_CDS_DISCLAIMER_TEXT]"
- For REGULATED_MEDICAL_DEVICE: "[MEDICAL_DEVICE_DISCLAIMER_TEXT]"
- For AMBIGUOUS_HIGH_RISK: "[AMBIGUOUS_DISCLAIMER_TEXT]"
- For all others: null

## CONSTRAINTS
- Do not generate any text outside the JSON object.
- Do not answer the user's clinical question.
- Do not provide medical advice, even in the rationale.
- If the input is in a language other than English, still classify based on the semantic content and return the JSON in English.

To adapt this prompt for your application, start by replacing the disclaimer text placeholders with your organization's legally reviewed language. The [REGULATED_CDS_DISCLAIMER_TEXT] should clearly state that the system cannot provide clinical decision support and direct users to consult a qualified healthcare professional. The [ESCALATION_QUEUE_NAME] placeholder should be replaced with the actual name of your human-review queue or ticketing system so that your orchestration layer can route high-risk classifications correctly. If your risk taxonomy needs additional categories—for example, separating FDA Class I, II, and III device functions—extend the RISK TAXONOMY section and update the OUTPUT SCHEMA enum accordingly. Test the adapted prompt against a golden dataset of at least 50 labeled examples spanning all five classification categories before deploying to production.

After pasting this prompt into your system, wire the JSON output into your application's routing logic. Classifications of REGULATED_CDS, REGULATED_MEDICAL_DEVICE, and AMBIGUOUS_HIGH_RISK should trigger human review and display the corresponding disclaimer to the user. INFORMATIONAL_ONLY classifications can proceed to your general knowledge retrieval pipeline. OUT_OF_SCOPE_SAFE classifications can route to your standard response flow. Monitor the confidence field in production: if confidence scores for AMBIGUOUS_HIGH_RISK classifications consistently fall below 0.7, review your classification rules and consider adding few-shot examples to the prompt. Never remove the human-review requirement for regulated categories without explicit legal and regulatory approval.

This prompt is a classification step, not a conversational interface. It should be called synchronously before any clinical reasoning, summarization, or generation model is invoked. The application layer must inject the relevant regulatory definitions into the [REGULATORY_FRAMEWORK] placeholder from a configuration store, not from user input. The [INPUT] should be the raw, unmodified user query. The prompt is designed for a single-turn classification task and should not carry conversation history.

The output is a structured JSON object with a classification, rationale, and required_actions array. The application harness must validate this JSON against a strict schema immediately upon return. If parsing fails, implement a retry with a stronger instruction to output only JSON. If the classification is REGULATED_CLINICAL_DECISION_SUPPORT or POTENTIAL_MEDICAL_DEVICE_FUNCTION, the harness must route the original user input to a human-review queue and must not display the model's rationale to the end user. For GENERAL_HEALTH_INFORMATION classifications, the harness can proceed to a downstream generation model, but only after prepending the required disclaimer from the required_actions field to the user's input. Log every classification result, including the raw input, model version, timestamp, and final routing decision, for auditability.

Model choice matters here. Use a model with strong instruction-following and low refusal rates on legitimate healthcare queries, such as GPT-4o or Claude 3.5 Sonnet. Avoid models fine-tuned for chat that may over-refuse or add conversational filler. Set the temperature to 0 to maximize deterministic classification. Implement a circuit breaker: if the model returns UNCERTAIN more than three times in a row for the same input, escalate to a human reviewer and log the event as a potential prompt failure. Do not use this prompt's output to make a final legal determination; it is a triage tool that informs a human-reviewed or rule-based routing decision.