EBME Forums Forums Management Medical Equipment Management Alarm Notification

What is the status of alarm notification systems in the UK?

Over here, an increasing number of "secondary" alarm notification vendors (Emergin, GlobeStar Systems, Nuvon and others) - and resulting sales - have resulted in a new proposed FDA rule targeting Medical Device Data Systems (MDDS).

The term "secondary" alarm notification was made up by vendors in an effort to avoid regulation by the FDA. You can buy these products, but in the fine print it says you must continue to rely on your medical device vendor's alarm notification. So if you have a ward with lots of alarms, nuisance alarms and alarm fatigue, you shouldn't turn down/off those device alarms and rely on your fancy new "secondary" alarm system. If you can't hear alarms everywhere you're supposed do, you shouldn't use your "secondary" alarm system for that either. But people do.

What's the situation here? Is alarm fatigue an issue? Do you have unregulated "secondary" systems?

That's another interesting question, Tim. Personally, I'd not heard of "secondary alarms" before (but, as mentioned previously, our government hospitals are perhaps not quite so wealthy as some of the hospitals in the US).

Yes, we have "alarm fatigue", just like everywhere else, I should imagine. There have been half-hearted attempts to standardize over the years, without tangible result as far as I'm aware. But, don't forget that our MHRA is a mere minnow compared with your FDA.

But how do these devices work, I wonder (what technology do they use)? How do they pick up the "primary alarm"? Can the alarm signals (audible, visual) be programmed (eg, with a view to standardization)? Can they relay alarms to mobile devices like phones, PDA's and all the rest?

Do you have any links for us,Tim?

How about Emergin GlobeStar Nuvon ?

These systems are typically made up of various software engines like a rules engine, messaging engine (like rules engine that determines what message goes to who, when and how), interface engine (like this one), which all talk to one or more databases. The current state of the art for these systems is to use a software architecture called an enterprise service bus (ESB) to tie connect all these engines with input (the medical devices and other systems like nurse call) and output (the actual messages, alarms and client applications). Another buzzword is SOA, service oriented architecture - same thing. Based on web services like SOAP, this software provides the plumbing for moving data around between applications.

One set of apps are the "plug-ins" or "gateways" that parse medical device RS-232 data and convert it to a common schema, typically XML. Currently there are two categories of products, those that deal with continuous data (LiveData, Global Care Quest) and those that are event driven - spot data, alarms, messages, etc. - like Emergin, iSirona, Ascom, GlobeStar and Nuvon. There are other similar vendors, but they don't provide alarm notification. (An earlier type of company focuses on the device drivers for medical device serial interfaces - CapsuleTech and Cain Medical come to mind.)

Once the device data is on the ESB, there's typically a rules engine that evaluates the data to generate alerts and messages. Messages are then passed to the messaging engine that looks up who should receive this message, the preferred methods (email, cell phone, PDA, etc.), and then pushes out the message. One of the subsystems also closes the loop on the message to ensure that it was received by the target device, and that the user acknowledged the message. The messaging system will escalate a message (based on site specific rules) if the message is not received, acknowledged, or the condition triggering the message is not resolved or repeats.

This all sounds very fancy, and if you had to write all this stuff from scratch, it would be. In actuality, vendors integrate the various major components, package it, and make sure it all works - not a trivial task in itself.

Several years ago Data Critical (now GE) sold StatView (Philips also sold StatView). StatView acquired patient monitoring alarms and sample waveforms that were sent to the caregiver assigned to that patient via pagers. Even though they got FDA approval, the system was proven to be inherently unsafe and pulled from the market. (StatView as unsafe because it used paging technology that was not closed loop - the system did not know if the page was actually transmitted, received or acknowledged by the user.)

Unlike StatView, these systems can provide closed loop monitoring of messages, and can respond when messages don't "get through." They also deliver alarms to the patient's caregiver, rather than the noise pollution you hear on some wards with audible alarms.

These systems also provide an important normalization across vendors and devices, providing a patient centric alarm system - rather than a vendor centric alarm system.

These systems support wireless phones (VoIP, DECT), cell phones, any wired or wireless network-attached device: computers on wheels, PDAs, tablets, etc.

Interesting stuff, Tim. And thanks for that. Gives me something to mull over! But who gets to write the rules engine, I wonder? What is it, some kind of look-up table, with a load of IF ... ELSE and all the rest, I suppose.

It's amazing that the StatView system was not closed loop! I wonder what made them think they could get away with something like that?

Geoff, you've hit on the new paradigm of the software business. Rather than writing hard coded applications, vendors are integrating highly configurable software engines (with engineers) and writing rules to create the actual application (with subject matter experts/users). In this case, the vendor's clinical specialists write the default rules (mostly for product demos and testing), and then customers and/or the vendor's clinical specialists revise or add to the default rules at installation.

Re: StatView and pagers, back in the day open loop pagers were the norm. I don't know if there was even a reasonable closed loop alternative available. The whole open loop thing is a surprising miss, for both Data Critical and the FDA. I think this is an example why risk analysis has gotten greater focus in the industry over the past several years.

One of the problems with the current crop of "secondary" alarm notification systems is that they are typically implemented today with pagers - because they're cheap and most hospitals are loathe to spend the bucks for a more expensive closed loop device.

Another short fall is the current systems don't provide a sample of the waveform that triggered the event. Hence the nurse is still left to run to the bedside (or central station) to validate the alarm as a true/positive. Besides the noise, this is a key contributer to alarm fatigue, burdening the nurse with manually verifying frequent false/positive alarms.

This feature (and well known market requirement) is left out of "secondary" alarm products in an effort to avoid being regulated. And I've heard hospitals justify the absence of this feature by saying, "we want the nurse to be at the bedside," which is problematic when you've got 8+ patients - any one of which could have a real alarm in between those dozens of false/positives.

Is anyone on the board keeping up with IEC 80001? This is a new "voluntary" standard on networking medical devices. There's not much on the internet about it, but this ppt is a good overview.

So, Tim (just so I get this straight in my mind), when we are talking about "closed loop", we are thinking of an ability to remotely cancel the primary alarm (supposedly after taking a look at a waveform on our PDA, laptop screen, or whatever)? Simply acknowledging the alarm is not enough (ie, perhaps authorising a colleague close to the patient to physically cancel the alarm and/or make any interventions necessary)? Do we need a two-level system here (ie, one with "closed-loop" and "advisory" options)?

It seems to me that the existing protocols depend upon hard-wire interfacing with the primary equipment (eg, via the monitoring bus). What I was hoping for was a universal approach, with (perhaps) an interface box that can be attached to any piece of equipment that can an issue alarm (that's why I was interested in how the devices pick up the "primary alarm").

Yes, I'm back to my Little Interface Box! But surely it's an interesting question:- how to devise an interface ("box") that can pick up any alarm signal (the hard bit), and then relay it on (the easy bit) to our remote receivers. The quick answer would be, I suppose, a microphone to detect the audible alarm! Something else, then, to ponder!

All of this is pretty ill defined, but I think of closed loop as tracking the status of a message/alarm and ensuring that it receives a valid response from a live person - escalating as needed.

Suspending alarms anywhere other than the medical device itself seems to cross the line to device interoperability. Ditto for changing alarm limits, both of which would ideally be mobile and nurse-carried.

To be truly actionable, alarms must be accompanied by contextual data so the caregiver can screen false/positive alarms. Alarm fatigue is a result of several factors, but a predominate contributor is false/positive alarms. This is why the alarm "switches" in nurse call systems are next to worthless.

Hiya,

Looks to me like the role of secondary alarms is currently limited to passing on patient monitoring alarms and info to someone whos remote from the patient. Current monitoring systems cant possibly give all of the info that the operator needs to send to a Dr or other specialist whos offsite for a second opinion and its little use in an emergency anyhow.

Use of secondary alarm system seems irrelevant to me if the person whos remote cannot interact with the alarm source or intervene with the patient (such as in an emergency). The reason why the interoperability of secondary alarms and patient monitoring is being restricted is probably in the interests of patient safety in fact.

With the current level of implementation thats allowed then all relaying alarm information and receiving feedback achieves is the same as a bleep and probably not as useful as a telephone call. Research into existing patient monitoring systems how alarms work together and how their used is probably the way to go to reduce false positives, etc.

Thinking about the way alarms tend to be used in critical care areas I've worked in the UK then having a secondary alarm system that can override the patient monitor and produce its own alarms, that can be controlled remotely to the operator whos onsite, is just asking for trouble! Such a system is a step too far currently IMO unless its a central station in the clinical area.

IMO what we need are nurses at the bedside, where they should be, and indeed where they used to be (in less "advanced" times)!

That's what "intensive care" originally meant. It was referring to the intensity of care (ie, a higher nurse to patient ratio than that seen on the normal wards).

Sometimes we need to remember that patients are looked after (cared for, treated) by nurses, not "monitors". In fact when you think about it, all the clues are right there:- monitor!

It seems to me that in these days when "everything is possible" (technically speaking, that is) we are always a bit too keen to keep bunging hi-tech solutions at what are, actually, "low-tech" (not to mention "hands-on") human concerns (eg, simple, traditional, nursing). We see this all the time in our daily lives outside the hospital, of course (surveillance cameras, electronic tagging, satellites peering down like the Gods of antiquity, and all the rest of the unnecessary - but intrusive - nonsense) ... but that doesn't make it "right".

Let me suggest another reaction to the plethora of patient monitoring, "alarm-fatigue", "false positives", and all the rest:- simplify, simplify, simplify! Yes, let's have quality, not quantity. Remember the truism (in this, and I would say all matters of import) Less is More!

I agree that alarm fatigue is an issue. There are often occasions when i go into the ITU or CCU and alarms are sounding for long periods of time. I sometimes wonder whether they are secondary alarms and therefore less urgent for the nursing staff to deal with, but upon inspection, many time i have seen what i would consider to primary alarms being ignored for minutes. I have spoken to nurses about this and been told to keep my nose out of their business. I personally think alarms should only go off for something that may be life threatening, and then increase in volume over a short period of time.

Alarms are covered under the EU medical devices directive MDD93/42:
2. The solutions adopted by the manufacturer for the design and construction of the devices must conform to safety principles, taking account of the generally acknowledged state of the art.

In selecting the most appropriate solutions, the manufacturer must apply the following principles in the following order:

- eliminate or reduce risks as far as possible (inherently safe design and construction),

- where appropriate take adequate protection measures including alarms if necessary, in relation to risks that cannot be eliminated,

- inform users of the residual risks due to any shortcomings of the protection measures adopted.

12.3. Devices where the safety of the patients depends on an external power supply must include an alarm system to signal any power failure.
12.4. Devices intended to monitor one or more clinical parameters of a patient must be equipped with appropriate alarm systems to alert the user of situations which could lead to death or severe deterioration of the patient's state of health

The EU Medical devices directive is not defining alarms to a clinical level, these are purely general manufacturing rules left open to interpretation.