CDS Hooks is HL7's standard for embedding clinical decision support in EHR workflow. It's been around since 2018, it's well-supported in Epic and Cerner and Athena, and it's the right primitive for shipping recommendations inside the tools clinicians already use.
It also has a well-earned reputation for going unused. We've audited CDS deployments where the technical integration was textbook — and where the clinical adoption was zero within two weeks. The standard isn't the problem. The deployment design is.
What CDS Hooks gives you
CDS Hooks defines "hooks" — workflow events in the EHR — and the contract between EHR and CDS service. Common hooks:
- patient-view — fires when a clinician opens a patient chart
- order-select — fires when a clinician begins ordering (lab, medication, imaging)
- order-sign — fires when a clinician is about to sign an order
- encounter-start, encounter-discharge — workflow milestones
The CDS service receives the workflow context (patient, encounter, current orders, draft order), returns "cards" — small structured recommendations that the EHR renders inside the clinician's UI. Cards can be informational, suggest alternative orders, or link to external apps (via SMART on FHIR).
The protocol is good. It standardizes integration with Epic, Cerner, Athenahealth, eClinicalWorks, NextGen — meaning your CDS service can ship to multiple EHRs from a single codebase. That's the half of the problem CDS Hooks solves.
Three adoption-killing design mistakes
The other half — adoption — has the same failure modes regardless of which EHR. Three patterns kill adoption faster than anything else.
Firing too often
A CDS card that fires on every patient-view is a card clinicians will mentally tune out within a week. The "wolf-cry" problem from alert design applies to CDS Hooks too.
Rule of thumb: a card should fire on no more than 5–10% of relevant workflow events. If it's firing on every patient-view, your filter logic is too loose. Narrow the condition.
Firing without evidence
"Consider checking ferritin levels" is a worse card than "Patient's last hemoglobin was 9.2 (Aug 15) — consider checking ferritin." The second card shows the data that justifies the suggestion. The first leaves the clinician wondering why this is appearing now.
CDS Hooks cards have a "source" and "indicator" structure for exactly this. Use it. Show the data inline. The clinician's decision is faster (and more likely to accept) when the evidence is visible.
Firing at the wrong workflow step
A medication interaction warning that fires at patient-view (when the clinician hasn't yet decided to prescribe) is annoying. The same warning at order-select (when the prescription is being composed) is useful. Same content, wrong hook, opposite adoption outcome.
Match the hook to the moment the decision is being made.
The trust-building deployment
Shadow mode first
Run the CDS service for 2–4 weeks in shadow mode — fire the same cards, but don't show them to clinicians. Log what the cards would have suggested, and (separately) what the clinicians actually decided.
Shadow mode is your sanity check. If the cards would have fired 12 times per visit on average, your filters are wrong. If 80% of cards would have suggested the same thing the clinician already did, the value is low. Iterate before showing anything to users.
Expert validation panel
Before exposing cards to general clinical staff, run them past a panel of 3–5 senior clinicians representative of the user base. They'll catch contextual issues that shadow data won't — "this card is correct but the wording suggests overruling the diagnostic process, and our doctors will hate it."
Iterate wording, not just thresholds.
Phased rollout by specialty
Roll out CDS to one specialty at a time, not the whole organization. Adoption signals from each phase inform the next:
- If primary care accepts a card at 60% but cardiology accepts the same card at 15%, the card's threshold or context is wrong for cardiology.
- If a card has consistently high override rates with consistently consistent reasons, you have data to retire or reword that card.
Designing the suggestion
Specific design rules we apply per card:
- Show the evidence inline (the lab value, the prior note, the drug-drug pair)
- Make dismissal one click (CDS Hooks supports "dismiss with reason" — use it)
- Provide a single, specific suggestion ("order ferritin" not "consider further workup")
- Include a link to deeper context for clinicians who want it (don't dump the full citation into the card)
- Cap the card body at 2–3 sentences
Clinicians scan, not read. Cards are scanned. If they don't get the gist in 2 seconds, they're dismissed regardless of clinical merit.
When NOT to use CDS Hooks
CDS Hooks fires on workflow events. It's not the right tool for:
- Real-time monitoring of physiological data (use streaming + alerts, not workflow hooks)
- SaMD-class recommendations that require regulatory clearance (CDS Hooks cards are typically non-device CDS; SaMD has different deployment and validation requirements)
- Background risk scoring that updates daily (compute it overnight, deliver via dashboard, not workflow card)
If your CDS needs to fire outside the moment a clinician is making a decision, CDS Hooks is the wrong primitive. Use it for the moment, not for the ambient signal.
Measuring CDS that works
Three metrics. Acceptance rate is the leading indicator:
- Acceptance rate (not "fire rate") — % of fired cards where the clinician accepted the recommendation. Above 50% is excellent; below 20% means the card is firing at the wrong threshold or context.
- Override-with-reason captures — structured input on dismissals. Cluster reasons monthly; patterns tell you which cards to retire or reword.
- Clinical outcome correlation — does accepting the recommendation correlate with better outcomes? Hardest to measure but the only metric that matters long-term.
A CDS that fires 1,000 times per month at 80% acceptance is delivering value. One that fires 10,000 times at 15% acceptance is consuming attention without delivering anything. Both look identical in basic "cards delivered" metrics. Acceptance separates them.
Closing
CDS Hooks is a well-designed protocol. It will not save you from a poorly-designed deployment. The standard solves integration; adoption is solved by shadow mode, by per-card iteration with senior clinicians, by per-specialty rollout, and by ruthless instrumentation of acceptance.
The teams shipping CDS Hooks at >50% acceptance treat each card like a product, not a feature. The teams shipping at <15% treat it like a checkbox.