MAUDE data represents reports of adverse events involving medical devices. This maude entry was filed from a 06 report with the FDA on 2009-11-18 for INVIVO CORPORATION/MEDICAL DATA ELECTRONICS 20500-16 manufactured by Invivo Corporation.
[21678686]
The user facility contacted the device manufacturer to inquire about the alarm settings at the time of a patient's death.
Patient Sequence No: 1, Text Type: D, B5
[21825497]
Method/results: the device manufacturer dialed into the user's system and downloaded log files. The data obtained outlined all the alerts called by the device during the user's period of interest. A copy of the data downloaded from the user's device was sent to the user. Review of the alert data showed that the device was providing alerts appropriately in response to arrhythmia events occurring, such as vtach, run, slow run and arrhythmia heart rate low and high alerts. It was also noted by looking at the alert log file that there was many times where the user was alerted to many ecg noise, ecg-all lead fail and bad ecg signal conditions. These conditions began to appear on the log at a regular basis at 6:25 and cease to appear on a regular basis at approximately 6:35. Correlation between these "noise" alerts and the actual arrhythmia heart rate data can be seen. At 6:26:54, the patient's heart rate was 162. Immediately after this time, the patient's heart rate appeared to change to 91, then 93, 90, 57. The patient's heart rate appears to average in the 50's, then jumps to 279 at 6:36. At 6:36, the system calls a vtach alert. Although it cannot be confirmed, it is believed that the heart rates that averaged in the 50's were not the patient's actual heart rate, but were ecg noise. According to the device's labeling (instructions for use), the definition of these conditions is: ecg noise: "noise has been detected on the ecg signal", ecg-all lead fail: "all leads failed", bad ecg signal: "the ecg signal being received is bad". These alerts are indicative of either a bad ecg signal being received or noise being detected. The instructions for use provide guidance and recommendations for obtaining optimal arrhythmia performance: "the best way to achieve the optimal performance from the arrhythmia algorithm is to provide the system with as clean an ecg signal as possible. The following guidelines can be used to optimize performance and minimize false calls. Utilize dual vector processing whenever possible. Dual vector processing provides the algorithm with more information with which to make decisions and validate data. Adjust the waveform size to a mid-range level that allows for good r-wave distinction and does not over emphasize the t-wave. If a particular lead is not generating an appropriate signal, switch to a different primary vector (lead i or iii) or re-position the electrodes to examine a more distinctive cardiac signal. Subtle changes in morphology can often lead to the incorrect classification of beats. A relearn should be done whenever a morphology change is observed, particularly after a drug infusion or conversion. Utilize the beat labeling feature in full disclosure to determine if the algorithm is consistently misclassifying beats. If so, initiating a relearn will cause the algorithm to throw out its previous knowledge of the patient's ecg and begin to obtain a new normal. If patient has a pacemaker, turn on pacer detection in ecg. " the user wanted to know the alarm settings at the time of the patient's death, but this exact information could not be provided to them without the user actually removing the device from service and sending the device in for evaluation. The user indicated that they chose to keep the device in service. The user indicated that at no time did they believe that the device malfunctioned and that their purpose for asking for the vital signs data was not to determine whether or not the device malfunctioned but for "other" purposes. When asked further for the reason for the data request, the user declined to provide any more information. The device manufacturer considers that there was no malfunction or labeling problem. The available information does not support that the failure of the users to resolve the inop conditions had any impact on the patient outcome.
Patient Sequence No: 1, Text Type: N, H10
| Report Number | 1051786-2009-00012 |
| MDR Report Key | 1534684 |
| Report Source | 06 |
| Date Received | 2009-11-18 |
| Date of Report | 2008-02-29 |
| Date of Event | 2008-02-29 |
| Device Manufacturer Date | 1995-03-01 |
| Date Added to Maude | 2009-11-23 |
| Event Key | 0 |
| Report Source Code | Manufacturer report |
| Manufacturer Link | Y |
| Number of Patients in Event | 0 |
| Adverse Event Flag | 3 |
| Product Problem Flag | 3 |
| Reprocessed and Reused Flag | 3 |
| Health Professional | 0 |
| Initial Report to FDA | 3 |
| Report to FDA | 0 |
| Event Location | 0 |
| Manufacturer Contact | JENNIFER MAGLIO |
| Manufacturer Street | 12501 RESEARCH PKWY. |
| Manufacturer City | ORLANDO FL 32826 |
| Manufacturer Country | US |
| Manufacturer Postal | 32826 |
| Manufacturer Phone | 4074556230 |
| Single Use | 3 |
| Previous Use Code | 3 |
| Event Type | 3 |
| Type of Report | 3 |
| Brand Name | INVIVO CORPORATION/MEDICAL DATA ELECTRONICS |
| Generic Name | ESCORT VISION CENTRAL STATION |
| Product Code | MLD |
| Date Received | 2009-11-18 |
| Model Number | 20500-16 |
| Operator | HEALTH PROFESSIONAL |
| Device Availability | Y |
| Device Age | DA |
| Device Eval'ed by Mfgr | R |
| Device Sequence No | 1 |
| Device Event Key | 0 |
| Manufacturer | INVIVO CORPORATION |
| Manufacturer Address | ORLANDO FL US |
| Patient Number | Treatment | Outcome | Date |
|---|---|---|---|
| 1 | 0 | 1. Death | 2009-11-18 |