The promise and perils of platforms

In their New England Journal of Medicine Perspective, Drs. Kenneth Mandl and Isaac Kohane suggest learning lessons from other fields that have seen large-scale IT successes:

An essential first lesson is that ideally, system components should be not only interoperable but also substitutable.

The Apple iPhone, for example, uses a software platform with a published interface that allows software developers outside Apple to create applications; there are now nearly 10,000 applications that consumers can download and use with the common phone interface. The platform separates the system from the functionality provided by the applications. And the applications are substitutable: a consumer can download a calendar reminder system, reject it, and then download another one. The consumer is committed to the platform, but the applications compete on value and cost…

The platform approach to software design can be used to create and sustain an extensible ecosystem of applications and to stimulate a market for competition on value and price. We believe that the Department of Health and Human Services (DHHS) should encourage the development of such a platform for health care — one that will support applications for communication and computation that span the domains of clinical care, public health, and research. There are early-stage examples of platforms in health care already. For instance, the emerging model of personally controlled health records (PCHRs) is based on a platform that has been adopted by Microsoft and Google, as well as by the Dossia consortium of large employers for its rollout of the Indivo product to employees of consortium companies. There is now an active marketplace of enterprises building PCHR applications.

The authors have a point, but my personal experience illustrates some of the tradeoffs of this approach.

I use a Macintosh computer and its Mac OS X operating system as a platform. Apple makes lots of applications but I only use the ones I like, such as GarageBand, iTunes, and iPhoto. But I use Thunderbird instead of Mail, Firefox instead of Safari, Google Apps instead of MobileMe, and a Blackberry instead of an iPhone. I have good reasons for each of my choices, but overall I’m not sure I’ve done the right thing.

For example, it’s extremely hard to sync my Blackberry and Mac, even though theoretically I can choose from lots of free and cheap sync programs. I much prefer the Blackberry’s keyboard to the iPhone touchscreen, yet I’d also like to keep my contacts and calendar up to date. As another example, when I have a photo I want to email, iPhoto wants to use Mail, and so on.

So while it sounds great for a physician to choose an EHR from one vendor, a billing system from another, and a prescription-writing program from a third –as the authors suggest–  practices might be better off with one integrated, well-supported system that supports their core needs. Then they might selectively choose specialized add-on’s, such as advanced clinical decision support tools where having something different is worth the trouble.

Kind of back to the future like Windows with Microsoft Office, which does the job even if it’s a pain in the neck and expensive.

April 7, 2009

2 thoughts on “The promise and perils of platforms”

  1. One of the examples used in the article – Apple’s AppStore for the iPhone – may represent an intermediate model, with more central control than Apple exerts on the Macintosh, but not monolithic control as in Microsoft Office, in which, BTW, the various applications integrate rather poorly.

    The authors didn’t mention one of the more powerful arguments for open architecture – decision support software. The natural scale for online textbooks or programs to help with diagnosis is global, and it would be highly inefficient for each EHR company to try to reinvent the wheel and provide their own material of this sort.

    It is always hard to choose an analogy perfectly, but the AppStore metaphor may get the degree of central control right in this instance.

Leave a Reply

Your email address will not be published. Required fields are marked *