|
A user report from ansm was received, indicating around 8pm, an asystole alert was generated on the smartphone.The user discovered the patient on the floor in cardio-respiratory arrest.The intensivist was alerted and cpr was initiated at 8:02pm and continued for 20 minutes; however, resuscitation was unsuccessful and the patient's death was declared at 8:22pm.The data at the central station was reviewed, revealing a red alarm for ventricular tachycardia was generated at 7:39pm, which transitioned to asystole at 7:48pm.The telemetry device was sequestered as a precaution and related smartphones were determined to be compliant.Additional information from the customer indicated there was a delay in receiving the alarms at the phone; however, a log review revealed the asystole was generated at 19:48:50pm, the alarm sounded at the central station, and the alarm was transmitted to the phones at 19:48:50pm.The alarm was silenced at 19:50:56 prior to the alarm being accepted at the phone, which interrupted the alarm transmission process.Based on this information, there does not appear to be a malfunction of careevent which contributed to the death; however, clinical workflow, alarm management or use error may have been a factor.
|
|
The remote service engineer (rse) provided an initial analysis of the logs and found that at 19:39, a tachy/vent alarm is triggered and is recorded in the registry of the central station.A "red alarm sound emitted" was found on the logs, indicating that the alarm rang at the central station.At the same time, a tachy/fib vent alarm was triggered and rang at the central station.An asystole alarm was generated at 19:48 at the central station.An acknowledgement (silence) of the asystole alarm occurred at 19:50 and the asystole alarm again sounded at the central station at 19:51.Given the analysis of the logs, the alarms were produced by the mx40 and sent as expected to the central station.A clinical product specialist reviewed the data and advised the following: ventricular tachycardia (tachy vent) was generated at 19:39:38 on pic ix:ovrcardio2 with the system time 19:39:58.These clocks are on separate time sources but are happening simultaneously.A 20 second difference in time stamp is shown, but this does not represent a delay.This alarm was sent to mobile device 1card3 and was accepted on this device.The tachy vent alarm was also sent to mobile device 2card3 and 3card3 which did not respond.The strip that was sent to the mobile device appears to be consistent with the tachy vent rhythm.Fib/tachy vent generated at 19:39:39 on pic ix:ovrcardio2 and was sent to 3 devices and was not accepted by 1card3, 2card3, or 3card3.This alarm ended when asystole generated at 19:48:30.The strip that was sent to the mobile device appears to be consistent with fib/tachy vent rhythm.Asystole was generated at 19:48:30 on pic ix:ovrcardio2 and was acknowledged at ovrcardio2 at 19:50:36.This alarm was sent to 1card3, 2card3, and 3card3 but was not accepted or read before the alarm was acknowledged at the pic and removed from the phones due to the configuration: auto close popup for handled events.If the event is acknowledged, ended, expired or accepted at another device, any open pop-up windows for the event are closed.With this option turned off, the popup window remains open until dismissed by a user.The strip that was sent to the mobile device appears to be consistent with asystole as no qrs appear to be present.Asystole alarm was generated at 19:50:47 and was sent to mobile device 1card3, which accepted this alarm.This alarm was acknowledged at ovrcardio2 at 19:51:16.This alarm reminded at the central station again at 19:54:48 and was acknowledged at 20:00:45.This was followed by ecg leads off at 20:01:00.This strip was not sent in the logs.Below is an excerpt from pic ix c.03 ifu: log entries for alarms.The log records for alarms contain the following information: ¿ alarms display in the colors corresponding to their severity level.¿ all red and yellow physiological alarms include the value of the corresponding numeric.¿ the text format depends on whether the device sends standard or enhanced alarm text.Intellivue telemetry system bedside monitors and mrx monitors only send standard alarm text.- for devices that send standard alarm text, the system tries to add the vital sign value as close as possible to the time of the alarm.For example, **hr high (hr = 122).This may not be the exact value that caused the alarm.- for devices that send enhanced alarm text, the log entry shows the actual alarm limit violation.For example, * hr 132>130.¿ the date column in the log record indicates the date and time displayed on the information center when the entry occurred.The action column contains the text generated when the alarm first appears in the sector, and ended when the alarm no longer appears in the sector.Note ¿ the time in the action column shows the clock time of the monitoring device.The clock time may drift up to 30 seconds before the information center clock synchronizes to the monitoring device clock.Below is an excerpt from pic ix c.03 ifu: warnings.¿ bed to bed overview at the intellivue patient monitor and the paging system is a secondary alarm notification system and is not intended for primary notification of alarms, physiological data, or demographic data.Receipt by the external software device of alerts is not confirmed, and delivery to the device is not guaranteed.Time data, including alarms may be delayed.¿ clinicians using the paging system must remain within monitoring distance of the primary alarm notification device (such as a bedside monitor).If there is no bedside monitor, the primary alarm notification device is the information center.It was determined that the control panel worked correctly and the transmission of the alarms on the phone was done on time.The products worked as designed and according to the configuration.The reported problem was not confirmed.This information was provided to the customer to resolve the issue.
|
