Medical Term Normalization Prompt for Clinical Query Understanding

This prompt is designed for clinical RAG system operators and healthcare application developers who need to bridge the gap between patient-facing or colloquial health language and the precise, standardized terminologies required for retrieval against clinical knowledge bases. The job-to-be-done is mapping a user's layperson query—such as 'water pill,' 'heart attack,' or 'bad sugar'—to its canonical medical equivalents (e.g., 'Diuretic,' 'Myocardial Infarction,' 'Hyperglycemia') with UMLS or SNOMED CT concept mappings before executing a vector or keyword search. The primary reader is an engineer integrating this normalization step into a pre-retrieval pipeline, not a clinician performing direct patient care.

You should use this prompt when your retrieval system indexes content by formal medical vocabularies but your users query in everyday language. It is appropriate for applications like clinical trial search, patient education portals, and provider-facing literature review tools. The prompt requires a [USER_QUERY] and a [DOMAIN_GLOSSARY] or reference to a terminology service. For safety-critical deployments, you must also provide a [DISAMBIGUATION_CONTEXT]—such as patient demographics or recent history—to resolve ambiguous terms like 'cold' (temperature vs. infection). The output is a structured normalization object containing the original query, a list of candidate canonical terms with UMLS CUIs or SNOMED codes, and a confidence score per mapping. This prompt is not a diagnostic tool and must not be used to interpret clinical notes, suggest treatments, or bypass a human reviewer in any patient-facing decision workflow.

Do not use this prompt when the input is already in a structured, coded format or when the retrieval corpus is purely patient-generated content that uses the same colloquial language as the query. It is also unsuitable for real-time emergency settings where latency constraints preclude a normalization step, or for domains without a maintained terminology service. A critical failure mode is term over-normalization, where a specific patient phrase like 'crushing chest pain' is abstracted to a broad concept like 'Chest Pain' and loses its qualifying severity descriptor. To mitigate this, always preserve the original query for a hybrid retrieval approach and implement a validation step that checks for semantic drift between the original and normalized forms using embedding distance thresholds. Before deploying, run an eval suite that includes disambiguation test cases, false cognates (e.g., 'stent' vs. 'stint'), and queries with no valid medical mapping to ensure the prompt abstains rather than hallucinating a match.

This prompt template is designed to be the core instruction set for a medical term normalization step in a clinical RAG pipeline. It accepts a raw user query, a domain glossary or terminology source, and a set of safety constraints. The primary job is to map layperson language (e.g., "water pill," "heart attack") to canonical clinical terms (e.g., "Hydrochlorothiazide," "Myocardial Infarction") and produce a structured, retrieval-ready output. This is not a general-purpose medical advice prompt; its sole function is to reduce the vocabulary gap between a user's natural language and a clinical knowledge base's indexing scheme. Use it when your retrieval system consistently fails on colloquialisms, brand names, or abbreviations that don't appear in your vector or keyword indexes.

textCopy
You are a clinical terminology normalization engine. Your task is to map colloquial, patient-facing, or ambiguous health terms in a user query to standardized medical concepts.

## INPUT
User Query: [USER_QUERY]

## CONTEXT
Authorized Terminology Source: [TERMINOLOGY_SOURCE]
- This may be a list of UMLS CUIs, SNOMED CT codes, or a custom in-house taxonomy provided as a JSON object or a delimited string.
- Example: {"heart attack": "Myocardial Infarction", "water pill": "Hydrochlorothiazide"}

## CONSTRAINTS
1. **Safety-Critical**: If a term is ambiguous and could map to multiple concepts with different clinical implications (e.g., "cold" could be a temperature sensation or a viral infection), you MUST flag it for disambiguation instead of guessing.
2. **Source Grounding**: You MUST only map to concepts explicitly present in the provided [TERMINOLOGY_SOURCE]. Do not invent or infer mappings.
3. **No Diagnosis**: Do not add diagnostic interpretations. If the query is "pain in left arm," normalize to "Left Arm Pain," not "Myocardial Infarction."
4. **Preserve Non-Medical Context**: Retain non-clinical query components (e.g., "what are the side effects of...") in the output's `free_text_remainder` field.

## OUTPUT_SCHEMA
You must return a single JSON object with the following structure:
{
  "original_query": "string",
  "normalized_terms": [
    {
      "original_text": "string",
      "canonical_form": "string",
      "concept_code": "string",
      "confidence": "high|medium|low"
    }
  ],
  "disambiguation_flags": [
    {
      "ambiguous_term": "string",
      "possible_mappings": ["string"],
      "reason": "string"
    }
  ],
  "normalized_query_string": "string",
  "free_text_remainder": "string"
}

## EXAMPLES
User Query: "Does ibuprofen interact with my water pill?"
Terminology Source: {"water pill": "Hydrochlorothiazide", "ibuprofen": "Ibuprofen"}
Output:
{
  "original_query": "Does ibuprofen interact with my water pill?",
  "normalized_terms": [
    {"original_text": "ibuprofen", "canonical_form": "Ibuprofen", "concept_code": "C0020740", "confidence": "high"},
    {"original_text": "water pill", "canonical_form": "Hydrochlorothiazide", "concept_code": "C0020297", "confidence": "high"}
  ],
  "disambiguation_flags": [],
  "normalized_query_string": "Does Ibuprofen interact with Hydrochlorothiazide?",
  "free_text_remainder": "Does interact with my ?"
}

User Query: "I have a cold"
Terminology Source: {"cold": "Common Cold", "cold sensation": "Cold Temperature"}
Output:
{
  "original_query": "I have a cold",
  "normalized_terms": [],
  "disambiguation_flags": [
    {"ambiguous_term": "cold", "possible_mappings": ["Common Cold", "Cold Temperature"], "reason": "Term could refer to a viral infection or a physical sensation."}
  ],
  "normalized_query_string": "I have a cold",
  "free_text_remainder": "I have a"
}

To adapt this template, you must replace the [TERMINOLOGY_SOURCE] placeholder with your actual knowledge base mapping. This can be injected dynamically from a database lookup or a static configuration file. The critical adaptation point is the disambiguation_flags logic: you should tune the prompt's examples to reflect the most dangerous ambiguous terms in your specific domain (e.g., "stent" vs. "stint" in cardiology). After generating the output, always validate the JSON structure and check that every concept_code in normalized_terms exists in your source terminology. For high-stakes clinical settings, route any output with a non-empty disambiguation_flags array or low confidence scores to a human reviewer before the query proceeds to retrieval.

Integrating this prompt into a production clinical query pipeline requires treating it as a pre-retrieval safety and normalization gate, not a standalone utility. The prompt should sit between the user-facing query intake and the retrieval engine. When a query arrives, the application must first check for PII and redact it before any model call. Then, the raw query is passed to the normalization prompt along with the approved terminology context—typically a curated subset of UMLS, SNOMED CT, or a customer-specific clinical vocabulary. The model returns a structured JSON payload containing the normalized query string, a list of term mappings with UMLS CUIs or SNOMED codes, a confidence score per mapping, and a flag indicating whether any term was ambiguous and required disambiguation. This output must never be trusted blindly; it must pass through a validation layer before the normalized query is forwarded to the vector database, keyword index, or downstream LLM for answer generation.

The implementation harness should enforce a strict validation contract on the model's output. Use a JSON Schema validator to confirm the presence and types of all required fields: normalized_query (string), mappings (array of objects with original_term, normalized_term, concept_code, vocabulary, and confidence), ambiguous_terms (array), and requires_review (boolean). If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block. If the retry also fails, log the failure and route the original query to a human review queue. For high-risk clinical contexts, set a confidence threshold (e.g., 0.85) below which any mapping triggers the requires_review flag. When requires_review is true, the system should pause the retrieval pipeline and present the original query, the proposed normalization, and the ambiguous mappings to a clinical reviewer through a lightweight UI or Slack notification. Only after approval should the normalized query proceed to retrieval. Log every step—original query, redacted query, prompt version, model response, validation result, review decision, and final normalized query—into an immutable audit trail for compliance with healthcare regulations.

Model choice matters here. Use a model with strong medical terminology grounding and reliable JSON output, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned open-weight model evaluated on your specific vocabulary. Avoid models with known hallucination tendencies on rare clinical terms. Implement a caching layer for frequently seen terms to reduce latency and cost: maintain a local map from original term to normalized concept code, populated from prior successful normalizations and reviewed by a clinical informaticist. Before calling the LLM, check the cache; only uncached terms should be sent to the prompt. This hybrid approach keeps the LLM in the loop for novel or ambiguous terms while avoiding redundant API calls for common mappings like 'heart attack' → 'Myocardial Infarction (SNOMED: 22298006).' Finally, build an eval harness that runs this prompt against a golden dataset of 200+ clinical queries with known correct normalizations, measuring precision, recall, and the false-positive rate on the requires_review flag. Run this eval on every prompt change before deployment, and sample production traces weekly to detect drift in normalization quality.