Going native with healthcare apps: stepping back from the functionality cliff

By Chris Watson, Product Manager at Exco InTouch

31 October 2014

The use of health apps to monitor patients' progress and to help them self-regulate their condition has been growing dramatically across the globe. With this in mind, there has been much debate of late about how to deliver public-facing healthcare apps across different operating platforms (iOS - Apple, Android or Windows8) to provide the best user experience.

There has been a huge demand in the healthcare industry for electronic clinical outcomes assessment (eCOA) providers to deliver user friendly solutions that patients find easy to use and accessible. Alongside this demand, there has been a lot of discussion recently on the growing use and popularity of native apps in the clinical industry. At present there are three different ways to present healthcare apps, all of which can come with an icon on the devices’home screen, but which fundamentally have different architecture:

• Native apps: downloadable software which is coded to run directly on the devices’operating system. The versatility of native apps means that they can be used without requiring a mobile or internet connection and can interface directly with the devices’inbuilt functionality (camera, Bluetooth, microphone etc.).
• Web apps: downloadable mobile websites that look and feel like native apps, normally built using HTML5 technology to utilize the devices’web browsers. Whilst they boast interactive functionality (as opposed to just capturing information), they are unable to readily access many of the devices’inbuilt functions. These apps consist of a HTML5 core which is embedded or wrapped”into a code base, which appears to the phone as being native code.
• Mobile websites: websites which are accessible on a mobile device and which have been optimized for use on a mobile phone or a tablet. Mobile websites by nature provide web-based controls to users on their own devices, storing the website URL on devices’home screens as an icon and generally providing information or facilitating the capture information from the user. However, they have limited functionality.

Currently the most common approach when developing healthcare apps is to use HTML5, which wraps a web app into mobile operating controls. HTML5 web apps are prevalent because the technology facilitates speed to market, as there is one fundamental build which is then embedded into a code base that enables them to run on different mobile operating systems.

However, as HTML5 is a web-based language, it does not enable the layout of the screens to be optimized for the devices’ screen size, or enable the incorporation of natural button configurations. Therefore, whilst HTML5 web apps may look like native apps at login, once inside they often adopt a web look and feel.

In contrast, native apps provide a consistent look and feel across all screens and devices' types and can be developed to deliver clinical and healthcare programs in a timely, cost effective manner across all platforms, without the need to compromise on the user experience.

Native apps enable the display to be optimized to the user demographics, so as to control how the screens are presented by automatically adapting to the users’controlled accessibility settings within the devices. This is especially crucial when dealing with patients of advancing years or those with disabilities.

In addition, native apps are ideal if a study is being carried out in geographies where mobile connectivity may be unreliable. In this case, a native app should store data locally in an encrypted form until a connection is made to enable secure data transfer.

Native apps will have enough capacity on the device to ensure eCOA data can always be stored when necessary and will have the mechanisms in place to ensure that the data is securely deleted once the data has been sent. This applies particularly in a Bring Your Own Device (BYOD) setting, which is becoming more popular due to patients’familiarity with their own devices, which in turn translates into increased engagement.

Furthermore, alongside the collection of primary outcomes data, native apps can also facilitate the measurement of secondary outcomes data through the active integration of medical device data (such as Vitalograph asma1-bt and MyGlucoHealth) and the passive integration with lifestyle devices (such as FitBit and the Withings devices) which are becoming increasingly popular tools for use in clinical research.

As experts in electronic data capture, Exco InTouch use their experience to deliver solutions which are designed to be fully compatible with a broad range of home monitoring devices, providing a simple interface for medical device reading for the end users.

Pressure to be first to market has seen many business and organization consider native apps as costly, timely and unwieldy. Detractors say that it is easier to develop a web app because there is no need to produce multiple app versions to operate on different platforms and their operating systems, such as iOS, Android and Windows8 Mobile. Nothing could be further from the truth when it comes to healthcare.

Apps for healthcare

For healthcare organizations, a native app will enable them to select their preferred delivery model, offering the flexibility to either provision appropriate devices for the study population, or to enable BYOD in both clinical and commercial health programs. This is enabled, for example, by Exco InTouch’s proprietary mDNA technology, which provides sponsors and payers the robust reassurance of protecting Personally Identifiable Information (PII) and maintaining data security even when using patients’ own devices.

At the heart of the native vs web app debate is an issue of selection. Going native does not rule out mobile web (native can utilize mobile web). What HTML5 does with a web app is a compromise — a halfway house that may be quicker and cheaper in the short term, but not for longer studies. The increasing popularity of native apps means they will become more prevalently used in future. There remains a functionality cliff with HTML5, and sooner or later it will become apparent. Would you rather develop an app twice — or do it right the first time?