Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Usability Principles for Health IT Tools

Posted on October 22, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

A recent article of mine celebrated a clever educational service offered on the Web by the US Department of Health and Human Services. I ended with a list of three lessons for the health care field regarding usability of health IT Tools, which deserve further explanation.

Respecting contemporary Web practices

Communications can be improved by using the advanced features provided by the Web and mobile devices. In the HHS case, developers went to great lengths to provide a comfortable, pleasant experience to anyone who viewed their content, even if the viewers were visiting a different web site and the HHS content was merely embedded there.

This commitment to modern expectations is rare in the health care field. Web sites and electronic records are famously stuck in the 1990s. Doctors have been warned that they can’t use unencrypted email or text messages to communicate sensitive information to patients, so they use patient portals that are self-contained and hard to access. The tools on my family practice’s portal, provided by eClinicalWorks, don’t even come up to the standards of email systems developed in the 1980s. They lack such fundamental features as viewing messages by sender or viewing threads of multiple messages.

Worse happens if a clinician needs to perform complex tasks in an EHR or to work in multiple windows at once. There are whole areas of health IT (such as the notions of health information exchanges and patient portals) that reflect its primitiveness. Access to data should be fundamental to health IT products.

Why? EHR vendors are focused on HL7 standards, clinical decision support, and other nuts and bolts of data-crunching. They don’t possess the most advanced design and Web coding teams. Given their small market size–compared to social networks or e-commerce sites–one shouldn’t be surprised that health sites and EHRs don’t invest in cutting-edge Web technology. It’s no surprise, for instance, that when athenahealth (the most forward-looking proprietary EHR vendor, in my personal view) decided to reach out to the mobile world, they purchased an existing mobile app development company.

Another barrier may be the old software and hardware used at many health care sites, as described in item 6 of an Open mHealth round-up.

The problem is that health care applications and web sites need to make things easy for the user–at least as easy as retailers do. Both clinicians and patients tend to visit such sites when the are feeling pressured, tense, and depressed about what they’re dealing with. Mistakes have serious negative consequences. So interfaces should be as usable as possible. It also helps if their interactive elements behave like others that the users have encountered in other apps and web sites; hence the value of keeping up with current user interface practices.

Consider the people at the other end

I’ve already explained how the mood and mindset of the app user or web visitor has a critical effect on user interface design. Designers never know in advance–even when they think they do–what the users are asking for. And users vary widely as well. Therefore, sites must be prepared to evolve continuously with input and feedback from users. This requirement leads directly to the next suggestion.

Open source meets more needs

Most health care developers (and app buyers) assume that software must be kept closed to establish viable businesses. In other industries, large institutions are thriving on Linux, open source Java technologies, free databases such as MySQL and various NoSQL options, and endless free libraries for software development. Yet proprietary software still rules in electronic health records, medical devices, consumer products, and mobile apps.

Releasing source code in the open seems counter-intuitive, but it can lead to greater business success by promoting a richer ecosystem of tools. The vendors of health apps and software still haven’t realized–or at least, haven’t really pursued to its logical conclusion–the truth that health prospers only when many different parts of the health care system work together. Under the shepherdship of the Department of Health and Human Services, doctors are groping their way toward working with other doctors, with nursing homes and rehab facilities, with behavioral health clinics, and with patients themselves. Technology has to keep up, and that means eliminating barriers to interoperability.

APIs are a fine way to allow data sharing, but they don’t open up the tools behind the APIs. Creating a computing environment for health that ties together different systems requires free and open source software. It enables deep hooks between different parts of the system. Open source EHRs, open source device software, and open source research tools can be integrated to make larger systems that offer opportunities to all players.

Platforms for innovation

Instead of picking off bits of the existing health care infrastructure to serve, developers and vendors should be making platforms with vast new horizons and new opportunities for business. Platforms that encourage outsiders to build new functions are the concept that ties together the three observations in this article. These platforms can be presented to users in different ways by leading Web developers, can incorporate enhancements suggested by users, and can rely on open source to make adaptation easy.

Two platforms I have discussed in previous articles include SMART and Shimmer. SMART is an API that provides a standard to app developers working with patient data. Shimmer is a new tool for processing data from fitness devices. Each is starting to make a mark in the health care field, and illustrate what the field can achieve when parties work together and share results.

Lousy EMR User Interfaces Aren’t Getting Enough Attention

Posted on May 13, 2011 I Written By

Katherine Rourke is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Though EMR vendors might argue the point, I keep hearing the same complaints from the field — that virtually none of them offer an intuitive user interface.

Readers of this blog are well aware of this issue, I’m sure, but I’d argue that it’s still worth discussing. After all, few if any EMR firms seem to have solved the problem. (If you know of an EMR you consider intuitive to use, please let me know and I’ll discuss it in a future article.)

Given the incredible problems clumsy UIs can create, I’m surprised pundits and consultants don’t speak out on the subject more often. My journalistic colleagues turn out story after story about wayward doctors who won’t use their institution’s EMR, but few dig into what’s wrong with the EMRs themselves.

Far too many EMR front-ends feel like jury-rigged database interfaces, rather than systems designed to support clinician workflow.  If I had to get my work done using counterintuitive forms, menus and checklists, I think I might leave journalism!

Unfortunately, the decision-makers who buy big EMR systems — you know, the ones who spend hundreds of millions over several years — don’t seem to be very concerned about this issue.  I assume it’s because they’re more worried about systems integration than user satisfaction, and hope they can force kludgy interfaces down clinicians’ throats. Under these circumstances, vendors don’t have a lot of incentive to change.

So, is there a way to change this dynamic? A couple of interesting, though unlikely, possibilities come to mind:

* I may have said this before, but isn’t it about time someone got Apple to design an EMR interface? I know the company has some serious detractors, but even if you don’t buy into the Apple legend  it hard to argue that it’s created some of the most usable interfaces on earth.

* Why not to develop a standard for measuring EMR usability, one which is publicly shared and built by consensus? I’m not saying it would be easy to develop such measures — in fact, I’m sure it would be very complicated — but if we could establish a few user experience benchmarks, it would be very helpful.

The bottom line, though, is that vendors do what the market demands.  Until providers dig their heels in and refuse to buy clumsily-designed systems, nothing’s really going to change.  Maybe CIOs will get more demanding when users stage a revolt and refuse to touch their painfully awkward EMR?