Clinical Trial Inclusion Criteria Extraction Prompt

This prompt is built for clinical research teams, trial matching system engineers, and data pipeline builders who need to convert unstructured clinical trial protocol text into structured, typed eligibility criteria. The core job-to-be-done is transforming narrative inclusion and exclusion text—often dense with nested logic, temporal constraints, and implicit rules—into machine-readable records that downstream systems can query. Typical users are integrating this extraction step into patient-to-trial matching engines, protocol feasibility analysis tools, or regulatory document indexing pipelines. The prompt assumes the input is a section of a trial protocol or registry entry describing who may or may not participate, not a full medical record or a patient-specific document.

Use this prompt when you need to extract criteria with their logical operators (AND/OR/NOT), value ranges, units, temporal constraints, and explicit inclusion/exclusion typing. It handles complex nested criteria and can surface implicit exclusion logic where the protocol states what is required without explicitly listing what is disallowed. The output is designed to feed directly into structured databases, search indexes, or matching algorithms. Do not use this prompt for extracting patient-specific data from medical records, for summarizing trial results, or for making clinical decisions. It is not a substitute for clinical judgment and should never be the sole basis for determining patient eligibility without human review.

Before using this prompt, ensure your input text is a clean, text-extracted version of the eligibility criteria section. PDFs with complex tables or multi-column layouts should be pre-processed into linear text. If your protocol uses non-standard terminology or institution-specific abbreviations, consider adding a terminology mapping step before extraction. For regulated environments, always pair this prompt with a validation layer that checks output schema compliance, logical consistency, and source grounding. Human review is required for any criteria that directly affect patient safety or trial enrollment decisions.

This prompt template is designed to be dropped directly into your extraction pipeline. It enforces strict output formatting, explicit handling of ambiguous criteria, and normalization of clinical units. The template uses square-bracket placeholders that your application must resolve before sending the request to the model. The most critical placeholder is [OUTPUT_SCHEMA], which should contain the exact JSON Schema you expect the model to conform to—this is your primary defense against malformed outputs in production.

textCopy
Extract structured eligibility criteria from the provided clinical trial protocol text. Adhere strictly to the output schema. Do not infer criteria not explicitly stated. If a criterion is ambiguous, set the confidence to 'low' and include the ambiguous source text in the evidence field. For implicit exclusions (e.g., 'patients must not have'), create a criterion with the operator 'EXCLUDES'. Normalize all units to the standard provided in the [UNIT_ONTOLOGY] variable. Return only the JSON object, enclosed in a ```json code block.

[OUTPUT_SCHEMA]

[UNIT_ONTOLOGY]

Protocol Text:
[PROTOCOL_TEXT]

To adapt this template for your own use, replace [OUTPUT_SCHEMA] with a concrete JSON Schema that defines the structure of each criterion object—fields like condition, operator, value, unit, temporal_constraint, confidence, and evidence. Replace [UNIT_ONTOLOGY] with a mapping of acceptable units (e.g., {"weight": "kg", "height": "cm"}) to enforce normalization. The [PROTOCOL_TEXT] placeholder should receive the raw, unstructured text of the clinical trial protocol. Before deploying, validate that your chosen model reliably produces output that passes schema validation; if it does not, add a repair step or consider a model with stronger instruction-following for structured generation. Always log the raw model response and the validation result for auditability, especially in GxP-adjacent workflows.

This prompt is designed to be called as a single-turn extraction step within a larger document processing pipeline, not as a standalone chat interaction. The primary integration point is a structured API call where the trial protocol text is passed as the [INPUT] and the extraction schema is provided as the [OUTPUT_SCHEMA]. Because clinical trial eligibility criteria directly affect patient safety and trial integrity, the implementation harness must enforce strict validation, audit logging, and human review gates before any extracted criteria are used for downstream trial matching or site selection.

Validation and retry logic should be the first layer of defense. After the model returns a JSON payload, validate it against the expected schema using a library like jsonschema or pydantic. Check that all required fields (criterion_id, condition, logical_operator) are present, that enumerated fields match allowed values, and that numeric ranges have consistent units. If validation fails, implement a single retry with the error message injected into the prompt as additional [CONSTRAINTS]. Do not retry more than twice—escalate to a human review queue instead. Confidence scoring is critical: if the model's self-reported confidence for any criterion falls below a configurable threshold (start at 0.85), flag the entire extraction for human review. Log every extraction attempt, including the raw model response, validation errors, and retry count, to a structured logging system for audit and prompt debugging.

Model choice matters for this domain. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may hallucinate criteria or mishandle nested logical operators. If you are processing high volumes of protocols, consider batching documents but never batch more than one protocol per prompt call—cross-document contamination is a real failure mode. Tool use and RAG are generally not required for this extraction task because the prompt operates on a single, self-contained document. However, if your pipeline needs to normalize medical terms against a controlled vocabulary like SNOMED CT or MedDRA, implement a post-extraction normalization step using a separate API call or lookup table rather than embedding the entire ontology in the prompt.

Human review integration is non-negotiable for production use. Build a review queue that surfaces extractions with low confidence, validation failures, or complex nested criteria (more than three levels of logical nesting). The review interface should display the original protocol text side-by-side with the extracted criteria, allowing a clinical reviewer to accept, edit, or reject each criterion. Store all reviewer actions with timestamps and user identifiers for compliance. Finally, never use extracted criteria for automated trial matching without human approval—the risk of misclassifying a patient's eligibility due to an extraction error is too high. Wire the approval status into your downstream systems so that only reviewed and approved criteria propagate to patient-facing applications.