"The World Don't Move to the Beat of Just One Drum -
What Might Be Right for You, May Not Be Right for Some."
- Diff'rent Strokes Theme Song*
Some enthusiasts of the free market believe that a type of 'capital darwinism' exists where the best products - those that most serve the needs of its clients in the best way possible - survive and thrive based on support of the consumers. Meanwhile the inferior offerings are shunned by the majority of the marketplace and eventually fall away, allowing only best of breed to continue into the future. (There are many reasons why this isn't exactly accurate, not the least involving government subsidies, marketing budgets, and other various advantages that favor larger organizations over small ones, but for now we'll run with the premise). Recently those who believe in the economic survival of the fittest argued that the government mandate for EHR adoption has distorted that 'natural' process - because healthcare providers are forced to adopt something that may not be totally what they want just to fulfill a requirement. Therefore, the argument goes, it's not the best solutions that are going to survive and continue into future generations but the best of limited choices that facilities have to choose from, rather than choosing none of them and forcing the market to come up with better alternatives. Outgoing head of Office of National Coordinator for Health IT (ONC), Jacob Reider MD, responded to this criticism in an excellent post, as well as addressing the broader question of unique aspects of usability in health IT.
In the post, Reider lists multiple reasons why health IT is different than most other technology offerings - certainly from the type individual consumers experience. The first differentiator is that
The user isn’t always the buyer. This causes usability to be a less significant component of buying decisions.
In many facilities, decisions to purchase a particular bit of health IT is certainly informed by physicians (and other users), but it is ultimately up to administrators who have to weigh the costs, time, and effort it would take to adopt this new solution. Depending on the size of the organization, not every physician will be consulted on what s/he thinks about the usability of the solution. (Although, in some cases, there is a direct relationship and overlap between users and admins, particularly in the ambulatory surgery center (ASC) marketplace where surgeons are also owners and/or stakeholders of the facility.) At mTuitive, we've had to ensure that our synoptic reporting solutions not only conform to and improve on physicians' workflows but also make sense to administration by being financially competitive while not demanding too much of resources. It's a difficult tightrope to walk and it requires careful navigation in order to make sure that neither side is lost while developing or launching products.
Of course, our synoptic report solutions are for specific audiences (pathologists, surgeons, triage workers, radiologists, etc.) - EHRs are meant to be used by everyone at a given facility. That's a lot more users to consult and a lot more workflows to try to mimic while still offering competitive economic advantanges. And what is the majority vote? If you're part of the administration and surgeons and nurses like the EHR, but internists and lab techs don't based on their unique needs, how do you decide? It's not an easy balance to strike and it can lead to users feeling frustrated by what was 'forced' upon them. The selected solution may not seem usable to a group of users while incredibly intuitive to other groups.
Another reason, Reider stipulates, that usability is different in health IT than other business is:
Multi-year contracts and technical “lock-in” cause portability to be a true challenge. One can’t just walk away from an EHR that’s not performing as expected. Buying an EHR is more like buying an airplane than a clock radio.
While I'm not sure how exclusive this is to health IT (think about your draconian cell phone contracts, or any office wide system that must cater to multiple users), it is still a factor in inhibiting change. Most workers have experienced the multiple weeks or months of implementation of any new IT solution at their facilities; the training sessions and interface testing and lord knows what else. Because of this hassle, it behooves sites to make sure that the solution will be there for a long time - also because it means an investment at both sides and allows for a few years of stability without constant changes that everyone has to memorize. But the downside of this multiyear committment is that it makes it harder for dissatisfied users to leave their EHR, at least not without both an alternative in place and not without ensuring that all of the (highly sensitive) data has been taken out of the old one.
Reider next points out the complexity of health IT solutions as another impediment to churning out improvements:
Legacy software in a high-risk environment will evolve slowly – for good reason. One can’t change workflow or user experience too quickly, as changes in the user interface can increase error rates even if the new design is better for new users. Errors can harm or kill people. Developers need to evolve user experience slowly and carefully. Usability won’t improve overnight.
EHRs are still relatively new entities in facilities. With changes in workflows, hardware capabilities and desired outcomes of users, it's still early yet to figure out the best way for users to interact with these solutions. Would speech work better on this screen than keyboard and mouse? What permissions should be granted to what type of user? Etc. There's a lot to cosnider in this nascent field and it's still being figured out before companies can release the next batch of improvements. But, while this is true especially in health system-wide applications like EHR, I feel like the healthcare community should continue to demand more improvements from health IT developers. Obviously there are multiple reasons for delays in publishing newer iterations - those mentioned above and even more - however there are still user interfaces that wouldn't look out of place in Windows 95 or don't seem to even know that the Internet is a thing that exists. Users should demand for more improvements and a more aggressive release schedule - but again that tightrope act is releasing helpful changes that don't overwhelm the users or jeopardize the lives of patients.
Lastly, Reider points out that due to all of the various parts of a healthcare system, it's hard to determine where the fault lies for problematic usability:
Health IT systems are complex and require local configuration. Inadequate local resources can cause well-designed products to offer terrible user experiences. To the end-user, they have no way of knowing who is responsible – the IT department or the software developer? Was it Boeing or United Airlines who made these seats so uncomfortable?
mTuitive's synoptic reporting solutions usually have to 'plug in' to other systems at a hospital - be it an EHR, a laboratory information system (LIS), a scheduler, whatever. As discussed here in a previous post ('The Costs of Interfacing'), we might have to make changes when working with these other vendors. Now our output report might look a little different, or the way users access or log in to our solution is not what we envisioned, or what have you. By having all of these disparate parts working together, it can be hard to figure out from whence the problems are arising. Is this program logging me out because it's poorly designed or because it's a HIPAA regulation? Are these PDFs ugly because the developers don't understand aesthetics or because it had to go through three other programs that all reformatted it before ending up in the patient's folder? While Reider doesn't offer up any real solutions to this one, it seems the more standards that are published and adopted (CCDA/HL7, specifying requirements of forms/documentation), the less excuses can be offered up by Health IT companies for not conforming to them and causing issues.
Health IT is a unique marketplace: covering a broad spectrum of types of users, in various settings using all sorts of devices, that need to conform to constantly changing rules and requirements, all while having a direct impact on the life and death of patients. That's a lot of variables at work under the possibility of the grimmest of outcomes - if a game app is harder to use on an Android phone vs. iPhone, people won't die en masse. But the fact remains that usability isn't as cut and dry a market force in healthcare as it is in other places. Some of it has to do with incentives of the developers - appeasing the Board while not outright angering the users, and being locked in for many years without needing to release improvements - some has to do with the burdens of interfacing perverting what developers originally intend, and some has to do with the rapidly changing requirements of delivering healthcare and the tools we use to do so. While research is released at a blistering speed, and new methods are developed, or new pieces of hardware are unveiled, health IT remains the slowest of the bunch - because it has to incorporate all of those in its performance.
The most important aspect of this is that developers must listen to their users - even if there are mitigating factors that hamper their releases. They have to know the workflow demands and priorities of all of their users. mTuitive looks at everyone who will interact with either the synoptic reporting solution or make use of the structured data we capture. We figure out methods to make sure they can access it in ways that are as easy and intuitive as possible. In return, users should have some patience - not with broken software or janky solutions, but with explaining what they need and what they want from their solutions. If developers are willing to listen, and users are willing to explain, then some semblance of understanding can be reached.
*Written by Alan Thicke. No, seriously - Alan Thicke wrote the Diff'rent Strokes theme song.