Posted by: RedaChouffani
mhealth, mHealth applications
In previous articles, I have discussed the impact mobile health’s rise in the industry and the EHR vendors’ reactions toward the plethora of new mHealth products entering the market every day.Wireless capability and remote data exchange is becoming of vital importance to physicians, as it allows clinicians the ability to expand the continuum of care and push forward telehealth and remote patient monitoring capabilities in their every day practice.
But in a product evaluation session I recently attended, one of the software vendors described their product as being one of the few solutions that offered a truly mobile app for its physicians. Unfortunately, after careful review, what was meant by a “mobile app” was nothing more than the browser based view of the chart that was available to any device, specifically an iPad, Android tablet or a Blackberry.
So, the question I was asked was:What is the difference between a native iPad iOS/Android app and a web based app accessible from iOS/Android platforms?Keep in mind that it is important to recognize the difference between the two, as there are some key functionalities that are lost with the web based app.
There are two common types of apps available in the healthcare market place, the first being web based apps:
·A web based app relies on server side processing for rendering content — and while there are some web sites that use local resources on the device itself, simply put, it is a web page that had some additional scripting done to it to ensure the look and feel is somewhat similar to the look of the native apps.
·Easy to deploy and won’t require marketplace approval or Apple Store review.
·Healthcare providers can have access to most of the features and functionality currently offered via web portals from the software vendors on almost any platform.
·Server side processing means better performance in most cases, since the end user does not have to wait for the information to transferred and manipulated on the device itself.
·From a development standpoint, web solutions tend to be easier to develop than native mobile device apps.In fact, there seems to be a shortage in mHealth developers vs. web developers.
·Web based apps are also cross platform compatible, where they can run on any browser regardless of the device you are using.
·Loss of hardware integration: In a web based model you are most likely not going to have the ability to use the cam or capture data from an external device ,such as location from GPS, or download data from a heart monitor, read vitals and other data from medical devices.
·Loss of some features, such as multi-touch, gesture recognition.There are web sites that have created controls similar to iOS controls, but they still lack the typical experience that accompanies the native ones.
·Lack of strong support for offline functionality when physicians don’t have access to WiFi or internet access.
Native apps are the products or apps developed using the device’s own development kit or (SDK):
·With the ability to be completely offline and the availability of local databases, native apps can easily and securely make charts and other health information available offline for review.This would allow end user to capture data and then synchronize it with the main data store once the connection is made back.
·A native app has the ability to interact with all the available devices through the SDK (software development Kit).Whether the app needs to transmit instructions to an external device, or simply capturing the image of a skin condition, the native app has many options from which to choose.
·In most cases, there are specific guidelines and rules that are required from app developers prior to getting their app published in the online app catalog.
·Native apps are move difficult to develop and require specific platform knowledge and programming language.For the iPad/iPhone Objective-C is the common route taken to develop, although other programs, such as MonoTouch, allows software developers who are used to Microsoft c# or .net to write for iOS.
·Costly and longer development cycle comes with this type of product creation.
·Lack of cross platform compatibility, which requires the software vendors to choose a preferred platform or have multiple teams developing for multiple platforms.
Whether evaluating web based or native apps, the most important step during the selection process is ensuring that it meets your minimum set requirements and resolves a workflow challenge.At this point, there are four major players: RIM, Apple, Microsoft and Google.Each vendor has a different programming language and different functionalities. It’s hard to determine who will lead the market down the road, but it is important to focus on what the app can do for you now, as a first step, so that you have a tangible ROI to take back to the table.