Medical Guideline Compliance Check Prompt Template

This prompt is designed for clinical decision support teams, medical informatics engineers, and healthcare compliance platforms that need to validate a structured treatment claim against one or more published clinical guideline documents. The core job-to-be-done is a guideline-to-claim reconciliation: given a specific clinical assertion (e.g., 'Initiate high-intensity statin therapy for patients with ASCVD') and the full text of the relevant guideline version, the prompt maps the claim to a specific recommendation, identifies its class and level of evidence, and flags any deviations. It is a verification step that produces an audit-ready compliance record, not a diagnostic tool.

Use this prompt only when you have both a well-formed treatment claim and the complete, version-identified text of the applicable guideline document available in the prompt context. The claim should be a single, atomic clinical assertion—bundling multiple claims into one input degrades the mapping accuracy. The guideline text must include the recommendation statements, strength-of-evidence ratings (e.g., Class I/II/III, Level A/B/C), and any relevant exclusion criteria or footnotes. Without the full guideline text in context, the model cannot perform a reliable comparison and will hallucinate guideline content. This prompt is not suitable for differential diagnosis generation, real-time clinical decision-making without human oversight, or scenarios where the guideline document is referenced by name only rather than provided in full.

Do not use this prompt when the clinical question is open-ended (e.g., 'What is the best treatment for this patient?'), when the guideline is ambiguous or under revision, or when the treatment claim involves off-label use without a corresponding guideline entry. In those cases, route to a human clinical reviewer and consider a separate evidence-synthesis workflow. For regulated or high-risk environments, always require human review of any output that flags a deviation or maps to a weak recommendation. The prompt is a compliance verification harness—it confirms alignment or surfaces gaps, but it does not make clinical decisions.

This prompt template is designed to validate a clinical assertion against a provided medical guideline document. It requires the clinical claim, the full text of the relevant guideline, and a defined output schema as inputs. The model is instructed to act as a clinical compliance analyst, comparing the claim to the guideline, mapping the strength of recommendation, and justifying any deviations. The output is a structured JSON object suitable for direct ingestion into a clinical decision support system or a human-review queue.

textCopy
You are a clinical compliance analyst. Your task is to compare a clinical assertion to a provided medical guideline document and produce a structured verification report.

[INPUT]
CLINICAL_CLAIM: [The specific treatment, diagnostic, or management assertion to verify]
GUIDELINE_TEXT: [Full text of the relevant clinical practice guideline, including version and publication date]

[OUTPUT_SCHEMA]
Return a single JSON object with the following fields:
- "guideline_version": string (extracted from GUIDELINE_TEXT)
- "claim_summary": string (a concise restatement of the CLINICAL_CLAIM)
- "guideline_recommendation": string (the exact matching or most relevant recommendation from the GUIDELINE_TEXT)
- "strength_of_recommendation": string (must be one of: "Strong", "Conditional", "Weak", "Not Addressed", "Insufficient Evidence")
- "match_result": string (must be one of: "Consistent", "Inconsistent", "Partially Consistent", "Not Addressed")
- "deviation_justification": string or null (if match_result is not "Consistent", explain the deviation; otherwise, null)
- "requires_human_review": boolean (true if match_result is "Inconsistent", "Not Addressed", or if the claim involves a high-risk intervention)
- "evidence_quality": string (must be one of: "High", "Moderate", "Low", "Very Low", "Not Graded")

[CONSTRAINTS]
- Do not fabricate guideline recommendations. If the claim is not addressed, set match_result to "Not Addressed" and requires_human_review to true.
- If the guideline text is ambiguous, note the ambiguity in deviation_justification and set requires_human_review to true.
- For any claim involving a high-risk intervention (e.g., surgery, chemotherapy, anticoagulation), set requires_human_review to true regardless of the match_result.
- Base your analysis strictly on the provided GUIDELINE_TEXT. Do not use external knowledge.

To adapt this template, replace the [INPUT] placeholders with the specific clinical claim and the full text of the guideline you are checking against. The [OUTPUT_SCHEMA] defines the contract for your application; ensure your downstream parser expects these exact field names and enum values. The [CONSTRAINTS] section encodes critical safety logic, such as mandatory human review for high-risk interventions, which should be mirrored in your application's routing rules. Before deploying, test this prompt with a golden dataset of known consistent, inconsistent, and not-addressed claim-guideline pairs to calibrate the model's adherence to the output schema and safety constraints.

Integrating this prompt into a production system requires treating it as a high-risk, human-in-the-loop workflow, not a real-time chatbot. The core loop involves: receiving a clinical assertion, retrieving the relevant guideline documents (by version and date), assembling the prompt with the assertion and evidence, validating the structured output, and routing any off-guideline or low-confidence results to a clinical reviewer. The model is acting as a comparison engine, not a medical authority, so the application layer must enforce evidence grounding and prevent the model from generating novel medical advice.

Start by building a retrieval step that fetches the correct guideline version based on metadata in the request (e.g., condition, guideline body, effective date). Use a combination of semantic search and metadata filtering to pull the exact sections relevant to the clinical assertion. The prompt's [GUIDELINE_DOCUMENT] placeholder should be populated with this retrieved text, along with its version identifier. After the model returns a JSON response, validate it strictly: check that every guideline_citation field contains a source_section and recommendation_strength that actually exist in the provided document. If the model cites a section not present in the context, flag the output for review and log a potential hallucination event. Implement a retry loop with a maximum of one retry for format validation failures, but do not retry if the model flags the claim as off_guideline—that is a valid, expected output that must be routed to a human.

For model choice, use a model with strong instruction-following and low hallucination rates on structured extraction tasks, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned variant if you have sufficient labeled data. Set the temperature to 0 or very low (0.1) to maximize deterministic output. Log every request and response, including the retrieved guideline version, the full prompt, the raw model output, the validation result, and the final reviewer decision. This audit trail is critical for compliance and for debugging drift when guidelines are updated. The application should also implement a human review queue that surfaces: the original clinical assertion, the model's compliance determination, the specific guideline excerpts used, and a pre-formatted approval/rejection action. Never auto-approve a claim the model marks as off_guideline or insufficient_evidence.

Finally, build an evaluation harness that runs offline against a golden dataset of known compliant and non-compliant assertions. Measure precision and recall on detecting true off-guideline claims, and track the rate of false positives that waste reviewer time. Monitor production drift by sampling outputs weekly and having a clinical expert review them. When guidelines are updated, re-run the evaluation set against the new document versions before promoting the change. Avoid the temptation to let the model 'explain' or 'justify' a deviation in free text without a human approving the explanation first—the model's role is to compare and flag, not to rationalize.