Long before HP was known for PCs, laser printers and Carly Fiorina, it was a manufacturer of test equipment for electrical engineers. One reason its products succeeded was because they were designed by the very people who ultimately used them. HP designers possessed a deep understanding of the product use case and empathy for the user — a highly educated and skilled professional with little tolerance for inefficiency. HP’s product design philosophy was called “the next bench,” and it worked extremely well.
In healthcare, physicians — also highly educated and skilled professionals with little tolerance for inefficiency — are obliged to use electronic health records (EHR) systems, most of which (from a physician’s perspective) work quite poorly. Most physicians complain that EHR systems are cumbersome, unintuitive and slow them down.
To be clear, EHRs are not designed by physicians. Most EHRs grew out of the computer systems that run a hospital’s inner workings — patient scheduling, admission and discharge, staff payroll and accounts receivable. For system designers, physicians’ needs were an afterthought. That’s why the typical hospital EHR frequently makes physicians less efficient and productive (and far more frustrated) than they ought to be.
Physicians are not about to give up caring for patients in order to start writing software code for the next generation of EHR systems that their peers will use. Therefore, healthcare IT vendors will not be able to replicate HP’s model exactly. So how can the lessons from electronic test equipment (“the next bench”) be applied to the healthcare IT industry (“the next bed”)? How can physicians’ needs and preferences be manifested in EHRs and other technologies that are inextricably linked to patient care, provider remuneration and physician satisfaction?
The answer is physician engagement — doctors actively participating in health IT product design and implementation processes. Physicians don’t have to code, but they do need to collaborate with those who do. If software developers and installers are given a view inside a physician’s day and physician workflow in the hospital, they should be able to translate those insights into features and functions embedded in the products they design and deploy.
Physicians must have a seat at the table when it comes to selecting and customizing the software they’re obliged to use every day.
Some commercial software developers already do this. However, if broad-based physician frustration with healthcare IT is any gauge, it is not done nearly enough — or at least not well enough. (An EMR & EHR blog post from several years ago speaks directly to that issue.) The American Medical Association (AMA), advocating for and acting on behalf of physicians, is investing in an initiative called Health2047, intended “to create new and important linkages between the physician community and the AMA’s content/regulatory experts with leading companies, emerging growth companies and individual entrepreneurs.”
The AMA published in 2014 what it called a “framework” outlining eight EHR usability priorities, one of which was to “expedite user input into product design and post-implementation feedback.” In 2016, AMA is still beating that drum; its CEO recently reiterated that “physician input in the development of new products is crucial to building effective digital products.”
Some hospital IT groups also recognize the importance of physician collaboration as a key to success. For example, when Vanderbilt University Medical Center announced its Clinical Systems 2.0 development project last year, it said an early step in the process would be “interviewing physicians, nurses and other staff in the hospital and clinics to help us evaluate current functionality and things that we don’t have today that we really need.”
Today’s healthcare industry has a unique opportunity to leverage advanced technology to completely transform the way that care is delivered. In 10-20 years, many of today’s medical practices will look as antiquated as applying leeches for bloodletting. But technology vendors can’t and shouldn’t attempt to effect this transformation alone. Physicians must have a seat at the table when it comes to selecting and customizing the software they’re obliged to use every day.
Doctors don’t write the code, but they know what they need software to do to improve the way they deliver care. So long as physicians collaborate effectively with technologists, there’s a strong chance doctors will be well-served by the technology that is developed through their partnership.