I recently had the opportunity to speak with Henry J. Feldman, M.D., instructor of medicine at Harvard Medical School at the Beth Israel Deaconess Medical Center (BIDMC). Dr. Feldman also serves as Chief Information Architect in addition to practicing as a hospitalist at BIDMC.
Dr. Feldman discussed BIDMC’s platform-agnostic mobile strategy, whereby clinicians access all HIS data through the browser of whatever device they happen to be using. Talking to Dr. Feldman was a far cry from talking with certain app-crazed technologists, who recoil at the thought of using the browser to deliver information into a busy doctor’s workflow. At BIDMC there are no cool mobile apps, just web forms (Ajax is not welcome either).
This is not a story of antiquated technology. I would consider BIDMC to be a lead user in the field of HIT and wireless health as they develop the majority of their systems in-house, have very large IT and informatics departments, and house the likes of globally recognized HIT leaders like John Halamka. (Full disclosure: I have been a fan of BIDMC since CEO Paul Levy co-taught my class ‘Economics of Health Care‘ at MIT.)
According to Dr. Feldman, BIDMC’s platform-agnostic architecture is working wonderfully well for them, and BIDMC has no need to jump on the app bandwagon.
Why Not the BrowserOne argument I have heard for shunning browser architecture is that the web-based user experience for a lot of clinical software is paltry – that the true potential of native UI is not realized. Another argument centers around network connectivity, for example: “Wi-Fi doesn’t reach the basement of our hospital”, or “10 days of patient data has to be stored on the device – we can’t take chances with the network”.
Tackling the user experience argument: Most mobile browsers use the Webkit rendering engine, which renders UI widgets with the same look (but not always the same feel) as native widgets. For a well designed webpage, this means consistency between the platform UI and the browser UI, something that nearly everyone prefers.
Now on to connectivity issues: BIDMC has invested heavily into its network infrastructure, creating a highly available, secure, very fast network. The result is that clinicians have high levels of confidence in accessing data through the browser anywhere at anytime within BIDMC.
It is a different story, however, when a doctor is out of range of the BIDMC network, where she doesn’t have the same talented networking team working for her. Also, most hospitals don’t have a true medical grade wireless network like BIDMC. What may help here is the FCC’s recent announcement on the use of white-space (vacant analog TV airwaves), leading to wi-fi on steroids in the not so distance future.
Thinking of some of the headaches avoided by using a browser-based strategy:
- No client to install and support on the end-device. Lowered complexity and fewer points of failure.
- No possible way to store data on the device. This means no complex mobile device management because of privacy/security risks.
- No worries about who will win the smartphone and tablet wars. If a device has a browser it is supported.
Of course, everything is a trade-off and while BIDMC has thrived with a platform-agnostic philosophy, this may not be the best strategy for all hospitals seeking to roll-out mobility to their clinicians. In Chilmark’s upcoming report, “Enterprise Adoption of mHealth Apps: Trends, Issues and Challenges”, we’ll dive into the specific factors that would benefit a hospital to choose one architecture over the other, and highlight the trade-offs involved.
This week I look forward to visiting Kaiser Permanente Garfield Center for HealthCamp 2010, and Health 2.0 in San Francisco with John. It is going to be a busy week!