Beneath the facade of high digital healthcare adoption rates in the U.S. lies a troubling reality: mHealth application developers are making headlines, but they aren’t making much headway.
As a long-time mHealth app developer myself, I have certainly encountered more than one physician or clinician with a horror story of their own. One minute they’re getting the go-ahead to invest in mobile, and the next, they’re dealing with a frustratingly time-consuming mobile “solution” that fails to expedite tried and true medical practice.
Unlike other mobile development arenas however, this conflict has immediate and devastating side effects. It eats up the precious time that physicians have for responding to patients–and in medicine, a second can mean a life.
Of course, that’s just the average medical office or lab–imagine what would happen if a major company’s supercomputer started giving people incorrect cancer treatment and advice?
There’s something really wrong here.
One study from 2017 offers further confirmation of how modern mobile healthcare solutions have been limited in their ability to address the real problems that patients and doctors face every day. While the tested healthcare apps in this study were created with the best of intentions, ultimately they failed to meet the needs, interests, or resources of their end-user respondents.
So, what the heck is going on?
In 2014, I led the development of a health-tracking platform for patients with autoimmune conditions. My team and I would centralize corresponding patient data and connect existing patients with each other, as well as with proper care.
Sounds great, right?
Wrong. During this two-year journey, I found out first-hand why mHealth applications like mine weren’t changing the face of healthcare in the way me and fellow developers had predicted they would. Our ability to make machine learning actionable during treatment was hampered by firewalled gardens such as Epic EHR. Gathering data was the easy part, it was compliance, fragmentation, and the general nightmare of responding to data interoperability issues that had everyone jumping through hoops. To put it bluntly, it was like watching the blind leading the blind. Doctors, patients, entrepreneurs–each stakeholder would at best have only a partial understanding of the whole picture.
And it wasn’t as if technology was behind. With annual trade shows like CES featuring advanced wearable tech, genetic testing solutions, EHR’s, along with other tracking apps like ours, there was no shortage of digital health innovation. Nevertheless, these technologies weren’t finding a permanent home in hospitals, research facilities, or (most importantly) the hands of doctors and patients.
In short, from a lack of integration to patient abandonment, these mHealth applications were rarely around long enough for the utility of the gathered data to be maximized.
The trend is bigger than just my own experience. In the very worst cases, mobile healthcare applications even expedite existing inefficiency issues, with a recent report concluding that clinicians are sometimes using up to 4.1 work-related mobile apps on a regular work day (with nurses using 3.2). Who wouldn’t be technologically exhausted by the idea of trying to onboard yet another mobile app solution?
If you’ve experienced your own frustrations with mHealth application developers, I can at least vouch for my industry partners in saying that some of the barriers to great mHealth development are much bigger than anyone outside of the industry can really see. From legislation that mandates FDA approval, to a lack of local funding (often because investors purposefully avoid products that require legislative checks), some mHealth development projects are finished long before they’ve even had a chance to take off. Throw in an aging population of both patients and physicians who are less likely to want to adopt mHealth technologies than millenials, and you’re in for a whole host of trouble.
Even today I find it remarkable that for all the advanced machine learning my team and I were able to provide with that big mHealth project in 2014, patients were still bringing printed excel versions of their app data to their doctors.
Still, what kind of app developer can’t handle a little critical feedback?
Suppose my career were in the prototype stage for mHealth success, then I needed to learn from my failures and immerse myself fearlessly within the patient organizations, hospitals, and physicians offices I intended to serve.
So I did.
With renewed motivation, I continued working with healthcare innovators and listening to healthcare professionals at all levels and specializations during the course of countless mHealth development projects. Surprisingly, they all had the same thing to say, and it had nothing to do with code:
Think Like a Doctor; Think Like a Patient.
That’s right. The secret is empathy. From listening to medical providers at all levels, I learned first-hand the lengths to which these people will go for their patients. At the same time, I learned the dedication with which these patients will respond to the advice their doctors give them. Both parties are willing to commit extra time to patient well-being, which sets them apart from the quick instant-gratification motives that come with building an ecommerce store or social media aggregator (I should know, I’ve built those too). And they will respond to mHealth apps that are made with a consciousness of how it might feel to use an app when you’re sick, or when you’re trying to help someone who is.
I mean, we’ve all been there, struggling to pierce the foil of a Nyquil tablet-pack, too weak to even get out of bed let alone find the strength to stab through that impossible triple-proof aluminum. In that moment you’re sure whoever created the packaging wasn’t thinking of you.
It’s no different with mHealth application development.
Developers have to remember that their audience either is, or is working alongside a very vulnerable population–a population in need of simplicity, accessibility, and compliance. Adding more barriers to the pile will only result in failure. And in the world of mobile health, adding more barriers is like building a wall where one already stands.
What I’m trying to say is this: when mHealth app developers begin to see the bigger picture–when they realize the solutions that they are building today could literally change the way people help other people–they are more likely to develop mobile responses that meet the specific expectations of clinicians, physicians, and other specialists. And in a market saturated by mHealth apps that try to do too much without enough follow-through, this increased focus can help newer apps stand out from the rest.
Keeping with this strategy, we created our four-step checklist to building mHealth applications that actually respond to end-user needs:
- Dedication to Simple User Experience
Why roadmap four activities (screens that users click through) when you can roadmap three? Why not make bigger buttons so your visually-impaired users can see them better? These are just some of the questions I find myself asking to make sure I’ve given enough thought to creating the simplest user experience possible. Confusion and inefficiency are the main reasons some applications experience high drop-off rates as early on as the prototyping phase, and the only way to change that is to offer both parties a tool that is simple and straightforward. In other words, medical practitioners don’t have the time to give their patients a technology lesson as well as a treatment-based one–if they can’t explain how to use the app in five minutes or less, what can I do as an app developer to change that?
- Empathetic Engagement
Empathetic engagement is more than just good customer service. Sometimes clients arrive to our doorstep thinking they need an app that does one thing, only to realize they really need an app that does another. Empathetic engagement is thus a strategy that you build before ever stepping foot through the automatic doors of an emergency room or medical lab. It involves thinking about the people who will actually be using your app, taking the time to put yourself in their shoes during every phase, and arriving at your road-mapping meeting with a strategy in mind of how you want to accomplish that. Keep in mind that you want to take as little time from practicing physicians as possible, but that their input is nonetheless critical from development to design, and most especially during testing. In my experience, the practice of building an empathetic engagement strategy ends promoting trust and produces all-out better applications.
When we are invited into a workspace to create something that’s going to change how people work, it’s important to contextualize ourselves within the existing digital environment of the arena we are about to enter, regardless of scope. This is not only beneficial for practical reasons (the increased efficacy of the app), but also helps simplify the eventual adoption of the mobile app for those “on duty”.For instance, new developments in port technologies are helping mHealth apps work from existing wifi networks, and new FHIR standards are based on more modern web technologies, making it much easier and faster for mobile developers to implement solutions that talk to existing EHR data. By finding solutions that meet the sustainability and cost-savings needs of mHealth providers, app developers can alleviate one of the biggest fears that practitioners experience when looking at on-boarding a new mHealth solutions–that they are going to have to change the way they do everything to accommodate for the new application.
- Foolproof Quality Assurance and Compliance Strategies
Doctors take the hippocratic oath, so why can’t app developers make the same promise to protect lives? That’s why I make sure that every mHealth application that we build complies with security and privacy legislation, despite the additional burden it puts on our shoulders. We implement a unique quality assurance process specifically tailored to test against data protection and system security for healthcare applications, and we make sure to maintain an atlas of digital healthcare technologies already dominating the space. That way, no matter the platform requirements, we can respond with regulation-approved mobile solutions to critical healthcare gaps on the ground.
- Dedication to Simple User Experience
Great healthcare solutions are born when mHealth app developers step into the shoes of the physicians and clinicians they are trying to help.
And the opposite is true as well: healthcare professionals looking to make a difference should actively seek out mHealth app developers who already understand where they are coming from. Only then can we perhaps mend the rift between technological adoption and technological solutions, pushing the two separate worlds of healthcare and technology into one.
There’s no better time than now.
In 2019, the impacts that healthcare developers and healthcare professionals have had on mobile healthcare development are creating positive feedback loops that have recently begun to manifest in the form of new pathways to FDA approval for medical apps, and larger amounts of funding for outcomes-focused technology (we created one of them). Even big players like Google and Healthkit are integrating their existing tech to make it easier for mobile developers to pull in real-time biometric data for almost immediate physician review. With hospitals starting to reimburse on outcomes and not on visits, and medicare even reimbursing for telehealth consults, physicians are more intrinsically motivated to integrate new mHealth applications.
Are you one of those physicians?
Whether your concerns relate to privacy, accessibility, or data management, it’s always good to team up with someone who knows where you’re at, and who sees where you want to go. Team up with us, and we’ll bring our battle-worn healthcare expertise to deliver an mHealth application that can truly benefit everyone.