CDS Hooks for FHIR: What Actually Works at Point of Care

CDS Hooks is the FHIR-native pattern for clinical decision support in EHR workflow. In 2026, three hook types ship in production; two others are aspirational. Understanding which is which affects integration timelines.

Production-ready hooks

1. patient-view. Fires when a clinician opens a patient chart. CDS returns cards with alerts, reminders, and links to more context. Best for care-gap reminders (missed screenings, overdue vaccines).

2. order-select. Fires when a clinician picks an order type. CDS returns cards suggesting alternatives, warning about contraindications, or requiring documentation. Best for opioid alternative suggestions and antibiotic stewardship prompts.

3. order-sign. Fires just before the clinician signs an order. CDS returns cards with the last opportunity for interception. Best for drug-drug interactions, coverage requirements (via CRD), and prior authorization triggers.

Not-yet-mainstream hooks

encounter-start and encounter-discharge are defined but supported inconsistently across EHRs.

Hook payload structure

Each hook fires with a JSON body containing context (the FHIR resources relevant to the workflow point) and prefetch (server-fetched resources to save round-trips). The service returns cards with summary, detail, indicator (info/warning/critical), and optional suggestions/links.

Card response constraints

- Max 5 cards per hook response (informal industry standard) - Critical cards should be rare (2-3 per week per clinician, not per patient) - Suggestions should be one-click actions, not multi-step workflows

Vendor state, mid-2026

Common integration mistake. Over-firing cards (>10/day per clinician) causes alert fatigue and cards get ignored. Under-fire until users request more, not the other way around.