The Potential of Personal Health Records (PHRs) - Part 3 of 3

In my previous two posts, I summarized a deep conversation with a group of knowledgeable people about PHRs. I then offered an innovative, low cost, uncomplicated solution to deal with the concerns others raised. Following is a continuation of the discussion.
One commenter wrote:

…In reading about PHRs (or EMRs) I often end up wondering if the underlying premise is faulty. Many existing electronic records seem more like simple the health record equivalent of "brochureware;" putting the paper record up in a pretty online version, perpetuating rather than re-imagining the concept. [As I see it,] there are three key pieces to a PHR/EMR: the source data, how the data is authored/generated/input, and which data gets presented when to whom. (I suppose the analytics that act on the data are a fourth crucial piece). The third piece is truly a CRM [(customer relationship management] question, and the solution does not need to be a monolithic structure that tries to have all answers to all questions presented at once. It may be a bundle of solutions, looking and acting completely different for different users or even for the same user at different times. [We need] PHR solutions that break the existing paradigm.

I replied:

I'd add a fifth key piece, i.e., how to exchange/share the data securely and efficiently between disparate applications without busting silos. Also, when it comes to presenting the data, in addition to tailoring data sets to user needs, there should be a focus on how the same data get presented differently to different users (e.g., mapping terminologies to user roles, such as providing explanations for technical terms to patients). And I like the analytics to be tied to evidence based guidelines the provide decision support and instruction.

This requires a paradigm busting PHR solution in which bundles of solutions are made available. So, what we need is a flexible, affordable, modular solution that enables many different applications to work together (interoperate), which is the very kind of system I've been advocating using a pub/sub node-to-node architecture for exchanging encrypted data files, and using template-based PHRs to consume those data files, as well as to connect to most any third-party software programs and data stores.

Another commenter then wrote:

We need to keep in mind that, not until the focus of healthcare and wellness is changed one from being reactive & curative [to one focusing on] preventive healthcare strategies [for both] physical & mental health.

I agreed, stating that it is crucial to integrate sick-care with prevention/well-care from a mind (psychological) and body (biomedical) perspective.
I then responded to an earlier comment about PHRs in public clouds, PHR functionaliy, and consumers' willingness to enter data into PHRs:

Using public clouds using a centralized database for PHRs poses a security risk that has not been adequately addressed, although private clouds—e.g., behind a provider's firewall—appear more secure. And I still contend that local storage of encrypted data files makes the most sense in terms of security, accessibility and portability.

I also think that the best way to provide multifaceted ever-evolving PHR functionality is through PHR add-ons, i.e., applications that can be used in conjunction with any PHR to fill its function/feature gaps.

With regard to the willingness of consumers to enter data into a PHR, I suggest another factor has to do with the usefulness of the data being entered. If people believe it will help them (and their providers) deal more effectively with a health risk or problem, and for less cost, the more likely the person will spend the time doing it. If it's just a glorified medical record that mirrors what's in EMRs/EHRs, then there less incentive to do so.

Another commenter wrote about problems with PHRs from a practitioner's point of view, to which I replied:

The incentive to divulge "proprietary data and methods of the individual practitioner and/or the institution providing care," imo, depends on who gets the data and how it is used. Let's say, for example, that a primary purpose of HIEs (Health Information Exchange) is to be warehouses/repositories that accumulate and aggregate extensive data sets of biomedical, psychological and environmental patient PHI in de-identified form, along with the associated plans of care (both sick-care and well-care/prevention data http://wellness.wikispaces.com/Tactic+-+Well-Care+Sick-Care+Integration ).

Such an HIE would include disease registries, biosurveillance and treatment outcomes databases. Analyzing these data would provide key information helping to protect public health and enabling comprehensive treatment cost-effectiveness research that focuses on identifying and refining the evidence-based guidelines (protocols, pathways, treatments/procedures) most likely to be of greatest value to each patient/consumer dealing with a particular condition or risk factor. In this case, both patient and provider data are necessary, and, as such, the providers' identification could also be hidden (i.e., by de-identifying the treatment-related data). An HIE should not, on the other hand, be a centralized database of identifiable PHI since that would be silo-busting, which has many negatives as I've previously discussed. In any case, the kind of incentive you suggested (payment token) could help facilitate it.

And I responded to comments about the lack of usefulness of PHRs this way"

If a PHR actually helps a person handle their physical, mental, emotional and spiritual lives in a way that improves their health and quality of life, then it's useful. That's because there would be a significant difference in the data the PHR contains and the feedback & guidance the PHR provides. For example, in addition to the typical biomedical data and observations of daily living (ODL), the PHR would include substantial PHI regarding a person's emotional state, beliefs systems, interpersonal relationships, behavioral tendencies, etc., which are not part of any EMR/EHR, and some of which the person may not want to share with a physician (and which the physician may not need or want to know). So, it has to do with one's vision of what a PHR should/could be.

Bottom line: We've got to think in a whole different way about what PHRs should be!