Human Factors in Healthcare Blog

In my last two postings, I provided some non-traditional advice about how to hire someone for a human factors engineering and design/safety job.  A reminder of the five jobs that contained attributes helpful for an HFE and Medicine specialist:

1. Bartender
2. Bean-packing plant safety manager
3. Lifeguard
4. Set designer
5. Wilderness survival expert

The #3 job, lifeguard, is easy for me to relate to;  I was a lifeguard at a quarry lake for 2.5 summers.  During my time there, two people drowned at this lake – both times I happened to be off.  Nevertheless, we “pulled” many kids and adults out of situations where they were drowning or near drowning (N=30-40 per summer).  It was an old, deep quarry that was very crowded and full of many people who could barely swim – but tried anyway.

What does this have to do with skills and knowledge to be a HFE and device/healthcare expert? 

It all starts with the training.  Nearly 30% of lifeguard training is learning how to use “judo” moves to escape the clutches of a frantic, grab-at-anything drowning person.  This frenzy is not nearly the same as designers and engineers whose prototype is “drowning”, but there are parallels.  We learned some of this at a how-to-be-a-consultant workshop I took at Usability Professional Association (UPA).  The “master” consultant went through several resistance strategies we would encounter from product designers who felt threatened – and how to “wrestle” our way out of their “clutches”.

Secondly, drowning or near-drowning does not look like what you see on TV.  Major human factors engineering design flaws are often not what you think (or just common sense).  There is very little splashing and waving.   Major HFE design flaws are often subtle or hide.  In both cases, you not only need to train yourself about these counterintuitive ways of monitoring the situation, you need to be able to teach others. 

Third, lifeguards very quickly learn that their job is a lot of being tested, being drilled, and regular practice.  Hands-on, lots of feedback, peer input, and building a thick skin.  Its not boot camp or military, but often close.  Applying HFE in the hectic healthcare or device development arena requires you have that thick skin.  You also need to develop it in your design, marketing, engineering, and management colleagues.  HFE is about high contact, hands-on, and lots and lots of testing.  Building thick skin requires repetition, tack yes, but repetition.

Next, we look at  the job of “set designer” (huh?!)

In no particular order, here is what I learned this summer:

1. All cars sold to haul kids on vacation trips should have “glass wall” options like taxis to close off the back seat noise and shrapnel
2. If someone says they are car sick, it is better to stop and spend 5 minutes for a short walk than to clean vomit for 15 minutes
3. GPS systems can be wrong…really, really wrong:  “turn left onto the (non-existent) ferry”
4. Seemingly small wayfinding and other design flaws in hospitals can grow large when your friend or brother are sick
5. Medical residents are getting more and more savvy about patient safety (this is a good thing)
6. Medical residents are impatient with progress in patient safety (this is a great thing)
7. You can say you are going to write blog posts every week, then life happens

For those (still) reading my posts, I am going to upgrade the system to make sure you get announcements of my new posts.  For those about to read my posts, I am going to improve my marketing and networking to inspire me to continue my posts more regularly.

Last week my dad found and read the print-out of my first 12 Blog postings.  He was very interested, and we talked about the useful nature of the Blog.  He thought it could have a wide audience and most postings were readable.  I had given him the print-out weeks ago, but until recently it was lost in a pile of other papers and items that are stacked 3 feet high near his TV chair.  He does not have a computer – so he had to read the paper version.  He is not computer-phobic, since he actually had used computers in his high-school class since the early 1970s (yes, 1970s).

My dad has been an indirect and direct inspiration to my work.  In 1998, I wrote an editorial to British Medical Journal about human factors engineering aspects of physician communication.  I wanted to humanize the editorial (critique) for this popular medical journal, but also push the concepts and methods of the underappreciated HFE.  So, I told the story of a miscommunication of a echocardiogram (ultrasound of the heart).

In 1997, a nurse had told my dad that the “Echo” report said that he had aortic stenosis, and needed to be seen by a cardiologist.  He told me later, and I was stunned because symptomatic aortic stenosis has a very poor outlook.  I happened to be traveling to Northern Wisconsin that next week and was anxious to learn more about any further testing and the plan (e.g., surgery?).  When I arrived and talked to my dad, he told me the nurse called back and said, “never mind, we got the report wrong, you only have minor changes of atherosclerosis!”  This is a fairly common finding for this age, and often not a big deal.  Since the mistake went in the good direction for my dad, we all laughed about it.

Years later, I was to find that there is a whole host of look-alike and sound-alike terms that get messed up during dictation, transcription, verbally communicating, etc.  Medication names are the most infamous.  In 1990, several journals described fatal confusion between lasix and losec.  This resulted in the drug name of losec changing to prilosec.  ISMP, FDA, and other medication safety organizations have devoted much time and energy to prevent as much of this as possible.

But most safety people find out quickly that we humans do not really “read” in the same manner as a computer scans a document.  We do not synthesize stuff in our head the way a computer program does.  Humans are great at grabbing fragments of the familiar, making a best guess, and acting quickly.  Star Trek the Next Generation and other SciFi shows have used our unique power of good guessing in their ”man wins out over cyborg” episodes.

But some “tricky situations” require us to switch from using inference and hunches and go to a more step-by-step approach.  But the problem is realizing when we are in these “tricky situations”.  How do we know when to slow down.  Worse yet, if they are REALLY tricky, like watching a magic show, our step-by-step approach will still fail us.  Magicians Penn and Teller have actually helped write and present at professional conferences about some of this linkage between magic and cognitive science.

The goal of human factors engineering is to find out where we have accidentally added “trickiness” to our devices or systems.  And we really want to find out if we have made our design so tricky that a magician would be proud.

A few weeks ago I was teaching about human factors engineering to a group of hospitalists at the Society for Hospital Medicine meeting.  Many of the hospitalists (physicians focused on delivering care mostly in hospitals) in the audience had a minor or major role in making things safer in thier organization.  Some had no idea about human factors engineering, or had heard it described as the study of factors that make us flawed humans. 

Personally, I like my former co-worker’s definition that focuses on ergonomics.  Since his early days at NASA was around engineers building new crew capsules, he defined human factors engineers as ”the group of people who measure people’s butt cheeks to design the seat so it fits!”

I have tried many methods to introduce HFE to novices, but the two main methods are interactive exercises and demonstrations that put people in position of seeing things that were previously underappreciated.  An exercise I tried for the first time at the SHM meeting was to have two groups of 2 people try to find the location of an AED.  The scenario was that I suffered a heart attack and they had called 911 and were pursuing an AED that they believed was mounted on the wall somewhere in the hotel conference center. [previously, I have written about signage for AEDs].

On each team, one person was assigned to find the AED and think aloud about their plan and other thoughts.  The other person was to record those words and actions – especially where the searcher was looking and resources they sought to find the AED.  The room had exits to different hallways for each team to began searching. 

In short, one person immediately asked hotel personnel, who did not know.  Then they asked conference information desk, who pointed across the middle, large hallway to the easily visible AED sign and wall storage unit.  The other person just had instincts to look centrally in the 400 foot main hallway, and was correct.  Neither used their smart phone, their map included in the conference agenda book, or other tools you might consider if not in a hurry – or, where they in a conference room answering questions in a laid back inteview.  There are a few studies on so-called wayfinding for designing hallway signs, but I have not seen any for searching and finding AEDs?  Do any of you know of some?

Interestingly, when someone did look at the hotel map, it provided locations of three things (besides room numbers-names):

1. Bathrooms
2. ATMs
3. Where you were allowed to smoke

In debriefing the two physicians who were frantically looking for the AED, they did provide one CAUTION to me about doing this exercise again:  make sure the people looking for the AED tell the information desk or other personnel that it is an EXERCISE, and no need to call 911!

I just started hearing that stupid brake squeal from the front of my 10-year old truck…again! The new brake components installed a few months ago were to replace the new brake components installed a few months before that.  I suppose I will have to go BACK IN in order to sell this pretty nice looking, but pig-sounding, truck.

Returning your human body back to the hospital is probably even more irritating.  Did “they” do something wrong? Did you?  Did both? We might decide the “bounce-back” is no one’s problem.  This might be the nicey-nice route, but now there is no incentive on your part or their part to do anything different (i.e., it will happen again).

Reducing readmissions is a key part of health reform and many quality efforts.  Bob Wachter (of Wachter’s World), has a pretty clear discussion of this at his Blog.

Question:  Can we reduce discharge “bounce-backs” with huge computer systems, 85 million pseudo-checklists, and a pile of brussel sprouts (think sulphury tasting carrots)?  I am not sure…

My wife has been discharged from same day and overnight hospital stays many times in the past few years.  What did the healthcare staff do to keep the complications from medical procedures and strong medications from pushing her back into the hospital?  I will save that for her to describe in specific detail another day.

Overall, however, the main tools to tell us how to avoid “bounce-back” were verbal instructions (doc), verbal instructions (nurse), written instructions (standard-printed), written instructions (hand-written), and whatever was printed on the medical items (bandages) or meds we were given.  Oh, and whatever was left over in my head from medical school-residency 25 years ago; and whatever she might have read on consumer or medical web sites or medical journals.  Lastly, in some cases we would get informal consult or input from my medical pals.

Depending on how you want to count, that is 8 or 9 sources!!!  I can hear some of you readers saying, “go with what the doctor says, and downplay the others”.  Some might advise, “go with the handwritten, it is the most customized to your situation”.   Others will recommend, “consumer web sites have the gold nuggets from real patient experiences and tips.  Those doctors and nurses have never REALLY experienced XYZ disease, what do they know.”

Tools (computer or otherwise) need to help streamline or sort this out in a more understandable, easy to use way.  What do I mean by easy to use?  You need usability testing by patients and their caregivers — most realistically when they are sleep deprived, scared, in pain, etc.  Not a simple task to do this usability testing, but CRITICAL to success.

You know that area of your house outside where the phone, electric, gas, etc come into the house (basement)?  Well, do NOT try to use your weed whacker to clear out weeds.  The weed whacker might have problems cutting tall or wet grass, but it chews right through the outer coating of your phone line.  It’s actually a delicate “chewing”, since it just exposes the copper wire to the rain and snow, so that the phone failure takes 4.75 months to happen.  By that time, you have forgotten that you meant to call to have the gnarled up wiring fixed in a routine, non-emergent fashion.

Do any of you know what happens when you call to get phone service fixed?  Yep, it is very much like trying to get an urgent (but not emergent) medical condition addressed by the primary care doctor you have not seen in 6 years.  You go through voice prompt systems, type in you phone or medical number 50 times, and finally talk to someone who tells you that someone else will call you back about the plan…  All that seems understandable, since these customer service people need to be efficient with their time and that of the professionals that they protect, er, help manage finite resources.  You realize the problem, though, when the first person can’t tell you who the second person is, or how to call that person if they don’t call.  Worse yet, you miss their call and you go the “back of the line”, even though you have given them every cell and land line number you own.

Like delayed flights in the last blog post, human factors engineering analysis can give us some clues about design features to improve timeliness of care (or return to phone service).

1) Offer the same ability to track your process as Fed Ex gives you to track your $29 vase of roses.

2) At the risk of being a broken record:  offer clear alternatives to give choice to fit a person’s need.  Offer a phone message every 4 hours, or text, or email…  Or, give a direct number to call if they have not called in X amount of time.

3) Offer up a web page form so you can enter the key details about your medical condition (or phone disaster).  I see why this is avoided, since clinics worry they would be liable for reacting slowly to ominous symptoms.  Okay, but there needs to be a better method than verbally, and less systematically, having someone go over the same story.  Think of this as trying to design stuff to create the best shared model about what is going on, and what should we do next.

You look up over the top of the newspaper you planned to read later.  You see the first sign of trouble:  two agents backing away from the counter whispering to each other.  Yep, it is 10 minutes past “official time”, and that darn door is not propped open.  You could ask the agents, but you know they will not tell you anything unless the delay becomes tragi-comic.  Perhaps not until they are sure you are 30 minutes late.  Sometimes the folks working in back will bypass the frontline agents, so you decide to check other sources of “truth” about how late you might get home.  Hopefully, you have “planned” to be late and do not have critical child care or work tasks.  Suddenly, you feel that hot, Elaine Benes-like, irritation welling up.  PLEASE MOVE!  Or, just tell us when we will all get moving.

Of course I am tricking you!  I am talking about almost any encounter with healthcare settings.  Although my level of irritation at delay last night in Providence did inspire this posting (60 minutes delay, not as bad as 12 hours in Baltimore last year).

There are many human factors engineering lessons about how to address delays when seeing a physician, getting a scan, or other services. 

First, vague concepts like “transparency” or “customer first” are hard to translate into design.  You end up with pictures of people rowing on the wall and signs that say “speak up if no one has talked to you in 30 minutes”.  Instead, think of delays with your computer.  Which helps more:  a) the little rotating symbol that indirectly indicates a web page might be loading; or b) a progress bar and estimate of time for download.

Second, people want clear options with costs and benefits that make sense to their condition.  NOT a good example of options: 1) stick around in earshot of a person you have never met who will yell your name over the top of other noises; 2) leave the area and lose your spot in the queue.  More useful options: 1) stay in earshot to see the surgeon and visit loved one in post-op in seconds; 2) stay within 5 minute walk and carry pager; and 3) give us your email for us to send you the outcome, and see your not-as-much-loved one upon discharge.

Third, situational awareness of those serving and those being served is tricky to do, but everyone benefits.  Do you think that gate agent last night wanted someone screaming at her when we were only 30 minutes late?  Why don’t they have a status light that is

• Green when they have actionable information and are about to tell you,
• Yellow when they have only partial information, and not actionable.  However, yellow is a promise a “green” light within 5 minutes
• Red is when everyone is the dark, and communication and trouble-shooting are broken.  It is always accompanied by a best guess number.  You are free to rebook at a $100 fee; or get a pager and go eat (they will pay if the pager goes off before you eat); or get a $50 certificate and stay in the area.

I know that last set of options would not work, but it tries to get at the idea of all of the key people having the best situational awareness possible.  Your thoughts?

- John

I am going to help organize and judge a patient safety re-design competition this Saturday.  Several groups of nursing, medical, public health, business and engineering students are going to look for known or potential design issues for a dialysis machine.  They will then have a few hours to conceive of and construct 3D models (boxes, paper, etc.).  It is a new competition for University of Michigan, and organized by a really cool student-led group called IHI-Open School.

Whenever I judge such things, my thoughts go in two directions:  what are my lessons learned on BEING A JUDGE?; and what are my lessons learned on BEING JUDGED.

JUDGING 101

Follow the rules.  If the producers of the Food Network show tell you to fill 4 plates of food…fill four plates – not just one to share.  When I was honored to be one of 6 judges of a Texas chili cookoff in Houston, they told me one inviolate rule: NO BEANS IN CHILI.  Sure enough, the 4th team had beans in the chili and the first judge just dumped it onto the ground and asked for the next team’s submission.

Know your audience (judges).  No one is without bias…or, said another way, are they able to forget what they have liked and disliked in the past; or able to forget what they just saw most recently.  During the chili cook-off, I noticed most judges giving 7s and 8s (out of 10) for the nice-tasting series of typical chilis.  When we got a super spicy entry, my spicy palate gave it a “10″, but the Texan next to me gave it a “2″.  I am not saying you should betray your “self”, but you should know that judging is not really fair in the way you would think.

BEING JUDGED 101

Listen to (almost) Everyone.  If your dad says your presentation was “so-so” because you frequently uttered the space filler “uuhhhhh”, you should listen.  If a post-session survey says your co-presenter is wearing a sweater that makes him look like “Mr Rodgers Neighborhood”, then less listening is okay.  (Note: photo courtesy of folks who invited me to present at Northport VA Medical Center…I don’t have a photo of my co-presenter in the sweater.)

Interpreting Constructive Feedback is Tricky.  See advice above…  The judge’s context, recent experience, and set of “rules” might not be all that obvious.  There were mostly positive items in two recent reviews of our book on HFE and Healthcare (Human Factors Society – Healthcare Technical Group; Biomedical Instrumentation & Technology - BIT).  In the case of BIT’s review, the reviewer also provided this critique:  “The authors are too narrow in their description of what constitutes a good HF engineer…”  And, “Many of the most successful HF engineers did not come from pure HFE academic backgrounds…”.  We had to read his critique twice and chapter 4 twice before realizing that our advice was somewhat easy to misinterpret (i.e., reviewer’s perception was correct).  We realized we had not emphasized enough that baseline HFE knowledge and skills could be acquired in many ways…and that experience in applying those concepts and methods were success factors (not necessarily formal degrees).

Judging Strengthens Everyone.  If you have to create a scale to determine the best redesigned device, you will learn.  If you have to make that judgement explicit, you will learn.  If you have to defend it in front of an angry mob of students, you will learn…to bring consolation prizes, like taking everyone for a beer after the competition.

In the past two weeks, I was honered to be invited to two healthcare conferences to talk about human factors engineering (HFE) and patient safety.  The locations and organizations were quite different, but the content I provided was nearly the same.  In New Orleans, I was on a patient safety panel with Bob Wears at the International Meeting on Simulation in Healthcare.  In Toronto, I was a presenter at the Canadian Society of Hospital Pharmacists (my slides can be viewed on their web site).

I was able to fly home from New Orleans before the big East Coast Storm…  But, I had to stay an extra day in Toronto to wait for the 6-12 inches of Midwestern snow storm to be plowed.  In New Orleans, I re-learned that I like the sound of the word “Gumbo” more than the taste. In Toronto, I learned that the goat in Jamaican “Goat Roti” tastes just like you would think that goat tastes! 

The other common theme besides interesting food was the questions about HFE.  In fact, these difficult-to-answer questions are common enough that I expect them and have written about them:

1. How can we use these ideas and tools in our job settings?
2. Where do we start?
3. Can we do this ourselves, or is it worth it to hire someone?

Q:  How do we use these ideas/tools?  A: The main targets I tell them about fall into two categories:  a) fix the stuff you are stuck with; and b) don’t buy stuff that you will need to fix.  This answer sits pretty well with most folks.  They see the training, re-training, post-market modifications, work-arounds, and other marginal attempts to deal with devices and tools that are hard to use or error-prone.  They want more systematic ways to find and address HFE flaws in the stuff they are stuck with.

They know, in general, that they should not buy stuff that needs to be fixed, but the pathway to do this is much murkier.  Shouldn’t FDA do this for us?  Shouldn’t our biomedical engineers know?  Why would someone build a widget with known HFE issues in the first place?  This is right about the time that I say, “does anyone have any easier questions!?”

Q: Where to get started?  A: there are many places to get started.  Laura and I get this question enough times that we came up with a list of nine ways to get started, and put the list in our new book…  Then, we thought we could expand on the list, and wrote an article for a HFE special issue of Biomedical Intrumentation and Technology.  In future Blogs, you will see excerpts from this list pop up.

Q: Do this oursevles?  Hire someone?  A: “Yes”, is the short answer.  The much longer answer is in our book we recently wrote and edited.  It contains 6 stories (case studies) from around the US and Canada about hospitals that are doing it themselves or had hired HFEs.  The book has recently been reviewed in a couple of venues, and we will make comment in the next Blog entry.

Some aspects of this Blog creation tool (WordPress) are very usable.  That is, they are intuitive to use without training or reading online “help”.  I will describe three types of HFE issues with the less intuitive aspects of this software tool:

1) Some aspects of the tool take some scanning and rescanning across the top and side bar menus to find.  The ones that seem to mimic MS Word, are the most straightforward, but there are some that are “grayed out” or are inscrutable icons.  By the third time I used this tool, I could remember where most were and use them fairly quickly.  My guess, though, is that if I went away from this tool for weeks or months, I would need to travel a learning curve again.

2) Other aspects take a bit of time to find, such as creating links, but then are pretty easy to find and use the next time.

3) One MAJOR tool that has been hard to find and use is the function for YOU to get email notification of the Blog entries.  I think I finally found it after searching 3-4 times, but I want to test it upon myself before saying you should try it.

 The three categories of HFE issues I talk about above are those found with many device interfaces.  You will notice that category #1 and #2 will fade in my memory as I become a regular user.  #3 is going to be a recurring bane of this tool.  #1 and #2 are unfortunately the type of issues that will haunt all of your intermittent users, skittish users, and distracted users.  These are unfortunately the user types that operate many of your devices.  Your expertise (and faded memory) will work against you as you refine and finalize your designs.  HFE tools, especially usability testing, is your defense against your faded memory of minor or moderate flaws that often have major consequences.

For those who like to read more aout this ”learned intution“, I have provided a link.  For those who like demos, find a FedEx logo and look hard for the “arrow” in it.  Once you find it, or get mad and have to Google it to find it, you will soon find it harder and harder to remember not knowing it is there.  Worse yet, you will slowly lose your empathy for those who don’t see it quickly.

In future Blogs, I will comment about some specific device-facilitated adverse events that I hear about.