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.
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.
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.
Comments