Every Alert Needs an Owner: A Recommendation for Clinical Decision Support Governance With Named Accountability and a Review Cadence
Student Name
Doctor of Nursing Practice Program, Aspen University
DNP865: Healthcare Technologies and Informatics
Instructor Name
Month Day, Year
Every Alert Needs an Owner: A Recommendation for Clinical Decision Support Governance With Named Accountability and a Review Cadence
Clinical decision support accumulates. Alerts are added after safety events, regulatory changes, and requests from departments, and they are rarely removed. Over time, the volume rises, the value of individual alerts falls, and some alerts stop working without anyone noticing. This paper recommends a clinical decision support governance program for a composite 350-bed hospital, specifying what it will do, who owns each part, and how often each element will be reviewed.
The Current State
An inventory conducted for this recommendation found 412 active interruptive alerts in the hospital's electronic health record. For 131 of them, no current owner could be identified; the person who requested them had left or changed roles. Over one month, 38 alerts accounted for 80 percent of all firings, and their override rates ranged from 72 to 98 percent. Two alerts had not fired at all for more than a year, including one intended to warn about a dangerous drug combination, because a medication code had been changed during an upgrade. Earlier work in this course documented the burden of a sepsis prediction alert and the effect of repeated alerts on clinicians' attention.
Why Governance Is Needed
Two kinds of failure justify governance. The first is overload: when many alerts are low value, clinicians override the majority, and repeated alerts reduce the likelihood that any given alert is accepted (Ancker et al., 2017). The second is malfunction. An analysis of 68 decision support malfunctions from 14 sites found that build errors, conceptualization errors, and the introduction of new codes or terms were the most frequent causes, that most malfunctions were discovered through user reports rather than monitoring, and that malfunctions caused both false-positive and false-negative firing; problems often followed code set updates and system upgrades (Wright et al., 2018). An alert that fires too often wastes attention; an alert that silently stops firing removes a safeguard that everyone assumes is still there. Both failures are predictable, and both require someone to be responsible for noticing them.
The Recommendation
The hospital should establish a Clinical Decision Support Governance Committee with authority to approve, modify, and retire interruptive alerts and order set rules. The committee will apply three rules. First, every alert must have a named clinical owner and a named technical owner, recorded in the alert inventory. Second, every new alert must state its purpose, target users, expected firing rate, and a measure of success before it is built. Third, any alert with an override rate above 90 percent for three consecutive months, or with no firings for six months, is automatically reviewed and either redesigned, justified, or retired.
Alternatives to Interruption
Governance should not only remove alerts but also change how guidance is delivered. Many interruptive alerts could become passive guidance: a default in an order set, a highlighted field, a worklist item, or a banner that informs without stopping work. Implementers' guidance on decision support describes a wide range of intervention types beyond alerts, and emphasizes matching the type to the decision, the user, and the point in the workflow (Osheroff et al., 2012). The committee will therefore ask of every flagged alert whether an interruption is necessary at all. An alert that warns about a dangerous drug combination at the moment of ordering justifies an interruption; a reminder to document a screening questionnaire does not, and belongs in a task list. Moving low-risk guidance out of interruptive alerts protects clinicians' attention for the warnings that truly require it, which is the underlying purpose of governance.
Named Owners
The chief nursing informatics officer and the chief medical information officer will co-chair the committee and be accountable to the chief quality officer for its results. The pharmacy informatics manager will own medication-related alerts and the monitoring of medication code changes after upgrades. A clinical informatics analyst will maintain the alert inventory and produce the monthly metrics report. Each alert's clinical owner, a physician, nurse, or pharmacist with responsibility for the relevant practice, will review their alert's performance when it is flagged and propose changes. The IT change management lead will ensure that no upgrade goes live without testing a defined set of high-risk alerts. Nursing representation on the committee will include at least two frontline nurses, since nurses receive a large share of interruptive alerts.
Review Cadence
Monthly: the analyst will report firing counts, override rates, and alerts meeting the automatic review criteria, and the committee will act on flagged alerts. Quarterly: the committee will review trends in total alert burden per 100 patient-days and clinician survey results, and report to the quality committee. After every system upgrade: the change management lead will run the high-risk alert test suite within 24 hours and report results to the co-chairs. Annually: the committee will review the full inventory, confirm or reassign every owner, and retire alerts that no longer serve their purpose.
Expected Results and Measures
Within 12 months, the program aims to reduce total interruptive alert firings by 30 percent, eliminate alerts without owners, reduce the number of alerts with override rates above 90 percent by half, and detect any post-upgrade malfunction within 24 hours. Clinician satisfaction with decision support will be surveyed at baseline and at 12 months. Safety events related to missing or malfunctioning alerts will be reviewed at each quarterly meeting.
Risks of the Program
Retiring alerts carries its own risk: an alert that seemed low value may occasionally prevent harm. For that reason, retirement decisions will be documented with the evidence reviewed, and retired alerts will be archived rather than deleted, so they can be restored if an event suggests they were needed. The committee may also face pressure from departments that want to keep their alerts; the rule that alerts meeting review criteria must be justified with data gives the committee a neutral basis for these conversations.
Conclusion
Decision support loses value when no one is responsible for it. The recommended governance program gives every alert a clinical and technical owner, sets rules for adding and retiring alerts, and establishes a monthly, quarterly, post-upgrade, and annual review cadence. With these structures, the hospital can reduce the alerts that waste attention and catch the ones that silently fail.
References
Ancker, J. S., Edwards, A., Nosal, S., Hauser, D., Mauer, E., Kaushal, R., & HITEC Investigators. (2017). Effects of workload, work complexity, and repeated alerts on alert fatigue in a clinical decision support system. BMC Medical Informatics and Decision Making, 17, Article 36. https://doi.org/10.1186/s12911-017-0430-8
Osheroff, J. A., Teich, J. M., Levick, D., Saldana, L., Velasco, F. T., Sittig, D. F., Rogers, K. M., & Jenders, R. A. (2012). Improving outcomes with clinical decision support: An implementer's guide (2nd ed.). HIMSS.
Wright, A., Ai, A., Ash, J., Wiesen, J. F., Hickman, T.-T. T., Aaron, S., McEvoy, D., Borkowsky, S., Dissanayake, P. I., Embi, P., Galanter, W., Harper, J., Kassakian, S. Z., Ramoni, R., Schreiber, R., Sirajuddin, A., Bates, D. W., & Sittig, D. F. (2018). Clinical decision support alert malfunctions: Analysis and empirically derived taxonomy. Journal of the American Medical Informatics Association, 25(5), 496-506. https://doi.org/10.1093/jamia/ocx106
How this DNP 865 Module 8 example is structured
DNP865 Module 8 typically closes with an informatics recommendation naming owners and a review cadence. Aspen does not publish module deliverables, so check your classroom for the exact prompt. This example quantifies the current state, justifies governance with evidence on two failure modes, states a specific recommendation, names owners by role, sets a review cadence and defines measures.
DNP865 Module 8 questions, answered
What does DNP865 Module 8 usually ask for?
The final module typically asks for an informatics recommendation that names who owns each part of the plan and how often it will be reviewed. Aspen does not publish module deliverables, so your classroom's instructions govern.
Why do clinical decision support alerts need governance?
Alerts accumulate and are rarely removed, leading to overload and overrides, and they can malfunction silently after code changes or upgrades. Governance assigns owners and reviews to catch both problems.
What causes decision support alerts to malfunction?
An analysis of 68 malfunctions from 14 sites found build errors, conceptualization errors and new codes or terms were the most common causes, often after code set updates or system upgrades, and most were discovered by users rather than monitoring.
Write yours, or have the desk draft it
This paper is an original model document written by our desk, not a submitted student paper and not an official Aspen University document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.