by Jerome Carter
According to Ben Franklin, John Adams, or someone else (I could not find a reliable source), “Every problem is an opportunity in disguise.” This bodes well for clinical care software because the number of complaints about current EHR systems grows louder each day. We know the problems: poor usability, lack of workflow support, reporting difficulties, decreased productivity, to name a few. How can these problems be turned into opportunities?
Obviously, solving these problems by designing better software offers an opportunity for software sales; however, I think there is more to it than that. Current EHR products grew out of a particular mindset and way of thinking about software and sales, and that mindset, I believe, has a lot to do with the problems EHR users voice.
When computers were new, they were sold primarily to businesses. The advent of the PC turned computers into consumer products. However, software and computer sales to businesses continued as they always had, which I think contributes to the issues small independent practices have with selection and implementation. Here is an example of what I mean. I have been buying software since I bought my first computer. This was always a straightforward process: find the software, pay for it, done. I remember my bewilderment while at UAB when I wanted to buy statistical software that had data mining algorithms. Since I was at the university, I was told I had to buy it through the university sales channel. I wanted a single copy. I could never find a salesman who would give me a price or tell me how to buy a single copy. I called the local, regional, and finally the national sales office. After a few weeks, I gave up. I never got the software, or even a price. What I did get were repeated promises that a sales rep would call.
Software sales to businesses assume a certain infrastructure (sales people, consultants, and other go-betweens) that does not exist in the consumer arena. The uptake of consumer-focused computing can be rapid—witness smartphones and tablets. In both cases, the products and their support were designed to be easy to understand, navigate, purchase—no consultant for implementation, no waiting for a sales rep to call.
With the above in mind, consider that the slowest uptake for EHR systems has been in small independent practices. Among the main reasons most often cited are software costs and implementation issues. The HITECH act created regional extension centers for the express purpose of helping small primary care practices with product selection and implementation. Now, here is my question: Is EHR product selection/implementation difficult because any software system that supports clinical care is necessarily complex OR is this a reflection of how business software has traditionally been sold? I think the latter plays a significant role.
Healthcare software has traditionally been sold to large groups, hospitals or health systems. In these settings, sales reps and consultants are the norm. There is an ecosystem based on software being difficult to configure and requiring weeks to learn to use expertly. Unfortunately, this thinking is not limited to clinical software. ICD-10 is a good example. There is an unquestioned assumption that consultants would be hired to help with implementation.
Eliminate the middle man
So how does the rancor over current EHR systems lead to opportunities for disruptive companies to offer new products and services? Simple. Eliminating the middleman is a classic business strategy, and the perfect place to test this strategy is in small practices. Moving to a consumer-focused sales model, sans reps and consultants, means making products more approachable and easier to understand, and as a result, lowers the barriers for those interested in buying systems. Typically, EHR products have hard-coded workflows and minimally-configurable user interfaces, and the selection process has to account for these inflexibilities. Thus, much of the challenge in selecting an EHR system grows out of the need to select a product that works as closely as possible to the way the provider or practice does. However, if the workflows and interfaces were readily adjustable by users, then product selection would be less harrying. Well-designed software should provide a way to set all important configuration options via a preference panel or other configuration tool (this includes security, data exchange, reporting, and other key aspects).
Of course, designing software that offers this type of configuration capability is much more difficult to develop than is software that requires consultant hand-holding and training. But consider the upside for the clinical care software company that does. Building a consumer-friendly product can lower the cost of sales (fewer sales calls and visits) and decrease tire-kicking by potential buyers. Such an approach would engender an add-on market as well. Apps anyone?
To those who say this is unreasonable or unworkable for clinical care software, I say it has never really been tried. Not convinced? Go to an Apple store and try to buy anything. If you have a question, ask a “genius.” Now try asking a typical sales rep a technical question about your EHR system. The likely response will be that they will have a tech person call. Amazingly, I experienced this recently when a sales rep for IBM’s Watson system called to invite me to a webinar about clinical applications. He could not answer a single question about Watson—not one!
Focus on productivity
EHR systems are the current model for clinical care software. EHR systems are designed primarily to be paper chart replacements (see Is the Electronic Health Record Defunct?), not clinical productivity enhancers. Clinical productivity features, such as those listed below, are glommed onto the chart model.
- Preventive care management
- Access to clinical knowledge
- Results management
- e-Prospective memory and to-do lists
- Remote access to patient records
- Easy population reporting
- Collaboration tools
As things now stand, it is simply taken for granted that productivity will decrease with an EHR implementation. Is this necessarily so, or is it the result of software that is designed primarily as a chart being bludgeoned into providing productivity features? Obviously, if one is willing to adjust his/her work habits to whatever an EHR product requires, then life will be easier than if one does not. But, why require wrenching adjustments as a matter of course?
Small practices are the perfect proving ground for clinical care software products that emphasize provider productivity, ease-of-use, and ease-of-implementation. Recent articles that focus on primary care-friendly EHR features, such as Electronic Health Records: Design, Implementation, and Policy for Higher-Value Primary Care and Electronic Health Record Functionality Needed to Better Support Primary, provide design hints that can be used to model the next generation of clinical care software. An easy-to-use, configure, and implement clinical care system with user adjustable workflows—for products fitting this description, the market is wide-open. And that’s what I call an opportunity…
