A Novel Way to Share Personal Health Information

Patient health data are stored in disparate silos—separate islands of information residing in often incompatible EMR/EHR and PHR databases controlled by different hospitals, clinics and public health agencies, as well different group and solo practices. The question is: What is the best way for this personal health information to be shared securely between the people who need it to provide quality care to individual patients, protect populations, and perform research leading to valid evidence-based guidelines?

There's actually a simple, inexpensive and secure way to exchange data between any PHRs, EHRs, EMRs and public health/research/biosurveillance databases. As I've discussed in previous posts, it requires a paradigm shift from...

• Monolithic, centralized, pull, synchronous systems—an architecture that's good behind an organization's firewall

to...

• Distributed federation of asynchronous pub/sub nodes that push data from publishing to subscribing nodes—an architecture that's good for the kind of loosely coupled P2P networks crossing organizational boundaries that comprise the NHIN (National Health Information Network).

The latter architecture uses a node-to-node transport method, which is similar to the way the telephone system works. It enables everyone everywhere to exchange data with little cost and complexity, even when bandwidth is low and Internet access is intermittent. It enables massive interoperability. With it, scalability is a non-issue. It provides composite reports containing information from many disparate sources. And it allows data views to be changed instantaneously (even when offline), which increases understanding by, for example:

• Data slicing, dicing and drilling down (i.e., breaking a body of information down into smaller parts, examining it from different viewpoints and dividing an information area up into finer and finer layers)
• Switching from lists and tables to graphs
• Answering ad hoc "what if" questions
• etc.

In order to implement the above solution, you would connect pub/sub node software to every application in a mesh node network. And you would enable each node to do whatever data translations and transformations are needed to assure the right data gets to the right place in the right format. Then transmit the data to subscribing nodes in PKI encrypted delimited text files (such as CSV) via FTP, e-mail attachments, MMS, or whatever protocol desired. Upon receipt, the subscribing nodes can import the data into their local databases and/or render the data locally using customized templates that can operate interactively offline.

I discuss this solution in detail at this at my company's LinkedIn group at http://www.linkedin.com/groups?home=&gid=2697006&trk=anet_ug_hm&goback=%2Eanh_2697006. You're welcomed to join.

A Novel Way for Everyone in the Nation to Exchange Health Data Simply, Inexpensively and Securely

It's becoming increasingly clear that while a monolithic centralized network is useful for sharing patient data within a large healthcare organization, it not a suitable architecture for interconnecting everyone in the nation (and world), including all patients/consumers, healthcare practitioners/clinicians, researchers, clinics and hospitals, labs, pharmacies, regional and state health information exchanges, and others. Why? Because the centralized model is much more expensive & complex, and arguably less secure, than decentralized (distributed, peer-to-peer, node-to-node) networks that are encrypted end-to-end.

This novel technology--which includes an optional proprietary (patented) component--connects all parties in a way similar to the telephone system. It enables massive amounts of patient data to be exchanged securely and inexpensively between any parties. It accommodates standalone and networked computers, as well cloud-based computing. It operates cost-effectively even when bandwidth is low and connectivity is intermittent regardless of available bandwidth, transmits comprehensive health data in the most efficient way possible, fosters collaboration among loosely individuals and organizations in coupled professional and social networks, and promotes the dissemination of ever-evolving knowledge providing evidence-based decision support that continually improves outcomes and lowers costs for greater healthcare value.

In this proposed architecture, the nodes are in a decentralized peer-to-peer (P2P) publish/subscribe mesh node network. The nodes can reside on any suitable computerized device, including computer hard drives, smart phones, smart cards, USB flash drives, etc. and it can works in conjunction with desktop (stand-alone; client-server) and cloud computing systems.

Related posts:

• The push for ‘push’ technology for the NHIN
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 1 of 2)
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 2 of 2)
• Simple, Low-Cost, Secure Health Data Exchange
• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 1 of 2)
• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 2 of 2)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 1)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 2)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 3)
• Dueling Data Formats
• Knowledge, Standards and the Healthcare Crisis: Part 6  
• Introducing our disruptive CP Split technology

Health IT: Comparing Cloud Computing and Desktop Applications (Part 3)

This debate about the pros and cons of Cloud versus Desktop computing, which I posted at this link, has continued on another forum. Following are excerpts.

One commenter wrote:

Cloud computing is going to be revolutionary in coming era. Earlier we have concern about bandwidth and performance of the application in terms of speed, traffic limit etc etc... as evolution of the technology and communication system like HSDPA and HSUPA with high-end bandwidth for data packet transfer we wont be feeling the difference between a cloud computing and desktop computing. The other hand in UK the government and NHS collaboration going to bring up a revolutionary "CENTRALIZED HEALTHCARE SYSTEM" accross the country. NHS is spending near about 1.2 B$ for the NHS IT and Care For Health. Now US President also declare a stimulus package for Health Reform which enhancing using the electronic media in Healthcare and making a centralized system of Patient Health Record and Electronic Medical Record. I still feel we can see the advantages of the cloud computing and how best we optimized this, in terms of developing web based apps. Microsoft Silverlight is one of the success pillar of the cloud computing and web 2.0 is the optimized technology for enhancing the Speed, Performance, User Interface etc. I hope our next generation technology will be more focus and drive towards Cloud Computing. In terms of the security what you mentioned most in your blog is going to be no more a threat in web based app. Although we and our psychology still retain us in the concept that we can have better security in desktop computing. But think an incident of computer crash or natural calamities or disasters can break all the boundary of the desktop and intranet environment.

To which I replied:

Thank you for your thoughtful reply. I also see value in cloud computing and centralization in certain healthcare use cases. For example, storing deidentified patient data in a central database in the cloud for research purposes makes good sense to me because the primary purpose is on aggregate data analyses of massive numbers of records (and privacy & security issues are much less). A good case can also be made for central databases behind an organization's firewall. Another is off-premises storage of encrypted files. But in many other situations, a mesh node network (telephone system-like) cyberarchitecture makes more sense in terms of cost, complexity, security and privacy, as well as supporting data exchange and collaboration in loosely coupled health information networks. For example a P2P publish/subscribe node network (see this link) would offer a convenient, secure, lower-cost and simpler way for:

• Primary care physicians to exchange patient information with the specialists to whom they refer.

• Patients who want to input, retrieve and share portions of a locally stored PHR with their providers without logging onto the Web.

• Individual practitioners and clinicians from a small organization (clinic, group practice, etc.) who want to access patient information offline.

• The exchange of patient data between disparate HIEs/RHIOs.

• Situations where bandwidth is low, network access is intermittent, networks are congested, or servers are strained causing unacceptable latency.

• Money is tight and expensive infrastructural build-out is unwanted.

Note that the benefits of the desktop node-to-node network are expanded by deploying an exceptionally efficient novel data structure and using e-mail to transmit data files in an innovative (see this link).

Concerning an incident of computer crash, natural calamities and disasters, the system we're proposing includes data file backups (on- and off-premises), UPSs, and an "auto-failover" process by which the best available alternative methods of data transmission would be used—such as using dial-up, radio, or satellite communication.

Another comment responded:

I think advances in software architectures and increasing data transmission capacity will take precedence over traditional issues on adjusting the place of functionality and computational capacity. So the borders between desktop computing and the cloud is disappearing and each desktop is going to be a part of the cloud ( A piece of cloud will be the cloud itself.).

I studied the links and I think that although your approach is a genuine idea, but its time is passed. Maybe the best surviving method be to develop proper conceptual model for finding the right attachment point and taking a free ride of the Cloud Computing wave, instead of competing.

To which I replied:

I thank you for your thoughts and would like to have a better understanding of your points.

When you say the desktop will be a piece of the cloud or the cloud itself, the key difference between the cloud and the kind of node-to-node (n2n) network I'm presenting appears to be that the cloud approach: (a) MUST rely on a central server to enable data exchange and (as least some) computation, (b) rejects SMTP (email attachments) as a viable transport protocol, and (c) doesn't consider the value of using preplanned data containers and grid templates as a means of structuring and presenting data.

Nevertheless, I am VERY OPEN to any ideas about how to merge the cloud and n2n architectures, so that the best of each can be applied to different use cases. It seems that you're alluding to such a hybrid approach when you say "finding the right attachment point and taking a free ride of the Cloud Computing wave, instead of competing." Please do elaborate.

Note that I'm working on a diagram to clarify the n2n model in which pub/sub nodes, disparate data stores, and APIs enable fluid connectivity between all end users and third-party applications (EHRs, PHRs, CDSs, BI tools, etc.).

Another commenter then wrote:

I think cloud computing is the future, however, because of the sensitivity of the data we deal with (clinical research data in my case), we must think in terms of private clouds, public clouds and hybrid clouds. With the greater availability and affordability of disk storage and virtualization, private clouds are with in the realm of possibility for most research institutions.

And I responded:

Don't get me wrong, there are certainly good use cases for the clouds, and using them form aggregating and analyzing de-identified patient data is a fine example. A private cloud could also be useful for storing identified patient data behind an organization's firewall. However, I contend that it is a poor choice for storing identified patient data that it is accessible by parties outside an organization's the firewall. Like many others, therefore, I'm reluctant to store certain of my personal health data with MS or Google, but I realize a hospital might use a private cloud to store my data behind their firewall and that's OK. Likewise, I would not want my data to be stored in identified form in an HIE, RHIO, or NHIN cloud where they can accessed by others because there are more secure, lower cost alternatives.

Related posts:

• Health IT: Comparing Cloud Computing and Desktop Applications (Part 1)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 2)
• The push for ‘push’ technology for the NHIN
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 1 of 2)
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 2 of 2)
• A Novel Way for Everyone in the Nation to Exchange Health Data Simply, Inexpensively and Securely
• Simple, Low-Cost, Secure Health Data Exchange
• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 1 of 2)
• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 2 of 2)
• Dueling Data Formats
• Knowledge, Standards and the Healthcare Crisis: Part 6  
• Introducing our disruptive CP Split technology