Medical Summary Fact-Separation Prompt

This prompt is designed for clinical documentation reviewers, medical informatics engineers, and healthcare AI builders who need to extract objective, verifiable observations from clinical notes, discharge summaries, and consult reports. The core job-to-be-done is separating measured facts (e.g., 'BP 140/90', 'WBC 12.5') from clinical judgment, differential diagnosis reasoning, and treatment rationale. The ideal user is integrating this prompt into a clinical data pipeline, a chart review application, or a medical QA system where downstream processes require clean, atomic factual statements that can be validated against lab values, vital signs records, or structured EHR fields.

Use this prompt when the source text is a clinical narrative written by a healthcare professional and the output must distinguish between what was observed or measured and what was assessed or planned. The prompt is appropriate for post-encounter documentation review, clinical data abstraction for registries, and pre-processing steps before automated fact-checking against medical knowledge bases. It is not suitable for real-time clinical decision support, patient-facing explanations, or generating clinical advice. The prompt assumes the input has already been de-identified according to your organization's policies; it does not perform PHI redaction. It also assumes English-language clinical text with standard medical terminology.

Do not use this prompt for generic health content, patient forum posts, or consumer medical articles. It is not designed for legal medical review, billing code extraction, or quality-of-care assessments. The prompt does not make clinical determinations about correctness of the documented findings—it only separates factual statements from interpretive ones. For high-stakes use cases, always route outputs through human clinical review before any downstream action. The prompt's value is in structuring unstructured clinical text for machine consumption, not in replacing clinical judgment.

This prompt template is designed to process clinical documentation—such as discharge summaries, consult reports, and progress notes—and decompose the content into two distinct categories: verifiable objective findings and clinical interpretation. The goal is to produce a structured output that a downstream verification system or human reviewer can trust, ensuring that measured values (e.g., 'BP 140/90') are never conflated with severity assessments (e.g., 'poorly controlled hypertension'). The template uses square-bracket placeholders for all dynamic inputs, allowing you to integrate it into a production pipeline where the source text, risk level, and output schema are injected at runtime.

textCopy
You are a clinical documentation analyst. Your task is to process the provided [CLINICAL_TEXT] and separate every statement into one of two categories: 'verifiable_objective_finding' or 'clinical_interpretation'.

**Definitions:**
- **verifiable_objective_finding**: A statement that can be confirmed or refuted by a measurement, a lab result, a documented observation, a timestamped event, or a direct patient quote. This includes vital signs, administered medications with dosages, lab values, and physical exam findings (e.g., 'tenderness to palpation in the right lower quadrant').
- **clinical_interpretation**: A statement that involves medical judgment, reasoning, differential diagnosis, risk assessment, treatment rationale, prognosis, or characterization of severity. This includes phrases like 'likely due to', 'consistent with', 'suspicious for', 'well-controlled', and 'significant improvement'.

**Input:**
[CLINICAL_TEXT]

**Output Format:**
You must produce a valid JSON object conforming to the following schema:
[OUTPUT_SCHEMA]

**Constraints:**
[CONSTRAINTS]

**Examples of Correct Separation:**
[EXAMPLES]

**Risk Level:** [RISK_LEVEL]
If the risk level is 'high', you must flag any statement where the boundary is ambiguous for mandatory human review. Do not guess.

To adapt this template for your own use, replace the placeholders with concrete values. [CLINICAL_TEXT] should be the raw, unprocessed note. [OUTPUT_SCHEMA] should be a strict JSON Schema definition, for example, requiring an array of objects with statement, category, source_span, and confidence fields. [CONSTRAINTS] might include rules like 'never modify the original text' or 'preserve all negations'. [EXAMPLES] is critical for few-shot performance; provide 3-5 examples that specifically address the distinction between a measured value and its interpreted severity. [RISK_LEVEL] should be set to 'high' for any clinical workflow, which activates the ambiguity flagging instruction. The next step is to integrate this template into a harness that validates the JSON output against your schema before any downstream use.

The Medical Summary Fact-Separation Prompt is designed to operate as a pre-processing step in a clinical documentation review pipeline, not as a standalone chat interaction. Its primary job is to receive a clinical note, discharge summary, or consult report and return a structured separation of objective findings from clinical judgment. In production, this prompt should be called via an API (OpenAI, Anthropic, or a self-hosted model) with the output parsed into a typed object before any downstream system consumes it. The prompt is stateless: each call is independent, and the application layer is responsible for managing document context, chunking long notes, and assembling the final structured output.

Model choice and configuration: Use a model with strong instruction-following and structured output capabilities, such as gpt-4o, claude-3-5-sonnet, or a fine-tuned clinical variant if available. Set temperature to 0 or a very low value (0.0–0.1) to maximize deterministic separation behavior. Enable structured output mode (JSON mode or function-calling with a strict schema) rather than relying on free-text parsing. The output schema should enforce the separation contract: an array of objective_findings (with statement, source_span, measurement_value, unit, reference_range where applicable) and a separate array of clinical_interpretations (with statement, source_span, interpretation_type such as differential_diagnosis, severity_assessment, treatment_rationale, or prognosis).

Validation and retry logic: After each model call, validate the output against the expected schema. Check that every objective_finding contains a source_span that can be located in the original document text. If validation fails—missing spans, unparseable JSON, or findings that appear to contain interpretive language—retry once with the same prompt plus the validation error message appended as a [CORRECTION_FEEDBACK] block. If the second attempt also fails, route the document to a human review queue with the raw model output and validation errors attached. Do not silently accept unvalidated output into downstream systems. For high-risk clinical settings, consider a dual-model verification pattern: run the same prompt on two different models and flag discrepancies for review.

Logging and audit trail: Log every prompt call with the input document ID, model version, prompt template version, raw response, parsed output, validation result, and any retry or escalation actions. This audit trail is essential for clinical governance, prompt iteration, and debugging separation failures. Store logs in a structured format (JSON) with timestamps and user/session context. Never log raw PHI to unstructured log streams; use document IDs and reference the source text from a secured clinical data store. For regulated environments, ensure logs are immutable and retained according to your organization's record-keeping policies.

Human review integration: The prompt's output should feed a review interface that displays the original document side-by-side with the extracted objective findings and clinical interpretations. Reviewers should be able to accept, reject, reclassify, or edit each item. Capture reviewer corrections as labeled feedback that can be used to evaluate prompt performance over time and to build few-shot examples or fine-tuning datasets. Set an escalation threshold based on confidence scoring: if the model's separation confidence (which you can request as an additional output field) falls below a configurable threshold for any passage, automatically flag that passage for human review even if schema validation passes.

What to avoid: Do not use this prompt as a diagnostic tool or clinical decision support system. It is a documentation structuring aid only. Do not feed its output directly into patient records, billing systems, or clinical decision support without human review. Do not assume the model correctly distinguishes measured values from interpreted severity in edge cases—always validate numerical extractions against the source document. Finally, do not deploy this prompt without a regression test suite of annotated clinical notes covering common failure modes: embedded facts within interpretive sentences, ambiguous measurement language, and notes where the distinction between observation and assessment is genuinely unclear even to human reviewers.