Ade Memoire: all mod cons

As I was thinking about predicting the future, it surprised me to discover that futurology has been around for about as long as electricity.

(As everyone knows, electricity was invented in the North East by a chap named Charles Hesterman Merz – @Comparesoftware / aka Joe McDonald presentations passim).

I have no way of knowing what futurologists might have been saying back in 1998. Well, there is Google I suppose; but I can’t be bothered.

Fact is, in 1998, at University Hospitals Southampton NHS Foundation Trust, we made a decision about the future; and our decision was that it was going to be web-based.

The web was the future (most places)

This was a bold decision in 1998, as we were just coming into the first set of browser wars between Netscape and IE5. We tried, in vain, to find anyone who would buy into our vision. But we still felt we knew best, and decided to build it ourselves.

At the time, the choice of functionality on the desktop either led you down the Java route (yuk) or the Microsoft ASP with Active X route (slightly less yuk). So off we went, with the Microsoft set up.

We were absolute beginners, so we engaged a proven analyst and a couple of contractors. Between us, we designed a system sitting on top of Oracle.

We still use it today, in part; although obviously we’ve migrated some technology. We also still do work with same developer.

Almost 20 years on, if you look at the world, you’d say we were right. But if you look at NHS software, you’d wonder how we got it so wrong.

Have a think about how many of the systems large and small that run in NHS hospitals even now are truly web based. An old IT manager at SUHT [sic] used to laugh at terminal services products and call them steroids for out of date technology.

That was in the early 2000s, yet we still continue to deliver services in that way. Some of it is old client server, some of it is a bit more modern, but not much of it is anything that anyone would describe as web.

Uneven, and unevenly distributed

What we have seen over the years is a fairly traumatic development of web standards. We’ve often lurched from one proprietary thing onto another so called standard, supposedly more future proof.

Seemingly, innovators and inventors try to own things at first in a proprietary way. Then, inevitably, as patents erode and so forth we migrate towards different versions of open.

This has, at times, been very painful, and it’s made progress very uneven. Witness the fact that some applications are stuck in IE8, with all the incumbent security risks.

It turns out that keeping all your clients on a workable browser is no less hassle than keeping them up to date with any other client software.

This is just the modern equivalent of DLL hell, except now it is starting to feel as though, with HTML 5, we are finally getting there. But health software applications? All mod cons? I’m afraid not.

The fork in the road

So what happened to those who took the other fork in the road, those who did not attempt to migrate to web?

Surely they are not still trying to run thousands of client PCs, all with different software packages conflicting on the desktop? Surely they are not running around the site every time there’s an upgrade, dealing with conflict after conflict?

The answer to that, I think, is ‘yes’ and ‘no’. Those steroids I mentioned above are still around, and they have become quite sophisticated.

We now have virtualisation on top of terminal services, and an environment where you just deploy a window onto the desktop, with conflict being dealt with by deploying applications in a much more highly controlled server environment.

So that’s all fine; except that it takes some hefty investment in server-side architecture and licences.

Nevertheless, if your view of the future is many applications delivered to a user on a Windows desktop, it is probably the only sustainable way to achieve it. It also lets developers off the hook, again.

The new fork

The new fork is about mobile versus Windows desktop. A while ago, we were pondering whether we should have invested in, or should plan to invest in, a virtualised desktop infrastructure or VDI.

Doing a bit more futurology, we concluded that the future was going to be discreet mobile apps on a mostly tablet or phone based device, so this would be rather pointless.

The mobility and mobile apps would cope with what the VDI was trying to do, whereas the desktop applications would still run on the more “traditional” browser client.

We also felt that our users would not really appreciate us trying to deliver a full Windows desktop onto their tablet device. Imagine the icons!

Imagine dealing with all the applications that are not optimised for a touch screen user interface. So our strategy remains web-based for desktop and mobile technology for mobile platform.

Another prong

Potentially, there is also a battle between the world of apps and the kind of thing that can now be delivered by a website in a so called web-app.

There are obvious disadvantages in the world of apps. You need to know the user has the latest app loaded, and you need to keep a different code base for each operating system and app store you support.

On the other hand, apps do deliver a nice user experience, and it is easy to hook into the mobile ecosystem, with its alarms, camera and such.

I think it is fair to say the jury is out on this one at the moment. I also think it is fair to say that an app should have to earn its place in your phone’s memory bank.

Allied to this, we have taken an interest in the new interfacing techniques, notably SMART on FHIR, because we think these will create a way for these mobile discreet apps to connect into the relevant data sources.

Potentially, this will open up a new way for users to interact with the back end data, through a strictly controlled layer of interfacing governance.

Cleft stick

So, now, here we are, in a cleft stick situation. Even though it would seem that our decision to go for web was correct, and we have been successful, the health software supplier market has been underfunded/lazy (delete as appropriate) and still relies on steroids.

These are drugs that, for some reason, have not yet been banned, and maybe never will be.

But it’s a bitter pill to have to pay for products, licence fees, upgrades, “motioning” and the rest that should come for free if things were designed properly from the ground up in a scalable modern architecture – web based or mobile.

Meantime, the future of mobile rests on obtaining the full read/write connectivity of the apps world to the data sources. I would like to think this will work.

Any supplier will have a tendency to lock our/the patient’s data (delete as appropriate) up for their own ends. So, once again, let’s have a plug for @INTEROPenAPI.

Liberate the data, create an apps mart, drag them into the modern world, don’t settle for same old. Don’t beat surrender. Too much to ask?