Showing posts with label alarm design. Show all posts
Showing posts with label alarm design. Show all posts

Saturday, June 21, 2014

Interruptions.....


I stopped to visit a friend in the hospital and had a chance to observe some clinical workflow in person.  The Nurse walked in.  She had a large brick of a phone wrapped in a plastic case pulling the side of her scrubs uncomfortably down.   She began asking questions as she prepared the medications.  She reached into her pocket and pulled out an Iphone……confusing…..then I realized it was her medication scanner.

As she was preparing to hand the medications to my friend the brick rang…..loud….very loud…. She apologized as she reached down and complained that the previous shift must have had the ringer turned up. (I was there at 8am in the morning so evidently night shift likes to carry a mobile alarm clock) She silenced it and went back to medication work.  I asked “Do you like your phone” – she held up her iphone and said “This isn’t used as a phone it’s just for meds and stuff.” I laughed and smiled “No the brick wrapped in bubble wrap hooked to your scrubs.”  She laughed and said “No Comment” as she finished putting the medication in the cup and talking to Holly she looked at me and said “That thing interrupts me when I am trying to work with a patient and it’s just rude to the patient. I don’t think it’s very practical…..I like to be fully engaged when I am with a patient”

Ouch…every technologist who has designed a decentralized workflow should wince when they hear that – this nurse is a young lady who grew up with a cell phone in her hand wanted to be what? “fully engaged with her patient”  She wanted to walk into a patient’s room and only think about what she needs to do in that moment.  She wanted to focus on getting my friends medications accurate, make sure she didn’t miss any aspect that could be a warning sign…..crazy thing….she wanted to be a nurse.

As I worked on this post – I started writing about ideas for fixing….pointing out that holding on to old technology only hurts your facility….listening to nursing because they actually do the work….blah blah blah…..but then I started think this isn’t just a hospital thing.

I was sitting in my family room – Noah (aka #4) on my lap talking about his day and my phone rang…..in that moment I stopped engaging with Noah and answered my phone…I tried to justify in my mind that I had tried to get ahold of this person all day and needed the information….as I hung up Noah said “Mom, can you just talk to me for a minute”….ouch…. As I began writing this blog for “Linkedin Content” to promote my industry knowledge…..I am pausing for a moment.

Our workflow design reflects our society design….the nurses response is reflecting the shift in our society to tolerate interruptions.   She recognizes that everyone would like a bit of undivided attention, especially when they are in a new environment.  She recognizes that the technology she had been given was not serving her well and was making her less effective in her job.  She recognizes that – just like Noah – her focus on my friend in that moment should be the most important part of her day.

So this post should serve two purposes – rethink how you are designing your clinical workflow and alarm design.  Clinicians are fatigued because their attention is constantly being split.  Clinicians are fatigued because we, as technologist, aren’t doing our jobs.

The second purpose – does your personal life reflect an interrupt driven society? When will that become not ok for you?

Last night…..I left my phablet in the kitchen….turned the ringer off….and enjoyed my family and some friends.  It was probably the best night I have had in months…..today…..the ringer is still turned off.

Tuesday, September 4, 2012

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.

Tuesday, April 5, 2011

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.

Monday, March 7, 2011

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.