The problem is that these new things do not solve any problems. Traditional product innovation concentrated on identifying problems, designing solutions and then selecting technologies that were capable of enabling those solutions. New technologies were usually born out of the necessity to solve a burning problem and those with enough applicability to larger markets became blockbusters. Every frying-pan today sports technology first invented in the process of creating refrigerants and later used for nuclear destruction (Teflon). Every large enterprise embarking on cost cutting, new markets acquisition, or general improvements, should know all too well that selecting a “cool” technology first, and then attempting to find a good use for it, is recipe for failure. As a former good friend of mine used to say, “There are three types of companies: engineering driven, sales driven and successful”. Successful companies are market driven – they look for those needs and problems that people are willing to pay to have resolved. Very successful companies create their own new markets by creating new needs that people didn’t even know they had. Sometimes, during this process, new technologies are invented for the purpose of creating products that solve people’s problems. Customers usually buy products and services. Rarely, if ever, do they buy “technology”. Moreover, technology should be transparent to the user and really good technology should feel like magic.
Back to EHRs, we are now trying to convince physicians and hospitals to buy cutting edge EHR technology, some of which has not been invented just yet. We are asking them to buy open platforms, clouds, information networks and more recently search-engine optimized data architecture. And when they drag their feet in utter confusion, we label them Luddites and technophobes. Furthermore, those supposedly concentrating on the “next generation” of health care computer tools are designing them in deference to the same cutting edge technology requirements with almost no consideration for business process. And when the business model gets in the way of the chosen technology, then the business model must go. This is why you always find criticism of our “fragmented” mom-and-pop health care system and vilification of the fee-for-service model in most health care technology reports. We have moved from the pre-HITECH sales driven approach to EMR (with an M), to an engineering driven effort to increase EHR technology adoption. I would like to suggest a third option: the market driven Product Management route.
Forget about EHR and databases and servers and networks. What problems do physicians and hospitals face today? This of course is a huge question and the answer will vary based on many factors. Hospitals are different than individual physicians; large hospitals are nothing like small rural ones; physicians’ problems vary with specialty, practice location, practice type and time of day. But why start with providers? If this is a National discussion, shouldn’t we primarily consider what Government and consumers need? Unless you are aiming at selling something to the U.S. Government, or to individual patients, my answer would be a resounding, and unpopular, No. Of course, providers’ problems will be inextricably tied to constraints placed upon them by both Government and their own customers, but the paying customer for our imaginary Product is the provider, and as all other industries that we so eagerly want to copy, already know: The Customer is King.
At this point, you would go out and talk to your customers, potential customers and non-customers. Most existing provider surveys are asking people about barriers to EHR adoption and why providers would be interested in paying for an EHR. This is not a very “innovation fostering” approach. Considering the large spectrum of customers we are exploring here, if you asked an open-ended question about pressing problems, you would most often elicit two general responses: inadequacy of reimbursement and a perpetual desire to provide better care. These two overarching requirements translate into different things for different market segments. The reimbursement issue, for example, can be looked at in two ways. How do I get more money from payers? How do I cut my costs down so I decrease overhead and increase profit? Providing better care is an even larger subject and more controversial too. For a primary care doc, this could translate into a desire for more time with each patient. For a hospital, it could mean reducing complications. For both these examples, the computer would be required to actively do something that either consumes time now, or something that is so time consuming that it is not done at all. Writing for The Health Care Blog, Dr. Steve Sanders describes a very simple vision of how computers, integrated into operations, could reduce falls in hospitals by triggering well defined sequences of human actions. This is how computers are used in manufacturing and supply chain operations.
Identifying business problems and suggesting adequate solutions requires careful examination of workflows, identification of commonalities and opportunities and constraints posed by conflicting requirements and external factors. Then, and only then, comes the time to select, or build, technologies capable of supporting your customer’s business goals. In 2006, a computer scientist thought that putting medical records on mobile phones would be pretty cool. In 2009, Eric Schmidt had the same thought, this time involving a motorcycle trip to Mongolia. In 2011, someone else had a similar epiphany. It’s not catching on. Although, the concept is very cool, it is only incrementally cooler than flinging “Angry Birds” on your cell phone and nobody has been able to locate a market segment willing to pay for implementing this concept because “pay it forward” is not a viable business strategy.
How about National strategies? After all, introduction of computers into the health care system is now a centralized Federal enterprise. On the surface, Government’s goals are very similar to providers’ goals: cutting costs and improving care by measuring outcomes, with the added lofty goal of conducting research. There is, however, a “slight” problem here because Government’s costs translate into providers’ revenue and you will be hard pressed to find a paying customer interested in software that will decrease revenues. As to measuring outcomes, just imagine trying to sell people software tools that would allow the IRS to better and more intimately measure their tax liabilities. Not much of a market there. As to research, while everybody probably agrees that clinical research is worthwhile, very few businesses, in any industry, would volunteer funds and effort to advance national research initiatives with no immediate and tangible ROI to the business itself.
We have reached a fork in the road. Either EHRs are built and sold according to free market rules, with some Government oversight and regulation, or they become regulatory, Government mandated and Government designed tools, required to be purchased and used in prescribed ways as a condition of licensure to provide health care in this country. The latter option, which seems to be where we are headed, will add another painful customer problem in need of solving: minimizing Government intrusion. For savvy HIT Product Managers, it is time to formally design a solution and begin the search for the best technology to minimize the pain created by, the yet to be agreed upon, Government technology. HIT is now a self sustaining enterprise.
No comments:
Post a Comment