Guest Article: Human Centering in Healthcare IT

I’ve been spending a lot of time on human-computer interactions in healthcare technology these days (both hardware and software). It’s a very hard problem to solve, especially with complex systems like EMRs. To help talk more about how to better design patient-centric healthcare technology, I’ve reached out to Steven Deal,  Vice President and systems engineer for Deal Corp, a Dayton-area engineering research firm that specializes in this kind of work.  Steven is also volunteer secretary for the Center for Innovation in Family and Community Health, a non-profit organization in the Dayton area so he knows about healthcare technology. Here’s what Steven had to say about human centering of healthcare IT:

One approach to reining in healthcare spending is the Patient Centered Medical Home (PCMH).  The PCMH model is intended to reinvigorate primary care by focusing on patient needs and desires.  Primary care reduces costs by systematizing healthcare delivery; it counters the piece parts (specialist-driven) approach that results in redundant, costly, and often unnecessary, procedures.

The PCMH delivery system is said to be patient centered, but just what does it mean to be “centered?”  Requirements for centering preferentially address the needs of one or more of a system’s stakeholders.  Alternately, a system could be centered on a particular enabling technology.  For example, personal computer systems were built around the enabling technology of microprocessors.  So if you are patient centered, you are first and foremost addressing the needs of patients.  This approach seems like a no-brainer, since healthcare, or more correctly medical care, is all about addressing patient needs?  What else would you center it on?

There are actually many options and a lot of them are being implemented today.  For example, healthcare could be centered on doctors, on payers, on medical schools, on hospitals, on the government healthcare systems (Medicare, Medicaid), on insurance companies, on research, on pharmaceuticals, or on information technology.  If you look closely at the principles of PCMH, it’s not too hard to see that it is really partially doctor centered and partially payer centered.  The tug-of-war that is the Washington healthcare-reform debate is really about which stakeholder will come out on top.

Another centering option is on the dyadic relationship between medical care providers, let’s call them doctors and understand that they actually include a broad spectrum of professionals, and patients.  Addressing a medical need is a collaborative activity between a doctor and a patient.  The doctor contributes domain expertise, capital resources, a record of treatment history, a diagnosis, an action plan, and information about the consequences of the candidate treatment options.  Patients contribute their genetic backgrounds, their lifestyle choices, their symptoms, the life context in which those symptoms arose, their treatment choices and preferences, and action plan execution.  For example, a doctor may recommend therapy; the patient has to make an appointment with the therapist, attend the sessions, follow the recommend exercise plan at home, and perhaps modify his behavior.  You might say, okay, both sides will execute, but it is not uncommon for the patient to drop the ball.  Think about all the people who hear, “You need to stop smoking,” or “You need to lose 30 pounds.”  As we all know, doctors sometimes drop the ball too.

Let’s call this dyadic centering, human centering.  Human centered design is a technique applied to the development of socio-technical systems.  In human centered design, stakeholder attributes are detailed in a Target Audience Document.  Cognitive task analyses are performed to understand the work that must be accomplished by users of the system.  Requirements are generated so that system functions and interfaces support decision making, planning, information retrieval, situation assessment, and other cognitive activities.  Screens are designed to direct attention to relevant data when they are needed.  Usable, useful and understandable systems are the result.

Dyad centering in medical care is not new.  The Planetree model of patient-centered care, which includes this concept, has been around since 1978.  Participatory medicine is another, emerging approach to cooperative healthcare.

Centering on the patient-doctor dyad has not yet materialized in the IT world.  That this is true is illustrated by a common marketing photograph used for communicating the advantages of electronic medical records.  In the photo, a doctor and a patient are shown from the back.  They are both intently pointing at a computer screen at the far end of the picture.  This image would be great if we were thinking about a two-player video game, but the work of the medical care dyad demands that the doctor and the patient look at one another.  The diagnosis depends upon looking at the patient.  The trust relationship between provider and patient is built upon eye contact.  The patient doesn’t want to see the top of the doctor’s head or a database screen.  In a human centering paradigm, medical care products will support the needs of the dyad.  Healthcare IT products need to enable the doctor to keep her eyes on the patient during the engagement.

Human centering on the dyad means that healthcare systems, which are sociotechnical systems because they incorporate people and technologies, must simultaneously address the needs of both the provider team and their patients.  Even if PCMH were really patient centered, the model would not adequately support medical care participants, because it would focus on only one half of the dyad.

Electronic medical records that eliminate the need for patients to repeatedly enter the same information on paper forms address the patient’s needs, but they don’t necessarily reduce the overload experienced by physicians and their staff.  Poorly designed EMRs may actually increase physician workload.

Doctors would benefit from a tool that addresses the “Oh, by the way,” problem.  This is the laundry list of stored-up ailments and concerns that patients tend to share as the engagement is concluding.  Such a tool might afford patients the opportunity to list their concerns before they get in the exam room.  It would help them to understand the amount of physician time required to address each issue.  It would help patients to schedule a series of appointments as opposed to trying to cram an hour’s worth of care into a 15-minute visit.  This tool would benefit doctors by alleviating overload — perhaps it would allow them to get lunch and take humane bathroom breaks.  It would help to keep the practice on schedule, and thus eliminate the time patients spend in the waiting room.  The practice and patients both benefit, but identifying the need for such a tool requires a perspective that systematically investigates both sides of the dyad individually and the dyad as a whole.

My experience in attending the Family Medicine Educator’s Association (FMEA) Northeast Region Meeting this past December provided two illustrations of failures to employ human centering.  When discussing Electronic Health Records (EHRs), a session moderator said, “What we really need are online user groups for each of the EHR products, so we can share the workarounds we’ve developed.”  I pointed out that there shouldn’t be workarounds.  The products should be designed to support their work and be understandable, useful and usable.  The discussion then moved on to certification.

Another doctor reported that their organization achieved certification that few before had achieved by modifying their processes to match what the EHR required them to do.  Once they did that, approval was easy.  Now, if modification of medical practice is the conscious intent of an EHR product, then that might be a good thing.  But I’m not sure I want an IT product developer to dictate the procedures my doctor is going to follow.  It’s not that developers aren’t good at what they do; it’s just that they don’t necessarily know the medical care work domain.  The point is medical care providers are becoming trapped by the IT products that are designed to improve healthcare quality.  Soon they, and we, their patients, will be at the mercy of these products.

I recently listened to a human factors engineer describe the redesign of the infusion pump display.  Infusion pumps are the boxy machines that are mounted on wheeled stands that are placed at bedsides.  They regulate the intravenous fluids that are administered to hospital patients.  The redesign was a marked improvement for doctors and nurses; the new display made it easy for them to determine the infusion history – when the bag was changed, when the flow rate was changed, when maintenance was last performed, etc.

While I was listening, I kept thinking back to the hours I spent sitting with my mother-in-law, my mother or my father while they were in the hospital.  Invariably, the infusion pump alarm would begin to beep.  Nurses would be too busy with other patients to shut it off, so the beeping would go on and on.  The longer the alarm continued, the more anxious I became.  I wanted to do something, to understand if this meant my mother was getting too little or too much medicine or if there was nothing to worry about.

As I’m listening to the presentation about the infusion pump display redesign, I’m thinking, ‘Well, none of that would’ve helped me when I was sitting there.  And come to think of it, I was spending more time with that pump than any nurse or doctor ever would.  Why didn’t that interface tell me whether or not this was an urgent situation or even provide some instructions on what to do?  After all, an Automated External Defibrillator (AED) can walk me through the steps of resuscitating a heart attack victim, why can’t the infusion pump do at least as much?’

That led me to think about the vital signs monitors.  Even though I copy readings into my caregiver notebook at regular intervals when I’m sitting with my family members, I don’t know what those readings mean.  I just record them and read them back when, on rare occasions, a doctor asks about the history of a particular read out.  Since I’m spending so much time looking at them, wondering what they might be telling me about my dad’s condition, it would be nice if that screen imparted information to me rather than just data for the doctors.

One of the doctors at the FMEA meeting asserted that there was no money to be made in electronic medical or health records.  As soon as one product came out with a popular feature, other manufacturers would copy it, and then they’d all have it.  Well, I know from my friend Dennis Carlson, who used to design pit stop support systems for NASCAR, that it isn’t just the technical feature; it’s the orchestration of the work that can make a differentiating performance difference.

The doctor’s comment and the comments I described earlier make me wonder if physicians are discerning enough to appreciate the difference between an approach that will add to their burden and one that will help lift it.  Many seem to flock to whatever is shiny and new only to subsequently find they’ve purchased a product that’s best suited to gathering dust on a shelf.  However, the size of their investment may influence them to field it anyway.  In my experience, doctors who are reluctant to implement electronic records might be won over by an implementation that allows them to keep their eyes on the patient and supports their self-defined work flow.

Patients will certainly appreciate IT solutions that effectively support the dyad.  They will appreciate them in the same way they appreciate iPhone apps that help them to navigate the details of their harried days.  I wouldn’t be surprised if healthcare payers, the government and private insurers, discover there is a benefit to their bottom line when the collaborative relationship that is a medical care engagement is integrally served by IT implementations.