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

I've been involved recently in an interesting virtual discussion (at this link on LinkedIn) that focuses on personal health records (PHRs). This begins a multi-post thread about key issue concerning PHRs that we've been examining.

1. Quite a few comments referred to the need for PHRs to have real value for the patient (or a loved one) that provide value add by:

• Providing data collection, analysis, feedback , instruction, follow-up care, decision-support tools, and patient-provider communications (e.g., instant chat, recorded voice, email/message, etc.) that:
  
  • Help individuals and their loved ones deal efficiently and effectively with their personal problems, including medical conditions, physical pain and psychosocial issues in order to improve a patient/consumer's health status (outcomes), save him/her money & time, and cut down on medical errors, omissions and unnecessary or ineffective treatments
  • Supply clinical data consist with Continuity of Care Documents/Records (e.g., diagnoses, medication lists/medication reconciliation data, allergies, problem lists etc.
  • Focus on prevention and self-maintenance (i.e., wellness) for even healthy people by including personally managed custom health/wellness programs, targeted incentives, health education, point of care updating and risk analysis, compliance and adherence motivations, and assistance in dealing with other personally (dis)stressful problems
  • Create empowerment and engaging experience for one's health management
  • Enable baby-boomer to help their aging parents and children who are in college through the healthcare process as needed.
• Using social media to connect people and promote digital collaboration with their entire care team (primary, specialists, nurses, mental health, holistic med) and personal support network (friends, family, and those that are similar to them/social network) in order to nurture support/encouragement and to educate
• Assisting with appointment preparation & scheduling, pharmacy, and insurance claims processes
• Being interactional and easy and convenient to use (so simple to use "a caveman could do it").

2. PHRs must be flexible and evolving, connect/integrated with EHRs/EMRs, and accommodate any relevant standards by:

• Being customizable and modular and used on an "agile" platform that enables it to connect with most other applications
• Automatically sharing data with providers' EHRs (i.e., PHR-EHR integration):
  
  • One possible solution is providing database synchronization where there is a big central database on the server side (e.g., an HIE) and a large number of small databases each residing on a device; the central database contains data for all the devices while each device's local database only contains the device's private data and some shared data
  • Another is having the PHR contain actual data or pointers to that data that the patient could either hand to a provider on a flash drive, deliver via an e-mail attachment or URL, or download directly into the provider's EHR from a secure, authenticated site; the PHR could then become the individual's HIE
  • And the problem will continue as long as EHR companies are still building silos—no one has stepped forward to create a truly interoperable network and each continues to build its respective silo and wants control of the patient data.
  • Able to use HL7 and all other data exchange standards.

3. PHRs data must be controlled by the patient: The patient should be able to control what types of information go to which source; this should be automated so that only the only portions shared are those required for the appropriate level of the transaction with patient in control [note that this is a disputed point]

4. PHRs must have provider tie-in:

• PHR adoption has to be driven from the provider side or we don't have complete solution; we need to provide for a environment that allows for that interaction and communication because patients do not have true access to their own medical information
• Certain information in a PHR must be truly useful to the provider (clinician/practitioner), e.g., showing the longitudinal trend is important
• Should not interfere with providers' workflows and be minimally intrusive

5. PHRs need payer tie-in:

• Scalability to these solutions needs to come from payers support; enrollment in insured program would easily support the informational requirements of an initial PHR.
• Most payers offer tethered PHR's, which are not really PHR's but histories of claim data
• PHR's are a difficult value-added service for a health IT vendor to roll out because they are high risk with little to know revenue generation, so payers could fund their development and deployment [note that this is a disputed point]

There were also several mentions of "data silos" in this discussion. I noted that on another LinkedIn discussion (at this link) we've had a deep conversation about that issue and most have come to the conclusion that silos are important to keep, but crossing them in a controlled manner is essential. I present a brief summary of the discussion on my blog at this link), which includes a link to a simple and low-cost way to cross the silos.

I discussed why I have a problem with creating monolithic centralized databases that contain individually identifiable patient health information obtained by combining data from disparate local databases/repositories (silos). I argued that health information exchanges (HIEs) should only contain (a) pointers to the silos where the data are stored, (b) aggregated deidentified data for biosurveillance and research purposes and/or (c) identifiable data stored in individual encrypted data files.

I agreed that PHRs should contain data automatically retrieved from providers' EHRs, and the EHRs should contain data automatically retrieved from patient's PHRs.

I asserted that the patient should determine the data sets that can be shared between the EHRs and between the EHRs and PHR. These authorizations would be contained in a Trusted Partner Agreement (TPA) created when the patient and PCP first meet, and would be updated as necessary.

In a pub/sub node-to-node (app to app) "forward and store" communications environment, the publishing nodes would automatically select the data sets to be exchanged with their subscribing nodes based on roles rules reflecting in the TPA's authorizations. This low cost, uncomplicated solution would deal with the concerns others raised.

I then explained that I've been working on a very different type of PHR for several decades, which we're calling a personal health profile. It addresses most of the requirements we've been discussing for a useful PHR. See this link for a three-part post about it.

Continued at this link.