Combining Cloud Computing, Client-Server and Novel Pub/Sub Mesh Node Network Architectures (Part 2 of 2)

In my previous post, I described three key architectures for deploying health IT software programs and exchanging patient information in a national health information network (NHIN). They are:

1. Cloud computing
2. Client server
3. Publish/subscribe mesh node networks.

In this post I describe the use cases of each, as well as cautions to be taken in their implementation.

Cloud Computing Architecture Use Cases

The cloud is most useful in use cases where (a) Internet bandwidth is high and connectivity is constant and consistent; (b) data and technology standards are well-established; and (c) there is concrete assurance that if a web service provider goes out of business, the healthcare organization will have ample opportunity to recover all the data stored there. A primary benefit of cloud computing is lower upfront cost compared to client-server architectures. That is, if your local computer doesn't have the resources necessary to run a software program, it may be cheaper, faster, or more convenient to run the program in the cloud than through traditional client-server architecture.

Cloud Computing Security Concerns

When cloud computing is used, however, caution should be taken to protect sensitive patient data in a cloud through end-to-end encryption or by storing only de-identified patient data. Because it is so important, I've included the following quotes from several sources about cloud security issues:

• "[Trend Micro, the] security company, in its in its predictions for 2010 predictions report for 2010, identified cloud computing as a trend that will amplify threats to companies over-reliant on cloud computing vendors. It… warned the nature of the cloud makes it an attractive target to hackers, who are drawn to the ease of going after a single cloud serving various customers and taking down 'multiple systems secured the same way'…The increased amounts of data handed over to cloud providers will also pose risks in terms of availability and data privacy, it said. Companies open themselves to the possibility of service providers going out of business, or having physical and internal breaches…It highlighted the importance of avoiding cloud lock-in and being able to switch providers "at will or in line with business needs", so as to retain control over the company's IT processes…Beyond the data center, threats lie in connectivity to the cloud…Web protocol technologies such as SSL (Secure Sockets Layer), DNS (Domain Name System) and BGP (Border Gateway Protocol) are still works in progress, being 'developed before security was a consideration'. Security researchers have been identifying flaws in these technologies--last year, a BGP vulnerability was revealed to have been known in the industry for over a decade, but remained an inherent problem…'The question is whether any cloud vendor could reasonably ensure that unauthorized access is not possible, that a hacker will never be able to copy millions of user records, login credentials, online banking information, billing information, transaction records and the like." [Reference]
• "DATA PROTECTION: cloud computing poses several data protection risks for cloud customers and providers. In some cases, it may be difficult for the cloud customer (in its role as data controller) to effectively check the data handling practices of the cloud provider and thus to be sure that the data is handled in a lawful way. This problem is exacerbated in cases of multiple transfers of data, e.g., between federated clouds…INSECURE OR INCOMPLETE DATA DELETION: when a request to delete a cloud resource is made, as with most operating systems, this may not result in true wiping of the data. Adequate or timely data deletion may also be impossible (or undesirable from a customer perspective), either because extra copies of data are stored but are not available, or because the disk to be destroyed also stores data from other clients. In the case of multiple tenancy and the reuse of hardware resources, this represents a higher risk to the customer than with dedicated hardware…MALICIOUS INSIDER: while usually less likely, the damage which may be caused by malicious insiders is often far greater. Cloud architectures necessitate certain roles which are extremely high-risk. Examples include CP system administrators and managed security service providers." [Reference]
• "…[B]usiness technology pros what worries them about cloud computing, security concerns…[may] end up sinking any move to the cloud… IT departments…aren't as confident of where pain points such as security flaws may be. What new intrusion points are introduced? How can a company be sure that its data sitting in the vendor's data center is safe? When should information be encrypted?...[S]ecurity defects in the technology…[is] a top concern with cloud computing …One of the biggest risks of cloud computing is that of the unknown… One can't assume that encryption is available in all cloud services…Encryption creates a lot of overhead, and suppliers don't want to degrade application performance or absorb the cost if customers don't put a premium on it…[C]ompanies need to think of their networks now extending beyond their own physical environments and into the supplier's data center. As companies stitch more cloud services together, that challenge multiplies. A related complication comes from the fact that cloud services have been designed in vacuums, with each vendor securing its own connections but not the others…[T]he more data that goes into the cloud, and the more valuable that data, the more appealing it becomes as an attack target…That's why companies, once they've worked their way through the network security issues of transferring data to and from a cloud provider, need to probe the vendor's data center operations…[C]ompanies must determine how comfortable they feel putting data and applications in the cloud…Only a brave few dive in…completely…Vendors acknowledge the fear…[and a] lack of trust about cloud service security." [Reference]
• Not only do security concerns exist outside the cloud, but as discussed below, privacy concerns exist inside the cloud since cloud vendors are able to look at your database. “'Cloud computing is a trap, warns GNU founder Richard Stallman…It’s stupidity. It’s worse than stupidity: it’s a marketing hype campaign'…Somebody is saying [that cloud computing] is inevitable – and whenever you hear somebody saying that, it’s very likely to be a set of businesses campaigning to make it true…Amazon’s marketing of a ‘VPN to the cloud’…as the solution to a company’s security concerns…[but] Amazon just doesn’t get it…’It’s them against us…thousands of hackers attacking and we just don’t have the resources.’…We can easily guesstimate that at any given point in time we’d have at least 1,000,000 hackers willing to compromise any mega corporation...Amazon’s response appears to be focused on creating a moat in front of their cloud, and while that’s not a bad idea, in no way does this alleviate the threats inside of the cloud itself not to mention an array of other reasons…’Computer security researchers had previously shown that when two programs are running simultaneously on the same operating system, an attacker can steal data by using an eavesdropping program to analyze the way those programs share memory space. They posited that the same kinds of attacks might also work in clouds when different virtual machines run on the same server…The bottom line is, how can you defend the outside of your cloud when you might not even be able to trust the inside of your cloud...Is a cloud provider willing to allow you to perform an in-depth penetration test to ensure you meet compliance? For now, can even forget about the outside threat to your cloud, those threats will always exist, what can you do to defend the insider? Seriously…So when a provider states that: ‘We reserve the right to invade your privacy at any given point in time,’ it just doesn’t sound so appealing, especially when companies are looking to potentially store customer data in the cloud. Do you honestly want a third party viewing your customer database?...[When Amazon states that] ‘It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances’…[and] ‘Abusers who choose to run their software in an environment like Amazon EC2, make it easier for us to access and disable their software’…how would Amazon know whether something is a rogue or a misconfigured application, without taking a look?...they’d HAVE TO look at it.” [Reference]
• "…[Y]ou can transfer risk but never responsibility…no cloud provider will give you the security you need. There can never be a cloud computing provider who can give you the kind of security protections that an in-house security team can and the logic behind this statement is a simple and factual one: a cloud provider won't lose as much as you would at the end of the day. Therefore the incentives to go 'above and beyond' can never and will never exist…Cloud computing providers can only cover so much ground when it comes to security and what they will cover is often a baseline based on often obsolete guidelines. Even if they could cover all the necessary bases, the virtualized environment itself would forever be at odds with forensics…When a machine is virtualized, its states change rapidly and the possibilities of doing forensics is out of one's hands and out of your company's control and in fact, even outside of the cloud providers' control. A cloud provider will not…take dozens if not hundreds of other virtualized machines offline to make a forensic replica should the need arise…Cloud services are especially difficult to investigate, because logging and data for multiple customers may be co-located and may also be spread across an ever-changing set of hosts and data centers. If you cannot get a contractual commitment to support specific forms of investigation, along with evidence that the vendor has already successfully supported such activities…[you're] worse off [with the cloud] than keeping things in house from a forensics point of view and an incident response point of view." [Reference]
• "There are always risks involved when dealing with working online, regardless of how secure a host might say a web application is, that fact of the matter stands that the security risk of running an application of the Internet is more significant than when running an application on a standalone desktop computer. Some applications require more security than others, playing Sudoku on a web application would cause little concern, but dealing with sensitive corporate formulas or accounting details in a web environment might be determined risky." [Reference]
• "Web applications are exposed to more security risks than desktop applications. You can have a total control over the standalone applications and protect it from various vulnerabilities. This may not be the case with web applications as they are open to a large number of users in the Internet community thus widening the threat." [Reference]
• "Working online has its own set of risks like hacking and virus threats. The risk is higher compared to a desktop computer, since a malfunction of the desktop can result in loss of partial data. The crash of a web server can result in consequences beyond the control of a business." [Reference]
• "Local applications installed on your computer give you better security and do not require a connection to the web. Also, in many cases, local applications provide better integration with the operating system." [Reference]
• "The Internet abounds with security threats; some users have reported automatically losing accounts and data with Google or other web services after hacker break-ins; cross-site scripts which install key logging software are especially problematic because passwords can be recorded and stolen as they are being typed; hackers routinely break into accounts with simple passwords (names, personal data, words from the dictionary, or anything less than 10 characters)." [Reference]
•  Clouds at Amazon, Google, Microsoft, AT&T, Paypal, Sony, the CIA, Citibank and Twitter have all been hacked [Reference1], [Reference2], [Reference3].
• "The hack into a Gizmodo writer’s Amazon and Apple accounts over the [first] weekend [of Aug 2012] is being used as a cautionary tale for consumers, a call to action for cloud providers regarding security policies and a sounding board for concerns about the rush to the cloud...an attacker quickly found his way into [a user's] iCloud account and wiped everything from his Mac, iPhone and iPad, all of which were linked to Apple’s cloud service. The attacker also hacked into his Twitter and Gmail accounts...larger concern was how quickly and easily the attacker...was able to get gain control of [the] account through just a couple of phones calls to Amazon and Apple [using] social engineering" [Reference] and [important comments].
  

Cloud Computing Use Cases

Taking security into account, use cases for the cloud computing architecture include:

• Providing access to browser-based EHRs and EMRs with end-to-end encryption in either:
• Tightly controlled private clouds
• Non-private clouds only if the patient identifiers are stored in encrypted data files (in the cloud or in local storage).
• Storing de-identified patient data in centralized databases for public access or for restricted access by authorized persons (e.g., for research purposes).
• Storing practice guidelines in public clouds.
• Home monitoring, whereby data from measurement devices (e.g., a glucometer) are streamed to a provider's private cloud with end-to-end encryption.
• CRM, business intelligence, content management and research-based applications in private clouds with end-to-end encryption.
• Hosting Web conferences to dispersed audiences.
• Enabling real-time collaboration in private clouds with patient data encrypted end-to-end or in public clouds with de-identified patient data only.

Client-Server Architecture Use Cases

The client-server model is most useful in use cases where the data remains within an organization's boundaries (i.e., behind the firewall) and subject to strong central control (authorizations, etc.); such use cases include:

• Managing patient data in a provider organization's EMRs and EHRs
• Running an enterprise health information management system (HIMS), including both clinical and financial applications
• Running business intelligence (analytical) applications within an organization
• Running protocol/medication adherence management and post discharge software programs, e.g., having text messages trigger alert that are sent to case managers informing them to contact certain patients under certain circumstances based on an organization's rules (algorithms).

Novel Pub/Sub Node Network Architecture Use Cases

The pub/sub node network model is most useful when:

• Exchanging sensitive patient data beyond organizational boundaries (i.e., beyond the firewall)
• The cost of infrastructural build-out for centralized systems is prohibitive
• At least some end-users must access data at times when bandwidth is low, connectivity is intermittent, or network latency is high
• Exchanging data between disparate databases
• Individuals prefer to have complete control over their own data
• Large scale emergencies disrupt communication networks relying on the Internet.

Use cases for such a node network architecture include:

• Exchanging patient data across organizational boundaries, including sending data between disparate data stores (e.g., exchanging data between incompatible EMRs, EHRs and PHRs).
• Sending de-identified patient data from PHRs and EHR/EMRs to data centers in HIEs/RHIOs and an NHIN repository.
• Connecting multiple cloud, client-server and desktop-based systems by providing nodes to able to access the applications and data sources in each system.
• Locally storing data collected through cloud-based applications in encrypted CPS data files, and enabling those data to be sent back to the cloud-based system as necessary. The same goes for client-server applications.
• Exchanging patient data in emergency disaster situations in which command & control units and first responders (fire fighters, police, EMTs, trauma center staff, etc.) must communicate quickly and effectively even when they each have different data needs and when the Internet is unreliable. This includes overcoming the "last mile problem"—which refers to the challenge to provide connectivity to all end-users' devices at all locations due to bandwidth mismatches and other connectivity constraints—by providing multifaceted asynchronous communications capability that includes radio, land line, and satellite communication options.
• Preventing any single point of failure problem of centralized systems by mimicking the landline telephone system, which always has a dial tone even when power goes out.
• Supporting an automated decision-support system in which the nodes host a "loosely-coupled decision network" of people from multiple locations and with different roles who sometimes work together to make decisions beyond the knowledge or skills of any individual. The nodes use their data transformation and universal translation capabilities to accommodate the diverse information needs and preferences of the participants in a way that reduces misunderstandings due to regional, departmental or cultural differences.
• Doing eligibility checking, i.e., when a patients go to their healthcare providers, the nodes send data back and forth between the nodes connected to insurance company databases to exchange eligibility data.
• Exchanging data between nodes connected to labs, providers and patients.
• Automatically sending certain data concerning communicable diseases and other biosurveillance data to and from the Center for Disease Control (CDC) via nodes connected to providers' EHRs/EMRs, patients' PHRs and the CDC's databases.
• Providing remote access to imaging data stored locally.

For more use case scenarios, see these links on our Wellness Wiki:

• Scenario - Emergency Department Care
• Scenario - Avoiding Adverse Event in a Hospital
• Scenario - Outpatient Psychotherapy
• Scenario - First Responders
• Scenario - Using Personal Health Records
• Blueprint for an Integrated HIT system - The Patient Life-Cycle Wellness System
• Evidence-based HealthCare Decision Support System

Conclusion

All three architectures have important use cases. The novel node-based architecture I've been promoting enables all three to work together in order to receive the benefits of each.

Related posts:

• Combining Cloud Computing, Client-Server and Novel Pub/Sub Mesh Node Network Architectures (Part 1 of 2)
• The push for ‘push’ technology for the NHIN
• 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)
• 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

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

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

This post is a continuation of the debate about the pros and cons of Cloud versus Desktop computing, which starts at this link.

The cloud computing expert I've been debating responded to my comments by writing:

We are just from different camps of software thinking. I have a CS degree from a college that taught on Unix machine not desktop and my entire experience is working with enterprises systems not desktops I was an early adopter of Java and attended the first Java one where the mantra was "The Network is the computer". Eric Schmidt CEO of Google is doing his best to make this happen. Yes they are looking to the future but Microsoft seem to be stuck in the past.

I reply:

Yes, we are from different schools and thus have very different points of views. We both see the value of networks with you focusing on networking computers within an enterprise ("behind the firewall"), and me from the perspective of enabling information exchange between "disparate islands of information" owned/controlled by (a) vastly different organizations and individuals with vastly different communications (from continuous broadband to occasionally connected dial-up) and (b) widely diverse information needs (including linking hospitals and clinics, individual clinicians across all healthcare disciplines, public health institutions, research organizations, as well as individual patients).

And while I am discussing the value of novel applications that use e-mail to enable all standalone (desktop/laptop/notebook) computers to have publisher and subscriber functionality (i.e., they have server-like functionality that enable P2P data transmission), the technology I'm proposing need not be Microsoft based since it can use any kind of automated spreadsheet grids and e-mail (although I do think the MS Office suite is currently the best, or at least the most ubiquitous, but OpenOffice or other tools could be used instead).

The conversation continues…

In response to my comment: "Since there are concerns about the security of data stored in the Internet cloud, people may feel more secure if they have complete control over their private information (such as personal health information), which is stored in encrypted data files in their own computers and other computerized devices," he wrote:

Cloud is just as safe or safer than office machines under desk. You can just take one home

To which I reply:

It's true that no matter what solution is deployed, security must be taken seriously. Examples of Cloud security risks can be found at http://tinyurl.com/ykv6s6o and http://tinyurl.com/lzr3gg; it's good that many people are working hard to manage those risks. My point is that storing a patient's health record in an encrypted data file residing on a local HD (hard drive) is much less complex and costly than securing the Cloud. This is especially true when data has to be shared with people outside an enterprises firewall.

In response to my comment: "Total cost of ownership is minimized since there is no need to rely on expensive central servers, databases, and server administrators," he wrote:

The cost [of expensive central servers, databases, and server administrators] is amortized, that is the point. And single machine are much more expensive than enterprise (depending on the size of staff).

To which I reply:

I assume you're comparing a thin versus thick/fat clients. With full power PCs continually coming down in price (many just a few hundred dollars), the cost difference can be minimal. And with the PC, you get the added benefits of fewer server requirements (a thick client server does not require as high a level of performance as a thin client server, resulting in drastically cheaper servers); offline working means a constant connection to the central server is often not required; better multimedia performance (thick clients have advantages in multimedia-rich applications that would be bandwidth intensive if fully served); more flexibility (on some operating systems software products are designed for PCs that have their own local resources, which are difficult to run in a thin client environment); using existing infrastructure (as many people now have very fast local PCs, they already have the infrastructure to run thick clients at no extra cost); and higher server capacity (the more work that is carried out by the client, the less the server needs to do, increasing the number of users each server can support) [see http://tinyurl.com/yl7tqxw]. And when it comes to exchanging data with people beyond an enterprises firewall (e.g., connecting with an independent clinician's EHR or patient's local PHR), the thin client is not an option for the remote individual!

In response to my prior comment: "All the information can be accessed anywhere/anytime, even if there is no Internet or other network connections," he wrote:

?? no network, are you talking sneakerNet? You can do the same with servers but....

To which I reply:

No, I'm not talking about handing a disk to someone. What I am talking about using an encrypted delimited data file, stored locally on a PC HD, which contains all the information needed on a patient (or on multiple patients for an aggregate report). No network, no problem. And when there is even a momentary resumption of the network, an e-mail with an attachment containing a portion of a patient's health dataset can be delivered or received with only a second or two of offline connectivity. I'm not talking about a centralized enterprise system, however,

In response to my prior comment: "Unlike communications requiring continuous connectivity, there is no loss of data when a network connection drops out (i.e., unexpected disconnection)," he wrote:

How about when you lose an HD or power in the building?

To which I reply:

If there's no UPS (uninterrupted power supply) on the PC or the HD fails, then you're right, there is no data to be viewed or shared.

In response to my prior comment:"There is no single point of failure to disrupt and entire network when a central server develops problems," he wrote:

Same argument but desktop have no redundancy.

To which I reply:

In addition to having backups (on- and off-premises) and UPSs, the kind of P2P, pub/sub, desktop-based, mesh node networks I'm discussing means that no single node (peer) on the network can prevent other nodes from working since there is no central server (i.e., each desktop node functions like its own server through use of e-mail). If the entire Internet fails (due to a natural disaster, terrorist attack, etc.), the local data files would still be available for local data access. But what about data exchange? In such a situation (that may be caused by) the networks I'm proposing would have communications "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—to send the e-mail attachments from anywhere to anywhere thereby enabling efficient emergency data exchange.

Also consider that central servers can never be immune to failure as evidenced by a recent disruption of an online EMR reported at this link.

In response to my prior comment "Since copies of the encrypted data files can be stored in many different locations (widely distributed), data survivability is enhanced," he wrote:

??? more sneakerNet?

To which I reply:

While physically exchanging disks or memory sticks containing the data file is one way to do it, by "data survivability," I'm referring to the type of emergency situation in my previous reply. When that happens, transmitting locally stored data files via e-mail using auto-failover communication methods provide a better solution than systems requiring Internet access to a centralized database.

In response to my prior comment "Maintenance has improved with automated desktop updates. On hosted systems, furthermore, users are at the mercy of the host; so, if an upgrade does not go well, or the individual user doesn't want or need the new features, the upgrade will still go forward," he wrote:

automated desktop updates require a host.

To which I reply:

Yes, but you don't have to install the update/upgrade, and can even reverse it if you installed it but don't like it.

In response to my prior comment: "There is greater security risk when running a web application online over the Internet than when running a desktop application offline," he wrote:

This is incorrect. Only if the system is not been setup correctly

To which I reply:

I realize there are ongoing debates about security, so here are a few quotes from people who argue that web applications are less secure than desktop applications: "There are always risks involved when dealing with working online, regardless of how secure a host might say a web application is, that fact of the matter stands that the security risk of running an application of the Internet is more significant than when running an application on a standalone desktop computer. Some applications require more security than others, playing Sudoku on a web application would cause little concern, but dealing with sensitive corporate formulas or accounting details in a web environment might be determined risky." [Reference] "Security - web applications are exposed to more security risks than desktop applications. You can have a total control over the standalone applications and protect it from various vulnerabilities. This may not be the case with web applications as they are open to a large number of users in the Internet community thus widening the threat." [Reference] "Security: Working online has its own set of risks like hacking and virus threats. The risk is higher compared to a desktop computer, since a malfunction of the desktop can result in loss of partial data. The crash of a web server can result in consequences beyond the control of a business." [Reference] "Local applications installed on your computer give you better security and do not require a connection to the web. Also, in many cases, local applications provide better integration with the operating system." [Reference]

In response to my prior comment: "Over the life of the software use, web applications are typically significantly more expensive because desktop applications are purchased outright and there are rarely recurring fees for the software use," he wrote:

This depends on a lot of factors but normally subscription based software is cheaper.

To which I ask: On what do you base this conclusion?.

In response to my prior comment: "Desktop applications typically operate faster because they are not affected by Internet traffic, server use, and latency," he wrote:

Only if the system was not setup correctly. You need Enterprise engineers to setup enterprise software.

To which I reply:

I guess by spending enough money and time on maximizing speed, you could reduce server processing time, queue waiting time, and network latency during high traffic. But you'd be hard-pressed even then to have a sophisticated healthcare application operate as quickly as a web app compared to a desktop app on a moderate power PC.

In response to my prior comment: "When using a web application that is hosted by a third party, privacy policies should be in place to prevent that data from being used by the web host," he wrote:

True, same for desktop privacy policies

To which I agree.

In response to my prior comment: "Multiple desktop applications can be integrate and used, enabling a model's functionality to be enhanced by other software programs. This cannot be done securely using a web-browser," he wrote:

Web apps can talk to each other that is the purpose of EAI.

To which I replied:

The seven main challenges of enterprise application integration are reported to be:

• Constant change - The very nature of EAI is dynamic and requires dynamic project managers to manage their implementation.
  
• Shortage of EAI experts - EAI requires knowledge of many issues and technical aspects.
  
• Competing standards - Within the EAI field, the paradox is that EAI standards themselves are not universal.
  
• EAI is a tool paradigm - EAI is not a tool, but rather a system and should be implemented as such.
  
• Building interfaces is an art - Engineering the solution is not sufficient. Solutions need to be negotiated with user departments to reach a common consensus on the final outcome. A lack of consensus on interface designs leads to excessive effort to map between various systems data requirements.
  
• Loss of detail - Information that seemed unimportant at an earlier stage may become crucial later.
  
• Accountability - Since so many departments have many conflicting requirements, there should be clear accountability for the system's final structure.
  
• Emerging Requirements - EAI implementations should be extensible and modular to allow for future changes.
  
• Protectionism - The applications whose data is being integrated often belong to different departments that have technical, cultural, and political reasons for not wanting to share their data with other departments.

Furthermore, There are high initial development costs, especially for small and mid-sized businesses . And a fair amount of up front business design, which many managers are not able to envision or not willing to invest in. Most EAI projects usually start off as point-to-point efforts, very soon becoming unmanageable as the number of applications increase [Reference]

Also see http://www.sdtimes.com/content/article.aspx?ArticleID=30776

The bottom line, imo, is that there is a place for centralized web-based enterprise networks residing in the cloud. But they don't even come close to supplanting the need for low-cost, secure, standalone/desktop-based, P2P mesh node networks that can cross firewalls without hassle, work offline using local computer resources, and exchange health information via multiple communication methods using e-mail.

The conversation continues at this link.

Related posts:

• Health IT: Comparing Cloud Computing and Desktop Applications (Part 1)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 3)
• 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