Bed Alarms Don't Work??

I recently read a blog by KevinMD – a blogger I really enjoy following – regarding the use of bed alarms and their lack of ability to reduce fall rates.  (http://www.kevinmd.com/blog/2013/01/bed-alarms-work-reduce-patient-falls.html)

I found his blog very interesting (especially since we now interface more fully with smart bed technology).  So being the nerdy geek I am – I did some investigation.  The blog is referring to a study done that compared falls at a single ubran hospital over a period of time.  http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3549269/

The simple summation is that “bed alarms” do not have a significant impact on reducing falls in a hospital. 

When someone says “Bed Alarms” they are generally reffering to any type of technology that notifies the caregiver that a patient has exited the bed.  So the technology itself is anything from a pressure pad to smart beds.   The study referenced was conducted using pressure pad type of alarm with two weight sensitivity settings.

Most pressure pad looks similar to a strip of material that is laid under the patient on a bed, to integrate it to a call light system (ie having the centralized notification) you plug it into a quarter inch jack. (A quarter inch jack is like a phone plug from the old operator based phone system where you crank the phone the operator answers and then physically connects your call to another)  The technology is a contact closure – it is “on” of “off”. 

The study used a pressure sensitive pad that is placed in the bed or chair.  So, if you scoot to the edge of the bed but keep the pressure applied to the pad then you will not trigger an alarm until the patient falls on the ground.   Or commonly when they are sleeping and the patient arches their back to adjust their gown, the alarm goes off – thus alarming and waking the patient.  (which would link to that whole “noise at night” issue with HCAHPS)  Further, this type of technology is prone to false alarms which can be linked to alarm fatigue situations. 

However, more modern “bed alarm” technology, such as Stryker’s iBed, allows the bed alarm to be triggered based on zones and weight of the patient.  There is an actual algorithm that evaluates the patient’s weight to determine where the center of gravity is located.   The cool factor here is that instead of an “on/off” technology it uses the potentially varying weight fo the patient to engineer a more precise alarm to indicate when the patient is moving TOWARD exit.  This does two things, it notifies prior to exit and reduces the occurrences of false alarms.  Think of it like the Indiana Jones scene where he replaces the idol with a bag of sand and it triggers the cave in. 

Some of the smart bed technology work on a similar assumption where a variation in weight triggers the alarm, the reason I think that Styker’s is so effective is that the “weight” is actual.  Most beds look for a shift of 20lbs or so but do not take into account the actual weight of the patient.  If a patient is 90lbs and 20lbs moves that significant if the patient is 300lbs and 20lbs moves that may not be as significant.

In the Styker product, the clinician determines the level of sensitivity.  It can be based on acuity or a fall evaluation.  The level of sensitivity will actually measure the movement of the patient TOWARDS egress not at the point of egress.   

So, do I agree with the study – yes, it appears that the technology that was evaluated in the study had little to no impact on the patients fall rate.  Do I agree that “bed alarms” as a category are ineffective? No, I don’t think technically that is the best assumption.

I do agree fully with KevinMDs statement “Maybe we need to rethink hospital fall prevention, and focus on more human and less technical solutions.”  

A bed alarm – like any medical device or alarm notification technology should be part of a more comprehensive plan – technology alone does not solve.  Think of it this way – if you buy a treadmill and just look at it, it won’t improve your health.  If you buy a treadmill and walk on it every once in a while….it won’t improve your health.  If you buy a treadmill and run on it every day but eat cupcakes every day….it won’t improve your health.  The “treadmill” is not the answer – the “treadmill” is a tool to be used in conjunction with behaviors and habits.  

Check out our clinical blog.  (www.sphere3consulting.com) where CNO Lynn Barrett discusses some of their holistic approaches to reducing falls.  

Nurse Call Selection Process

 I thought I would share some tips to anyone looking to upgrade their nurse call system or drive any change within their current platform (upgrade is a variable term which encompasses hardware and software)  Sphere3 has walked a number of hospitals through this process and are glad to be of service to any hospital looking to update.

Hospital Tips:

1)      Define the REASON for change first – it’s generally three things – new construction, remodel, or existing system is "old". Your hospital will have some SOPs attached to each one. If you are looking for definition around "old" we have tools you can use to define and structure your business case for update.
 
2)      Define the INITIATIVES you want to improve which will be enabled by the change. Strip away everything that does not align with those initiatives, and compare the systems.

3)       Define the WORKFLOW associated with improvement of these initiatives.  Don't think about the technologies - define what would be the best process to improve your initiatives.  I know this can be very chicken and the egg for some folks.   There are groups like Sphere3, Burwood and others that can provide you with a vendor agnostic view of what current technology CAN do which allows you to define HOW you want the system to work.    
 
4)      Pick Three Systems and review for alignment with your core workflow, and meet with representatives.  Provide them all with the same workflow and initiative information and allow them to present how their system will meet your needs.  Their presentation MUST show you how their product will perform the workflows you have described.

They will all have “Whiz Bang” features and will highlight them as something that you should use to make your decision.  The truth is  if “Whiz Bang features”(which can only be supplied by “one” vendor) become decision points then it really detracts from your ability to make a workflow decision.  Please note – talk paths, voice over IP, single sign on for multiple applications, SQL databases, etc these are not Whiz Bang – these are essential functionality statements.  Understanding each systems IT structure and potential limitations is really important.  We should never make a decision in a bubble – multiple parties use the system and multiple parties maintain the system.   Make a clear delineation between Whiz Bang and Functionality.  
 
5)      Reduce to 2 systems and set up site visits of ACTUAL working client sites – their factory tours are all cool and the experience is meant to be incredible. Whether you go to the “farm” or an “experience center” you will be wowed…..that’s the point. Though I will agree with the vendors – having the opportunity to see all of the flexibilities of the systems can be valuable.   Go visit at least one real client site….proof is in the live pudding. 
 
6)      Review the database for ease of reporting AND structure.  If they claim have ability to interface with other products such as middleware, RTLS, phones,  Aperum® etc ask for them to provide a site where the data has been validated. Then ask for a sample DE-identified file for review. I need to emphasize here – there are holes in the way certain systems record data – it’s important to understand what those are and how it will impact your ability to use their data to make decisions in the future.
 
7)      Get your prices and take time to understand what is in them (or hire someone to review them for you who will understand the gotchas.) I have found on several projects now that pricing can be challenging to review (even for me and I started working with nurse call in 1986….if you do the math that’s a funny statement.) I have seen simple parts lists with a price to a 300+ page document.  If they send you a 300+ page document – read it – wow is it revealing about what they will and will not guarantee. (Check the contract if they will not “guarantee the operation of their IT system” runaway)

When you strip away everything that is “fluff” in these proposals and get down to the brass tacks of will this do what you want, will the vendor be available to service you when you need (not when they can make time to get to your area), and is the hardware AND software high quality and reliable  --- then you know you are making a good decision based on your specific needs not on their competitive advantages.

I could write pages on this process – if you are making a change this is a major capital and operational investment that affects a hospitals HCAHPS scores (which leads to reimbursement etc) it's important to really do your homework.  The industry changes are really interesting right now so don’t get caught with a system that won’t be here in a year or a company that can’t support your needs. 

If you have questions feel free to email me or call us.

kgovro@sphere3consulting.com

A Coloring Page for Root Cause Analysis

The other day #2 boy brought home a coloring sheet from church.  I asked him to tell me about his picture.  He went into a wonderful description of the story of David and Goliath.   Goliath was colored blue similar to a giant smurf and David was wearing a green skirt.  He had added grass, bushes, and even some small animals.  His hands flew through the air describing his well colored picture and telling me in detail that Golliath blue from him blueberry pancakes and why David was “late to the party”.  As he talked, I began to focus in on the upper corner of his paper to the small gray airplane.  “What is that?” I asked.  Tucker’s eyes lit up and he replied “That’s the fighter pilot backing up David in case he missed.”

It's interesting when we begin see the outline of a picture and think we have the whole story.    

As I have been reviewing RCA’s from different hospitals and researching the rebuild of the incident – I find it interesting that many hospitals do not build the picture from data that is very representative of what is occurring in the room.   Many times this is simply that they do not know that the data is available or that they have systems in place that the data is locked inside and not accessible. 

I was working with a hospital on a fall analysis - extracting data to begin to layout the outline of a picture of what happened surrounding the patient fall.   The patient requests and responses are a lot like a blank coloring sheet.  The outline is your basic patient request data and based on the patterns it began to paint a picture.  The physiological alarm data, the medication data, and other bits and pieces began to color in the outlines to give a full view of what was occurring in that patient’s room.   Did the patient have a critical telemetry alarm?  Who received it? What were they doing?

Another interesting piece of the puzzle is communications between caregivers.  I was having a conversation with Voalte’s Trey Laudedale about the value of the Text Message.   As I was thinking about this blog it occurred to me – the text messages are the hand drawn fighter jet in the picture.  Sometimes the outlines and the information we are looking for does not create the whole picture. Sometimes the picture needs to have more data then what we would normally consider to complete it.  

So here is my tip for an RCA

·         Review the Patient Requests from the Nurse Call and Response of the Caregivers
·         Review the Physiological alarm data that was sent to the Caregivers
·         Review the text messages between clinicians

Remember data is always available if you are careful to set up your technology correctly.

How to Define "Help"?

When you order BBQ in Kansas City – you don’t just order burnt ends – you can order chopped burnt end sandwiches which can be sauced or dry – you can order a platter which can be sauced or dry – you can order it as a combo. Then there are the side dish selections…cheesy corn, beans, slaw, pickles….

Question #4 “During this hospital stay, after you pressed the call button, how often did you get help as soon as you wanted it?”

The interesting thing about the next section of the question is its tie to “help”.   What defines help?  In most hospitals if you press the “call button” there is one “button” it’s big and it’s red. You can figure out it’s for “help” even when you are groggy or sick. The newest fad is to add more buttons – which is great for me would work. I am used to self selecting. I self-check at the airport, I order meals and movies on my Iphone, and think nothing of the lack of real “service” that is providing.

My mom (who is 62) would think the extra buttons were a novelty. She would laugh as she tried to find her glasses to read the small words on the extra buttons “water, pain, or toilet” then ask me if she pressed toilet does that mean she has to go or that she went. She would never press the pain button because she rarely admits when she is in pain.  She would always press the red button.  (Please no hate mail here, I am generalized a generation based on my experience with my parents)

My grandma would press no buttons….even with her glasses she probably couldn’t read those little words, and she would look at the crazy “paddle” and say why are there so many buttons. Then she would look at me and say “Bo, go get my nurse” I would either press her big red button or I would just walk out of the room to find the nurse.

The point is defining “help” is challenging in a healthcare environment especially in a patient self-directed self-selection process. Evaluating “help” is even more challenging. There are numerous options and building the paddle would be a challenge. Ironically, in an industry move to be more efficient and direct patients needs to a caregiver using a decentralized design method – we lost a great deal of the data modeling. There is no way to track the request specifics in an automated fashion in a decentralized design without additional manual steps (which frankly defeats the purpose). There is no way to get specifics but there are request patterns.

There are ways to collect this request data – get a good understanding – then design you call processes. Just to take it a step further – we can tell you how many of each type of request hit when, how many were answered in your desired time frame (or what your average time frame), and even how the caregiver interacted with the request. If there is a hospital interested in knowing how to create a real patient centric care model – call us – we are looking for partners in a study to make life better.

The current analysis structure (at least what we have found published) looks at qualitative information – how many focus groups does it take to get to water, pain, and toilet? What’s crazy is all the information you could want to design the paddle or better the process is locked inside the nurse call system….if the hospital has a reporting package because most nurse call systems are built like archaic life safety tools with proprietary databases.

What’s more – I am the patient – I want to know how quickly you responded to my need – I know the information is there and frankly I know how to get to it. Stop and think how valuable that could be though - if I am going to do a survey (qualitative) to evaluate my care would it be better if I knew on average you answered my call light within 30 seconds every time PRIOR to me filling out the survey. Sometimes it feels like longer – but when you KNOW what the time is aren’t you more patient….Do you think that would influence my decision on whether or not I had good care?

But what do I know…. I am just a mom who had a sick baby and instead of blasting a hospital for a bad experience – I dug down to figure out how to solve for a pain I felt during a hospital stay.  It really is that simple….by the way so is the data.

"The Immediacy Conundrum"

Question #4 “During this hospital stay, after you pressed the call button, how often did you get help as soon as you wanted it?” Answers: Never, Sometimes, Usually, Always, and I never pressed the call button.


“after you pressed the call button”

Patience is not in abundant supply at Gate’s BBQ. When you walk in the door they shout at you - “Hi May I help you?” you must know to yell back very quickly – there is no patience for Umm or questions – by either the counter staff or the patrons behind you. You must shout back – quickly with full confidence - “Yes, I want a burnt end sandwich, fries, and a Ice Tea.” The food arrives to the counter very quickly – you can watch the man through the cook window constantly chopping and slicing meat to serve – you know it will be good, hot, and fresh.

The Gates atmosphere creates an expectation for an immediate response to questions, there must be no hesitation. I have reviewed reams of data from nurse call systems and 4 years ago when we started – the average wait time before exit of the bed for a patient was about 1:13. Now we see a majority falling under the 30 second threshold. Are people getting more impatient? Maybe…

We live in a world where as soon as I want to be connected my expectation is to have connection. The problem with “after you pressed the call button” is many patients expectation is immediate. Geeky techy stuff – if you have a nurse call system older than 2 years and you are functioning in decentralized – there is a lag time. Depending on the specific system – it can be an “eternity” in terms of immediacy. This is not a reflection on caregivers, it may actually be a reflection on the implementation of technology. Yet, caregivers are under pressure. Just like Gates, the health system and government is creating an atmosphere around hospitals that require immediacy. By its ever- more acute care criteria for entry, there is an equal expectation for immediate response?

Let’s talk solutions to the immediacy conundrum. The Decentralized Nurse Call craze of a few years ago is beginning to subside as hospitals realize the limitations of moving the patient call to an individual who is mobile and has variable task responsibilities on the unit. Decentralizing or sending the “Normal” patient call to a wireless device does not solve for immediacy – it’s actually the most difficult methodology for nursing to utilize because there is no immediate feedback on volume of requests or the “queue”. Immediacy requires the “queue” to be low and the person answering the call to interact and disconnect quickly. Think Economics - Basic Supply and Demand Theory – if you have too many nurses and not enough calls then you are fine. However, what is generally the case at documentable specific periods of shifts, if you have too many calls and not enough staff then you are going to get low scores on question 4.

The trick is the patient has a need and since they are not in their home environment and have very little control of their surroundings – many “wants” become needs. Not to mention the variation in expectation. The patient requires an immediate interaction – not an immediate solution. This is a really important point – so don’t miss it – the patient needs an immediate interaction and a sense that their need has been identified and help is on the way. The second key to this is you must deliver on the promise. So, if you have pushed your button and someone has quickly told you “help is on the way” then help must really be on the way. The only way to manage that is to develop a methodology to alert the needed caregiver with a specific request – data rich. Then Mobilize AND Monitor their action towards delivery. What does this mean – the person interacting with the patients request should be air traffic control – they should be able to monitor the total quantity of requests and estimate a delivery time. If there is a change in delivery time – maybe the patient should even be notified…..

The Recipe Matters

I love a challenge, and recently I have taken to making cakes. I am not Duff or Carlos, but I am determined to conquer the cake. My weakness is I don’t like recipes – ok, so I don’t like being told what to do, and I feel a recipe is just Betty Crocker’s way of bossing me around. When cooking, her recipes are general suggestions, but unfortunately in baking, it’s an order.

The thing with a recipe in Betty’s book is someone experienced has documented it – it has been verified – and it has made it to the general public. A recipe is successful because the common language used in each step. We are taught in grade school the standard terms of measure – cup, teaspoon, tablespoon, etc. We are also taught time – minutes, seconds, or hours. We are taught by our moms how to “preheat”, and we are taught by the Food Network how to “fold” in an ingredient.

Documentation of anything requires standard terms and common language. In a recent revelation in speaking with others about my professional passion for clinical alarm data and the picture of patient needs hidden within it, I found that there is not a current standard terminology in the arena of clinical alarm design. Therefore, I am proposing one. Just to set the minds of my readers at ease – Patient Communications Platforms are in my blood. You could say my youth encoded a understanding of clinical alarms into my DNA. I went to my first “nurse call” training before I could drive a car, and had a doll house with RTLS. I am not a novice, however, I am not so proud to think that what I’m proposing can’t be improved upon. Actually, I’d be thrilled if this proposal sparked a debate. So,I challenge all of my readers (all 700 of you) to comment. Collaboration can only occur if we are not so prideful to think we are perfect – if we can agree that little companies have as good of ideas as big companies – if we can solidly stand by saying we must create things for the betterment of healthcare because it’s really about patients – not all about profits.

This is Sphere3’s proposal for common language for documentation of Clinical Alarms. Below is a cascade of action – reaction that can either be generated by a person or the configuration of the clinical alarm system.

Initiating Action:

This is the beginning of the call. It can be manual, such as a patient pressing a button or physiological, such as a telemetry alert. The initiating action can also be a system trigger such as an occlusion or a system creating an alert based on a malfunction or necessary service request. The easy way to remember an Initiating Action is “it’s gotta start somewhere”.

Example:

Patient Press a “Normal Call” button on their Nurse Call System

Patient’s heart beat indicates a “V-Tach”
Notification Action:

How do people know that a clinical alarm has occurred? A Notification Action is the ring, ding, buzz, text, etc. This is the way in which a caregiver knows that an initiating action has occurred – they way they know the patient is in need. There are generally multiple Notification Actions for every Initiating Action. Every Notification Action is an invitation for the Caregiver to interact with the patient or their device.
Example:

Initiating Action = Patient Presses the “Normal Call Button”

Notification Action 1 = The Dome Light is White

Notification Action 2 = The PCT’s Wireless Device buzzes

Notification Action 3 = The PCT receives a Text Message “Normal Call Room #” with the option to “dial back” to the patient room.

Acceptance OR Rejection Actions:
If the Notification Action is the caregivers invitation to interact with the patients need it forces an acceptance of that request or a rejection. Accepting the alert requires an interaction with the patient or their technology. A rejection is a “delay of response” while it could indicate that the call is being ignored, mostly it indicates that the capacity of the caregiver to interact with the workload is challenged.
Example:

Notification Action3: The PCT receives a Text Message “Normal Call Room #” with the option to “dial back” to the patient room.

Acceptance Action 1: The PCT presses “Accept” it “dials back” into the patient’s room, they communicate with the patient.

Rejection Action 1: The PCT is unable to answer the call due to being engaged with another patient.

Escalation Action:

A Patient Communication Platform (aka Nurse Call) has a feature called “always an answer” where it will bounce a call if it’s not handled within a set time frame. Anytime a call is rejected, it bounces either automatically based on timeframe or physically based on a button push. That being said anytime a call is “rejected” technology should be programmed to create an automatic escalation action. Similar to an Initiating Action the escalation action is the technologies methodology of moving the call to the next person or place in line.

Example:

Rejection Action 1: The PCT is unable to answer the call due to being engaged with another patient.

Escalation Action1: Since the call has been “ignored” the technologies internal timer has allowed for a wait time of 2 minutes after which the call is sent to the RN’s wireless device with a message “Normal Call Rm 320”.
Escalations drives additional Acceptance and Rejection Actions, based on time frame. Again, a Rejection Action will create an additional Escalation. The hospital has to decide when the patient request (physiological or physical) has gone on too long, and at what point a failure to respond will generate the final Mandatory Action.
Mandatory Action:

The hospital’s determination of the final phase of the escalation process is the mandatory action. This designation is generally linked to Overtime calls. When a mandatory action occurs, the technology should force a physical face-to-face interaction with the patient. Mandatory Action is a new Initiating Action with a required interaction from staff.

Example:
Normal Call has not been answered in 4 minutes.

Mandatory Action: Due to escalation past allotted time frame the technology changes the alert verbiage to “Overtime Room 320” and tones at the main console and duty stations in all caregiver work areas on the unit. Additionally, the PCT and RN’s wireless phone receives a text message “Overtime Room 320” with no capability to call into the patient’s room. The call can only be cancelled at the patient’s bedside.

Now, let’s get back to baking cakes. Here is what I’ve learned in my most recent experience. There is a certain amount of discipline that comes with baking. To try to get creative on the basics is the best way to really ruin a dessert. Getting the basics of a cake right makes for a great foundation. But, the real fun and creativity begins once you have solid knowledge of the basic fundamentals of a cake. You see, I’ve now learned how to take a basic recipe and make an exciting dessert for my family—its about the secret additives, the substitutes that have just a little more interest in flavor, the interesting style of presentation, and complimentary chemistries of toppings, sides and coffees.

Clinical Alarms is the same thing. You have to know the basics and assure the foundational strategies in clinical alarm design were applied. BUT, once that is accomplished, there is so much more that can be done to enrich the patient and caregiver experience with request and response.

The documentation above associated with each phase is laid out similar to a process chart used in lean, however Sphere3 has created a methodology that is easy to understand and see at a glance. I will create a blog series on each phase of the process if there is feedback on this, but if there is not then we will just leave it as one persons attempt to create some normalcy to the market.

Comment Back – Ask Question - Email me kgovro@sphere3consulting.com if you don't want to post a comment – join this conversation.

It’s not “IP” it’s about creating something we can all use. This shouldn’t be an uneven playing field - this is Sphere3 stepping up and saying it's about the patient - not about the technology.  If alerts are designed incorrectly in the extreme case someone could die – in the most likely case a patient is dissatisfied with their care.

Hospital Value-Based Purchasing Program (VBP)

I am pleased to welcome my first guest blogger.  Rebecca Mackinnon has been working with Sphere3 for several months.  She successfully built a HIT company called Beyond Now Technologies which is now part of Cerner's portfolio.  A brilliant woman who offers great insight and perspective.

Hospital Value-Based Purchasing Programs

We've been told for years that hospitals would be judged and paid upon performance, and now it looks like the time has arrived!

The Hospital Value-Based Purchasing Program is the first concrete step with defined timelines of performance measure for the purposes of calculating premium to the DRG. The interesting detail in the labyrinth of language: there will be a baseline reduction in the DRG and then VBP calculation will be applied on the new DRG base.

Unwind and interpret...you will be penalized if you can’t prove minimum quality performance.

The CMS proposal: 17 clinical processes of care and 8 measures (from HCAHPS) with a currently proposed ticking clock beginning from 7/1/2011 through 3/31/2012 to adjust the FY 2013 DRG payments. If I do the counting on my left hand correctly, five months before the clock begins ticking.

So here is what I know. Regardless of what any hospital wants to purport, some of the very expensive and very avoidable clinical measures are not being managed.

Here are the basic questions every hospital CEO should be using to challenge the CMO and CNO:

What is our Falls Ratio (falls/1000 patient days)? How are we assessing the Root Cause?  Is the information being used in and educational and reforming way to improve for the future?

What is our rounding procedure and how often is it adhered to on the Unit level?

What is the actual response time to a patient request? Response time to pain? Response time to toileting?

What is our hospital noise coefficient?

What are our alarm frequency measures and response times?

Each of these is the most basic unit level measure of performance and ties directly to the ability to improve performance in the FY 2013

A very insightful CEO of an inner city health system spoke to a small group in the recent weeks. His best advice to his audience, “you have to get into the bowels of your organization, you have to know what’s happening and be able to create a clear line of sight from staff activities to mission critical performance”

Sphere3 has been expecting this for two years. This month, we will debut of a comprehensive option for managing quality.

Sphere 3’s business intelligence software endeavor combined with our consulting team who are experienced in clinical process, Nurse Call and other alarming technology design is now more important than ever.

Changing Lanes

I was driving to work yesterday in the Tahoe (aka Mommy Mobile) since my car (aka Princess) has a flat. As I sped down the road with Cruise Control set – I couldn’t figure out why the Tahoe wasn’t slowing down as I approached a much slower moving vehicle. All of the sudden, I remembered that the Tahoe does not have the cruise control distance feature that Princess has built in to ebb and flow with traffic.  I slammed on the break as to not hit the vehicle in front of me. You see, the Princess car can practically drive itself. You set cruise control and it slows down as it approaches a vehicle and once that vehicle moves out of your lane it resumes its constant speed.

This change in vehicles has caused a number of issues for me this week. I have no hands free calling if I push a button on my steering wheel and say “Call Dad on Cell” it only changes the radio. When I go to change lanes there is no light telling me there is someone in my blind spot. When I go to back up, I actually have to look over my shoulder because the radio does not change into a back up camera picture. All fun and joking aside - This experience really relates to what we are seeing with devices and workflow design in healthcare. (Bet you didn’t see that coming.)

There are really two paradigm shifts. First, there is an expectation that a technology will provide more and require us to “do” less. This does not discount the fact that we still need human interaction. Princess really can’t drive herself, but Ford has developed ways to reduce the amount of action I need to take while driving. They looked at the driving requirements and removed steps out of the process that could be replaced with technology. They also provided technology that could enhance the driver’s ability to make decision. Isn’t that what all technology is supposed to do?

There is a warning that should be going off in your head at this point.  All of this high tech stuff is great but what do you do if the technology is different from unit to unit? What if Med-Surge is driving a Tahoe and Med-Oncology is driving a Princess? Caregivers float between units. They are asked to shift from one process to another without missing a beat. This is the second paradigm shift, technology must be flexible but the flexibility must be tempered by continuity. We ask a caregiver to go from driving a full featured princess car to driving a low featured school bus then we wonder why there are mistakes.

Workflow design should be based in finding commonalities and working to drive similarities between the units. Every car is different but every car has a turn signal, break lights, head lights, and there are requirements to use them within the standard confines of the law. Then that has to be monitored to drive the similarities to be consistencies.

Please heed my warning to all of you in Kansas City – especially those at Cerner because I pass your facility daily - If you are driving home and see a large Tahoe barreling up behind you – I recommend you just change lanes. I am not an aggressive driver but sometimes I forget what technology I have (or don’t have) at my finger tips.

Alarm Fatigue

I was cooking a BIG meal – one with several burners going, the oven on, and even the microwave.  It was one of those “Martha Stewart has nothing on me moments.” (Ok, I was really more like a I'm a tall version of Rachel Ray) There were 4 boys running in and out asking questions and trying to “help” - other kitchen noises like the garbage disposal, can opener, food processor plus of course the TV was on in the other room. It was loud - like the Chiefs Stadium when we beat the Chargers on Monday night – LOUD! The point is I had a lot going on and neglected to set the egg timer for one of my pans and ignored the beeping on the oven……all of this to say we ended up eating at Culvers that night.

My kitchen scenario is much LESS intense than a nursing floor. No one was critically ill, there were no emotionally distraught family members, there was no Code Blue – it was a kitchen. (Well, the food was critically ill by the end of it – I digress) The point is think about your most intense - loud - busy moments and then think of how much more intense - loud - and busy the nurse is and you will begin to understand  “Alarm Fatigue”.

On a floor with 30 patients with IV pumps, nurse call, telemetry, other physiological alarms, etc there is bound to be some noise. The current methodology of listening for an alarm can really hinder productivity – but leave productivity out of it – it is a major safety concern.

Let’s take an easy one - Do you know the most common way we document a response to an IV pump alarm? The patient has pressed their call button and the nurse is notified that the IV Pump was dinging in their room. Think about how scary that is for a patient and their family – who has no idea what the dining means. Do you know the most inexpensive way to fix that problem? Automate an IV pump alarm to the caregivers wireless and explain to the patient and their family what will happen if the alarm goes off. (BTW – repeat that information every time you enter the room for rounding.)

Here’s a freebie - Depending on your nurse call system there is generally a quarter inch jack that can take a contact closure alarm – old school – this is the way my Dad did it when he sold nurse call in the early 1980’s. Order the cord you can use it tomorrow in your hospital. IF you have a question (hospital) – call or email me I will walk you through it. There are much more expensive ways to automate these as well.

The challenge is at some point in alarm automation and “management” you simply begin to displace the problem. If a clinical alarm device is trigger happy then your wireless device will be as well. Too many alarms is still TOO MANY ALARMS – just because it’s quieter on the unit does not mean its better. At some point it’s time to really review the technology that is making the alarm happen, AND review the process of who is getting what alarm when and why. The event in Boston was not due to the alarm noise, really it wasn’t even due to accountability because no one “heard” the alarm. The Critical alarm was turned off and the Warning alarms were ignored. Some automation would’ve helped the issue but it may not have solved.

Patient safety officials across the country have said the heart patient’s death at Mass. General shines a spotlight on a national problem with heart sensors and other ubiquitous patient monitoring devices. Numerous deaths have been reported because of alarm fatigue, as beeps are ignored or go unheard, or because monitors are accidentally turned off or purposely disabled by staff who find the noise aggravating.  ()http://www.boston.com/news/local/massachusetts/articles/2010/04/03/alarm_fatigue_linked_to_heart_patients_death_at_mass_general/?page=1

It’s tragic that a death occurred due to an alarm issue, and no family should have to go through that.  That death should be a rally point for all of us in the device industry.