Archive for the 'PHR' Category

The announcement that Google Health was being discontinued shouldn’t be a surprise. In March the Wall Street Journal reported that once Larry Page took over the CEO role at Google he would be looking to cut projects:

Some managers believe Mr. Page will eliminate or downgrade projects he doesn’t believe are worthwhile, freeing up employees to work on more important initiatives, these people said. One project expected to get less support is Google Health, which lets people store medical records and other health data on Google’s servers, said people familiar with the matter.

There have been a number of retrospectives written today already, most concerned with the future of PHRs. For example:

It just goes to show you that being a pioneer does not guarantee long-term success. Microsoft HealthVault has done a much better job with device integration than Google Health did. There are many other factors that will determine the viability of PHRs in general though. Adoption by the general population and a revenue model to support growth are just a few.

Why did Google Health fail? Simple and obvious: consumer demand for personal health records is close to zero, which has always been the case and probably always will be.

Probably true.

Google predictably did what its know-it-all technology company predecessors have done over the years: dipped an arrogant and half-assed toe into the health IT waters; roused a loud rabble of shrieking fanboy bloggers and reporters…

OK, but how do you really feel?

Seriously though, I think Google’s foray in the Healthcare space was no different then how they approach any other market: “If we build it, they will come.” If they don’t come, we pull the plug. Google has a graveyard full of products that suffered the same fate.

I mean “hackable” in the sense of the word that is quickly growing in popularity: allow owners of a product to manipulate, re-purpose or add to the functionality of a product to serve their own personal needs.

Ms. Wray asks:

Doesn’t it make sense to allow patients to put the technologies together in a way that meets their needs?

Their own needs? Maybe yes, but probably not.

The biggest incentive for innovation will be where someone sees an opportunity to meet a lot of other people’s needs. This may well be for group that shares a common problem or aliment with the technologist(s). The initial intent may be altruistic, but real growth will only take place when a market emerges. This is the reality that could lead to significant new health data management solutions.

The device, consisting of interfaces that can feed-in data such as blood pressure, pulse rate, ECG reading and weight from the respective devices, is connected to the gateway that would format it into standard patient information and transmit it to either public health data platform such as Google Health or to private platforms like Microsoft Health Vault.

What exactly is “standard patient information”? Maybe they’ve finally developed the magic interoperability bullet. Yeah, right! I’m sure companies like Capsule see these kind of claims all the time. Statements like these are unfortunate because they give the impression that health data interoperability is a given. Of course we know that is not the case.

But by 2020, when a vast majority of American health providers are expected to have electronic health systems, the data mining component alone could generate sales of up to $5 billion…

The magnitude of data needed to generate that kind a revenue is significant. The likelihood that “de-identification” of someone’s health information will occur is very high. “Anonymized” Data Really Isn’t points out the same thing that the NYT article does:

Computer scientists over the past fifteen years show that it is quite straightforward to extract personal information by analyzing seemingly unrelated, “anonymized” data sets.

I was recently browsing in the computer (nerd) section of the bookstore and ran across an old Joel Spolsky edited book: The Best Software Writing I. Even though it’s been about four years, good writing is good writing, and there is still a lot of insightful material there.

One of the pieces that struck a cord for me was Adam Bosworth’s ISCOC04 Talk (fortunately posted on his Weblog). He was promoting the use of simple user and programmer models (KISS — simple and sloppy for him) over complex ones for Internet development. I think his jeremiad is just as relevant to the current state of EMR and interoperability. Please read the whole thing, but for me the statement that get’s to the point is this:

That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion.

Why is it that when I read “demanding, abstract, rich but systematized” the first thing that comes to mind is HL7? I’m not suggesting that some sort of open ad hoc system is the solution to The EMR-Medical Devices Mess. But it’s painfully obvious that what has been built so far closely resemble “great creaking rotten oak trees”.

The challenge for the future of Healthcare interoperability is really no different than that of the Internet as a whole (emphasis mine):

It is in the content and the software’s ability to find and filter content and in the software’s ability to enable people to collaborate and communicate about content (and each other).

I would contend that the same is true for medical device interoperability. Rigid (and often times proprietary) systems are what keep devices from being able to communicate with one another. IHE has created a process to try to bridge this gap, but the complexity of becoming a member, creating an IHE profile, and having it certified is a also a significant barrier.

Understanding how and why some software systems have grown and succeeded while others have failed may give us some insights. Flexible, Simple, Sloppy, Tolerant may be a dream, but it also might not be a bad place to start looking for future innovations.

… we have heard people say that it is too hard to build consistent standards and to define interoperable ways to move the information. It is not! … When we all make this vision real for health care, suddenly everyone will figure out how to deliver the information about medicines and prescriptions, about labs, about EKGs and CAT scans, and about diagnoses in ways that are standard enough to work.

We don’t have to wait for new standards to make data accessible—we can do a ton now without standards. What we need more than anything else is for people to demand that their personal health data are separated from the software applications that are used to collect and store the data.

Use of an open-source framework approach is probably as good as any. As a management model, I don’t see it as being that much different from the way traditional standards have been developed. Open-source just provides a more ad-hoc method for building consensus. Less bureaucracy is a good thing though. It may also allow for the introduction and sharing of more innovative solutions. In any case, I like visions.

USB plug-n-play (plug-n-pray to some) may be a reasonable connectivity goal, but it does not deal at all with system interoperability. Sure, you can connect a device to one or more monolithic (and stable) operating systems, but what about the plethora of applications software and other devices? This just emphasizes the need to get out of the “data port” (and even “device driver”) mind-set when envisioning communication requirements and solutions.

The Health Guide stores and displays the collected information on a touch screen and sends to a secure host server, where health care professionals can review the information. Patients using the Health Guide can monitor their health status, communicate with care teams and learn about their medical conditions.

There are many health conditions that would benefit from improved remote monitoring capabilities, but heart disease is certainly at the top of the list and has been shown to reduce hospital re-admissions. Holter monitoring has been around for a long time, but this type of embedded ECG hardware and software technology along with interactive devices like the Intel Health Guide, could significantly raise the bar for ambulatory patient heart monitoring. Companies like CardioNet are already counting on this trend.
It’s a good bet that PHR providers like Google Health and Microsoft HealthVault will start to incorporate similar interactive technologies into their offerings. Also, Microsoft offers a device certification program that will draw in more devices. Google has similar developer and branding policies in place (see here).

If you use any of the Google applications (like Gmail), it’s just as easy as all the others:

It will be interesting to see if this and HealthVault have an impact on how patients interact with their medical service providers. The privacy and security issues are certain to remain a significant barrier to adoption. Only time will tell.