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.