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.
John,
No existing PHR/PHP, EHR or HIE platform currently uses a standardized and clinically integrated format to report all patient diagnostic test results to physicians and patients.
It’s ironic at a time when reducing unnecessary costs and waste in the current health care system is a critical national priority and there is a seller’s market for any member of Congress who has a credible plan or amendment to cut costs while also improving quality.
Using standardization and clinical data integration to more efficiently report, view and share the billions of annual test results in the United States would help to minimize duplicate and non-contributory testing costs, improve patient safety and satisfaction, foster widespread adoption by enhancing interoperability and usability and leverage the highest value from investments in all three HIT platforms.
The major reasons this hasn’t yet been achieved by any of the hundreds of HIT vendors are eloquently described by Clayton M. Christensen at: http://innovatorsprescription.com .
John, Interesting thought and good conversation to strive for but as Dr William Hershof OHSU once said “technology is not the problem”. The problem is getting Providers and patients to use the technology. We need a program to educate both groups to the real benefits and saving to utilize this technology. As for the Holy Grail, Interoperability that will take a while and with many false starts to get that moving. For hospitals and doctors there has to be real demonstrable cost saving to get there business to by in we are still talking about who owns a patients record. What we will need is a mandate, which may come with Health Reform.
As for the platform idea, I like and I’ve wrote about it and support it. The problem here is which platform do you choose, there will be many. But with real standards, protocol gateway and froward thinking this too is possible.
This is all achievable, we have the technology today. What will need to change is culture which is the hardest to change. March on!
Jeff Brandt,
motionPHR http://www.motionPHR.com for iPhone
myMedBox http://www.mymedbox.com for Android
How about the term:
PHR Platform
?
Vince,
The problem with so many TLAs. I have no problem with more TLAs as long as we don’t try to use them with patients because it causes confusion. You would have to explain what a Platform is. I have found that the K.I.S.S method is best when working with patients/consumers, Dumb it down.
If you mention EMR/EHR/PHR to almost any non-clinical person they will not know what you are talking about, I agree. But, If you say “Personal Health Record” they at least have an idea of the connotation. Everyone know what A health record is. I do get what John is saying and where he is going. I think there may be a better word than Platform for the public. It is possible that I missed the point on who this new term is directed towards.
Jeff Brandt motionPHR or maybe motionPHR Platform :’) http://www.motionPHR.com
Jeff, a year ago I would have agreed with you that term “platform” would confuse Joe the Plumber.
…not so sure now that iPhone has made term “app” a household term.
Even if specific term of “platform” isn’t right, the concept of a platform is important.
BTW, what’s a “TLA”? 🙂
V
Bob, thanks for you rcomment and couldn’t agree more. Do know of Clayton’s work, but honestly, not all that new, at least to me. Having worked in the IT space for many years, previous to founding Chilmark, worked in manufacturing sector. Within that sector, software vendors were loathed to adopt common standards for sharing data – still a big problem in certain sectors, e.g. sharing of CAD/CAM drawings among various systems. It is against the best business interests of software vendors to make this happen, maybe platforms like GHealth, Dossia or HealthVault, maybe even some other that has yet to appear will get around this issue.
Jeff, as to which platform to choose, not sure if that is the path to go down at this point. The main gist of the post here s to get the conversation to change from one talking about PHRs, which most definitions define as a digital file cabinet to a discussion of platforms that support/provide actionable information based on what is contained within an individual’s health data set.
And as for who the term “Platform” is directed to, tend to agree that it might be difficult for public to grasp, but honestly, they never really grasped PHR all that well, but they sure did grasp app and AppStore, so maybe the public is just a little more savvy than we typically give them credit for.
Vince, I abhor FLA (Four Letter Acronyms) thus the use of PHP. BTW, TLA = Three Letter Acronym.
John, When I got into HIT Healthcare IT (I hate that TLA) I did notice that FLAs were everywhere.
Standards are a difficult problem that only certifications can help but not solve. I still think it is a great idea, Maybe we should start the standards for such a platform
As for the App store, You give me the iPhone Appstore budget and I can have the public understand anything. Savvy and credit, as we say in the sailing world, “You just keep hanging onto that lifeboat” :’)
Great talking,
Jeff Brandt http://www.motionPHR.com http://www.mymedbox.info
The only real value of a PHR is if it provides a personal journal for the patient, Personal Health Management Tools (PHMTs) to help the patient manage his/her health, and it is tethered to the Electronic Medical Record (EMR), Hospital Computerized Patient Record (CPR. a Gartner Term), or EHR so as to be able to display labs, pharmacies, allergies and summary of care back in the PHR. Data entered in the PHR should be able to be written to the EMR, CPR, or EHR and annotated as such as “patient-reported data”, or data supplied directly from home medical devices. The PHR should also be integrated closely with secure patient to provide communications. Perhaps RelayHealth has the best combination of functionality? Lastly, the PHR should be CCD C.32 compliant, and not just CCR compliant.
Given all of this, I find it somewhat amusing that the EHR, CPR, EMR vendors have to supply the PHR to patients. If it truly is a PHR controlled by the patient, then the patient should choose his/her own PHR. To do otherwise almost reeks of the problems of paternilistic medicne, and not true consumerism. On the other hand, if the PHR is to be linked to the EHR, EMR, CPR, then the vendors of these systems may be in the best position to offer it.
Perhaps Google Health, Microsoft Health Vault, or the NHIN itself can offer standards-based PHRs as a web service on their exchange platforms.
But PHP is associated with the programming code (PHP, Java …) I think at some point people would have to make the difference between both terms….
I would prefer PHR Platform or PHPt.
Victor, I agree and it was the first think that I thought about; but that happens frequently with TLAs from different domains. I vote for PHPT
Jeff Brandt
http://www.motionPHR.com