| Model Number |
MOBILE MONITORING GATEWAY (MMG) |
| Medical Device Problem Codes |
Device Alarm System (1012); Alarm Not Visible (1022)
|
| Health Effect - Clinical Codes |
Bradycardia (1751); Death (1802); Ventricular Tachycardia (2132)
|
| Date of Event |
06/12/2019
|
|
Type of Reportable Event
|
Death
|
|
Additional Manufacturer Narrative
|
|
Details of this event are documented in the ascom (manufacturer) ticketing system (jira) under ticket number (b)(4).The system in place at (b)(6) medical center was not returned for evaluation as it is part of the wired it infrastructure within the facility.However using mechanisms built into the design for logging events in for grading remote access via virtual private networking (vpn) ascom's technical assistance center (tac) staff can access and update the configuration of the system remotely as well as download logs.Investigation evaluation of the system at (b)(6) medical center was conducted through vpn access and review of the system logs.The ascom unite mmg system is designed to be configurable with respect to the various levels of clinical alert and alarms it receives, the timing of redirection levels, the number of redirection levels and the handsets assigned within each level.This site already had in place non medical device version of unite middleware and was using various ascom wireless handsets for messaging and communication.A recent upgrade to the site added ascom unite mmg to facilitate the presentation of alarms from ge healthcare patient monitors as alerts to these same handsets.Ascom's clinical applications specialists worked jointly with (b)(4) and the site to define filtering and mapping of the various alerts to handsets carried by various levels of clinical staff.The system facilitates multiple levels of redirection and redirection time delays depending on the nature, type and clinical priority of the alert.This information is documented in a clinical design worksheet, developed by ascom, (b)(4) in the end-user site.The end-user site retains final approval of the configuration.The mmg system is configured to escalate all unhandled calls to a "catchnet".By default the catchnet is defined as "all staff on shift".So any alerts sent to wireless handsets not accepted by assigned staff, are by default redirected to "all staff on shift".In this instance our distribution and sales partner requested a "dummy user" to be created in the system with no assigned handset.This was done to facilitate testing of the ascom unite view system.The ascom unite view system is a console display used at a central monitoring location that mirrors the alerts sent to the wireless handsets.When alerts are sent to handsets, and they are not accepted by the assigned staff, the ascom unite view display visually changes the appearance of the alert to indicate the alert has not been accepted by any of the handsets.Depending on the number of redirection levels and the redirection time delay configured in the system for each redirection level, the ascom unite view display can take several minutes to update to indicate the alert has gone unhandled by staff.By creating a dummy user with no assigned phone, the ascom unite view console display will reflect the visual change of an unhandled alert faster, and reduce test time on site.In this instance, when the testing of the ascom unite view console was completed, the catchnet was not returned to the default settings as defined in the clinical design worksheet.This left calls from the ge carescape gateway for unit 4e defined as crisis level alerts (vfib, vtach, and asystole) not delivered to assigned handsets.The investigation conducted by the ascom tac team determined that in addition to unit 4e, four other units were configured similarly.Ascom tac contacted the site on 13 june 2019 and spoke with (b)(6).At that time ascom advised him that four the units were similarly misconfigured and requested permission to correct both unit 4e and the other identified units.With his permission, ascom tac connected via vpn into the site and corrected unit 4e, 2c, 2e, 6e and cc.Units 6e and 4e were successfully tested on 13 june 2019.The remaining units had not yet gone live at the time the configuration corrections were made.Based on the timeline reconstructed from the system logs: two instances of hr lo (heart rate low) were triggered by the ge healthcare patient monitor, and were displayed on the ascom unite view console before they were dispatched to the wireless handsets.The second hr lo alert was accepted by the person assigned to the handset at the time.Two instances of brady (bradycardia) were also triggered by the ge healthcare patient monitor, but were not displayed on the ascom unite view console, nor were they dispatched to wireless handsets at the request of southeast alabama medical center as defined in the clinical design worksheet.Two instances of vtach (ventricular tachycardia) triggered by the ge healthcare patient monitor, and were displayed on the ascom unite view console but were not dispatched to the wireless handsets due to an oversight to return the catchnet back to the default of all staff on shift following the completion of testing.Despite the noted issues, two instances of hr lo were displayed on the ascom unite view console before they were dispatched to the wireless handsets.The second hr lo alert was dispatched and accepted by the person assigned to the handset at the time.Two instances of vtach were also displayed on the ascom unite view console.These events reflect three opportunities for medical intervention in the first 1 minute and 40 seconds (8:20:36 to 8:22:16) commencing with the initial hr lo, and two more opportunities for medical intervention in the next 2 minutes and 24 seconds (8:22:16 to 8:24:40).The ascom unite mmg system performed as it was designed.The core issues were: in allowing the use of dummy (placeholder) phone (handset) numbers within ascom products in order to facilitate test catchnet functionality.An oversight to return the catchnet that to its default setting following completion of testing.
|
| |
|
Event or Problem Description
|
|
On 12 june 2019 at 2:42 pm an email communication was received from (b)(6), a project implementation representative from our sales and distribution partner, (b)(4) this email was sent to members of the ascom clinical applications specialist team, and implementation team.Her email indicated that the "ascom phone alarm relay" was not working on units 6 and 7, and that the customer had experienced a sentinel event that morning, with the nurses reporting that the alarms were not relayed to the phone.(b)(6) indicated that they had attempted to analyze events using the activity viewer on the ascom system but the data was not clear to them and asked if ascom could provide a report for the alarms received and sent to phones for room 454 from 8:00 am through 8:30 am central standard time.She requested ".A report for all the alarms received and then sent to phones for room 454 from 8:00am through 8:30am cst." and to include "the phone number it was sent to, and the course of escalation including each destination phone." on (b)(6) 2019 at 2:50 pm an email communication was received from (b)(6), a member of the (b)(4) complaint handling unit (chu).This email was sent to the same members of the ascom clinical applications specialist team and implementation team, but also included members of the ascom technical assistance center (tac) that constitute the ascom complaint handling unit (chu).This email was in regard to the same sentinel event that occurred at (b)(6) medical center in the morning of (b)(6) 2019.She also advised that she had spoken to (b)(6), an ascom strategic sales representative to bring him into the loop to facilitate response and reporting.On (b)(6) 2019, (ticket updated at 17:14) (b)(6) from the ascom tac team logged in remotely to review the status of the mmg (mobile monitoring gateway*) application installed at the site.Our tac team was able to determine that several crisis alerts for bed 454-1 were not sent to any of the staff assigned to this unit, 4east.Ascom tac discovered that this was due to misconfiguration of the catchnet function in the mmg, in which any crisis alerts were sent to a dummy number instead of the staff members that are on shift.The specific alert, vtach, was triggered at 8:24am and did show on the ascom unite view monitors for 30 seconds before it auto-dispatched to the handsets, in this case, dummy numbers.The way crisis alerts were configured (using ascom unite assign) in the system overall, was that they would all go to "all staff on shift".However, for this unit (along with 4 other units), "all staff on shift" was replaced with a dummy number of "unhandled", which does not exist as a handset.So after the alarm displayed on the ascom unite view for 30 seconds, as directed by the clinical design worksheet, the alarm is auto-dispatched to the dummy number "unhandled".The mobile monitoring gateway (mmg) application integrates ascom unite with the ge healthcare carescape for message distribution to wireless devices and corridor displays.The mmg delivers patient monitor alarms, parses and filters alert messages, provides route management, and enables message interactivity with mobile devices.A client application provides the clinical staff a fast, intuitive means to dynamically assign the clinical staff to specific patients and notification levels.The integrated system provides near-real-time message alarms, alerts and notifications from ge healthcare patient monitoring systems to wireless, portable handsets.
|
| |
|
Search Alerts/Recalls
|
|
