Ade Memoire: on developing apps

 A question. Why is it, four years after the release of the iPad, that we are not seeing clinicians routinely carrying out their work on one of these lightweight, touch screen wonders?

 The answer, in short, is that while your favourite, everyday websites – news, information and retail – have provided a very good mobile experience, your heavyweight, workhorse healthcare applications have not.

Generally speaking there are two reasons for this. The first is that in the wider world there was a commercial need to supply something that ran on the users’ favourite device.

The second is that with many apps having world-wide potential, even though they use very generic data and views, those involved can apply their global development team to get it done.

On top of that, while there’s a bit of money at stake, they just need to get their security right and any poor code isn’t going to harm people.

In contrast, although we have all been running web-based health applications for a long time now, many of the richer user interfaces require controls to be downloaded onto the local machine (PC) and rely on its full operating system to function. They will simply not run natively on a tablet device.

Some will claim success at running a virtual window for the application, using Citrix or terminal services. In this technology, the application session is actually running on a remote server and just presenting a view onto the user’s device. The problems with this are twofold:

• The user interface was probably written for someone with a large monitor, keyboard and mouse, with all of its click-ability.
• The user will have become used to a set of very friendly gestures that are supported by a tablet device and any application that is natively written to run on it. The old application will not support this, however it is presented.

You don’t need it all

Full blown clinical applications are large. They cover many screens of specialist data collection and there’s often more data on any individual screen than you would like to present on a tablet.

Successful tablet based applications are small and well defined. Is it possible that we will be able to develop tablet-based apps that fulfil a function – such as observations collection – and feed their data into something like a clinical data repository so that it links up with the rest of the electronic patient record?

 It should be, but it requires a supplier market buy into working this way across the board. It might therefore be possible to build components of the EPR that are independent and vendor agnostic. Some will already claim to do this, but the trick is not just defining and building the system, but understanding where the data belongs and working with third parties to get it there.

Standardise or not?

Generally, we as customers – along with our application vendors – will have to decide whether we are going to commission “apps” that are served up via the different versions of “app store”, or stay within web browser standards using the emerging HTML 5 standard.

The main benefit of the former is that with an app you can fully take advantage of all the operating system features; but you have to write apps for each operating system you support (IOS, Android, Windows Mobile).

In the latter, the main benefit of the HTML standard is that it is cross platform (the same code will run on all types of device), but not as functionally rich. And although it is a standard, it behaves differently on different devices and different machines.

If we try to support too much, we will be caught in a never ending cycle of developing and testing. With an app, therefore, we need to consider whether we are going to develop for just one platform, and with HTML we need to decide whether or not we are going to limit testing to a preferred browser on a preferred platform.

Then there is deployment. HTML code is easy and can be served up from a server as long as it’s available, internal or external (internet).

With apps comes the world of app stores, and whilst Android is nice and “open”, the more locked down features in the Apple IOS system add control.

The Apple release programmes are a challenge. The business app store turns code around in five days, which is fine for a planned release, but what if there is an urgent bug fix on a clinical application?

Apps can be deployed locally on networks, but commercial issues might create problems with that; and the tablet device will not pick-up its updates automatically.

Nobody wants to have to visit hundreds of tablets to apply updates, or give the end-users a password to the corporate iTunes account. Mobile device management software does not cover all of these bases. Or at least, none of the software that I’m aware of does, at the moment.

So what’s the answer?

We must assume that having taken the world by storm, tablet devices are the correct strategy; but this is not going to be easy.

When we started developing web-based clinical functionality in Southampton back in the nineties, we found it difficult to engage with a partner because the market generally knew that it was not ready and the architecture still had a long way to mature.

We ended up developing with tools that deployed Active X components and locked us in to Internet Explorer (IE) in order to get the functionality. This decision was made even though we actually had an Oracle backend platform to the system.

Years later, we develop for much more openness because we can. It seems to me that the world of apps and mobile is at this point where we were back then with web development.

My own belief is that unless you are blessed with the kind of resource I could only dream about, we are going to have to standardise on a platform. And, in the cases where an HTML 5 version will fit the bill, cut down on the number of browsers and platforms we support.

Adrian Byrne

Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.

On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.