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
No comments:
Post a Comment