PHRs are operating systems

Personal Health Record software is not really an application. It's more like an operating system.
Written by Dana Blankenhorn, Inactive

User Centric has a white paper out comparing the usability of Google Health and Microsoft HealthVault. (Picture from Tecni-Blog, a Spanish-language tech blog.)

The news is not good. Both rated poorly in terms of user experience. User Centric has followed up with a set of recommendations.

It occurs to me all this misses a rather important point, namely that Personal Health Record software is not really an application.

It's more like an operating system.

A PHR has to do many different things for many people. It must be able to take in data cleanly and seamlessly, sometimes automatically. That requires interfaces with hospital records, and with a host of consumer devices.  It may also require taking input from alternative therapists, like chiropractors.

Second it needs simple security, so that patients have notice and the ability to easily control who gets access to PHR data, and audit downloads. That's not as easy as it sounds, because lots of people should only get a portion of the record. Standards for giving the right people the right data have to be automated.

Finally a PHR needs a host of new user interfaces to make its data truly useful. Not just PC interfaces, but interfaces to iPhones and other devices. Ticklers to remind us when to take different pills, or when to check different conditions like our blood sugar. Applications that let us interpret data and take appropriate action, or that might alert those who need to take action.

Look at all these needs, all these interfaces, and a PHR quickly moves from being a form, to an application, to a personal health operating system. Building such an operating system will require an ecosystem of suppliers, projects built around database management, user interfaces, and around security.

So I think it's vital that the code be accessible by all the many stakeholders in this process, and that compatibility be assured. There is a long road ahead. The company which can manage this process best is going to win the market.

In this effort both Microsoft and Google have real assets to offer.

Microsoft has always been great at developer relations, and at helping developers build their business models through sales channels. Both these things are vital in the coming competition.

Google has shown a talent for gaining publicity, for using the open source process, and for building quality APIs. These, too, will be important.

Both competitors, as the illustration shows, also have a problem. Competition can lead to secrecy, can lead to proprietary differences, can lead to incompatibility.

So here's my final idea. The first of these to get their code, and their ecosystem, integrated with Open Health Tools is going to have a big advantage in this space.

Editorial standards