We’ve written before about how fitness and healthcare apps are making people fitter, happier and more productive (in a cool way, not in the creepy way Thom Yorke implied in those Radiohead lyrics). In fact, we even put together a wishlist of fitness apps we’d like to see from visual designers, just in case you want to create your own mobile healthcare app but don’t know how to rise above the fray with a unique idea in what seems to be a market saturated with medical apps.
But as cool as healthcare apps are, designers and developers need to take care to make sure that their products aren’t just functional and beautiful, but also safe — and there are two separate, but important components to that safety. Creators of healthcare and medical apps must be careful not to endanger the life of the user with their apps’ functionality, and they must also ensure that user data is protected from data thieves and other privacy threats.
Fitbit and Heart Rate Monitoring: A Tale of Two Data Points
Nobody understands this double-edged sword better, perhaps, than Fitbit. On one hand (the one wearing the tracker itself?), Fitbit has actually saved a man’s life by providing critical data to emergency personnel at a hospital where he arrived following a seizure. By looking at his Fitbit data, medical providers were able to determine that cardioverting an atrial fibrillation would save his life rather than do the opposite, triggering a life-threatening stroke.
On the other hand, Fitbit also had to face a class-action lawsuit alleging that the heartrate data on its HR, Surge and Blaze trackers was dangerously inaccurate, underestimating heart rates in unsafe zones and lulling its users into a false sense of security as they exercised.
Designing Healthcare Apps With Safety and Security in Mind
Apps are the future of healthcare, but if you have a game-changing medical app idea, you need to take special care to protect the precious data your app will handle. Let’s take a look at what you need to know about designing healthcare apps, from accessible UI design to keeping hackers out of pacemakers and insulin pumps.
3 Things That Can Go Wrong With Healthcare Apps
At Proto.io, we love to encourage innovation, industry disruption and chasing wild dreams, so harshing a designer or developer’s mellow isn’t really our style. With that said, you can’t create an app that changes the world if the peculiar pitfalls of medical apps kill your creation before it even has a chance to get shut down by Apple’s byzantine approval process, or if your medical app literally kills its users.
That might sound dramatic, and it’s unlikely, but given how sophisticated healthcare apps are becoming, we are entering a new world of possibilities, both good and bad. For an example of how exciting today’s medical apps are, look at Dexcom, a continuous glucose monitor and adjacent smartphone app for people with diabetes. For those who are used to pricking their fingers with a dedicated device and reading one digital output at a time, the idea of tracking their glucose continuously on their phones, monitoring trends over time, is nothing short of game changing.
Of course, it’s also easy to see how technology like this could go wrong, with a mere sync error standing in between a user and possible diabetic coma. And while it may not be likely, the prospect that a hacker could tap into such an app is spine-tingling (but again, highly improbable, unless maybe you’re a high-profile politician in a dark cyberpunk novel).
Let’s take a look at four possible pitfalls of designing and developing healthcare apps, and how you can steel yourself against them:
Healthcare apps that don’t deliver as promised may hurt a user’s health.
Let’s revisit the Fitbit lawsuit, because it’s a good example of what can happen when the product you deliver as a designer or developer doesn’t match the expectations of the user, who (rightly or wrongly) is looking at your app or wearable as a mobile healthcare device.
When the lawsuit started making headlines in January of 2016, it couldn’t have been a more nail-biting time to be a Fitbit developer — or shareholder. Between the alleged heart rate inaccuracies and the lackluster response to the Fitbit Blaze smartwatch debut at CES, Fitbit stock dropped 18%.
Scarier than that dip, of course, was the prospect that the activity tracker could actually threaten a user’s safety. Imagine if you purchased a Fitbit HR as a gift for a loved one who wanted to become more active, and the next thing you know, you receive a phone call with the news that your loved one is in the hospital after suffering chest pains due to strenuous exercise. Would you blame yourself for putting so much faith in a device or medical app?
Thankfully, for both Fitbit as a company and its huge community of users, the claims made in the lawsuit likely weren’t telling the whole side of the story. Consumer Reports tested the Fitbit and determined that its heart rate monitoring technology, PurePulse, delivered as promised. Despite a rocky January, Fitbit managed to move a billion Blaze fitness watches within a month of the device’s availability and reclaim its position as the belle of the wearable ball for exercise enthusiasts and walkaholics.
While Fitbit came out on top in the end, the situation does present an important set of “What if?” questions. What if its PurePulse technology wasactually dangerous, or at least oversold? (The FDA shutdown of 23andMe, a genomic testing startup caught in hot water for being too fast and loose with its own marketing promises, is another good example. It took years for the company to bounce back.) What if healthcare apps drove their users to hospitals, or worse — to their deaths?
The Healthcare Apps Antidote: Plenty of Testing and Quality Assurance
Inadequate testing and QA can sink virtually any app, but spending plenty of time in the testing and QA phase of your process is of particular importance when you build healthcare apps. We imagine that Fitbit probably tested its PurePulse technology in a variety of conditions and against various industry-standard pulse measuring devices, over and over again, to ensure the technology’s accuracy.
Let’s say you’re making a very simple app for tracking calorie and macronutrient counts. Think of what can go wrong and how you can prevent it. For example, somebody on a carbohydrate-restricted diet might need very accurate sugar counts in order to avoid insulin spikes, so a glitch in the app that leads to an entry disappearing, or being inputted twice, could cause discomfort or even a minor health crisis in your user.
Practice inputting items into the app under various conditions, take copious logs and encourage ample feedback from your beta users. One way you can do this easily is by using a prototyping tool that allows for feedback and collaboration from multiple commenters.
As always, iterate, iterate, iterate until you have a more or less perfect final product.
Accessible UI design is important for every app, but it’s especially important for medical apps.
Let’s not mince words here: if you’re not building accessibility into each and every UI you design, you’re doing your users a disservice, you’re doing yourself a disservice and you’re doing the world of UI/UX at large a disservice. Accessibility is not an option — it is a requirement for each and every app. Your product will be used by people with various levels of visual acuity, hearing ability, intellectual ability, attention span, age, gender, size, physical ability and more, and you need to craft your user experience with this great diversity in mind. (Don’t know where to get started? Check out our beginner’s guide to accessible mobile UI design, and then learn how to design with audio).
As important as accessibility is to user interface design in general, it’s doubly imperative when you make healthcare apps. You need to consider that given the category you’ve chosen to develop for, many of your users may have health conditions that may or may not affect the way they use the technology.
For example, let’s say you’re building an app that helps people with chronic illnesses track their symptoms and triggers over time — we’re really excited about Flaredown, a crowdfunded app that promises to do just that. Some of the conditions Flaredown suggests using the app to manage are conditions that affect the user’s motor coordination, like multiple sclerosis, or that can cause brain fog, like fibromyalgia. Other conditions may cause pain or lack of mobility in the hands, like psoriasis, arthritis and Raynaud’s phenomenon. In addition, your users may treat their conditions with medications that affect their ability to use your app.
In every case, consider the limitations your users may have and build your app with that accessibility in mind. Even if you intend for your app to be used by healthcare professionals rather than their patients, remember that healthcare professionals are not immune from needing accommodations, themselves!
Healthcare apps may house personal health information (PHI) that needs to be protected under HIPAA
We could devote an entire series of posts to what mobile app designers and developers need to know about the Health Insurance Portability and Accountability Act, better known as HIPAA, but here we’ll cover the very basics: specifically, what the HIPAA Security Rule is, and what your app needs to do in order to comply with HIPAA.
The most important thing you’ll need to ask yourself when creating medical apps is: does HIPAA even apply to my app? The answer to that question hinges on whether your app will be used by, or to transmit data to, a “covered entity.” Covered entities are doctors, nurses, medical professionals, hospitals, dentists, insurance companies, healthcare clearinghouses and virtually any personnel or facility that professionally handles PHI (Protected Health Information). PHI can include everything from healthcare appointment dates to surgical histories to prescription medication information.
Basically, if you’re building apps to be used by doctors and other medical or insurance entities, you’ll need to make sure your app is compliant with the edicts of the HIPAA Security Rule, which establishes certain parameters to protect patient privacy. This includes certain security standards for the facilities housing the servers on which PHI data is stored, best practices for authentication and information access and when to use encryption to protect data. For a brief overview, see this article from InformationWeek: HIPAA Compliance: What Every Developer Should Know.
Even if you’re not developing apps to be used by a covered entity, chances are your users don’t want data like their weight, resting heart rate, diagnoses and prescription medications to sit unencrypted on an easy-to-hack-into server, or to otherwise be vulnerable to breaches from nefarious data thieves or even just confused onlookers — or whoever happens to pick up their iPhone. If you’re building healthcare apps, it never hurts to read up on best practices for HIPAA compliant mobile development and implement them on your own app. Strong encryption is always a great idea, as is multi-factor authentication (requiring the user to combine two methods for access, like a password and a thumbprint or voice recognition).
Prototyping Healthcare and Medical Apps
While some of the hypothetical pitfalls of developing medical and healthcare apps may seem daunting, don’t let them scare you off: mobile healthcare development is a burgeoning field that is changing the way people interact with themselves and their health data, and designers like you can make a huge difference in the life of a patient.
If you have a brilliant idea to help people live healthier, more fulfilling lives, get prototyping! With Proto.io, you can quickly create lifelike digital prototypes of your healthcare apps, complete with interactions, animations, sound design and everything else you need for a truly accessible, usable experience. Plus, you can prototype for wearables like Apple Watch or Android Wear with ready-to-use UI libraries, if you want to take advantage of the fitness tracking capabilities of each OS.
[Proto.io is a mobile app prototyping tool used by entrepreneurs and startups to create fully-interactive realistic prototypes that look and feel like real apps.]
