Story in today’s Boston Globe that highlights the experiences of a cancer patient, David Debronkart, who exported his medical records from Beth Israel Deaconess Medical Center (BIDMC) to his Google Health account. His experiences, which he discusses at length (beware, it’s a long post), exposes a very real problem we have today in the healthcare sector, that of inaccurate data – the old “Garbage In, Garbage Out” problem, though in this case it is the inverse, Garbage Out, Garbage In.
There are many potential sources of healthcare data (claims, clinical, PBM, self-reported, biometric, etc.) that a consumer might use to populate their PHR. Today, however, the most prevalent source (we estimate 80%) is claims data as it is digital, and both employers and payer sponsored PHRs can use it readily in their offerings to employees/members. And as in the case BIDMC, it is what they push to Google Health at a customer’s request. Problem is, claims data is based on limited code sets (ICD-9) that physicians use for reimbursement. This can lead to inaccurate entries/codes as physicians struggle to fit a diagnosis to a given code or possibly prescribe a drug for off-label use, or even “game” the reimbursement system. Either way, end result is an inaccurate picture of the consumer’s health.
Now some may argue that this is exactly the reason we need PHRs that are tethered to an EMR. EMR data does not necessarily rely on claims codes and could provide a better, more accurate view of the consumer’s health. Problem here, as we have outlined before, is that tethered PHRs do not aggregate consumer health data from multiple care providers for a full longitudinal record, only the data from those associated with the entity using the EMR to which the PHR is tethered. These tethered PHRs also do not support portability (MyNYP.org breaks from this tradition, thankfully) which in untenable.
Big Question is: Will Inaccurate Data Stall PHR Adoption?
Consumers are just beginning to wake-up and realize that maybe taking more control of their health records is a good thing. We are still very much at the early adopter stage with only some 3.5% of consumers using an Internet-based PHR today, but we are beginning to see a measurable uptick in adoption, best represented by Kaiser-Permanente who now has nearly 50% of members actively using the KP PHR.
Challenge in the PHR market from day one though is: How do we provide compelling value within the context of a PHR for the average consumer to encourage use? A primary component of that value proposition has been: Let’s help the consumer by pre-populating the PHR with healthcare data and automating the process for future updates. The consumer can then use this data as the basis to better understand their health, their risk profile, assist in engaging the healthcare industry and even help them manage a chronic disease or more importantly, prevent them from contracting such a disease.
But this value proposition may quickly unravel if upon entering their brand, spanking new PHR a consumer finds the kind of inaccuracies that Dave found in his experience with Google Health. How many consumers will go to the trouble of trying to correct the PHR by either annotating each data field that is wrong (and even if they do that, would another physician looking at the PHR trust it?) or contacting the source of the erroneous data to have it corrected, which we imagine would be a Herculean task. Our guess is few would be willing to take on this task and simply walk away from the PHR.
At least two things need to happen to maintain PHR adoption growth.
1) In the near term, we need to begin setting appropriate expectations for the consumers i.e., yes, we have done the best job to provide you an accurate portrait of your health via your records, but there may indeed be inaccuracies that you will need to identify and correct.
Along with setting expectations, we need to provide tools for the consumer that allow them to make necessary corrections (annotations) to their records and a process whereby a trusted source (e.g., physician or other care provider) verifies such changes are correct. Will Crawford of IndivoHealth believes that a good starting point is to simply point out to the consumer what types of claim data sets (codes) are known to be problematic that may require their attention. A great idea to move along this path.
2) Longer term the adoption of ICD-10, which will assist in insuring that claims data is more reflective of actual diagnosis and treatment, combined with wide-spread adoption and meaningful use of EMRs via the HITECH Act have the potential to significantly increase data accuracy and liquidity. This, in turn, will facilitate the consumer’s ability to access and aggregate accurate health data and eliminate the need for those actions listed in Number 1.
Looking even farther down the road though at PHR adoption…
While data may indeed be the foundation of any PHR, it is hardly compelling, engaging and unlikely to drive adoption in any significant fashion. For far too long, most PHR providers have focused on the data issue and not what a consumer will find of value. This is simply a legacy of most PHRs in the market today that were built by physicians. Such simple solutions we give the moniker of PHR0.25. Adding associated content brings us to PHR0.5. Combining some journaling and disease management brings us to PHR1.0. You get the idea.
The slow evolution and growth in the PHR market is partly a function of low market demand (consumers rarely engage in their health at that level) and poor solutions that offer only modest value. For adoption to continue to accelerate, PHR vendors need to begin thinking beyond the PHR construct that is prevalent today. A new model is required that divorces itself from the old model striking new ground and offering a compelling new value proposition. With Google Health (if it gets its act together) and MS HealthVault now doing the heavy data lifting work, developers have a unique opportuntiy to refocus their resources and create new and compelling solutions that truly engage the consumer and provide direct, measurable value.
Thanks John! (Although I’m ex of-Indivo, which has gone back to the research domain).
John, this is one of the reasons that we like using the “package and reconcile” model for pulling data into HealthVault.
In this model the user receives a “package” of data from a source in the form of a CCR or CCD document. Within this document can be many different individual data elements, all bound together as a snapshot of what that source belives to be true. These snapshots remain in HealthVault, and are useful for many purposes just as they are.
The user then has another choice — they can “reconcile” the package by looking at the individual items and choosing which ones should be extracted into their record.
A few nice things about this approach:
* Users have a well-defined place to make decisions about what elements they want to move over and which are wrong. Right now our “reconciliation” process is pretty manual, but as we go forward we expect to do smarter things … for example, this would be a great place to hilight questionable codesets per William’s idea.
* It bounds the “dirty data” problem so that users can benefit from all sources without worrying that their records are going to become polluted with errors.
* It turns out that sometimes the package is what people want to deal with — for example, a referring doctor that wants to see the result of surgery at NYP probably wants the digitally signed CCR from that visit, not the user’s all-up history.
Your readers can see some snapshots of our reconciliation interface as part of the HealthVault Nickel Tour … look for the “integrating information” part of http://blogs.msdn.com/familyhealthguy/pages/the-healthvault-nickel-tour.aspx .
Anyways … there is no perfect solution right now, but we are all making progress. Momentum is good, and I hope that the outcome of Dave’s experience, rather than any slowdown in adoption, is that we start to see real consumer demand for more transparency so we can FIX the problems that are in the system.
—S
Added to EHRLinks.com
I am a member of the HL7 EHR, PHR and RM-ES (Records Management and Evidentiary Support) workgroups. Discussions there are now focusing less on accuracy and more on source control. There will always be inaccurate information in a patient’s EHR and PHR. Of course we need to do what we can to minimize inaccuracy, but it will always be there. What is more important (in my opinion and that of others) is that the source of the information be known to any reader/recipient. Mistrust by clinicians of PHR data is more closely tied to uncertainly of the data source than it is to questions of its accuracy.
If the recipient is able to reliably identify the source of the data, he/she is able to make a decision about how much trust they put on the data. Without knowing the source, the accuracy is a moot point since it almost certainly will not be trusted.
Nathan,
Thanks for your comment and you are correct, knowing where the data comes from and whether or not it has been altered is critical for trust, not only clinician trust in the data but patient/consumer trust as well.
While I have not been a big fan of certification initiatives, such as CCHIT’s for PHRs, there is a need for PHRs to clearly identify the source of PHI in a given PHR – is it clinician derived, patient derived, loved one etc. Such clear data tagging will help build trust on both sides of the current divide.
But more broadly speaking, believe the terms EHR, PHR, etc are artificial. THere is only one record, which we have begun calling a CHR, collaborative health record. Terms such as PHR, EHR create artificial divisions and are no longer relevant.
I like the CHR approach, but would argue that the PHR/EHR divisions are still relevant…at least in the eyes of the providers. Unfortunately, it is the physicians that seem to be hesitant to accept a close PHR/EHR integration. There is a widely held belief among many healthcare providers that patients can modify/edit data in the PHR in such a way that future recipients of that data will be unaware of the changes. While this may not be true with many of the PHRs, it is a reasonable fear considering the number of PHRs that have sprung up. With no standards to control their operation, there is nothing to prevent a PHR vendor form allowing it.
In my opinion, proper certification of PHRs is essential to alleviate those fears. It is the healthcare providers that will eventually make the PHR part of a true CHR…and right now, they are not universally on board.
There are widely accepted standards for EHRs being developed, but PHR stardards still lag behind…but we are working on them.