
HIPAA 101 for Software Development Teams - chasb
https://www.aptible.com/blog/common_HIPAA_questions.html
======
patio11
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.

~~~
Johnny555
_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.

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

~~~
Johnny555
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...](http://www.hhs.gov/hipaa/for-professionals/faq/570/does-hipaa-permit-
health-care-providers-to-use-email-to-discuss-health-issues-with-
patients/index.html)

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

------
ashworth
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...](https://github.com/truevault/hipaa-compliance-developers-guide)

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

~~~
jason_wang
@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...](https://drive.google.com/file/d/0B-CT1SxLwR31X293VXFCSll3Z1E/view?usp=sharing)

~~~
tinco
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?

------
Johnny555
_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...](https://aws.amazon.com/compliance/shared-responsibility-model/)

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.

~~~
nickpsecurity
"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?

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

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

~~~
theallan
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?

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

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

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

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

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

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

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

~~~
kgosser
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/hipaa-compliance)

[https://catalyze.io/hitrust](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](https://catalyze.io/learn)

~~~
JoshMandel
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](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...](http://www.hhs.gov/hipaa/for-
individuals/medical-records/index.html) 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/...](http://www.hhs.gov/hipaa/for-
professionals/privacy/guidance/access/) .

(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...](http://www.healthinfolaw.org/comparative-analysis/who-owns-medical-
records-50-state-comparison)

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

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

~~~
dang
Looks like you meant to post that to another thread; possibly
[https://news.ycombinator.com/item?id=11377847](https://news.ycombinator.com/item?id=11377847)?

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

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

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

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

