By Larry Ozeran MD, President, Clinical Informatics Inc.
HIMSS core objective as an organization is to improve healthcare quality and patient safety through the best use of IT and management systems. As hospitals and providers work to implement electronic health records and other IT and management systems, HIMSS is launching a blog series on health IT and patient safety to help providers and hospitals identify potential risks to patient safety that have resulted from problems with EHR implementations and mitigate those risks through proactive measures.
If you are a software vendor, how actively do you listen to your users?
Your options might include:
- Hire actively practicing clinicians onto your development team for every clinical domain that your software serves.
- Hold focus groups and use testers who are actively practicing clinicians in all of your clinical areas to evaluate every product before release.
- Preview your products with your user groups long before release.
- Support user groups that meet periodically in person and continuously virtually so that critical issues reach you soon after their clinical recognition.
- Actively request input from all of your users and make it easy for them to reach you by phone, fax, online form, online chat, social media, or text. This might include holding contests to find the most concerning software bug.
The focus of user discussions should be to find what is universally broken and what may be minimally altered to permit local options. Software updates should be prioritized by the likelihood that new features enhance patient safety or bug fixes resolve a patient safety problem. Only then should you consider the other prioritizing factors (like cost, revenue, resources, and personnel).
Vendors that passively wait, make communication with users difficult for users, pay little attention to user input when they do connect, or a combination of the three, can anticipate negative impacts to their EHR/health IT patient safety record.
What is the risk of a logic error? We have a recent example of an health IT product that asks for neonatal weights in pounds, but internally converts them to kilograms when calculating medication dosing (recommending 2.2 times the appropriate dose). Newborn children might have died needlessly. A direct and intensive user engagement process could have addressed such a danger before risking patient safety.
What is the risk of a product that has an inconsistent user interface? Clinicians expect consistency to support their daily routines. When red stops meaning important and starts meaning danger, avoidable user errors tend to occur. Similar errors occur when fonts, screen location, and even product terminology change or are different in different modules. The easiest way to avoid these errors is to maintain consistency in the user interface. Any of the bulleted options listed above, implemented consistently, will support early recognition of preventable problems. How early and at what expense depend upon which of the options you select.
While it may not be true that the customer is always right, it is true that the end user tends to know more about their work environment than the developers do, even when the developers are clinicians. Clinicians do not work in identical environments, so there may be assumptions made by the developers based on their clinical experiences that are simply wrong in some environments. Seek early and then continuous feedback from clinicians in different specialties, in different sizes of institutions, and in different geographic regions.
At the same time, you will not be able do what all of your customers want. Trying to be all things to all customers means satisfying few to none of them. Making compromises to try to satisfy everyone would ultimately satisfy no one. If you can address this issue with configurable options, then by all means do so, but only in the context of continuing to get user feedback.