Clinical Note Evidence Extraction and Ranking Prompt

This prompt is designed for EHR and clinical summarization engineers who need to extract findings, assessments, and plans from unstructured clinical notes and rank them into a structured timeline. It is intended for production systems where recency, provider type, and diagnostic certainty must be weighted explicitly. Use this prompt when you need a machine-readable clinical evidence chronology that downstream CDS or summarization modules can consume. The prompt assumes input notes have already been de-identified and that the calling system enforces access controls.

Do not use this prompt for real-time diagnostic decision-making without a human-review gate. It is not a substitute for clinical judgment and should not be the sole input to treatment decisions. The prompt is optimized for retrospective chart review, summarization, and evidence organization—not for prospective risk prediction or alerting. If your use case involves generating clinical alerts, treatment recommendations, or medication changes, you must add a human-in-the-loop approval step and validate outputs against established clinical guidelines.

Before deploying, ensure your pipeline enforces de-identification, logs all extractions for audit, and runs eval checks for copied-forward stale data and unresolved differential diagnoses. The prompt works best with notes that have been pre-processed to remove PHI and normalized to a consistent structure. If your notes contain significant shorthand, non-standard abbreviations, or mixed-language content, you should add a normalization step before extraction. Start with a small batch of representative notes, run the eval harness, and review outputs with a clinical SME before scaling to production volumes.

This prompt template is designed to be pasted directly into your system prompt or user message. It instructs the model to act as a clinical evidence extraction engine, processing raw clinical notes and producing a structured JSON output. The prompt enforces strict rules for ranking evidence by recency, provider type, and diagnostic certainty, while explicitly guarding against common failure modes like copying forward stale data or presenting unresolved differential diagnoses as confirmed findings. Before using this template, ensure you have a clear understanding of your input data structure and the desired output schema for your downstream application.

textCopy
You are a clinical evidence extraction engine. Your task is to process the provided [CLINICAL_NOTE_TEXT] and extract all findings, assessments, and plans. You must rank each extracted item by recency, provider type, and diagnostic certainty to produce a structured clinical evidence timeline.

# INPUT
[CLINICAL_NOTE_TEXT]

# CONSTRAINTS
1.  **Stale Data Detection:** Explicitly identify and flag any information that appears to be copied forward from a previous note without a new date or provider confirmation. Mark such items with a `staleness_risk` flag.
2.  **Differential Diagnosis Handling:** Clearly separate confirmed diagnoses from active differential diagnoses. For differentials, include a `diagnostic_certainty` field set to "differential" and list the supporting and refuting evidence mentioned in the note.
3.  **Provider Attribution:** For each extracted item, identify the provider type (e.g., Attending, Resident, Nurse, Specialist) if available. Rank items from attending or specialist providers higher than those from other sources when recency is equal.
4.  **Temporal Ranking:** Rank all items in reverse chronological order based on the date they were documented or observed. If an item has no date, place it at the bottom with a flag.
5.  **Source Grounding:** For every extracted item, you MUST include a verbatim quote from the [CLINICAL_NOTE_TEXT] as the `source_quote`. Do not paraphrase.

# OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "patient_id": "string | null",
  "note_date": "string | null",
  "evidence_timeline": [
    {
      "item_type": "finding | assessment | plan",
      "description": "string",
      "source_quote": "string",
      "date_documented": "string | null",
      "provider_type": "string | null",
      "diagnostic_certainty": "confirmed | differential | ruled_out | unknown",
      "staleness_risk": "boolean",
      "supporting_evidence": ["string"],
      "refuting_evidence": ["string"]
    }
  ],
  "unresolved_differentials": ["string"],
  "stale_data_flags": ["string"]
}

# RISK_LEVEL
HIGH. This output may inform clinical decisions. All extracted information must be directly traceable to the source text. If the note is ambiguous, you MUST reflect that uncertainty in the output rather than making a definitive statement.

To adapt this template, replace the [CLINICAL_NOTE_TEXT] placeholder with the actual clinical note string. You can further refine the [OUTPUT_SCHEMA] to match your application's data model, but the core constraints on staleness, differential diagnoses, and source grounding should remain intact. For high-risk deployments, this prompt's output should be treated as a draft that requires human review, and you should implement a validation layer that checks the JSON structure and flags any items where source_quote is missing or staleness_risk is true.

This prompt is designed to operate as a stateless extraction and ranking step within a larger clinical documentation pipeline. It should not be the sole consumer-facing output. Instead, wire it as a microservice or serverless function that receives a de-identified clinical note payload and returns a structured JSON evidence timeline. The calling application is responsible for assembling the [INPUT] (the clinical note text), [CONTEXT] (patient demographics, encounter metadata, and a list of prior resolved diagnoses if available), and [OUTPUT_SCHEMA] (the expected JSON structure for findings, assessments, and plans). The model should never receive raw PHI directly; de-identification must occur upstream.

Validation and retry logic is critical. Before the output reaches any downstream consumer or database, validate the JSON structure against the [OUTPUT_SCHEMA]. Check that every extracted finding has a non-null source_span (a direct quote from the note), a recency timestamp, and a certainty score. If validation fails, implement a single retry with the error message injected into the [CONSTRAINTS] field. If the retry also fails, log the raw output and the failed validation details, then escalate to a human review queue. Do not silently drop malformed extractions. For high-risk deployments, add a secondary LLM call using a dedicated hallucination detection prompt (from the Hallucination Detection and Flagging pillar) that compares each source_span against the original note text to detect fabricated quotes.

Model choice and tool use: Use a model with strong JSON mode and a context window large enough for the longest clinical note plus the output schema. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate starting points. This prompt does not require tool calling or RAG at runtime because the evidence is self-contained within the provided note. However, the harness should log every input, output, validation result, and retry attempt to an observability platform for trace analysis. Pay special attention to two failure modes: copied-forward stale data (where the model extracts a finding that appears verbatim in a prior note but is not re-stated in the current note) and unresolved differential diagnoses (where the model presents a differential as a confirmed finding). Mitigate the first by including prior note snippets in [CONTEXT] with explicit instructions to ignore them unless re-stated. Mitigate the second by requiring the certainty field to use a controlled vocabulary (confirmed, suspected, ruled_out, differential) and flagging any differential entry for human review before it enters the problem list.

Next steps: After validation passes, the structured evidence timeline can be ingested into a clinical data warehouse, used to update a patient summary, or fed into a downstream CDS prompt. Do not treat this prompt's output as a final clinical document. Always route findings tagged as differential or certainty: suspected to a human reviewer. Run periodic eval suites using a golden dataset of annotated clinical notes to detect regressions in extraction recall, precision, and copied-forward detection.