I regret that I cannot answer this question in the way you have phrased it, because you can't just check a box and say that a cloud host is suddenly HIPAA compliant or not. There are various procedural safeguards which you'll need, the absence of which will make any technical safeguards irrelevant from a compliance perspective. For example, one of the requirements is that you have a nominated HIPAA officer, another is that you have a written policy to discipline employees who abuse patient health information. You need both of these things regardless of whether your host makes certain aspects of compliance with the Security Rule easier.
About those things: HIPAA was apparently drafted by Congressional aides, not by technologists, so the Security Rule establishes a bunch of checkboxes which have eff all relevance to my main concerns as a systems engineer about application security.
For example, HIPAA and the assorted guidance is, as far as I know, totally silent on what this:
Do you have procedures for creating, changing, and safeguarding passwords?
actually means when the bcrypt hits the road. I'm pretty sure that "Yes, we do. We enforce 8 character maximum passwords, they have to be changed every 3 weeks and 1 day except when the anniversary date falls on a Tuesday, and they are secured in our database by ROT13, an advanced encryption technology." is facially compliant as long as you have written it down somewhere. There is very little in terms of either best practices or safe harbors.
This is a long way to say that you probably can't take an application and HIPAA-ify it by writing a check to a hosting provider.
Given that you have the procedural and technical safeguards in place, I'm personally of the opinion (and feel free to check with your lawyer) that the right words, procedures, and application-level security features make it possible to host HIPAA-compliant applications on most common cloud providers.
I am not a lawyer, this is not legal advice, yadda yadda.
I would be careful using most cloud providers for storing PHI because most cloud providers will not sign a Business Associates Agreement (BAA). Keep in mind that the HHS has recently made a 'final ruling' that makes BAA contracts more stringent for companies that deal with health data as well so you may want to take a peek and ask a lawyer if you are worried.
As patrick notes most the Security Rule is mainly just a lot of documentation that has to be written. If you have even a little security background you probably have a good technical handle on it already (encrypted in transit, encrypted at rest, have good access controls, etc). Specifically it feels like a way for non technical people to track whether an organization is doing anything in regards to security. Keep in mind though since these policies and procedures are what you hand an HHS auditor when they come knocking you better have them in some fashion. Even a little documentation turns the conversation from "willfully neglected x,y, and z" into "You need to improve on x, y, and z". If you are interested in a fairly comprehensive checklist tool check out this little program from NIST http://scap.nist.gov/hipaa/
I am not a lawyer, not legal advice, etc etc
--------- Personal opinions and speculation
Keep in mind that in order to fall under HIPAA you have to use/store personally identifiable health information.
If you are looking for an easy way out of HIPAA you might want to look up 'de-identified health information'. Essentially what this means is that if you strip out all identifiable data from your records you no longer fall under HIPAA regulation, which may be useful if your company is doing statistical analysis of flu trends but probably less helpful if you need to be able to piece the data back together. I believe there are officially 18 or 19 pieces of information that make information personally identifiable.
As another note, once PHI is encrypted it is no longer considered PHI. It's my own opinion that you could probably leverage cloud services for a lot of operational work such as automated backup storage as long as you carefully encrypt everything before it hits any disk. Food for thought
My impression at a distance is that the act of outsourcing may open a new can of worms when it comes to HIPPA. Is that consistent with your understanding?
We are now approaching the territory of "Seemingly simple questions it is maddeningly difficult to get a straight answer on", but I have discussed this with multiple lawyers, often experts at HIPAA under the employ of enterprise clients, and "You don't own the hardware?" has never been a dealbreaker for them.
YMMV. Ask a lawyer if you want to sleep better at night.
I will close with the observation that, empirically, the system that you and I come up with is OMGWTFROFLSTOMP more secure than what passes for state-of-the-art at many of our clients. ("We didn't want the data to be stored in a database, because that isn't secure, so just think of worse places to put data because I think I've heard them all.")
I know a couple of things regarding HIPAA compliance, first-most you need a very high level of security on the transport layer (I believe it's 256 bits AES or higher for SSL - some spout that 128 bits is sufficient, but effectively a standard SSL certificate doesn't cut it). The second is HIPAA compliance is multi-part (see http://luxsci.com/blog/what-makes-a-web-site-hipaa-secure.ht...) and the infrastructure can only support HIPAA compliance (ex. if you're using AWS S3), but your application is responsible for the implementation thereof.
Your application cannot be branded to be HIPAA compliant simply because your infrastructure supports it. You'll have to go through the requirements list in order to construct your infrastructure to support it and then enforce the rules on the application and systems thereof (at least via unit/behavioral testing). You cannot really prove your application is compliant without proper test cases that enforce the rules.
About those things: HIPAA was apparently drafted by Congressional aides, not by technologists, so the Security Rule establishes a bunch of checkboxes which have eff all relevance to my main concerns as a systems engineer about application security.
For example, HIPAA and the assorted guidance is, as far as I know, totally silent on what this:
Do you have procedures for creating, changing, and safeguarding passwords?
actually means when the bcrypt hits the road. I'm pretty sure that "Yes, we do. We enforce 8 character maximum passwords, they have to be changed every 3 weeks and 1 day except when the anniversary date falls on a Tuesday, and they are secured in our database by ROT13, an advanced encryption technology." is facially compliant as long as you have written it down somewhere. There is very little in terms of either best practices or safe harbors.
This is a long way to say that you probably can't take an application and HIPAA-ify it by writing a check to a hosting provider.
Given that you have the procedural and technical safeguards in place, I'm personally of the opinion (and feel free to check with your lawyer) that the right words, procedures, and application-level security features make it possible to host HIPAA-compliant applications on most common cloud providers.
I am not a lawyer, this is not legal advice, yadda yadda.