Guest Article: Selecting or Designing iPhone and Mobile Software for Physicians

_I get a lot of questions asking for advice on how to build mobile software and one of the most popular questions is about how and where to save data on a mobile device (because of HIPAA and privacy rules). I reached out to Adam Kenney, a software engineer pMDsoft who leads a team of developers focused on mobile charge capture. Adam and his team have been building medical apps for mobile platforms and his insights arise from direct experience managing the design, development, and support of native applications for the Palm, BlackBerry, and iPhone. Here’s what Adam wrote.

_

Any physician who spends time in the hospital setting understands the importance of “taking it with you”. Web-only software is great; but even now, when many hospital rooms have a terminal on hand, the overhead of logging in and logging off for each patient can be intolerable for busy physicians who are already spending too much time on administrativia.

This is where mobile software comes in. Doctors were among the first adopters of mobile devices such as Palms. With the rise of smartphones, and with government initiatives such as e-prescribing, mobile software is more appealing than ever. But it’s challenging to make software that fits the constraints of a mobile platform yet is fast, fun, and friendly to use; and only usability will allow you to save time and achieve 100% adoption within your organization.

One of the biggest factors in the usability of mobile software is how data gets onto and off of the device. Here are a few of the most common approaches that mobile software companies take, with the pros and cons:

Option 1: “What happens on the device stays on the device”

The simplest applications are native (i.e. installed on the device) and have no way to exchange information with outside systems. In some cases – such as a drug reference, calorie counter, medical calculator, or a personal to-do list – this may be all that’s needed. This type of software is fast to develop and easy to support because there is no shared data, either between users or between the device and a server; so the range of possible scenarios is narrow.

There are some downsides to this approach that make it unsuitable for complex or mission-critical applications. For one thing, there is no ability to exchange information between users, so any situation that requires shared data – such as an EMR or rounding list – is beyond the capabilities of a standalone app. Additionally, if the software stores sensitive patient information on the device, it must both encrypt (scramble) that information; and also use a logout mechanism to prevent anyone who picks up the device from seeing it. Finally, if anyone loses or breaks their smartphone, you have no recourse except to hope that there’s a recent backup. Otherwise, the data is gone.

Option 2: “Your information is out there somewhere”

Mobile-optimized Web sites and native applications whose data are stored entirely “in the cloud” have enjoyed great popularity recently. Mobile Web browsers have become increasingly capable, and we live in the golden age of cloud computing, where software is increasingly being liberated from local environments and stored instead on a third-party hosted server. It’s an appealing approach: the data is stored and backed up at a centralized facility, so disaster recovery is simplified. You can access it from anywhere, as long as you’re connected.

That’s the kicker, though. If an application doesn’t store any data locally, or stores only a subset of the data it needs, then the user experience is terrible whenever the device doesn’t have a strong signal. Hospitals have notoriously poor cell phone reception and spotty WiFi coverage. Indeed, we hear horror stories about a duct-taped “X” on the floor marking the only spots that can get a signal. This scenario is so common that it’s crucial to design for it, otherwise the users will have to waste a lot of time searching for a signal just to get their job done.

With growing support for emerging Web technologies such as AJAX and HTML 5, it’s increasingly possible for Web applications to provide a satisfying offline experience. The line between Web applications and native (installed) applications is blurring. But it’s still a lot faster to use an application that’s installed on the device, assuming it’s well-designed.

For example, iPhone and BlackBerry users can access a webmail site – sometimes a highly-optimized one such as GMail – using the Web browser on their phones. But, they’ll almost always prefer to use the built-in email software instead, because it can combine emails from various personal and work addresses; it allows them to tell when new messages have arrived; it has a user interface that was designed from the ground up for that device; they don’t need to have network coverage to read and compose emails; and they are never logged out of it. Similar advantages hold true for many kinds of medical software.

Even Web applications that contain sensitive patient information must take certain precautions to ensure that the data is kept safe. Secure sites must use the HTTPS protocol – the same method of communication used by bank Web sites – to encrypt data while it’s being transmitted. When creating Web-based software, it’s necessary to enforce strong passwords, since an attacker can use any computer to try to gain access to a user’s account. Finally, even mobile Web sites can end up storing some sensitive data on the device in the form of cached pages. Web browsers automatically store copies of pages that you’ve visited, to speed up page loading in the future; but unless your site explicitly disables this behavior, or you put a password lock on the entire device, it can be a security risk.

Option 3: “Your information is everywhere you are”

An application that uses two-way synchronization combines either the best or the worst aspects of the above approaches. It’s notoriously hard to do sync right – and when it’s done wrong, you can end up with data that’s trapped on the device; frustration and wasted time trying to sync; users who are missing information that they expect and need; or, worst of all, data loss.

But having a fully-functional offline mode is rightly considered the holy grail of mobile user experience. If all of your data is stored on the device, then you can use the software anywhere, whether or not you have a signal. The app will start quickly and respond instantly to your actions, yet your changes are safely uploaded to the cloud as well, where they are out of harm’s way. And if the synchronization is wireless and happens seamlessly in the background, then updates from other users in the group can appear almost magically during use, and users can stay informed throughout the day.

It all comes down to the quality of the engineering. A well-designed and well-executed application syncs transparently, letting you know when you’re working offline without interrupting you. And it syncs efficiently, sparing your battery life by avoiding many of the data requests that a Web site needs to operate.

As you might expect, applications that synchronize need to address some of the security and HIPAA concerns of both other approaches. They must use encryption for any sensitive data that they store; must also restrict access on the device using a password; and must use HTTPS or another secure protocol when exchanging potentially sensitive information. At least they don’t have to worry about browser caching, since the Web browser is not needed to use these apps!

What’s right for you?

Usability – and specifically, data storage and synchronization – is just one of many factors to keep in mind when selecting or designing software. It is the most important single factor that distinguishes great mobile software from mediocre mobile software, but your organization may have additional requirements relating to HIPAA compliance, type of device (e.g. BlackBerry versus iPhone), and must-have features.

The important thing is to anticipate what it will really be like to use an application. Will it save time, or impose additional burdens on physicians? Will they love it, or want to throw their smartphones out the window? Taking the time to understand a solution well before you buy it can prevent headaches and remorse down the road.