Rob Lerman, MD, CMO, Kent Seckinger, CCDS, Customer Success Director and Fran Moriarty, Director of National Accounts, PrepMD Clinic Solutions Team
Management of clinical alerts is unquestionably one of the most challenging tasks for remote monitoring programs. Optimizing alerts saves staff time and focuses energy on clinically relevant issues. Customizing alerts addresses the variations in care that are seen between clinicians. Development of a clear clinical escalation policy ensures expedited communication between the care team and reduces the time between clinical event and clinical action.
Whenever a remote monitoring program is started or reviewed, it is helpful to bring all the clinical stakeholders together for a discussion about alert programming. That includes anyone from the physicians and advanced practice providers (APPs) who see escalations to the nurses and techs that may be the primary alert reviewers. As difficult as it may be to get physicians and APPs to sit down for such a meeting, establishing their preferences up front saves a great deal of everyone’s time in the long run. It is important to go through all the manufacturers’ alerts with fresh eyes and select whether they are programmed on as a clinic default and if so to what level of urgency (red vs. yellow, etc.) If possible, it is helpful to create categories of patients based on indications and create standardized programming parameters for those patient groups. For example, patients with complete heart block should likely all have the alert for excess RV pacing turned off. A clinic may want to have one standard set of alerts programmed for primary prevention ICD patients and another for secondary prevention patients. While there will always be customization, if you can standardize the alerts as much as possible across your population, it will reduce confusion and make communication that much easier.
Patient-level customization should start at or even before implant with a conversation between the implanting physician and industry representative. Implanting physicians will often have a wealth of clinical information about the patient which will inform device programming, and device company representatives typically know the details of features and algorithms better than anyone else. An experienced device company representative will learn the programming preferences of the physicians and clinics they serve and will often quickly learn the typical alert preference programming. Nonetheless, the implanting physician should always confirm the proper programming for an individual patient, especially when it deviates from the customary.
The first clinic visit after implant is another great opportunity to check in with the clinicians on alert programming for an individual patient, especially if the follow-up staff is not the same as the implant staff. The lab or operating room is often a hectic environment and there isn’t always an opportunity for a thorough review of alert parameters at implant. The follow-up wound check may provide a better opportunity to raise questions such as whether a patient in atrial fibrillation will be a candidate for cardioversion and thus should have AF alerts programmed on or whether that patient is in permanent AF and should have those alerts turned off. Making the initial investments in time to program alerts properly pays dividends over the long term.
One issue that is often a source of variation in programming is whether to program alerts as “red” or “yellow” or other. Certainly, there are some alerts that are not programmable and default to red status for almost all manufacturers. Examples of those would be a battery at end of life or a hardware reset. Other alerts can be programmed as red or yellow, or for many Medtronic alerts, as a website only alert that will not be identified by color. For the most part, red or yellow alerts are displayed at the top of the dashboard on the manufacturers’ remote monitoring portals, so their main benefit is that they are readily identifiable as issues requiring attention. Many device nurses or techs will start their reviews by attending to the red or yellow alerts, so those designations may have a direct impact on clinical workflow. Some physicians or APPs will direct their clinical escalations based on alert color, such as “Only call me for red alerts”. Others may treat red and yellow alerts identically. While alert color is helpful, not all clinically actionable events may be identifiable by a red or yellow alert. Episodes of pace-terminated ventricular tachycardia or a single ICD shock may not always be eligible for red or yellow alert designation, depending on the manufacturer.
Many alerts offer opportunities to customize further based on parameters such as arrhythmia duration or heart rate. For example, a patient with known short bursts of paroxysmal atrial fibrillation could be programmed to alert only if an episode lasted for a prolonged period of time or if the AF burden met certain criteria. Likewise, a patient with permanent AF with controlled ventricular response could be programmed to alert only if the ventricular rate exceeded a certain value and a patient with known brief sinus pauses could be programmed to alert only for prolonged pauses. This contrasts with for example, a patient with a history of cryptogenic stroke for whom you may want to be alerted for any episode of AF that might identify the need for anti-coagulation. Customization of alerts in this manner goes a long way towards increasing the odds that an alert will be actionable. It is important that members of the care team who are adjusting alerts have access to important clinical information such as anti-coagulation status which may change over time.
Many implantable cardiovascular monitors, or implantable loop recorders (ILRs), are seeking to decrease the large burden of non-actionable alerts by offering indication specific programming as a “bundle”. For example, a patient with suspected ventricular tachycardia may have the “Tachy” parameter programmed on as a red alert but the “AF” parameter off altogether. Often clinics will program alerts broadly “On” at implant but aggressively narrow the alert parameters as time goes on.
Regardless of the best intent, some false positive alerts are inevitable. ILRs are probably the most common culprits because of the nature of the device. Given that they are not intracardiac but subcutaneous their signals are subject to more external disruption and noise than intracardiac leads. Additionally, since like surface leads they have combined atrial and ventricular electrograms, sophisticated algorithms to differentiate atrial from ventricular arrhythmias based on A-V relationships are often unavailable. Of course, even pacemakers and ICDs often have trouble differentiating atrial from ventricular tachycardia and may generate false positive alerts. Programming around these can be quite difficult. The programming of ILRs is often more “liberal” with respect to arrhythmia identification, because as diagnostic-only devices they cannot treat the arrhythmias that occur, raising the importance of identifying rhythm abnormalities (such as long pauses or tachyarrhythmias) so that they can be treated before adverse events occur. Some physicians are less interested in being alerted for events that the device has treated, such as a single ICD shock.
Minimizing false positive alerts decreases alert fatigue amongst clinicians, but even when this isn’t possible, the primary alert reviewer needs to remain vigilant and at least briefly review every alert. A true-life example where this played out was a woman in her mid-20s with an ILR who transmitted over 100 false positive alerts for sinus tachycardia before she had an episode of true ventricular tachycardia at over 200 bpm. Many ILRs now allow reprogramming remotely which would have allowed us to filter out the sinus tachycardia during her daily workouts, but even when that is unsuccessful it is important to review all data, even though it can be frustrating at times.
Different physicians may have very different attitudes about what kind of arrhythmias are important, especially when considering therapy such as catheter ablation. Whereas one cardiologist may not be interested in asymptomatic episodes of ventricular tachycardia below the rate cut-off of an ICD, others are more aggressive about ablation of complex arrhythmias and may want to be aware of those same arrhythmias. Similar philosophical differences apply to atrial arrhythmias, so again communication between physicians and the primary event reviewers is paramount. In organizations with multiple physicians, it is often helpful to have a physician champion for the remote monitoring program who can often drive at least some level of standardization of alert criteria.
The final, and in some ways, the most important piece of the alert management puzzle is development and operation of a coordinated cohesive clinical escalation policy. The escalation policy determines how clinical information gets turned into clinical action. Once the primary reviewer, be it a clinic nurse or tech or a third-party remote monitoring specialist, determines that an alert or event is real, what do they do with that information? What types of events should generate a report? What types of events require escalation to another member of the care team and how should that information be conveyed? Is a note in the EHR sufficient or does it warrant a phone call or text message? To which member of the care team does the message go? Does the physician ever want to be interrupted in clinic or in the lab and if so, for what? Are there specific clinical scenarios which merit that a patient should call 911 or go to the emergency department? Are there others when scheduling a clinic visit is more appropriate?
Clear delineation and documentation of the clinical escalation policy reduces stress for the care team and ensures that urgent situations get addressed quickly and that no one is interrupted with unnecessary calls or messages. Typical issues that might be addressed include episodes of atrial fibrillation- how long or fast do they need to be in order to be escalated? How is an anticoagulated patient handled differently from one who isn’t anticoagulated? How about episodes of nonsustained ventricular tachycardia in both ICD and pacemaker patients? How long does a pause in an ILR patient need to be to require urgent attention? Don’t forget to address both normal working hours as well as nights, weekends, and holidays when the entire team is not available. An upfront investment of a little time to define escalation policies improves patient care and goes a long way towards avoiding awkward and sometimes unpleasant conversations.
Clinical escalations should always be documented, whether in the EHR, remote monitoring software platform, or elsewhere and the escalation protocols should be a living document that is periodically reviewed. Emerging clinical data, changes in clinician staff, or improvements in clinical operations are just a few of the reasons that protocols may need to be changed. At minimum, an annual stakeholder review improves the chances that everyone is staying on the same page.
Data deluge and alert fatigue are some of the principal barriers to adoption of remote monitoring for CIEDs. Careful attention to alert management can minimize false positive alerts and keep the focus on moving from clinical event to clinical action. Standardizing alert parameters as much as possible by device type and patient indication can simplify clinical workflows, but customization of alerts for individual patients further refines the data that needs review. Developing clear clinical escalation policies improves efficiency and patient care, while minimizing unnecessary distractions.
Questions about this article should be directed to the PrepMD Clinic Solutions Team.
