The days of one-and-done annual checkups, unassisted surgeries, and faxed health records are all but over.
Despite misconceptions that patients don't want technology involved in their healthcare, data from McKinsey & Company suggests that 75 percent of them would like to use digital health services. The success of sites such as
Still, some healthcare companies are deterred by the idea that digital health tools require complex, expensive features. In truth, patients have much more modest expectations. According to the aforementioned McKinsey research, their priorities center around easy access to information, more efficient processes, and the option to get in touch with a human if the digital solution isn't doing the job.
Maladies of Digital Health Product Development
Remember, though, that healthcare technologies require smart, secure design and development. If a retail technology malfunctions, somebody might have to go talk to the manager; if a healthcare technology does, somebody's life could be on the line.
So be sure to avoid the following 8 mistakes when developing your digital health technology:
1. Breaking ground before prototyping
Ironically, when companies skip the prototyping phase, it's usually because they're trying to save money. In fact, the cost of poor design, time spent on unnecessary features, and a lack of user research can far exceed prototyping expenses.
"The first company to come out with the right product at the right price wins it all," Chueyee Moua, an R&D engineer at Catheter & Medical Design Inc., points out. "Therefore, prototyping is the most important step ... during the design phase to identify any needed changes and make quick decisions."
2. Skipping user testing
Guessing at what users want is the surest way to develop an irrelevant product. When a startup designed a high-tech product to detect a rare childhood illness, it waited until it had a rudimentary prototype before talking with doctors. When it finally did, doctors told the company that they'd rather use an X-ray because it's widely available, inexpensive, and covered by insurance.
Make user testing less painful with empathy mapping, a technique Yeti uses to get inside the head of a product's users. Of course, we also check in with users after building each feature to make sure we're on the right track.
3. Using the waterfall method
Use agile to develop products faster, at a lower cost, and with less risk of creating
4. Prioritizing unnecessary features
If you suffer serious burns, would you want doctors to first treat your face or your finger? That might sound like a silly question, but we see technology creators get distracted from the core functionality all the time. Additional features are called that for a reason.
Shoot first for a minimum lovable product. In short, you're trying to satisfy your users' core needs before giving them the bells and whistles that they might also want. After watching how the product performs in the market, you can add
5. Short-changing back-end development
Healthcare products need a nice interface, but that doesn't matter if the product can't keep data secure. Security, user authentication, logging, validation, and transaction support are all important for HIPAA compliance and users' peace of mind.
If you're struggling to build these on time, try a backend-as-a-service (BaaS) solution. Outsourcing development of core features can save up to 50 percent of the time and money required to develop a digital health application.
6. Utilizing technology that's too old or too new
There's a Goldilocks period in every technology's life cycle: It isn't so new that its bugs haven't been worked out, but it's still new enough to play well with other contemporary technologies. Plus, patients understandably want their healthcare technologies to be cutting-edge.
When Office Practicum built an IoT solution to help nurses transfer data efficiently and securely, it attached an RFID tag to an iPad, which could then communicate with medical devices equipped with an NFC sensor and microcomputer. It's a tech-forward solution, but it's not so new that it's untested or cost-prohibitive.
7. Ignoring technical debt
Technical debt describes redundant or unnecessary code or features in a technology product. As it builds up, applications tend to become slower, act up more frequently, and take longer to troubleshoot.
Technical debt can become a chronic problem. Back in the '90s, the Cleveland Clinic adopted an Epic electronic health record system. Today, the EHR is integral to its practice, but it's also riddled with technical debt.
Associate CIO William Morris calls it the innovator's paradox. "You want to be innovating, but you also want to be retiring legacy when it gets folded back into your core solutions so you can continue to innovate."
8. Skipping the stress test
Remember the launch of Healthcare.gov? In the first two hours of launch, the site received five times the expected traffic of 50,000 users, causing it to crash. Dropdown menus were also incomplete, and the login page — shared by users and the development team — could handle even less traffic than the main site. Just six users were able to complete applications and choose health insurance plans on day one.
Here at Yeti, we're no strangers to serious server demand. A year or so ago, we launched comedian Chelsea Handler's “Gotta Go!” app. It gained immediate traction, threatening to overwhelm our servers, but we stepped in quickly thanks to a suite of monitoring tools.
The digitization of healthcare is already happening. From the doctor's office to the operating table, virtually every medical situation and surgery will soon be aided by digital tools.
Get your digital healthcare product in the game sooner rather than later with Yeti's free whitepaper, "10 Steps to Prototyping Better Healthcare Solutions."
For an even bigger boost, contact us for a free design, development, or product strategy consultation.
Dean Mercado is a Developer at Yeti. Dean is a developer at Yeti, and more importantly the owner of Yeti's office dog, Ben (benjipoops.com). His interests include baking bread, long distance running, and two other activities that cancel each other out. When he's not developing apps, he's drawing diagrams on his desk and drinking tea.