Google battles Microsoft for medical domination
Google vs. Microsoft? Some cavalierly portray the battle as merely a cat and mouse game over logoed tee-shirts!
While inconsequential “gotcha” games and “litmus” tests are fun, and easy fodder for laughs, Microsoft vs. Google is a world-class competition with universal reprecussions.
How about the health care industry as a monumental case in point. Pegged at a $2 trillion industry in the U.S., it touches every one’s life, and death.
Google declares war on $2 trillion health care industry I announced this morning. Dr. Google to the medical rescue? Adam Bosworth would have “health care consumers” believe so, but savvy ones will not.
The Google health care strategy echoes the typical Google diversification maneuver: Drive Google search love over to the latest Google game in town.
SEE: Google to big business: Google love belongs in the Enterprise! and Google aims to usurp campus email systems
While the Google VP of Engineering takes his medical case to the public to whip up a consumer frenzy for Dr. Google, however, Microsoft is going about its health care business the old fashioned way, taking the serious IT route.
The Connected Health Framework Architecture and Design Blueprint, "Microsoft's foundation for knowledge-driven health":
A system implemented according to Microsoft's guidelines would employ a common architecture—based on industry best practices and modern design techniques—to link patients, healthcare professionals, application developers, independent software providers (ISVs), and government agencies.
What is Google’s pitch? Who needs healthcare professionals, government agencies…Doctors don’t even rule, Google emphatically underscores, in Google's "vision" for the consumerization of health care!
The Microsoft IT blueprint:
After studying the healthcare industry at length through its work with customers, developers, and ISVs, Microsoft identified the top 10 issues any comprehensive e-Health system must deal with. They are:
Creating patient health records, Building life-long health histories for patients from information stored in multiple diverse systems, Managing identity and authorities, Identifying patients and healthcare providers, "Joining up" different systems on different platforms, Interconnecting diverse systems so they are interoperable, Communicating with remote systems, Reusing legacy systems, Achieving flexibility and agility, Achieving performance and scalability.
To meet these requirements, Microsoft's "vision" for knowledge-driven health incorporates three core capabilities:
1) Connected software systems that span applications, devices, services, and healthcare organizations to streamline processes and improve knowledge sharing and reduce costs.
2) Information-driven software that dramatically improves the way healthcare workers find, organize, and act on information.
3) Improved collaboration for healthcare workers and patients through rich interfaces, including high-quality audio, video, and natural language.
Microsoft underscores:
Microsoft created the Connected Health Framework Architecture and Design Blueprint to facilitate the emergence of an ecosystem of healthcare solutions that deliver on those capabilities. Developers and independent software vendors are invited to create e-Health solutions that deliver agile healthcare processes on a stable technological foundation.
Ceation of an integrated e-Health system based on the Microsoft Connected Health Framework does not require the use of individual Microsoft products, but such a system could be built entirely with off-the-shelf Microsoft solutions.
Google’s Google solution for the "authentication of medical data":
Google Accounts authentication for web-based applications allows the application to access a Google service protected by a user's Google account. To maintain a high level of security, the Authentication Proxy interface, AuthSub, enables the application to get an authentication token without ever handling the user's account login information. Using the proxy, the user of the web application logs into their account through a Google-supplied login page and consents to grant limited access to the web application.
The authentication process flows as follows:
1) When the web application needs to access the user's Google service data, it makes an AuthSub call to the Google Accounts URL.
2) Google Accounts responds with an "Access Consent" page. This page prompts the user to log into their Google Account and grant/deny access to their Google service.
3) The user logs into their Google account and decides whether to grant or deny access to the web application. If the user denies access, they are directed to a Google page rather than back to the web application.
4) If the user successfully logs in and grants access, Google Accounts redirects the user back to the web application URL. The redirect contains an authentication token good for one use; it can be exchanged for a long-lived token.
5) The web application contacts the Google service, using the authentication token to act as an agent for the user.
6) If the Google service recognizes the token, it will supply the requested data.
The Authentication Proxy diagram shown below illustrates interactions between the three entities involved: web application, Google servers, and the user.
Developers can opt to handle authentication with either secure tokens or non-secure tokens. The use of secure tokens requires that the web application be registered with Google and file a certificate; if registered, the web application can secure all requests referencing an authentication token with a digital signature.
GOOGLE VS. MICROSOFT: WHO WILL RULE OUR MEDICAL FUTURE?