• Decrease font size
  • Return font size to normal
  • Increase font size
U.S. Department of Health and Human Services

MAUDE Adverse Event Report: ASCOM (SWEDEN) AB ASCOM; MOBILE MONITORING GATEWAY (MMG)

  • Print
  • Share
  • E-mail
-
Super Search Devices@FDA
510(k) | DeNovo | Registration & Listing | Adverse Events | Recalls | PMA | HDE | Classification | Standards
CFR Title 21 | Radiation-Emitting Products | X-Ray Assembler | Medsun Reports | CLIA | TPLC
 

ASCOM (SWEDEN) AB ASCOM; MOBILE MONITORING GATEWAY (MMG) Back to Search Results
Model Number MOBILE MONITORING GATEWAY (MMG)
Medical Device Problem Code Device Alarm System (1012)
Health Effect - Clinical Code Death (1802)
Date of Event 07/08/2019
Type of Reportable Event Death
Additional Manufacturer Narrative
Details of this event are documented in the ascom (manufacturer) ticketing system ((b)(4)) 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 and for granting 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.Ascom staff members were also on-site fw29 2019 to investigate the perceived issues on the part of the end users.Ascom's investigation determined that the system performed as designed.The adverse event occurred (b)(6) 2019.The adverse event was reported to ascom 11 july 2019.In the intervening three days (b)(6) medical center generated reports from their various systems including ascom's.In the reports generated by the ascom reporting system the facility noted only the names of the staff to which the alarms the alerts were sent.The reports also included the phone numbers for the handsets to which the alarms and alerts were sent.The phone numbers of the handsets reflected in the reports were accurate, reflected the sites clinical design worksheet, and indicated the handsets to which the alarms and alerts were actually sent.Issues with the interface from the rauland responder nurse call system (which the site was using for staff assignments) resulted in the text field for the name associated with handset number phone number in the reports as being incorrect.But the names were only incorrect in the reports.The alerts were sent to the correct numbers and to the correct clinical care levels.The assumptions on the part of the site that calls were miss routed to the wrong shift and to the wrong care level are incorrect and were based on the names in the report only, not the handset numbers to which the alerts and alarms were actually sent.The site has subsequently also elected to adopt the ascom tool entitled "unite assign" for managing the assignment of staff names (with clinical care levels and with handset phones numbers), thus eliminating the issues with the interface to the rauland responder nurse call system.
 
Event or Problem Description
On 11 july, 2019 at 11:01 am, ascom vp of professional services, (b)(6), received an email from (b)(4).(b)(4) is our distribution partner for ascom product called mmg.Ms.(b)(4) received an email at 10:19 am this same morning from (b)(6), director of patient care services at (b)(6) medical center ((b)(6)).In that email ms.(b)(6) stated the following: "we had another sentinel event that we are investigating.The ascom system was sending the alarms to the day shift staff instead of the night shift staff.The assignments for night shift were in responder appropriately and at 1900.(b)(6) reached out to someone two days ago and we still have not heard anything back.Once again this is unacceptable.We had a patient pass away due to the system alarming to the wrong assignments.At this point they are most likely going to make us stop using the ascom portion of this system.I need a response at our 1100 meeting.Also, the patient account (b)(6), (b)(6) 2019 from 1830-2045 i need everything from (b)(4) and ascom side from this patient.I have a meeting tomorrow morning with the ceo about this situation and i need this information asap." on 11 july, 2019 ascom's technical assistance center (tac) logged into the system remotely and downloaded from the site: rauland sync logs for (b)(6) 2019; analyze report showing all event data for room 778 between the times of 6:30pm and 8:45pm on (b)(6) 2019, room (b)(6); rauland staff assignment report "staff coverage report (b)(6)" and "staff coverage report (b)(6) part 2".After discussion with the site and representatives from (b)(4) via (b)(6) at 12:00 noon, 11 july, 2019, we were able to ascertain that the issue implied with day shift staff and night shift staff was incorrect.The calls were actually going to the correct handset phones / numbers.However the retrospective reports generated from the system were associating the wrong staff names (and clinical care levels) with those handset / phone numbers.Noted in the call with the site and (b)(4) on july 11, 2019 ms.(b)(6) (director of patient care services) specifically stated that this particular issue (sentinel event) was not with the (b)(4) system or ascom system.She also stated "there were things her monitor techs should have done but did not" (monitor techs are the (b)(6) staff in the central monitoring unit at the site).However she and her staff were going to have to go before the board at her hospital 12 july 2019 to explain what happened.The sites perception is that the ascom system was not working correctly, regardless of whether it could be attributed directly or indirectly to the death on july 8, 2019.Concomitant devices will include the (b)(4) carescape gateway in the rauland responder.This site reported another adverse event (mfr report # 3008952681-2019-00001) from 12 june 2019, following that event ascom and (b)(4) staff were onsite 01 july 2019 - 03 july 2019 to test and confirm the system configuration.The system was fully checked out and confirmed to function according to the clinical design worksheet (cdw).The cdw is the document that defines the system configuration desired by the site and coordinated with (b)(4) and ascom.The cdw defines what alerts and alarms are sent to what staff, and delays (if any) between redirection to next level staff.The cdw was revised at the request of (b)(6) while our staff was onsite and delays added for tachy and brady events.The configuration was reviewed, and fully tested, and observed by all parties and deemed to function as requested and defined.
 
Search Alerts/Recalls

  New Search  |  Submit an Adverse Event Report

Brand Name
ASCOM
Common Device Name
MOBILE MONITORING GATEWAY (MMG)
Manufacturer (Section D)
ASCOM (SWEDEN) AB
grimbodalen 2
goteborg, SE-41 749
SW  SE-41749
MDR Report Key8878938
Report Number3008952681-2019-00002
Device Sequence Number16216083
Product Code MSX
UDI-Device Identifier17350088670009
UDI-Public(01)17350088670009(10)V4.4.0(11)180322
Combination Product (Y/N)N
Initial Reporter CountryUS
PMA/510(K) Number
K111215
Number of Events Summarized1
Summary Report (Y/N)N
Reporter Type Manufacturer
Report Source other
Initial Reporter Occupation Non-Healthcare Professional
Type of Report Initial
Report Date (Section B) 08/01/2019
1 Device was Involved in the Event
1 Patient was Involved in the Event
Is this an Adverse Event Report? Yes
Is this a Product Problem Report? No
Operator of Device Health Professional
Device Model NumberMOBILE MONITORING GATEWAY (MMG)
Device Catalogue NumberSW000400
Device Lot NumberVERSION 4.4.0
Was Device Available for Evaluation? No
Type of Report(Section G)Thirty-Day
Initial Date Received by Manufacturer 07/11/2019
Initial Report FDA Received Date08/09/2019
Is This a Single-Use Device that was
Reprocessed and Reused on a Patient? (Y/N)
No
Patient Sequence Number1
Outcome Attributed to Adverse Event Death;
-
-