One thing you are sure to find this time of year are predictions. I’ve decided to do my own not so much to join the crowd but rather because I look forward to comparing my predictions to what actually happens in a little less than a year from now. So with that, here are my predictions for the year in HIT – which ones do you think will come to pass, and which ones have I missed?
1. mHealth experiences a re-birth
mHealth is all the rage and for good reason – it holds great promise to make a significant impact for both providers and consumers alike. But while mHealth for consumers is still on the upswing of innovation and expectations, mHealth for providers is starting to pass the Peak of Inflated Expectations. Walk the floors of any HIT trade show over the last year+ and you were bound to run into iPads at every turn – not necessarily because these vendors were mobile app developers, but because they either 1) wanted you to think they were or 2) managed to make their products “accessible” via a mobile device. But accessible is not the same as usable or efficient. Perhaps the most public example of this was chronicled in a CIO magazine article that described physicians handing in their iPads after a poor experience accessing their EMR. This doesn’t signify a failure of mHealth for providers, rather it was a failure to recognize that app design is arguably more important on a mobile device than in a portal/web or desktop application. Design flaws and workflow gaps are even more exposed on a mobile device. Now that the market has begun to recognize and experience this reality, intelligently-designed mobile apps (whether native or web apps) will continue to rise to the top and carry providers through to the Slope of Enlightenment.
2. Providers begin to expect full workflow support on mobile devices
This prediction is admittedly a bit late as providers have already moved beyond mobile access to clinical results to expect full workflow support. And why not? We should not expect a physician to access lab results on his/her iPhone only to set that device down on the nursing station next to the computer terminal (that is already in use) to enter orders, document care, enter a charge, etc. Perhaps what has fueled this expectation the most is the iPad and other tablets (though not many others). Not many would expect to enter a clinical note or use order sets on a smartphone, however, the tablet form factor presents a new opportunity to do just that – support a physician’s entire workflow. Full, integrated workflow support is a (perhaps the?) critical component of sustained physician adoption of HIT. Where reasonably-sized form factors are concerned, this will also hold for mobile workflows.
3. What worked for Stage 1 will not for Stage 2
My summary of the first year of Stage 1 Meaningful Use (MU): fewer than expected (or budgeted by OMB) meaningful users in year 1, lots of confusion and less movement due to the Stage 2 delay that wasn’t a delay, and early movers characterized by the use of existing systems to meet the bare minimum Stage 1 objectives (e.g., using ED systems to achieve the 30% CPOE threshold). But many hospital IT and physician leaders have already or will soon realize that a Stage 1 strategy isn’t likely to succeed for Stage 2 and beyond. The latter stages are going to require much deeper adoption, use and exchange of health information. IT leaders will need to lay a strategic path that considers all stages of MU, ICD-10 migration, efficient revenue capture, ACO/Value-Based Purchasing and a litany of federal, state and local priorities if they are to be successful. Each of these and other priorities hinge on efficient, meaningful use (pun intended) of integrated systems that respect and protect physician efficiency (and revenue) if they are to succeed.
4. ICD-10 is not Y2K
As the fireworks exploded in Times Square last night, someone said to me “remember how freaked out everyone was at this very minute back in January 2000?” Yes, I do, and the fallout (or lack thereof) threatens to put providers and hospitals significantly behind the ICD-10 eight-ball if they consider that migration to be another non-event like Y2K. Most reports, surveys and commentary place providers and hospitals significantly behind in their preparations for migration to ICD-10. This will have to change in the coming year. But I believe the challenge and emphasis will ultimately be on documentation and not on systems simply supporting the 4-fold increase in the number and format of ICD-10 codes. IT solutions that focus on improving documentation (thoroughness and efficiency) will best prepare providers for ICD-10 and shield them from the potential loss of revenue.
5. ACOs will (continue) to get more attention than they deserve
This is not a repudiation of ACOs or what they attempt to accomplish. But ACOs have dominated much of the conversation during the latter half of 2011, and I expect that to continue. While the tenets and concepts of ACOs are likely here to stay, I still think it’s too early in that process to warrant the airtime to-date. Instead, providers will continue to focus on many of the critical building blocks required to support successful ACOs in the coming year – they just won’t necessarily be doing so in the name of a formal ACO. Do you sense a common theme? Use of integrated, efficient systems in the name of care coordination and higher-value care. While ACO will undoubtedly continue as the preferred acronym of the day, the foundational work required to support an eventual ACO model will be where the real action happens.
Happy New Year!
Today, Manhattan Research announced that 75% of U.S. physicians own some form of Apple device while, unlike the general consumer market, the iPhone continues to dominate Android among physicians.
Overall, smartphone penetration among physicians has already exceeded earlier analysts’ projections of 81% by 2012. Why has Apple dominated the device market and why has smartphone adoption among physicians exceeded that of the general population?
The answer to why Apple is actually pretty simple – apple has the iPad while Android is still waiting for a real market entry to compete with Apple’s popular device. The iPad has captured physicians’ attention like no tablet (or device) before, and this trend is likely to continue as more EHR venders provide access to their systems on this device. Another potential reason for Apple’s dominance could be as simple as the availability of healthcare-related apps. Developers have shown a willingness to create apps on the iOS platform more often than on the Android OS. Of course this could be a chicken-egg scenario – more apps and more market share beget more vendors developing on the platform and the opposite. Whatever the reason, more vendors support iOS than do Android at this point. It’s also possible healthcare organizations prefer the closed app approval process required of the App Store. The open source nature of Android app development has lead to higher incidence of malware attacks, something healthcare organizations are sure to want to avoid.
As for why smartphone adoption among physicians continues to be higher than the general population – smartphones and tablets support physician workflow in many ways like no device before. Physicians are inherently mobile, whether simply rounding from floor to floor to lab in the hospital or traveling from hospital to different physician offices. Simply put, a smartphone or a tablet fit within a lab coat better than a laptop or a computer on wheels. Due to their screen size and form factor, these devices run applications that must focus on efficient user interaction and experience with near instantaneous “boot up” time.
Bottom line, where physicians’ are involved, smartphones and tablets appear to cure what ails EHR adoption.
How about when an iPhone replaces a stethoscope?
Long the symbol of the medical professional, this is exactly what’s starting to happen with an iPhone app designed by a researcher at University College in London. More than 3 million users have downloaded this app that turns an iPhone into a stethoscope. Need more evidence? Google “mHealth conferences” and see how many results are returned. Search “#mHealth” on Twitter and admire the minefield of tweets. Even consider the fact that physicians have adopted smartphones at a greater rate than consumers.
Now that device quality (e.g., form factor) and connectivity have essentially been removed as barriers, what are some of the key factors that will continue to accelerate or potentially slow this fast-paced train? I’ll throw out a few of them.
- Physicians. As mentioned previously and in many articles of late, physicians love mobile health. This should not be surprising if only because medical professionals are inherently mobile. Whether rounding in the hospital or shuttling between offices or simply taking a call from a colleague, physicians are always on the go. If they can access important clinical information upon which to base their decisions all the better. Despite popular (though fading) opinion, physicians are also technology enthusiasts.
- Consumers. For better or worse, the largest portion of apps in the “Medical” category on iTunes are really more health and wellness the medical apps. To the extent these and other apps begin to connect with or take on some of the functionality of a mobile Personal Health Record (mPHR), consumers will be a major driver in the mHealth movement. Hospitals, practices and vendors will ignore connectivity with consumers apps at their peril (not to mention this kind of functionality will increasingly become required as part of the Meaningful Use requirements).
- Vendors and App Developers. To date, the most popular apps used by physicians have been drug reference and medical calculators/resources like Epocrates and Medscape. These will no doubt continue to be popular, but for deep and sustained penetration, physicians will (and have already begun to) demand access to clinical information on their patients – direct access to EHRs and any other system that contains information on their patients. EHR and mobile devices vendors have been more than happy to oblige and will likely continue to dip their entire leg into the mHealth pool.
Potential Retarding Factors:
- FDA. The FDA has already begun to drop not so subtle hints that they are at the very least exploring what their role could and should be with respect to regulating mobile health devices. The degree to which this crosses over into smartphones running “medical” apps or stays primarily focused on devices used to remotely monitor patients remains unclear and developing. Suffice it to say, this bears watching and could help continue the growth of mHealth to the extent it gives hospitals, providers and patients comfort that someone is looking out for their interests. There will of course need to be a balance struck between regulation and innovation.
- Privacy and Security. Are mobility, privacy, and security mutually exclusive? They shouldn’t be, yet there are still many people who feel they are. Still others remind us that our mobile devices may already be transmitting information about us that is equal to or perhaps beyond the scope of some PHI.
I’m often asked which is the better approach to mobile applications (apps) – a native app or a mobile web app – for accessing information via smartphones. This question has become increasingly relevant given the tremendous potential impact of mHealth on physician adoption of IT. In fact, physicians continue to adopt smartphones at a greater rate than the consumer market, therefore, this question will become increasingly relevant for organizations and vendors to consider as part of their mobile strategy.
If I had been asked this question only a few years ago, I would’ve undoubtedly said native apps are preferable if only because cellular networks and Wi-Fi connectivity were not nearly as widespread as they are today. Similarly, device browsers and form factors have greatly improved, making browsing and navigating the mobile web much more useful. Owing to at least these two important factors, the decision to go native or mobile web is not nearly as cut and dry as it has been historically.
Essentially, a native app refers to an application that is installed on a mobile device (usually a smartphone). Although apps developed for and distributed through Apple’s iTunes App/Store predominate, other mobile platforms, namely Android and to a lesser extent BlackBerry, are beginning to make headway in the native app space. Still, people tend to think of Apple devices when discussing apps, if only because more data exists on their distribution and use, due in part to the closed ecosystem that Apple has created via the App Store model.
In simplest terms, a mobile web app is an icon on a device’s home screen that links to a website that is optimized for a smartphone’s mobile browser. Currently, most web apps require connectivity (either Wi-Fi or cellular) for use, although this could change to the extent that web apps begin to use HTML5, Google Gears, or Widgets to deliver content.
So which is the better app approach? Sorry to disappoint, but the answer is, it depends. There are advantages and disadvantages to both shown in the following table:
- Support environment – Does the organization have the IT support infrastructure to support devices installed on mobile (remote) devices that may not be easily retrievable (e.g., physicians who practice one day/week at the hospital)?
- Device ownership and management – Are devices provided to end users by the organization or do users provide their own devices? Is there a narrow and tightly managed list of supported devices or is it a take all comers approach?
- Version control – Does the organization require lengthy internal certification before accepting newer versions of apps?
- The number of users – Does the need organization need to support the deployment and administration for a select number of users or many hundreds of users (e.g., an entire staff of physicians)?
- Connectivity – How widely available and stable is Wi-Fi and/or cellular connectivity (e.g., hospitals are historically inconsistent with respect to Wi-Fi and cellular access)?