1) The requirements are theoretically tractable by an SMB but only just.
2) Non-compliance is ridiculously widespread. Ridiculously. This is partly because HIPAA prohibits people from doing things they really want to do (emailing about a patient, perhaps to that patient) and partially because the requirements are so vague.
3) Be prepared to use HIPAA as a pricing segmentation engine and for your providers to use it on you. Getting a BAA with Rackspace, for example, quintupled our costs.
4) Get insured. Because literally everyone is exposed to this and investigations are infrequent, the industry treats them like acts of God. You can insure, minimally, the cost of responding to an investigation (though my policy doesn't cover any fines assessed) and breach notification.
My healthcare provider solves this by having a health portal that I log in to to send/receive messages to my doctor and view test results.
It's all SSL encrypted and protected with my individual password, which is more than they can guarantee with plain email. When I have a new message in the message center, they send me an email to tell me to log in.
I should hope that any healthcare provider that wants to share PHI with a patient does the same rather than using email, where they have no assurance that the email is encrypted, stored securely, or protected by a strong password.
It's unlikely they'll receive a complaint/investigation for installing that software.
You have a new message from *Redacted Healthcare System*
Please click on the link below, or copy and paste the link into your browser.
HHS specifically allows a provider to use email:
The Privacy Rule allows covered health care providers to communicate electronically, such as through e-mail, with their patients, provided they apply reasonable safeguards when doing so. See 45 C.F.R. § 164.530(c).
I'll go further to say it's probably one of the best models a company can use since vast majority of INFOSEC research and product development goes into exactly that sort of construction and tech. Even high assurance sector has solutions for some of that. Plus it has high usability and compatibility. Win across the board.
Our Search API (all other services unaffected) experienced an extended outage last Thanksgiving affecting ~9.2% of our customers. This is the full incident report: https://drive.google.com/file/d/0B-CT1SxLwR31X293VXFCSll3Z1E...
While HHS may not tell you what to do on your own private cloud, if you host on a public cloud, you'll have to sign a BAA where the provider will tell you what you need to do to ensure HIPAA compliance of their platform. AWS, for example, requires encryption everywhere -- end-to-end encryption from the client to your servers, encrypting all PHI data sent between your servers (web, app, db servers, etc), and encrypting all data at rest.
If public cloud providers require encryption everywhere, I'd sure hate to have to explain in a HIPAA audit why I thought it was not "reasonable and appropriate" to do the same thing in my own datacenter after investigation for a breach that used a network sniffer between my servers.
We had one application that did not support encryption natively, everything was sent in the clear, so we ended up setting up a point-to-point VPN between those servers to encrypt data in transit. Otherwise, AWS wouldn't have signed off on the BAA if we could not assure them that all PHI was encrypted.
That's basically the hack I used for situations like that, too. I have considered modifying something like tcpcrypt w/ authentication with hooks that force the application to use that. Not entirely sure it's a good idea but might help on legacy stuff. Put the keys and whitelists in there manually. Optionally put it and TCB in a TCP/IP offload card that also provides a performance boost as further justification. What you think?
It can obviously be useful as a sales avenue to US based customers, but I'm wondering what channels you need to go through if you are not a US based company.
Most of the standard desktop AV vendors have contacted me with taglines like "meet your HIPAA obligations today!". I can name Kaspersky, Symantec, McAfee all as having had really confused salespeople when you try asking them why an Australian company would have HIPAA obligations, often just replying to insist "it's actually the law".
Generally, if you can meet the requirements, you can handle patient data for US customers. HIPAA doesn't have any sovereignty requirements (geographic restrictions on where the data are stored/transmitted), although it's fairly common to see them introduced in contracts or BAAs.
There are a few ways to come to HHS's formal attention:
1) A complaint;
2) Via another enforcement action, usually against one of your business partners; or
3) An audit
Phase 2 of the HIPAA audit program is starting this year. The first step is a questionnaire that asks you to confirm if you are a business associate. HHS is also asking that each entity they contact provide a list of their business associates.
All of the above is true even if you are based internationally. Most of the Phase 2 audits are desk audits, meaning HHS will ask auditees to submit documents and other data. I'm not sure how an onsite audit would work for an international entity.
If you're in the US, but working with only international healthcare providers and international patients, HIPAA is less likely to apply. You may have other privacy laws and regulations to deal with, however, especially in Europe.
It's amazing just how misunderstood HIPAA has become.
I wish the UK had something so concise.
That being said working with payers and providers you are obviously going to want to learn the ins and outs of HIPAA. However increasingly providers, and by proxy, payers are requiring that their vendors be HITRUST certified. It is worth realizing that being HIPAA compliant will not be enough for a lot of the big players. Just something to be aware of!
FYI, my company's platform is HITRUST certified, beyond the simple self-study, which, again, is often not enough for the big players in health care.
To tack on to my colleague at Catalyze: We provide two thorough guides to both HIPAA and HITRUST. If anyone is looking for a deep dive on either topic, you can access the guides here:
The guides are a thorough summary and aggregation of all our content spread throughout the web, which is why they are behind a form. If you would like to access all the content directly, it's largely all available for free as separate entries in our Academy:
You may want to re-word what you say about patient rights in https://catalyze.io/assets/media/HIPAA-Compliance-Guide.pdf -- you say that HIPAA "gives individuals ownership of their health records", but I don't think that's quite right. The Office for Civil Rights has a good overview on patient rights at http://www.hhs.gov/hipaa/for-individuals/medical-records/ind... and when it comes to the right to access, there's an excellent in-depth overview at http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/... .
(Note: it would be nice if you made your PDFs searchable; currently they're images, which makes it hard to find and cite relevant content.)
EDIT: for an in-depth treatment of the "ownership" issue (in its nuanced glory) see http://www.healthinfolaw.org/comparative-analysis/who-owns-m...
164.308(a)(5)(ii)(B): We have policies for guarding against,
detecting, and reporting malicious software. Specifically, we require our workforce to use Macs or Linux machines, and we exclusively host our applications on Linux machines, as industry consensus is that these machines are less vulnerable to infection by viruses than Windows machines. We will revisit this policy annually and revise if we determine that the risk of infection of a Mac or Linux machine is greater than Very Low. Our present assessment is Very Low. See also $POINTER, where we discuss securing the applications we host. Accordingly, our risk analysis recommends against spending engineering resources on this threat. Note that this subsection is Addressable, not Required, so we believe that this is sufficient for this subsection.
Welcome to HIPAA! You can do almost anything as long as you document the heck out of it.
There's already lists of code smells where you know the code might be shit if you see things on the list. I propose regulation or certification smells for things like above. Your process has it? Then it's not going to make things better for real.
4. Anti-virus. We use Sophos, but anything that updates itself and stays out of the way is fine to start out.