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]