Making ICU Alarms Smarter Dr Ido Schoenberg i

Making ICU Alarms Smarter Dr. Ido Schoenberg i. MDsoft Dr. Roy Schoenberg, Dr. Charles Safran Center for Clinical Computing Beth Israel Deaconess Medical Center Harvard Medical School

Purpose of alarms • Alert ICU staff to changes in patient status that are clinically significant* and require immediate response or intervention *Significance - as judged by the ICU staff member responding to the alarm 2

The needle in the haystack (what alarms are looking for) • Physiological events (e. g. pulmonary edema) • Gradual and continuous over time • Affect multiple physiological parameters • Variable ¨ In a single patient ¨ Between patients ¨ Relative in time 3

Alarm systems that are used today. . • Follow a single parameter (e. g. heart rate) • Are boundary based • Have fixed, audiovisual output • Are discrete • Are unaware of interventions 4

Alarms. . . • 86% are false readings • 6% are true but clinically insignificant • 8% are significant* For some devices - only 2% are significant *Tsien CL, Fackler JC; Crit Care Med; 1997 Apr 25: 4, 614 -9 5

The effect of a 1: 50 ratio ( the cry wolf effect ) • Alarms are disregarded 1 • Alarms are silenced for a period of time • Alarm ranges are “adjusted” 2 • Alarms are turned off 3 • Monitoring is turned off • Murphy’s law kicks in. . . 6

Alarm systems we wish for • Sensitive • Specific • Sensible Smart alarms ! 7

Traditional monitors - using boundaries 91, 92, 89, 10, 81, 85, 88, 90, 92, 95, 93, 98, 25, 121, 118, 112, 115, 119, 114, 123, 280, 128, 122, 117, 114, 112, 11 • If [HR]>120 or [HR]<60 , 117, 114, 112, 110122, 128, 280, 123, 118, 112, 115, 119, 114, 121, 25, 81, 85, 88, 90, 92, 95, 93, 98, 1091, 92 121 25 122 128 280 8

The study system - using algorithms 91, 92, 89, 10, 81, 85, 88, 90, 92, 95, 93, 98, 25, 120, 118, 112, 115, 119, 114, 123, 280, 128, 120, 117, 114, 112, 11 Filter values below 30 bpm and over 250 bpm ] . 1 HR] > 120 bpm. 2 Average [HR] of 1 minute > 110 bpm. 3 Moving value-delta over 20 seconds > 10 bpm. 4 Two minute delta of 1 -minute-average > 5 bpm 9

The study system - using algorithms 91, 92, 89, 10, 81, 85, 88, 90, 92, 95, 93, 98, 25, 120, 118, 112, 115, 119, 114, 123, 280, 128, 120, 117, 114, 112, 11 . 1 if true=0. 2 if false= 0. 1 . 2 If true=0. 8 if false= -0. 3 . 3 if true=0. 3 if false= 0 . 4 If true=0. 4 <trigger value if false= -0. 2 0. 9 , 280, 128, 120, 117, 114, 112, 11012391, 92, 89, 10, 81, 85, 88, 90, 92, 95, 93, 98, 25, 120, 118, 112, 115, 119, 1 10

The study system • Interface build in Visual Basic • Core & drivers in C++ • Meta. Vision™ from i. MDSoft© • MS Windows™ NT 4. 0 • MS SQL Server™ 7. 0 11

Study design • Six patients, five days in a university hospital ICU • Manually documented monitor alarms for heart rate, blood pressure and oxygen saturation • ICU staff identifies subset of significant alarms • Study system produces its own set of alarms • Measure the ability of both systems to detect significant alarms *ICU staff classified alarms as they occurred. 12

Monitor alarms Significant alarms PV P Time PV P Algorithm alarms 13

Results - monitor alarms 6, 872 alarms recorded during 337 hours of study time 14

Results - algorithm system 544 alarms generated • Missed 55 significant alarms (18. 6%) 15

Alarm distribution (By parameter) 16

Positive predictive values (By parameter) P=0. 011 17

Alarms - overall 18

Positive predictive values (Overall) 19

The increased PPV can be attributed to. . • Averaging values • Attaching high weight to persistent changes • Excluding outliers in calculations • Slow sampling rate • The use of “delta” rather than absolute values • Negative valued components 20

The missing 18% • Missing data • Bad algorithms • Time ranges • Delta ratios • Incorrect weight assignment to components • Missing alarms were insignificant ? • . . . Bugs in code 21

Discussion • High specificity and predictive value • Sensitivity at 81% ( Good enough ? ) • Further research & development: • Better algorithms • Multi parameter algorithm • Cascading alarms 22

Building a septic shock alarm • Developing tachycardia Tachycardia Urine output • Developing hypotension • Dropping body temperature Positive blood culture • Dropping urine output • Positive blood culture Hypotension Temperature 23

Making ICU Alarms Smarter Dr. Ido Schoenberg i. MDsoft Dr. Roy Schoenberg, Dr. Charles Safran Center for Clinical Computing Beth Israel Deaconess Medical Center Harvard Medical School 24

Sensitivity & PPV of a system Significant Insignificant Detected a b Not detected c d • Sensitivity = a / ( a + c ) • Specificity = d / ( b + d ) • Positive Predictive Value = a / ( a + b ) 25

Analogy to neural networks 26

Customizing formulas 27

Customizing statements 28

Customizing alarms 29

Running the alarm 30

Categorizing alarms 31

Building a component Parameters Functions HR Logic Operand & Reference value Abs value [ ] RR SBP DBP > + Delta(xtime)[ ] + LVD [ HR ] >5 AND Delta_Avg(1, 3)[HR]>10 = Last Value Delta [ ] MBP Delta Avg(xtime)[ ] Sa. O 2% Component Example < Avg(xtime)[ ] And Or Missing values false true Not 0. 5 0. 2 0. 8 Component Score 32

Running an alarm Alarm components Component 1 Component 2 Component 3 Component 4 True = 0. 8 False = 0. 2 True = -0. 2 False = 0. 3 True = 0. 4 False = 0. 1 True = 0. 5 False = 0 Status at 10: 57 AM Score True 0. 8 True 0. 2 - False 0. 1 True 0. 5 1. 2 Alarm trigger set to 1. 0 1. 2 > 1. 0 Alarm will sound 33

Conclusion • Holds promise mainly in filtering false alarms • As is -- May serve as an “emphesizer” to traditional monitor alarms • Further Research & Development : • Better Algorithms ( Sharing knowledge ) • Multi Parameter Algorithms • Linkage to other clinical resources • Decision Support 34

35

Evolving tachycardia ? • Is there a continuous increase in heart rate ? • Are these values likely to be erroneous readings ? • Is the actual heart rate high ? • Does this look like a steady rhythm or an arrhythmia ? 36