In a meeting last week with senior management at Harvard Medical School, one of our leaders asked, "What is our cloud strategy?"
My answer to this is simple. The public cloud (defined as the rapid provisioning and de-provisioning of CPU cycles, software licenses, and storage) is good for many things, such as web hosting or non-critical applications that do not contain patient or confidential information. At Harvard Medical School and Beth Israel Deaconess Medical Center, we've embraced public cloud technology, but transformed it into something with a guaranteed service level and compliance with Federal/State security regulations - the private cloud.
Here's the approach we're using to create private clouds at HMS and BIDMC:
1. At HMS, we created Orchestra, a 6000 core blade-based supercomputer backed by a petabyte of distributed storage. Thousands of users run millions of jobs. It's housed in Harvard controlled space, protected by a multi-layered security strategy, and engineered to be highly available. We also use grid computing technologies to share CPU among multiple high performance computing facilities nationwide.
2. At BIDMC and its physician organization (BIDPO), we've created a virtualized environment for 150 clinician offices, hosting 20 instances of logically isolated electronic health record applications per physical CPU. It's backed with half a petabyte of storage in a fault tolerant networking configuration and is housed at a commercial high availability co-location center.
3. At BIDMC, our clinical systems are run on geographically separated clusters built with high availability blade-based Linux machines backed by thin-provisioned storage pools.
Each of our private clouds has very high bandwidth internet connections with significant throughput (terabytes per day at HMS). The bandwidth charges of public clouds would be cost prohibitive.
We are investigating the use of public cloud providers to host websites with low volume, low security requirements, and no mission criticality. Public solutions could be better/faster/cheaper than internal provisioning.
Thus, our cloud strategy is to create private clouds that are more reliable, more secure, and cheaper than public clouds for those applications which require higher levels of availability and privacy. For those use cases where the public cloud is good enough, we're considering external solutions.
Someday, it may make sense to move more into the public cloud, but for now, we have the best balance of service, security, and price with a largely private cloud approach.
Wednesday, December 15, 2010
Subscribe to:
Post Comments (Atom)
8 comments:
Don't forget about optimizing the environment to save energy, reduce costs, and CO2 emissions. 1E (www.1e.com) can help in both the datacenter and at the PC level.
Hi John,
I disagree with you on this one. And posts like this one only continue the myth about the cloud not being secure for PHI health data. Just because a solution is deployed to a private data center it is not more secure. Bad software can just as easily be deployed to a private hosting physicality.
<<
Thus, our cloud strategy is to create private clouds that are...
>>
<<
more reliable,
>>
Your private 'blades' are not more reliable than ec2. Their scale dwarfs yours, thus ec2 is more reliable. Their multi-location and redundancy ability, I have to believe, is better than yours. You didn't mention multi-location redundancy, but maybe you have that to some level.
<<
more secure,
>>
'Maybe' your Harvard hosting is as physically secure as Amazon ec2, but I would bet on Amazon - their business viability requires they pay attention to this at the highest level. After physical security, your security is only as good as how you or your vendors architect your solutions (think OWASP).
<<
and cheaper than public clouds
>>
No way?? This statement doesn't make sense to me. There is no way you acquiring hardware and staffing your hosting facility cheaper than a public cloud option.
I've worked in healthcare IT for 20 years where security around PHI is always of top concern. And a breach would mean the end of the reputation of the company and probably the company itself. So none of these opinions come lightly from me. At my latest employer which works with health PHI data, we are deploying to the cloud (ec2) and I feel this solution is the most secure, reliable, and HUGELY less expensive than any I've ever worked on. And I've worked in some very big health IT shops that had their own very advanced hosting facilities (with virtualization/'private clouds').
We've implemented very comprehensive encryption at the field level in the db.
Here's the interesting question - will Amazon sign a Business Associate Agreement and accept the liability of a privacy breech?
Amazon probably doesn't sign business associate agreements (I don't know this for a fact). I'm not sure that is a common practice by hosting companies anyway. Amazon, by default, doesn't have access to ec2 instances (they don't use/interact with the data). In your situation seems like you would be assigning liability back on yourself anyway since a related entity within your organization is the hosting provider, so I don't understand what a business associate agreement gets you (I'm not a lawyer though :) And like I said before, I think Amazon has more reasons to keep their data centers at the highest security.
I'm not trying to say that a public cloud is the only option. By no means is this the case and what you are doing sounds like a good solution and maybe more flexible in some ways? I just want to make the point that deploying PHI healthcare solutions on a public cloud is very realistic today and companies are doing it.
Thanks for sharing your thoughts and publishing my comments.
meant to leave this link as well - amazon HIPAA/PHI whitepaper - http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Final.pdf
This is a great example of the contrast in opinions and viewpoints related to cloud computing in healthcare. Thank you for your perspectives. We included this post on our blog today - http://www.pathagility.com/blog/index.php/2010/12/16/great-healthcare-cloud-computing-posts/
Hi John, I agree with Chad on his comments on your cloud strategy. Having said that it makes sense that in your industry privacy and compliance are compelling reasons to build private clouds. Reading your post it looks like you have built a custom multi-user mainframe out of standardized components.
On your cloud strategy, how do you prevent hospital staff using cloud based services now that you can access these with the swipe of a credit card?
I am currently looking at cloud deployment strategies, hence the question. Anyway, thanks for the interesting post!
Pim
Your comment about liability is very interesting -- that does not protect patient privacy any better; it protects Harvard Medical School though.
Are you implying that having the paperwork to cover liability is more important than the actual security of patient data? (since it was an answer to a security question)
I agree with Chad that, in the age of wikileaks, there is no logic in assuming that any HMS network is more secure than Amazon.
In fact I believe the opposite is more likely: Everyone can be considered to be amateurs compared to guys like http://perspectives.mvdirona.com/
Naming of clouds provided by third parties as "public" is confusing as wel (I know it is not your invention! =) - In either case, one goes through a bunch of authentication layers to have access to data.
Post a Comment