Posted by Lygeia Ricciardi on October 20, 2007
“With enough eyeballs, all bugs are shallow.” Roughly translated, a large enough number of minds can solve any technical problem. Such is the perspective of open-source advocate Eric S. Raymond.
If ever a morass of problems needed the input of many minds, it is the US health care system. In the next couple of months Elliot Maxwell, an author, lecturer, and IT strategy advisor, will publish a paper called “Openness in Healthcare” commissioned by the Committee for Economic Development, a non-profit economic and social policy research organization.
The paper explores the concept of openness in health care from many angles, including biomedical research—like the collaborative process behind mapping the human genome; access to data from ongoing clinical trials for drugs and devices; and the implications of EHRs, PHRs, and the information-sharing culture they encourage. According to Maxwell’s Rule, “the team with the most smart people wins." Yet he does not argue that greater openness is a necessary or even positive condition in all circumstances.
The paper opens the reader’s mind to new ways of approaching old problems. It also includes policy recommendations regarding areas in which Maxwell believes greater openness is most likely to have a positive impact. He has offered to make “advance” copies of the paper available to readers of the Project HealthDesign blog upon request. If you want one, please submit a request to this blog via the “post” function (I won’t post your request unless you include a comment).
So how does openness apply to Project HealthDesign and its grantees? Steve Downs, the Robert Wood Johnson Foundation program officer overseeing the project, has several ideas. First, Project HealthDesign is built on the assumption of an (eventual) open flow of health data. Though HIPAA gives people the right to ask for their health records, the information is typically not available in digital form. At some point, if PHRs are going to be successful, we’ll need the ability to download our personal health data, in a standard format, from all of our providers. Clearly we have a ways to go.
Another relevant aspect of openness is the concept of open source. As the grantees know, any creation resulting from Project HealthDesign must be either placed in the public domain or licensed as open source, meaning that the software “source code” is publicly available with few (or no) intellectual property restrictions. As Downs says, “Some of the teams are solving problems that others will encounter in ways that are generalizable—making those solutions publicly available is the best way to leverage their impact.” His hope is that access to the inner workings of nine cutting-edge PHR applications will catalyze development within the broader PHR industry.
On a related point, Downs points out the desirability of providing access to application programming interfaces or APIs to PHR services. APIs are interfaces that enable developers to write software that can communicate with or draw on the resources of the service that offers the API. For example, Microsoft has an API that enables developers to write programs that work with Windows. Similarly, Google Maps has an API that developers use to integrate mapping interfaces in their web sites. If services that maintain PHRs offered APIs, then developers, such as the Project HealthDesign grantees, could build tools that draw on the data stored in the PHRs. That way, not everyone who wants to build a better medication reminder service needs to solve the problem of how to get access to the current meds list–they can simply write to the API of the PHR provider and request the meds list.
As Elliot Maxwell points out in his paper, openness is not an absolute value, but a spectrum of possibilities. A question for Project HealthDesign grantees and others developing PHRs: Are there ways in which openness has been a help or a hindrance in your work? Do you have ideas about how the status quo should be more—or less—open?
