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

In my previous post, I summarized a deep conversation I've been having with a group of knowledgeable people about PHRs. I then offered an innovative, low cost, uncomplicated solution to deal with the concerns others raised.

The solution I offered led to several questions and concerns about (a) security, privacy, access privileges; (b) getting hospitals, clinics, radiology centers, labs and physicians to send an electronic copy of patients personal health information (PHI) to a location where the patient has control over it; and (c) having the PHI be portable, accurate and complete. I answer these questions and address the concerns in this post.

First, here's a basic diagram of the architecture I proposed (a prototype of which we have demonstrated):

* Database Management Systems are software programs that manage databases. In healthcare, these databases are used by EMRs and EHRs and other health IT systems.

** In addition to providing send (publisher) & receive (subscriber), encryption & decryption, and authentication/authorization functionality, each pub/sub node connects with automated data processing templates for querying any databases, parsing any files, manually inputting data, transforming & translating the data, and presenting (rendering) the data.

*** Each data file (DF) is encrypted end-to-end (at rest and in transport) and can be in any data format (CSV, XML, XLS, HTML, etc.). They are stored locally, can be (a) composited (combined/integrated) when multiple publishing nodes send DFs to the same subscribing node, and (b) decomposited (broken apart) when a pub node is authorized to send only a subset of the DF's contents to a particular sub node.
Now to the technical concerns mentioned…

Security: End-to-end encryption of the DFs (including PKI methods). It is also possible to store the personal identifiers in a different DF (which could even be stored at a different location).

Privacy: "Granular level" data control by patient through PHR (see this link).

Access privileges (confidentiality): The human owner of a node can access and render a DF only with user name and password (or, preferably, with a biometric indicator). And the DFs contain only the PHI for which the person is authorized.

Sending an electronic copy of PHI from multiple sources/repositories to a location that the patient controls: Each publisher (provider, lab, etc.) node can do this by (a) querying a database to which it has rights, (b) storing the query results in DF with the transformations and translations required by each of its sub (i.e., patient) nodes, and (c) transmitting the DF to the sub nodes as an encrypted e-mail attachment (or other methods).

Portability: The node software and data processing templates are all modular object oriented applications, and the DFs are individual electronic files, so everything is very portable.

Accuracy and completeness (data integrity): Examples include data validation routines (assessing whether each data element is within predefined parameters), cross-checking data values from different sources, and identifying missing values.

Availability: Since the DFs and processing templates are stored locally on different computerized and storage devices, and since the DFs can be updated automatically via low-bandwidth and briefly connected means (such as e-mail), a recent version of PHI is available anywhere/anytime.

I do not claim to have all the answers, but do come to the table with 30 years of knowledge and R&D. We are seeking to expand our network of collaborators and are very open to creative ideas. Anyone interested in joining our team are welcome to join my company's LinkeIn group—Crafting the Future of Health IT with Novel Solutions—at this link (requires registration).

Other questions were also raised, including: (1) How best to share PHI among disparate systems; (2) How to increase PHR adoption; and (3) What makes a PHR truly useful to the patient and his/her providers in terms of improving care, self-maintenance, quality of life and, of course, controlling one's PHI to maximize privacy. In addition, I was asked if I ever considered Open Source and if we've tried to connect with the big online PHRs. Following were my replies.

Open Source. We have dipped a toe into the open source "waters," but got "stepped on" by the FOSS folks who claim that there is no such thing as a truly valid software patent, and that all software patent holders are greedy, manipulative frauds. After months of debate trying to seek an amicable solution, I left with a bad taste in my mouth (see this link). Nevertheless, I believe open source has a place—especially with commoditized (non-novel) programs—and we have offered an OS app at this link for converting XML to CSV.

Connectivity. MS HealthVault, Google Health and (I believe) Dossia are all public cloud PHRs. With all the security concerns over public cloud computing (see this link), we are shying away from them. We've made attempts, however, to get MS and Google interested in our novel node-to-node system (issue #1 above), but to no avail.

We have not yet written the interfaces you mentioned (also issue #1), although we have interfaces to legacy (X12) and relational databases, as well as XML and other document parsing routines. And although querying remote/external databases is the one method, we've found that having the DBMS run a query and generate an output stored in a CSV (or other delimited text file) is a simple alternative.

Adoption drivers/impediments. I agree that the lack of financial benefit to the database owners has been an impediment to PHR adoption (issue #2), and our crazy provider reimbursement model (pay for quantity, not for value) makes matters worse. It is one reason that we're currently focusing on using our technology in an application that supports information exchange of referral data between PCPs and specialists in patient-centered medical homes while (b) continuing to field test and enhance our PHR application in preparation of its commercialization through workplace wellness programs and other venues.

For the first time in my 30 years as a provider and software inventor/developer, the need to control costs and improve quality is becoming more widely recognized, in part because of the recent healthcare reform debates and the number of people suffering inadequate care. They say that true (disruptive/discontinuous) innovation—one that saves money, reduces complication, and improves overall value—is more likely to be accepted when an economy is in trouble. So, maybe the time is finally right!

PHR usefulness. As far as what makes a PHR useful (issue #3), I would say it's the ability to help the patient & providers (a) increase/improve knowledge and awareness of the patient's health risks and problems, (b) make valid decisions about how to deal with the patient's particular health risks/problems in the most cost effective ways, and (c) become increasingly competence (through education) in implementing the appropriate steps to avoid the risks from becoming problems and ameliorate the severity of existing health problems for a better quality of life. This should include a focus on biomedical & genetic, psychological/psychosocial, and environmental factors. And it should avoid information overload (see this link), while providing complete and accurate data.

[Come back later for part 3]

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.

Should Personal Health Information Reside in Silos-Continued?

There have been several replies to my previous post about data silos.

They questioned my definition of "silo" as a "repository" and made the point that the existence of silos are not only caused to technological issues, but also to constraints involving:

• Legal factors, such HIPPA, state regulations, contractual agreements  
• Human factors, which are things that affect the input and output of the data, such as control issues, distrust, tradition, if it ain't broke don't fix it mentality, etc. 

I responded by saying that, to me, “repository” simply means “storehouse” (a place where data are stored). When a repository has constraints that prevent the data it contains from being shared with other repositories, then each of those repositories is a silo with respect to the other repositories. At the same time, however, any of those repositories that do share data are not respective silos. That is, a repository may be a silo with regard to one respository, but not another.

In any case, my previous post focuses primarily on the technological constraints of silo’ing with regard to incompatible software, databases, etc.

That means that a repository may be silo’ed from other repositories for:

• Technical reasons, such as lack of software/database interoperability; this is a vendor/developer-related issue. However, if data are exchanged between repositories using paper, fax, voice, or other non-software/database methods—then the repositories would NOT be silos, imo, since data are being exchanged.

• Nontechnical reasons, which include legal and human factors. In this case, even if the software/databases are able to exchange data between repositories, the repositories would not do so, which means that they continue to be silo’ed from each other.

Should Personal Health Information Reside in Silos?

Over the past few weeks, I've been engaged in a conversation with an intelligent group of people about whether personal health information (PHI) should reside in disparate "silos" (repositories) that do not communicate with one another, or whether standards should be adopted that "bust" the silos by merging the information into a common warehouse (centralized database) that spans multiple unrelated healthcare organizations, agencies and practices.

Some argued that silo-busting centralization has benefits that include narrowing the number of places the data reside, improved auditability, and the ability trace and report access attempts and actual reads (i.e., "access/read tracing") more effectively than individual computers.

Others (including me) argued that silos have real value, as long at the PHI they contain can be readily and securely shared among "trusted partners," a model which I call "controlled silo-crossing." I proposed a novel and cost-effective way to do this through a federated, node-to-node, publisher/subscriber model we've developed, which is described at this link and elsewhere on this blog. Using this method for controlled silo-crossing provides major benefits, including the following:

• Minimizes information loss. Busting silos leads to the loss of important information—i.e., data details and terminology/semantic nuances—because "local" data standards unique to different silos are destroyed in favor of "global" data standards required by monolithic centralized systems, as I discuss at this link.

• Gives PHI control to the owners of that information. Both providers and patients should have their own silos and have control over who is allowed to cross them. That is, patients ought to authorize the individuals and organizations that have the right to obtain their PHI from their own PHRs and from their providers' EHR/EMRs. The authorized parties should: (a) get only information that meaningful/useful to them, (b) have that information delivered to them from any silos in which they reside, and (c) receive that information after it has been translated and transformed for use in their own respective silos. Also, if silos were busted, it presents the thorny issue of who should be in charge (be the boss) of the merged data?

• Provides strong information security. Personally identifiable PHI in the physical possession of the parties owning and controlling it is inherently more secure than allowing third-party vendors to manage that information in centralized databases residing off-premises. This relates to the issue of "public cloud" security as I discuss at this link.

• Enables auditing and access/read tracing. Auditing and tracing are handled effectively using node-based software residing in individual computers.

This all raises other questions: Who currently wants to cross silos and why?

Two entities are public health agencies and research (academic) organizations. Two others are Health Information Exchanges (HIEs) and the National Health Information Network (NHIN). They all require PHI from multiple silos to, for example, identify public health emergencies through biosurveillance (e.g., dangerous medications and medical devices, pandemics, bioterrorism, etc.), as well as to develop evidence based practice guidelines.

Another entity that wants to cross silos is healthcare providers who want to give their patients the best possible care by, for example, sharing PHI through patient centered medical homes, which I discuss at this link.

In addition, patients who understand the problems in healthcare would also support silo crossing. For example, anyone knowledgeable about the serious knowledge gap in healthcare—which I discuss at this link—would realize how important it is to have interdisciplinary teams of clinicians, their patients and researchers share information and collaborate to promote ever-better (higher-value, more cost-effective) care, and by having payers offer financial incentives to practices running certified medical homes.

To help realize this vision of controlled silo crossing, we ought to focus on revamping our culture into one in which value (cost-effectiveness) to the consumer is the upmost importance, and in which delivery of such value is a collaborative effort that is highly rewarded. The results, over time, would include:

• Ever-better personalized evidence-based guidelines for prevention and care that patients and their providers use to improve results and lower costs by reducing waste, fraud, abuse, errors, omissions, ineffectiveness and inefficiencies would be dramatically reduced.
• Providers would be more effective in diagnosing/testing, treating and preventing health problems in their patients, and would gain financially by doing so.
• Providers would not have to worry about malpractice suits by following the evidence-based guidelines and offering sound justification for rendering alternate plans of care; this would also lower malpractice insurance premiums and the pressure for wasteful "defensive medicine."
• Patients/consumers would be better able to manage their own health.
• Payers would not have to pay for low value (expensive, unbeneficial) procedures and tests.

Bottom line: While centralized databases have their place, controlled silo-crossing is a key strategy for improving our healthcare system.

Discussion continued at this link