HIPAA 101 for Software Development Teams | Hacker News Reader

HIPAA 101 for Software Development Teams

aptible.com

251 pointschasb36 comments

What I've learned over the last few years:

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.

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

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.

This is a great example of a HIPAA poser, because that system: still a violation if one treats the regulations as actually meaning what they say. The "We have a message for you" disclosed a doctor-patient relationship (protected health information) about an email address (personally identifiable).

It's unlikely they'll receive a complaint/investigation for installing that software.

I fail to see how the email discloses anything protected, since it's completely generic:

    Dear member,

    You have a new message from *Redacted Healthcare System*

    Please click on the link below, or copy and paste the link into your browser.

So from the email it's impossible to tell if it's even a message for me, or someone else in my household that I'm authorized to receive healthcare information for. And it hardly seems any more revealing than the weekly "wellness emails" that every healthcare system seems to send to its members.

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).

http://www.hhs.gov/hipaa/for-professionals/faq/570/does-hipa...

Exactly. He's calling himself a poser with a claim like that. The use of protected portals with generic notifications is both allowed and widespread in use. Almost every provider I've run into does a variation of this. There's even turn-key solutions in this and other regulated markets. Incidentally, it was also the solution secure email providers came up with for when people don't have your encryption software but do have regular email & HTTPS-enabled browsers.

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.

The patient would presumably consent first (to the notification emails).

I work in this industry, connecting customers' data flows, and one of the biggest problems I have on a regular basis is trying to describe to a client how their ADT data is not matching their claims data (which matches on account numbers, mrns, etc) without using PHI for examples. It's very frustrating.

I second 1, 3, and 4. Good advice. The market could handle Number 2 like they did in smartcards and DO-178B sector. Apparently, whatever they're doing isn't appealing.

From the team at TrueVault, a GitHub repo with a developer's guide to HIPAA compliance. Similar to Aptible, they pitch themselves within the guide but still a good resource:

https://github.com/truevault/hipaa-compliance-developers-gui...

The guide is pretty good and definitely helped me get up to speed with HIPAA. The product, not so much. They had 10 days of downtime around Thanksgiving. Not a happy holiday for my team.

@servercobra is correct.

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...

Nice report, sounds like a nightmare scenario. You seem to take care to don't mention any names of the used technologies/vendors even though the report specifically says they have admitted to misleading you. Is this because you have reached some kind of settlement with them?

Is it reasonable and appropriate not to encrypt traffic between an app and a database inside a virtual private cloud? ... There is little official guidance for engineers and developers today

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.

https://aws.amazon.com/compliance/shared-responsibility-mode...

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.

"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. "

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?

Does anyone have experience with HIPAA who is not based in the US?

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.

We have several non-US customers. What do you mean by "channels you need to go through"?

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.

I had assumed that you would need to register to claim to be HIPAA compliant, but that doesn't actually appear to be the case. It looks that if you claim it, you can be audited by Dept of Health and Human Services (HHS). I wonder how that works internationally?

Exactly, there is no official registration or certification for HIPAA. It's more that HHS will take an interest if you come to their attention and appear to be creating/receiving/transmitting/maintaining regulated patient data.

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.

Do US companies need to be HIPAA compliant if working exclusively with international companies ("covered entities" if they were located in the US)?

Focusing on the data help clarify this. This is a negligently simple explanation, but: HIPAA regulates identifiable patient data that touches a US-regulated insurance transaction somewhere in its lifecycle.

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.

As an Australian, an astounding amount of security product vendors use HIPAA as part of a worldwide marketing strategy, and never stop to consider that it's not a thing elsewhere.

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".

This was a good read. It's something that I can point people to, since even as a health care provider (firefighter/paramedic) we frequently run into other levels of provider that are clueless about HIPAA and use it as an excuse to not provide information that we need. (in other words, they're being lazy, and claiming "that's a HIPAA violation" is way easier for them.)

It's amazing just how misunderstood HIPAA has become.

Not subject to HIPAA as in the UK but something I'm working on stores medical data, this looks interesting though.

I wish the UK had something so concise.

Yes. As someone who's worked in the healthcare industry in both Australia and the US I actually miss HIPAA in Australia. While it was a huge PITA, the majority of what it specifies is actually common sense and good security / privacy practises. The explicit nature of the guidelines and the force of law sitting behind them is very empowering to engineers who want to implement these practices but struggle to convince senior management that they are important otherwise.

Full disclosure: I'm an engineer at Catalyze Inc, a direct competitor of Aptible's.

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.

Educating the startup community on the complexities and necessity of HIPAA is important. I'm glad Aptible is helping the YC community.

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:

https://catalyze.io/hipaa-compliance

https://catalyze.io/hitrust

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:

https://catalyze.io/learn

Thanks for these guides.

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...

Thanks a bunch for the feedback, Josh! Forwarding right now to our Privacy Officer.

I have a place in my heart for concatenative languages. When I was a junior engineer in 1970 working on the first sealed hard disk, I used forth to build test routines for the disk. I started with transferring bytes, to seeking, up to reading any block. It went fast and was very flexible.

Looks like you meant to post that to another thread; possibly https://news.ycombinator.com/item?id=11377847?

Yup. How did that happen? I'll have to be more careful. Oh well, a bunch of downvotes won't kill me.

Asking HN commenters: Regarding HIPAA requirements, how do you get protected from malicious software on Macs?

1. Training

2. Training

3. Training

4. Anti-virus. We use Sophos, but anything that updates itself and stays out of the way is fine to start out.

Document something akin to the following:

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.

Mac and Linux being less vulnerable is not a guarantee anymore. There's some that argue that the past few years, Mac and Linux have had more vulnerabilities than Windows has, especially severe ones (and especially Mac). Here's [one article](http://thehackernews.com/2015/02/vulnerable-operating-system...) on it, but there's plenty out there.

"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.

Reply on news.ycombinator.com