This past weekend I bit the bullet and upgraded my laptop to Microsoft’s latest Windows 8 (accessed early as a Microsoft Business Partner network member). This was painful, as my laptop had employed whole disk encryption, which needed to be decrypted before the update! The update went flawlessly, but now I have to go through the pain of re-encrypting the drive! (I use whole disk encryption to protect client data!).
First impressions? On a laptop I don’t see a big difference! My desktop looks pretty much the same, but instead of booting up to it, you have to deal with the Windows 8 UI (previously Metro). On a portable device this is pretty cool. On a laptop, the jury is still out as far as utility.
The dilemma I now face is that I am at least two to three generations ahead of most of my healthcare clients! Example: even before the upgrade, I was at a client location last week for a presentation and was told the room had a PC projector. That it did, but only interfaced to an in-room computer! So, I had to transfer the presentation to a thumb drive only to find out the room PC was still running Windows XP! That meant saving the presentation again from my laptop in an Office 2003 format and transferring it again with the thumb drive.
This got me to thinking about the degree of complexity and issues facing healthcare providers as they wrestle with the changing regulatory environment. Both facilities and equipment providers are wrestling with moving off of Windows XP as support is quickly ending. It is more extensive than the operating system, as browser versions can be just as big a problem. It is sort of a catch 22 though. If IT vendors begin delivering applications that are supported on newer operating systems/browsers, but the facility’s update plans are not consistent, will the consequence be an inability to deploy technology necessary for ARRA/MU compliance?
Lately there is a lot of buzz in the marketplace about mHealth (mobile health) and BYOD (bring your own device). Healthcare is not alone in terms of industry impact as evidenced by the following blog posting (http://www.informationweek.com/windows/operating-systems/is-windows-8-too-risky-for-it/240008045?cid=nl_IW_daily_2012-09-27_html&elq=23d6a2110781487baa5902fee80b78a3). Clearly most of these devices are running on newer platforms than many providers’ IT infrastructure, which may limit their ability to accommodate productivity gains from the newer technology.
This explosion in computing technology may represent a sea change for healthcare. The previous pace at which facilities updated platforms and operating systems may need to quicken in order to take advantage of newer applications. Of course the reverse is also true. The equipment vendors may be just as far behind with applications still based on Windows XP, with clients wanting them to run on newer versions of Windows.
I am reminded of the site that has CT scanners that do not support the facility’s enterprise anti-virus platform and are a constant source of aggravation and a potential virus source! The vendors constantly face this quandary as they introduce new releases that may support newer OS’s but they don’t bother to go back and test older versions, due to time and cost constraints.
If the pace of technology is in fact being accelerated by regulatory/business requirements, it may be time for both sides to rethink software validation processes. In a conversation today with Steve Rankin, CEO and President of Client Outlook (http://www.clientoutlook.com/), I learned that they utilize software development tools that enable them to assess their applications across an array of operating systems, so that they don’t have to individually validate each one. This enables them to produce an application that works with multiple versions of Microsoft Windows, as well as Apple OS and Android systems.
This makes a lot of sense on the vendor side, and one can only hope that along with technology advances, there will be advancement in deployment tools that will allow faster and smarter deployment of new operating systems. This may be one of the more hidden technological and capital-intensive factors affecting compliance with ARRA/MU.