CAN WE BUILD MHEALTH APPS IN DAYS? ABSOLUTELY... THE NEED FOR MHEALTH-AS-A-SERVICE
The mobile health (mHealth) market is massive by any measure. Research & Markets, Inc. estimate mHealth annual revenues of $13B. They forecast a 9-fold increase over the next 10 years to ~$110B.[i] Some are estimates are even more optimistic.[ii] Per PwC, the largest mHealth segments are: supporting independent aging (46% of the market), chronic patient monitoring (19%), diagnosis support (15%), treatment support (10%), and health practitioner support (5%).[iii] Multiple factors fuel this mHealth market. mHealth increases competitiveness, supports new care models, and creates operational efficiencies. All healthcare enterprises-- including providers, payers, and life sciences companies-- need to harness these gains to remain viable. Tactically, such mHealth growth means there are many apps to be built, and lots of code to be written.
Unfortunately building and deploying apps is expensive. A Clutch.co survey of mobile application developers found the cost to build a generic new mobile app ranges from $38,000 to $171,000.[iv] This range includes using some lower-cost Indian or Eastern European developers. mHealth apps can be even more expensive. In fact, some mHealth apps cost several hundred thousand dollars to build.[v] This high cost is not surprising. mHealth apps, at least those that have patient information in them, typically need to:
- Capture and manage complex data sets;
- Support a diverse user types;
- Drive multiple workflows;
- Comply with various security and other regulations;
- Adhere to multiple data standards;
- Organize ever changing embedded content and business logic; and,
- Maintain high accuracy and availability.
Outside healthcare, enterprises have dramatically simplified their application deployment using Platform-as-a-Service (PaaS) providers. Consider the following example. Historically when an organization wanted to deploy a new web or mobile application they would purchase servers and storage devices, find a secure physical location to house the hardware in, buy bandwidth from an Internet Service Provider, and maintain the infrastructure ongoing. Today, that is no longer necessary. The enterprise can “lease” as much storage, server capacity, and bandwidth as they need on demand from a cloud-based Platform-as-a-Service vendor like Amazon Web Services, Microsoft Azure, Salesforce, and Rackspace. In this new model the company deploying the app does not own any of the hardware that their apps run on. They just buy the rights to use as much shared infrastructure as they need, when they need it. These PaaS vendors typically provide other supporting services like security and data backup as well. There are even healthcare specific PaaS vendors like ClearDATA and Aptible. These organizations help meet the specific challenges of the healthcare industry. Platform-as-a-Service is just one “-as-a-Service” business type. Some platforms go even farther. Application-Platform-as-a-Service (aPaaS) vendors not only give enterprises all the back-end technology to deploy new technologies, but allow users to create entirely new applications themselves within the platform.
With aPaaS infrastructure, users can literally build from scratch entire workflow-applications without ever writing a single line of code. aPaaS solutions typically use visual drag-and-drop interfaces and reusable components. This allows non-technical personnel to rapidly build and then iterate new web and mobile applications. Once the app is done the author simply clicks “deploy.” Then users around the world can take advantage of the new program. While not a perfect metaphor, one could think of some simple aPaaS solutions as building a shared Microsoft Excel spreadsheet and then drawing application interface screens in a Microsoft PowerPoint®-like environment. The aPaaS technology automatically converts these designs into a functioning application. In fact, many simple aPaaS solutions allow developers to upload Excel spreadsheets to serve as the starting point for creating online applications.
As part of researching this blog I built four different applications from scratch on one such aPaaS solution named KnackHQ. There are many other simple aPaaS vendors including Caspio, Kintone, Mendix, TrackVia, ZoHo Creator and Quick Base. Please note, I have never written code professionally. I have not even seen code in 20 years. Within 30 minutes, and without code, I built a tool that allows my wife and I to log into a secure website to track our son’s nanny’s Paid Time Off. This app has many of the features one would expect in time tracking software-- time & date stamping, reasons codes, reporting, etc. On the same platform, in about 10 hours and again with no code, I built a time and expense tracking tool for my consulting business. It includes multiple user types, e.g., sub-contractors, super users/admins, and client users. The application has dedicated desktop and mobile interfaces, both of which are branded with my Company’s logo. It includes approval and sign-off workflows, a tiered permission model, expense receipt image management, and some moderately complex reporting. The third tool, again written in hours without code, helped me manage a house renovation project, including to-do lists, vendor contact information, and budget management. Finally, I built a demo tool that would allow a patient to track a single Activity of Daily Living (ADL), e.g., hours slept, and comment on the entered observation. In the app the user could request their care manager review their data. The tool of course included the care manager interface to view the alerts from their patient panel. It would also flag aberrant values (e.g., if hours slept last night was more than 12). Building and deploying this demo took about 90 minutes. Would it not be great if healthcare organizations could deploy technology to patients and providers this quickly?
Exploring the complexities of the aPaaS market and the related Mobile App Development Platform market is beyond the scope of this blog. There are many players in this space. Each has a different focus, offers application makers different sets of tools, etc. However, almost none of the players that I looked at purely focus on healthcare. Some vendors do boast healthcare clients, and some comply with HIPAA and will execute a HIPAA BA agreement, but few if any had a health care specific solution. There should be.
Specifying what such an mHealth-as-a-Service solution would include is challenging, especially as mHealth is such a broad term. A first step in defining the capabilities is to identify some common use cases for such a platform. There are I suspect hundreds, but below are a few simple examples:
- Highly-specific ongoing patient tracking of self-gathered and device-captured metrics (e.g., hours of sleep, mood, pain, weight, Blood Pressure);
- Rule-based patient alerting and reminding for specific conditions, including rare conditions whose prevalence does not support dedicated disease-specific apps in today’s high-cost-to-build world;
- Customized clinician- and patient-facing data collection tools to support new clinical programs and/or clinical trials;
- Creating mini-, customizable patient registries to support specific medical or care management workflows;
- Cost-effective provisioning of interactive physician and patient educational materials; and,
- Disease-, practice-, or drug-specific “micro apps” for gathering a limited set of data from patients and prescribers.
Such mHealth-as-a-Service solutions would differ from generic aPaaS described earlier in several ways. For example, mHealth-as-a-Platform would:
- Overall anticipate clinical uses cases versus business use cases;
- Assume clinician and patient users versus business users;
- Be built from the ground up with security and HIPAA in mind, including easy-to-manage permission models, multi-factor authentication, and detailed application logging;
- Provide pre-configured clinical data containers for common healthcare objects like providers, problem lists, medications, encounters, etc.;
- Support clinical taxonomies and data types, e.g., ICD-10, CPT, NDC, LOINC;
- Able to accept clinical data in multiple formats, and ultimately pre-negotiated deals with various EMRs and medical devices, and/or the integrator of these data sets;
- Extend multiple healthcare specific user plug-ins, tools, and controls, e.g., patient-provider messaging, e-prescribing, tele-visits;
- Have templates for quickly deploying patient- and provider-facing apps to support common mHealth use cases; and,
- Employ service and support professionals that are intimately knowledgeable of mHealth.
As with non-healthcare focused aPaaS solutions, mHealth-as-a-Service solutions will likely come from many sources and take many forms. Existing EMR and Care Management systems will likely develop platforms that offer out-of-box integration. This is similar to how Salesforce has their own aPaaS solution. There will be pure-play vendors similar to the KnackHQ platform I experimented with. These platforms will be particularly useful for applications accessed by multiple providers running multiple EMRs. Simplified API-based data sharing methods like FHIR (pronounced “fire”) will make such pure-plays even more useful. There may dedicated provider- and patient- mHealth-as-a-Service platforms, or there may be integrated ecosystem-oriented solutions. Some aPaaS solution will focus more heavily on end-user features, while others on system and device integration. Healthcare is big industry. It will support many different types of offerings.
Rapidly deploy-able applications leveraging mHealth-as-a-Service platforms are not a panacea to providers, payors, and life sciences companies. Many use cases will require dedicated applications. It is not practical to build an entire EMR or Practice Management system with mHealth-as-a-Service today. Secondly, while the FDA states it does not intend to regulate large swaths of mobile apps, including symptom tracking, patient education, etc., some potential mHealth-as-a-Service apps will not fit within the regulatory framework.[vi] Finally, and most importantly, effective mHealth application building is not simply checking off functional requirements. Rather it is creating useful, engaging, easy-to-use software, and then getting people to use it. While mHealth-as-a-Service has potential to use templates and shared tools to help with this, the design burden is not eliminated. Thus, the likely best use cases for mHealth-as-a-Service initially are "micro apps." These are highly customized widgets for very specific users to replace existing simple paper-based processes. For example, apps that support a basic departmental QI initiative, or ask a patient to track side-effects of a rarely used medication, or a facility-specific pre- procedure patient to-do list. The economic value of any one of these is likely small-- but it may be worth a few hours of time to deploy something "good enough," especially when "good enough" only refers to functionality, not security.
The sheer size of the need for more and better mHealth tools suggests there are least some places where mHealth-as-a-Service could help. The ability to build and deploy secure mHealth applications in days versus months, with hundreds versus tens of thousands of dollars, created by clinicians versus programmers, and iterated upon weekly versus quarterly is very exciting. Who knows, with the right platform, even I could get into mHealth app building.
i. Global Mobile Health Market Analysis & Trends - Industry Forecast to 2025, Research & Markets, March 2016
ii. mHealth Market Is Expected To Reach $49.12 Billion By 2020. Grand View Research, August 2015.
iii. Touching lives through mobile health, Assessment of the global market opportunity. GSMA & PwC, Feb 2012.
iv. Cost to Build a Mobile App: A Survey. Clutch.co website. January 30, 2015.
v. How much does it cost to make medical apps for health care professionals? Quora.com, Nov 16, 2016.
vi. Agate interpretation of FDA website page “Examples of Mobile Apps For Which the FDA Will Exercise Enforcement Discretion,” on Jan 24, 2017. Note, Agate Consulting does NOT provide regulatory advice, and readers are encouraged to contact appropriate legal counsel as their needs dictate.