The healthcare industry has long struggled with how to handle vast amounts of data. Over a decade ago, everything existed on paper and hospitals had to rely on those printed pages and the memory of employees to prevent errors. Today’s clinicians benefit from technology that collects and collates large amounts of data to identify patterns or potential issues, with the ultimate goal of improving patient care. This data can exist in many different forms, and be stored in disparate sources. Therefore, it’s vital to understand what kind of data exists.
Let’s suppose we can sort alerts on patient data into three buckets:
- Bucket A: Information that is accessible, quick to use; the action is often straightforward, but can sometimes lead clinicians in myriad directions regarding patient care. For example, an inpatient with a positive result for measles.
- Bucket B: Information that looks at patterns within patient data for a whole-hospital or unit-specific view, i.e. cluster alerts and reports for MRSA or influenza. In these cases, there might be additional actions taken based on the pattern.
- Bucket C: Information that contains issues you don’t yet know about. This is the murkiest pile and requires a surveillance system that’s easy to use and easy to mine data from. For example, a spike in surgical site infections that relate to a particular surgeon. If the user isn’t able to readily access data in order to research the issue, these problems often fly under the radar.
Additionally, if the workday is consumed by responding to the alerts in Bucket A or B, there often isn’t time to seek out additional quality issues that could be impacting an organization.
No matter the bucket from which they are generated, alerts remind clinicians about everything from hospital-acquired infections, to patients’ drug allergies, possible drug interactions, dosing guidelines, and lab testing guidance. Clinicians can either follow the alerts’ recommendations, override them, or ignore them.
While alerts are important and can save lives, clinicians can become inured to them when they are repetitive and unnecessary. When this happens, staff may reflexively ignore the alerts and thus miss new and valid notifications of potential problems. This “alert fatigue” is one of many ways in which the complex interaction between clinicians and digital records can contribute to unintentional patient harm.
Alert fatigue and patient harm
Overriding alerts that are clinically relevant can potentially lead to harm, according to a recent study1 in BMJ Quality & Safety, by clinicians at Brigham and Women’s Hospital in Boston. Alarm fatigue was also a constant theme throughout ECRI’s 2017 patient safety list2—the same report that tapped diagnostic errors as the No. 1 concern this year.
Providers desperate to avoid alerts that don’t help them make better decisions may turn to workarounds, the No. 4 hazard on ECRI Institute’s 2018 patient safety list3. This can contribute to the challenges of the next item in the report: The overall dangers of poorly integrating health IT into tasks related to keeping patients safe.
Best practices for reducing alert fatigue
Whether you have a sophisticated clinical decision support (CDS) system or you’re still completing some of these processes manually through spreadsheets or other methods, there are five things to consider when implementing a CDS system or optimizing existing solutions to proactively reduce alert fatigue:
- Develop a plan that meets your goals
Is your organization trying to reduce errors, improve adherence to policy and protocols, create efficiencies, and/or save money? Consider the following items in the planning process to achieve your goals:
- This process will likely involve using data from multiple systems. Consider how different data sources might integrate into your CDS system. Contrary to popular belief, more data from more systems won’t equal more alerts but rather it allows for more specific, actionable alerts to be created. It’s important to choose a CDS that is sophisticated enough to incorporate different data sources to reduce noise.
- Determine interruptive versus non interruptive alerts (active versus passive): Serious warnings like drug allergy alerts are better as interruptive, while low-risk drug interactions may be better as non interruptive.
- Choose a delivery method for the alerts based on whether it’s active or passive. Will actionable alerts be sent in real-time or be report-based? No matter the type of alert and delivery method, there are times when both may be needed.
- Prioritize alerts based on severity and risk of harm.
- Avoid duplicative alerts, or the same alerts in two different systems. The system you choose should streamline and improve the current workflow, not add another workflow on top of an existing one.
2. Choose a system with a sophisticated rule engine
Select a system with the ability to tailor available patient information to the alert or reporting rule (e.g. gender, weight, laboratory values, radiology procedures, dietary needs, diagnosis, current problem list, location of care delivery). Next, include relevant drug information (e.g., dosage forms, routes, frequencies, dose, order status, ordering provider). Here are a few examples:
- Parameters for thrombocytopenia may be different for oncology vs non-oncology patients.
- Renal dosing criteria needs to compare both the creatinine clearance and the drug’s dose/route/frequency. Systems unable to evaluate the dose/route/frequency create nuisance alerts.
- IV-PO conversion rules should incorporate dietary orders as well as clinical data like fever, WBC count, etc.
Be sure to also incorporate multiple data elements (pharmacy, lab, micro, eMAR, ADT, radiology, surgery, vitals) and monitor trends in lab results. Choose a system that can integrate the patient’s vital signs, surgeries, radiology reports, and the presence of a relevant device when alerting for healthcare-associated infections. Strategies like these can be far more reliable than employing alerts based on a single lab result. Finally, include outcomes, such as lab monitoring for drug/drug interactions, to avoid alerts if these outcomes are met. A system with this level of complexity reduces noise and the amount of time a clinician has to spend reviewing charts for this information.
3. Customization is key
Customization helps avoid misinterpretation of alerts while offering the ability to easily include or exclude variables, something not possible with out-of-the-box alerts. By including “if-then” or “and/or/not” statements, alerts for a high INR can be suppressed if the patient is also receiving argatroban, for example, since argatroban is known to falsely elevate INR. You may also choose to customize certain alerts for patients who already have increased monitoring, such as those being treated in the ICU.
Customization also allows the CDS system to scale up in the event of an emerging pathogen. For example, during an Ebola outbreak, it would be important to have an alerting system that is capable of quickly creating rules to identify patients that report recent travel to the countries impacted by the outbreak.
4. Set up your system to retract alerts if information changes
Choose a system that retracts (literally withdraws or removes) the alert if something changes and it is no longer relevant. For example, if an hour after receiving an alert in your queue, the drug in question is discontinued, the alert should automatically be removed from the list. Or perhaps a new lab result post that change the action or dosing necessary for proper patient care.
5. Regularly review alert frequency and usage
Your CDS system should not only provide robust clinical and patient data reports, but also allow for reporting on frequency and usage of alerts. Meet with your team quarterly, or biannually, to review how often alerts trigger and what action is taken by clinicians when they do. For more consistent assessment, ensure that clinicians have a process to provide immediate and regular feedback on the usefulness of alerts they are receiving.
Your CDS system should also offer you the option of peer-to-peer review of your rules. The vendor should employ experts who understand your clinical workflow and the functionality of the rule engine. This way, they can offer you informed advice to improve your current usage of alerts.
Revisiting Buckets A, B, and C of data, it’s important for hospital organizations to talk about how their surveillance process works now and how it fits into the technology solution in place. Identify what’s immediately actionable (Bucket A) and what can fit into Bucket B or C. Remember: An actionable alert system is only as good as the data it receives.
Regardless, remember that researching, developing and executing on actionable alerts can reduce alert fatigue, but it’s an ongoing process that’s ever changing. There will always be new drugs, infections, and services, new clinicians and new procedures. Dedicate the time to review the process, incorporate feedback, and you’re well on your way to improving decision support, today and well into the future.