Yesterday, we outlined why the PHR term has the potential to stunt future advances in consumer health and engagement via HIT. Our thesis is that the PHR term is rooted in a dated concept of simply providing the user/citizen a virtual file cabinet for their health records. Since the initial introduction of Internet-based PHRs nearly a decade ago, adoption has been by and large abysmal. Our belief is that adoption, or lack thereof, is symptomatic of PHRs not having a sufficient value proposition for the vast majority of potential users.
But where we really get concerned with the PHR term is that in the meaningful use recommendations that were accepted in July. Under meaningful use guidelines, those obtaining Stimulus (ARRA) funding for adoption of a certified EHR must provide a PHR to their patients by 2013. Trouble here is how will HHS define what that PHR is? Last year, HHS paid a princely sum to have the PHR term defined (see below). This term, we have been told, is what will be used within the context of meaningful use rule making. If this is indeed true, adoption of PHRs will continue to be lackluster.
PHR, Personal Health Record: “An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.”
To move beyond the limitations of this definition (and the baggage that goes with it) Chilmark proposes a new term, Personal Health Platforms (PHPs) with the hope that others will pick up the banner moving us beyond where we are today and hopefully get HHS to look beyond the narrow confines of the PHR definition that they have before them.
What is a Personal Health Platform?
Our proposed definition is as follows:
A Personal Health Platform (PHP) is an Internet-based platform that securely stores and manages a citizen’s personal health data, data that may be derived from multiple sources including among others clinical systems, payer systems, self-enter data, and biometric. The PHP also provides the framework and capabilities to support applications, services and/or tools that a citizen may invoke to leverage their personal health data enabling the citizen to make better, more well-informed decisions regarding their health or the health of a loved one.
The second sentence of that definition is the key differentiator. A PHP does more than simply store the data, it makes that data actionable.
While the acronym may be new, at least in the context of healthcare, the concept is not. There are a number of examples of PHPs in the market today with WebMD arguably one of the most well-known. Microsoft’s HealthVault, Google Health and Dossia are other examples of PHPs. One could even argue that tethered systems such as Kaiser-Permenante’s MyChart is a PHP for MyChart provides a wide range of services to K-P members. In each of these examples, the PHP is not just a repository for health data but provides users various tools, apps and services that leverage that data to enable a deeper level of engagement, something a PHR, as defined above, cannot do.
As an example, Sean Nolan, Chief Architect for HealthVault recently talked about how one might leverage HealthVault ecosystem partners medLAB and Keas leveraging lab data to create personalized care plans. Another example is the recent partnership between Medikeeper and change:healthcare wherein change:healthcare will become a widget on a citizen’s Medikeeper dashboard enabling the citizen to make wiser, more cost effective health decisions that are based on health data stored in a Medikeeper account.
Now that we have introduced the term PHP, and the justification for the need of this term in future policy discussions, our next step is to create an ontology for the PHP market. You’ll have to stay tuned for that one which we hope to get out next week between our trip to the AHRQ conference and the Health Data Management event in Boston.