BLOGS 
NEWSROOM 
CASE STUDIES 
WEBINARS 
PODCASTS 
ASSET HUB 
EVENT CALENDAR 
TL;DR
- The same risk score should reach a nurse and a prescriber in two different ways, and most systems send it the same way to both.
- Nursing CDS and physician CDS are not different technologies. They are the same logic delivered at different moments to people with different authority to act.
- A nurse usually cannot action a prescribing alert. Sending it to them is noise by construction, and no amount of tuning fixes a recipient who has no lever to pull.
- The firing point encodes the role: a passive score where a nurse reviews a chart, an interruptive card at the moment a prescriber commits an order.
- The research is consistent that nursing CDS implementations underperform, and it names workflow fit and usability as the causes rather than clinician resistance.
- We have shipped role-targeted decision support that clinicians engaged with 87% of the time. Not a nursing product and not a sepsis product. The architecture, and we say which.
What Clinical Decision Support Actually Does For A Clinician
A clinical decision support system takes patient data, applies clinical logic to it, and puts the result in front of a clinician while there is still time to act on it.
Everything interesting is in that last clause. The logic is rarely the hard part. Drug interaction rules, risk scores, guideline checks and duplicate-order detection are well understood and have been for years. The hard part is delivery: getting the right output to a person who can act on it, at a moment when acting is still possible, in a form that takes seconds to evaluate.
That is why the same system produces very different results in different hands. A guideline-adherence prompt that changes prescribing behavior when it reaches a physician at order entry does nothing at all when it appears on a nurse’s chart-review screen four hours earlier, because the nurse cannot write the order. The logic was correct both times.
The category has been split into “CDS for nursing” and “CDS for physicians” as though they were two products. They are not. They are one capability with two delivery contracts, and confusing the two is the most common reason a rollout underperforms.
Nursing CDS: Where It Fires And What It Should Carry
Nursing decision support fires mostly at observation and escalation, not at ordering.
A nurse’s day contains a small number of repeating moments where decision support is genuinely useful:
- Chart review at the start of a shift or after a handoff, where the useful output is a summary of what changed and who is deteriorating
- Vitals entry, where a value crossing a threshold should surface immediately rather than be discovered later
- Escalation, where the decision is not what to prescribe but whether to call someone, and how urgently
- Documentation and protocol adherence, where the system checks that a required step happened
Three of those four are about noticing something sooner. That points at a specific delivery style. In an EHR supporting CDS Hooks, the natural fit is patient-view,which fires when a chart is opened. It is present when the nurse arrives, it interrupts nothing, and it is available to be read rather than demanding to be answered.
That is the right default for a role whose job is observation. A risk score sitting in the chart summary gets absorbed. The same score delivered as a pop-up that must be dismissed with a documented reason gets dismissed, and the nurse learns to dismiss the next one faster.
The escalation case is the exception worth designing for. When a patient meets deterioration criteria, the useful output is not a score. It is the score plus the criteria that triggered it plus who to call, because that is what the nurse will need to say on the phone in the next sixty seconds.
Physician CDS: A Different Moment, A Different Product
Physician decision support fires at commitment, which is a much narrower and much higher-stakes window.
The moment that matters is order entry. It is the last point at which the plan can change cheaply, and it is where the prescriber has both the authority and the intent to act. Two of the three hooks that Epic supports in practice sit there: order-select when a clinician picks an order, and order-sign immediately before it is committed. The third, patient-view,is the nursing default described above.
Epic supports exactly three of these hooks in practice: patient-view,order-select,and order-sign. Most vendor documentation says only that Epic supports CDS Hooks without saying which, and the difference decides where a piece of logic can live.
What a physician-facing card needs is different from what a nursing summary needs:
- A single action: A card offering four options becomes a menu, and menus get closed. One decision, one way to act on it.
- The reason, stated: A score with no explanation cannot be evaluated in the seconds available. Naming the two or three values that moved it lets the prescriber agree or disagree on the evidence.
- Interruption, but sparingly: At order-sign an interruptive card is appropriate, because the alternative is a wrong order committing. That budget is small and spending it on low-value checks is how it gets exhausted.
Note what happened to the search language here. Ask about clinical decision support for physicians and you land in academic literature and patent filings. Ask about clinical decision support tools for physicians and you land among vendors. The buyer looking to change something searches for a tool. That gap between how the category is written about and how it is bought is worth knowing if you are evaluating options rather than reading around the subject.
Same Alert, Two Roles: What Actually Changes
This is the comparison that decides most implementation arguments, and it is missing from nearly everything written about the category.
Take one sepsis risk score crossing its threshold. Here is what should differ:
| Nurse | Prescriber | |
|---|---|---|
| When it fires | Chart open, vitals entry | Order entry |
| Delivery | Passive score in the summary | Card at order-select or order-sign |
| What it should say | What changed, which values, escalation criteria | What to order, and why this patient |
| Action available | Assess, escalate, document | Order, or decline with a reason |
| Interruptive? | Rarely. Observation does not need interrupting | Sometimes. Commitment is worth interrupting |
| Failure mode when wrong | Ignored, and the next one too | Overridden, and the override rate climbs |
The row that decides the rest is action available. Decision support is only useful to someone who can do something with it, and the two roles can do different things. A drug-interaction warning is actionable for a prescriber and, in most organizations, informational for a nurse. Routing it identically to both is not thoroughness. It is a design that has not decided who the alert is for.
That is also the honest answer to the perennial question of whether nurses get too many alerts. Often the count is not the problem. The problem is that a meaningful share of them were never actionable by the person receiving them.
Make Clinical Alerts Work for the Whole Care Team
Why Nursing CDS Implementations Underperform
The literature is fairly blunt about this, and it is worth being blunt back.
Studies of clinical decision support in nursing report low implementation success rates, and the barriers named are consistent: alarm fatigue, limited usability, poor integration with existing workflow, and insufficient training. Qualitative work using fit-between-individuals-tasks-and-technology framing reaches the same place from a different direction. What is striking is what is not on that list. Clinician resistance is not the headline cause. Neither is inaccurate logic.
Every named barrier is a delivery decision made by whoever configured the system.
- Alarm fatigue is a consequence of firing on things the recipient cannot act on, and of firing interruptively where passive would do.
- Usability at the alert level means the card is readable in the seconds actually available, with its reason attached.
- Workflow fit means firing at a moment the clinician is already in, rather than at the moment the data happened to update.
- Training partly compensates for the other three. A system that fits the workflow needs much less of it.
The program-level work of managing alert burden across an entire health system, tiering, suppression policy, governance and measurement, is a larger subject than one page can carry. We treat it separately in reducing alert fatigue in clinical decision support. What follows here stays at the level of the individual alert and who receives it.
Role-based Routing: Which Alerts Should Never Reach A Physician
Routing is the cheapest improvement available in most deployments, and it is usually treated as a configuration detail rather than a design decision.
The test is one question. Does the person receiving this alert have the authority and the information to act on it right now? If the answer is no, the alert is misrouted, and no amount of threshold tuning will fix it.
Applied honestly, that question moves a lot of traffic:
- Many medication-level warnings belong in a pharmacy workflow, not a prescriber interruption. Pharmacy can resolve a substantial share before the prescriber ever needs to see one.
- Preventive care and screening reminders are usually better placed with nursing or care coordination, where following up is the job rather than an interruption to it.
- Deterioration and escalation signals belong with whoever is at the bedside, which is nursing, with a defined path to the prescriber rather than a simultaneous alert to both.
- Order-level checks belong at order entry with the prescriber, and nowhere else.
Two implementation notes that catch teams out. Use the feedback endpoint so a service learns a suggestion was accepted or overridden, because re-firing on something already actioned is the most avoidable alert in any system. And know when a card is the wrong container: anything genuinely multi-step belongs in an embedded SMART on FHIR application launched from a card link, not in the card itself. The technical implementation detail covers the request and response contract.
What We Have Built, And What We Have Not
We have not built a nursing decision support product, and we have no nursing case study. Being specific about that is more useful to anyone evaluating options than the alternative.
What we have built is role-targeted decision support at the prescriber end, in production.
For a perioperative client we built decision support delivered as CDS Hooks cards inside Epic’s ordering workflow. The order-sign hook fires, patient data goes to our service, and missing preoperative labs come back as a card with one action attached. Missed labs fell from 15% to 2%. Lab ordering time dropped from 60 minutes a day to 10 to 15 minutes. Surgery delays caused by missing labs went from around 10 a month to 3 to 5.
Provider engagement with that card was 87%.
That number is worth setting directly against the research above. It is not a claim that our logic was more accurate than anyone else’s. It is evidence that a card presenting one decision, at the moment the decision is made, to a person with the authority to act, gets used rather than cleared. The literature says nursing CDS implementations underperform and names delivery as the reason. This is a data point from the other side of the same argument.
We have also built the observation half, for a different condition: a validated predictive model surfaced inside Epic through SMART on FHIR, reaching 83% accuracy, which is the passive-score pattern described for nursing above. Different clinical problem, same delivery shape.
All client details are anonymized. The metrics are from delivered work.
What To Ask Before You Buy Or Build For Either Role
The same questions separate a system that changes behavior from one that adds notifications, whichever role you are buying for.
- Ask which hook, and for whom: If the answer is that it supports CDS Hooks, ask which ones, in which EHR, and what the card contains. If the answer is a dashboard, ask who is expected to be looking at it and when.
- Ask what the nurse can do about it: For any nursing-facing alert, ask what action it enables. If the honest answer is “escalate”, the alert should carry the escalation criteria and the contact, not just a score.
- Ask about routing before thresholds: Most vendors will discuss sensitivity. Fewer will discuss which alerts never reach a prescriber at all. The second conversation is usually worth more.
Ask for the override rate by role, not overall. A blended figure hides the case where one role is being served well and another is being spammed.
Ask who owns the configuration after go-live, how often it is reviewed, and what evidence triggers a change.
Where an EHR’s native decision support already fits the workflow, the work is configuration and routing rather than building. Where it does not, the gap is usually the delivery layer rather than the logic, and that can be built as a service against hooks the EHR already exposes without replacing anything. If you are comparing options, our clinical decision support software buyer’s guide sets out the criteria, and worked examples of clinical decision support shows what these look like in production. For the broader category, start with clinical decision support systems.
It is decision support delivered at the moments that make up nursing work: chart review, vitals entry, escalation and documentation. In practice that usually means a risk score or summary of change presented passively when a nurse opens a chart, plus threshold alerts on values as they are recorded. It is the same underlying logic used in physician-facing decision support, delivered at different points and in a different form.
The logic is often identical. What differs is when it fires and what the recipient can do about it. Nursing decision support fires at observation and escalation, where the useful action is to assess or call someone, so passive delivery usually works better. Physician decision support fires at order entry, where the clinician has the authority to change the plan, so an interruptive card with a single action is appropriate. The deciding question is whether the recipient can act on the alert.
Research on decision support in nursing consistently reports low implementation success, and names alarm fatigue, limited usability, poor workflow integration and insufficient training as the barriers. Notably, clinician resistance and inaccurate logic are not the headline causes. Every named barrier is a delivery decision, which means most of them are fixable in configuration rather than by replacing the system.
Most nurses use decision support embedded in the EHR rather than a separate product: deterioration and early-warning scores, protocol and documentation checks, and threshold alerts on recorded vitals. Reference tools sit alongside these. Where an organization needs something the EHR does not provide natively, it can usually be added as a decision support service against the hooks the EHR already exposes, rather than as a separate application.
Yes, and it is generally the highest-value change available. Many medication-level warnings can be resolved in a pharmacy workflow before a prescriber sees them, preventive care reminders often belong with nursing or care coordination, and order-level checks belong at order entry. The test for any alert is whether the recipient has both the authority and the information to act on it immediately. If not, it is misrouted rather than mistuned.
