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 even when they have the best healthcare app ideas.
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 healthcare apps, 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 even with great medical app ideas. 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.
Another recent study (2020) looks at the clinical value of mHealth for patients. It concludes that while healthcare apps “have the potential to hold value for patients when used as part of a clinical workflow, the level of evidence is currently only sufficient to support the use of apps in a small number of defined clinical scenarios.”
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 I and fellow healthcare app 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.
Related Post: The Ultimate Guide to Building The Best mHealth Apps
And it wasn’t as if the 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 health 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 workday (with nurses using 3.2). Who wouldn’t be technologically exhausted by the idea of trying to onboard yet another health app idea?
There are also many cases when mhealth apps fall short of their promises. For instance, 2020 research into consumer-facing mhealth apps revealed that the majority of diabetes self-management apps fail to provide patients with info on the threat of hypoglycemia or hyperglycemia, putting them at risk of serious health issues, including death.
If you’ve experienced your own frustrations with healthcare app 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 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 millennials, 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 was 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 was 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 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 and 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 e-commerce store or social media aggregator (I should know, I’ve built those too). And they will respond to healthcare mobile app (ideas) 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. At that moment, you’re sure whoever created the packaging wasn’t thinking of you.
It’s the same when developing healthcare apps.
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 healthcare software ideas 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 and innovative healthcare 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 is more than just good customer service. Clients arrive at 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 a strategy that you build before ever stepping foot through the automatic doors of an emergency room or medical lab. It involves thinking about 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.
Related Article: SMART on FHIR Guide
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.
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 with their medical software ideas 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 (Google Fit) and Apple (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 to make mobile health app ideas come true. 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.
Check out this controversial digital health hype cycle put together by Lloyd Price. It’s pretty close to our expectation with telemedicine, symptom checking, remote monitoring & testing, and online triage solutions being ripe for impactful implementation.
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, and believes in your ideas for health apps. Team up with us, and we’ll bring our battle-worn healthcare expertise to deliver a mHealth application that can truly benefit everyone.
Challenges that Healthcare Apps Can Solve
Let’s look at some of the challenges that mhealth apps can solve given today’s state of mobile healthcare technologies.
Remote patient care & self-health monitoring
The primary role of the majority of mhealth apps is to enable remote patient monitoring and encourage self-health control among patients. Indeed, it’s hard to overestimate the strain that such mobile healthcare solutions remove from all patients and doctors.
Video calls and text chats available in telehealth apps render physical visits to a hospital unnecessary and save time for medical personnel.
One of the remote patient monitoring apps we developed was Smart Symptom Tracker for TMJ & Sleep Therapy Centre Of San Francisco. The app helps clinic patients to record and track their progress, refill prescriptions, message their doctors, keep diaries during treatment, and visualize their health.
Also read our guide on Remote Patient Monitoring App Development
Healthcare data aggregation
With all the new medical devices and fitness trackers appearing on the market, healthcare apps are quickly becoming micro hubs for collecting all sorts of user vitals: From the heart rate to oxygen level to calories burnt to ECG readings, etc.
Related article: How to Develop a Fitness Tracker App
Like many other mhealth developers, we rely on GoogleFit, HealthKit, or Samsung Health to access this user data, and then apply our UX/UI know-how to make it work for caregivers and users in the most efficient way.
The iFaint app we did for the Stanford University School of Medicine is a perfect example of a mhealth app that gathers patient data (heart rate and fainting spells) and provides feedback to participants of the iFaint medical study.
Promotion of healthy lifestyle behavior and support for health services
There’s a lot of mhealth research that proves that mobile healthcare solutions can play a significant role in promoting a healthy lifestyle. This type of apps focuses on dietary recommendations, similar to the Kitchen Wizard app we built, or help users remain active by doing physical exercises. Users with chronic medical conditions use such healthcare apps to track progress on health-related goals and support other types of health-promoting behaviors.
Actionable insights from AI-processed medical data
Once patient data has been accumulated, it’s then up to us, healthcare app developers, to process this data and turn it into something actionable. At my company, I’ve found that we tend to ship the most high-performing apps when employing AI and ML algorithms for munching through gathered healthcare data. This practice helps us turn data points into actionable advice.
An exciting project that comes to mind when I think about the healthcare applications that required our AI & ML expertise is an app for Athcorp. We developed an AI-assisted mental health chatbot for their well-being self-management and reporting tool. The chatbot helps users manage their mental health with content recommendations and learns from their inputs.
Patient- and doctor-centered approach
Of course, healthcare mobile applications put the patient or doctor, depending on their target audience, front and center. And it goes beyond adding accessibility options or voice-enabled interfaces. Both patients and doctors expect unparalleled ease of use from modern mhealth solutions so that they can solve their tasks in a couple of minutes max.
On-demand healthcare apps
Uberization has not left healthcare untouched. There pop up more and more projects that aim at connecting nursing and other medical personnel with clinics. In fact, we are working on a similar on-demand healthcare app that will enable hospitals to hire temp medical staff.
For nurses and other medical workers, the app offers a job marketplace where they get to choose jobs based on their availability and other preferences.
Optimization of medical workflows
Whether it’s a mobile solution that helps clinical trial managers to capture and analyze data for their medical studies or a web app that streamlines order management of medical supply — healthcare apps can certainly boost efficiency in a medical workspace.
This optimization, of course, goes well beyond a HIPAA compliant CRM because of healthcare-specific workflows, and a mhealth app in this context is a perfect tool for addressing the unique needs of medical personnel.
If you’ve had to deal with a healthcare app that you know must be working differently to enable you to serve your patients better, or want to discuss your mobile app ideas for healthcare, then you know what to do. Get in touch today, and we’ll help you build the healthcare app that will work the way you want.
- How to Build a Doctor’s Appointment Application
- How to Create a Telehealth Application
- Healthcare Mobile App Design Guide
- How to Start a Healthcare Startup
- How to Make a Pharmacy Application
- HIPAA Compliant App Development Guide
- How to Develop an EHR/EMR System
- Mental Health App Development Guide
[This blog was originally published 4/7/2019 and has been updated for more recent content]