Difficulty getting access to alarm data is the elephant in the living room in the house of alarm fatigue. There are lots of conference presentations, webinars and papers about analyzing medical device alarm data. What's missing are detailed discussions on how to get to the actual alarm data in the first place. This post will present a framework for the hardest part of alarm analysis: getting access to alarm data so it can be analyzed. We're going to define the kind of data we're seeking, where it can be found, the various ways to get access to said data and finally, analytical tools.
The vast majority of medical device systems currently in use in hospitals were never intended to provide the means to analyze alarm data. New medical device systems currently under development will likely provide a client app with a nice user interface to do alarm analysis. Some devices currently being sold have add-on products that will provide alarm analysis tools(like the new Spacelabs product pictured above), and some manufacturers have started providing services (to do some variation of what's described below for customers) to provide access to alarm data.
The Role of Alarm Analysis
If you take the Joint Commission's National Patient Safety Goal (NPSG) on Alarm Management (pdf) and break it down into a basic project plan like this one (pdf), it becomes clear that the actions mandated by the NPSG are focused on consensus building, risk management, prioritization and writing policy and procedures. There are no requirements to perform an actual analysis of your alarm data to identify and reduce non-actionable or nuisance alarms. I guess it's a good thing that the Joint Commission doesn't require hospitals to do something for which there are no easy solutions available from manufacturers. And yet, how can you reduce alarm fatigue without analyzing your alarm data?
The old adage that one must measure something before it can be managed certainly holds true with managing alarms. The most efficient and effective way to reduce non-actionable and nuisance alarms, and thus reduce alarm fatigue, is to analyze the alarms generated in detail. Only by accurately quantifying alarms generated, making changes, and then measuring again can one reliably chip away at alarm volume and fatigue.
Defining the Data
Alarms can be divided between alarm events and triggers. Alarm events are just that, they have a beginning and an end. For each alarm event we need to capture the time the alarm began and the time the alarm ended. The elapsed time can be calculated later as this is an important metric. The parameter and value that triggered the alarm must also be captured. Actions taken during an alarm (silencing the alarm, interacting with the medical device) should be captured if possible as they can indicate when a caregiver arrives at the bedside in response to an alarm.
Triggers are occurrences where some change is indicated by the trigger. For example when a bag of fluids being administered becomes empty a trigger is typically generated. A leads-off condition from a patient monitor is a trigger. Likewise a low battery warning from a battery powered medical device is a trigger. Here we want to capture the type of trigger that occurs and when.
Both alarm events and triggers should identify the type of medical device, parameter and alarm category associated with the alarm.
Along with the the basic alarm data above, certain meta data is required. The patient Identity associated with an alarm is key, as alarm volumes can vary considerably from patient to patient. The care delivery area along with room and bed must be captured. More challenging meta data elements to capture are the primary and secondary caregivers assigned to the patient - typically this will not be known to the medical device but may be recorded in other systems like the EMR or nurse call system.
Where to Find the Data
It's important to understand where your alarm data is located and how it will be accessed to do alarm analysis. Of the three types of alarm analysis solutions discussed below, the DIY approach requires that you find and gain access to that data yourself. Solutions from third parties and medical device manufacturers include getting access to the alarm data as part of the overall solution.
There are two options as to how to access the data. The first option is to access data stored by the medical device manufacturer. Alternatively, you can capture and store your own data for alarm analysis. Let's look at these in more detail.
Manufacturers tend to store the data generated by their medical device in a couple places. Virtually every digital embedded system device creates logfiles. Logfiles are created by engineers when they design their product so they can monitor the internal operation of their device, diagnose and trouble shoot problems. Logfiles are like the black box flight recorders found on airplanes.
Due to their technical nature and intended use by engineers, logfiles are hard to find and hard to understand. You won't find instructions on finding and using log files in the medical device's user manual. That said, it is possible to determine the location of logfiles - often times with a little help from peers or a particularly helpful service engineer. Once found, there are off-the-shelf (OTS) software tools for reading and analyzing logfiles.
The other common way manufacturers store alarm data is in a proprietary or OTS database. Many medical device systems store this data so client applications can query, analyze and retrospectively review medical device data. For patient monitors, this is typically the event review application that allows clinicians to review retrospective high fidelity waveform data, along with events like alarms. While instructions on how to use the event review software can be found in a user manual, the type and location of database files cannot. Again, the customer is left to their own efforts and relying on the kindness of peers and service engineers to find these files.
When a proprietary database is used the data must be converted into something that can be read by generally available software. This means converting the data to a SQL database format or CSV. With proprietary databases, the customer is dependent on the manufacturer for access to that data. When the manufacturer is unable or unwilling to help, logfiles are a viable alternative.
The use of standards based OTS databases, such as SQL, are much easier to work with. Readily available folks in your IT department and elsewhere can work with SQL and other common standards based databases. These databases can be copied and have scripts run against them to extract alarm data for analysis.
The other approach to gaining access to alarm data is to capture it yourself and store it in your own database. Virtually every electromechanical medical device in use today includes a serial port. Like logfiles, the serial port was originally intended to be a service and support tool to debug problems or update software internal to the device. Part of this use case is the streaming of data captured or produced by the medical device out the serial port. Medical device data systems (MDDS) have used serial ports to acquire medical device data for years. The data coming out of the serial port is formatted in a proprietary protocol that can vary by product model and version.
You may be able to get the serial data protocol from the manufacturer. In the case of ventilator manufacturers, many post a specification of their protocol on their web site for download. Other manufacturers are more selective as to who they share their data protocol specifications with, often requiring license and non-disclosure agreements. Alternatively, it is possible to reverse engineer the protocol. Again, OTS tools are available for doing some or all of this and getting the data into a form that can be analyzed.
For medical devices with a network port, the alarm data can be captured as it is streamed on the network. The advantage here is that all the medical devices connected to the network can be accessed from the network. The disadvantage is that the alarm data must be separated by device before it can be used for analysis.
How to Get Access to the Data
Now that you know the basic options and mechanics of accessing alarm data, the next question is which of the three methods you plan to use to actually get your hands on the data to be analyzed. These methods are: DIY (do it yourself) using OTS tools, use third party alarm analysis tools or solutions, or go with medical device manufacturer solutions. We will consider each method in turn.
The DIY method is the most resource intensive and least capital intensive. Options include coding your own MDDS for biomedical device integration and writing the data to a relational database. Alternatively, you can use a tool like Mirth to parse the serial port or network data stream and store the parsed data to a database. Once located, logfiles can accessed by OTS software intended to capture and analyze logfile data.
The next option is to use a third party alarm analysis or management solution. These solutions can be packaged as a standalone tool or as part of a broader alarm notification system. Purchasing an alarm notification system is a major decision, and many of these vendors offer a separate alarm analysis solution (with the intent to sell you an alarm notification system in the near future).
An advantage of the DIY and third party alarm management solution options is that they are medical device agnostic. The alarm analysis capability is common across any medical devices from which you can get data. Thus you have one tool for your alarm analytics.
The final option is to buy alarm analysis tools from medical device manufacturers. This means a separate tool for each manufacturer (and potentially, each device). This means separate tools for patient monitoring, infusion pumps and each of the different manufacturers of ventilators. Don't expect each and every manufacturer to have these tools available, now or ever.
If you go with the last option from medical device manufacturers, determine if there are any data export capabilities. If so, you could export your data from these systems to one analytical solution to provide cross-medical device analysis of alarms.
Tools for Analyzing the Data
Take a deep breath. Now your alarm data is accessible to be analyzed. The only thing remaining is selecting the actual analytical tool. For the last two options above, solutions sourced from alarm notification and medical device manufacturers, the analytical tools will be built in (unless you're exporting data). For the DIY approach, there are OTS tools ranging from Excel to client software and software as a service (SaaS) that supports both analytics and real time dashboards across the enterprise.
Summary
A basic framework for gaining access to alarm data and providing the tools to analyze that data has been described in this post. Just to keep things clear, the following outline describes the basic approach.
- Gain access to alarm data
- Stored data
- Logfiles
- Database
- Streaming data
- Serial port
- Network
- Stored data
- Selecting a solution
- DIY using OTS software
- Third party alarm solutions
- Medical device manufacturer solutions
- Analytics tools
- Required for the DIY approach
- Provided with third party or medical device manufacturer solutions
We have both covered a lot of ground and started to barely scratch the surface when it comes to alarm analysis. In a perfect world, there is a simple straight forward DIY way to analyze alarms. I believe the potential is there for every hospital to analyze their alarms, we just haven't discovered it yet. Let's keep digging.
Any experience or recommendations from hospitals, vendors or trade associations are welcome.
Recent Comments