How I learned to stop worrying and love HIPAA: part 3

Greg Detre
4 min readDec 10, 2017

From Part 1, you have a sense of what data you need to protect and how to assess risk. Part 2 discussed documentation requirements.

The Security Rule

In this section, we’ll focus on some of the HIPAA Security Rule requirements. You know, the nitty-gritty/infrastructural work you knew you’d need to do: encryption, banning passwords on post-its, locks on filing cabinets, etc.

Perhaps the most striking thing to me about HIPAA is how little it specifically mandates. It doesn’t say that you must use a particular algorithm to encrypt your hard disks with, or how many locks you need on your door. It divides its ‘implementation specifications’ into ‘required’ and ‘addressable’. Addressable doesn’t mean optional — it means that those things are a very good idea, so you should either do them, or document in your Risk Assessment why they don’t apply or what you have done instead.

In practice, we implemented pretty much all of what HIPAA considers addressable, eventually. Even recommendations that seemed unnecessary at first, such as anti-virus for our Mac laptops and Linux servers, have since proven worthwhile (and necessary for more prescriptive standards like ISO27001 and HITRUST).

[Source unknown]

The Security Rule divides safeguards into the physical, administrative, and technical.

Physical safeguards

The Security Rule applies to electronic, paper and oral security. We’ve tried to minimize the risks posed by physical access to our offices, by avoiding any printed PHI and hosting on AWS (whose data center physical security guarantees are strong). [Make sure you have a BAA in place with your hosting provider, and read the fine print about what they require of you.]

But if non-employees have access to your office or your data center, you still need to think hard about the worst things that could happen through a physical attack, theft, natural disaster or other incident. Depending on your Risk Assessment, you may need to think about things like: how you wipe/reuse hard disks, encrypting USB keys, securing physical backups, records of access to your offices, what happens if your office is inaccessible. [HIPAA doesn’t just care about breaches — it’s also there to protect against lack of access to patient data].

Any devices that have PHI on them (USB keys, laptops, hard disks) should be encrypted at rest, passworded, with a quick screensaver, and generally locked down as tightly as possible — better still, minimize downloading of data from your data center at all.

Administrative safeguards

We’ve touched on many of the Administrative Security controls in Parts 1 and 2 with Risk Assessment, training policies.

This also covers workforce security (e.g. sanctioning employees who violate HIPAA, hiring procedures and background checks).

It covers the logistics of security, such as good password management, backups, disaster recovery, and anti-virus software.

It also covers administrative procedures, such as regular reviews, access control, and procedures for dealing with Security Incidents.

Technical safeguards

  • Encryption. In the case of encryption, it’s almost always better to have more. If you accidentally disclose PHI that has been encrypted, it does not count as a breach. We encrypt all PHI at rest, including servers, logs, backups, laptops, and any other devices. Otherwise, a single stolen hard disk could be catastrophic. Encrypting in transit is just as important — tunnel everything over https and ssh. If you can throw a VPN into the mix, all the better, though that’s more complex to set up.
From https://xkcd.com/257/
  • All of the safeguards stress the importance of being able to log what happened, and who did it. Each personshould have their own account, and all security-critical actions should be logged.
  • This is where HIPAA specifies how users should be verified — at the least, it expects good practices (check against encrypted password). Depending on the risk (e.g. for your AWS root password), consider stronger password requirements and 2-factor authentication.

Conclusion

HIPAA is a journey, not a destination, and we’re continually working to improve our security and our policies.

HIPAA provides a solid foundation — once you can say honestly that you’re HIPAA-compliant, you’ll already be well on your way towards a stricter standard (like ISO27001 or HITRUST), and you’ll also know clearly where your weaknesses are.

Resources

  1. These are my favorite HIPAA security intro documents — they provide a clear high-level introduction to the various components of HIPAA. See also.

A request

If you found these guides useful, drop us a line at hello@sleepio.com, and let us know if you have questions for future guides!

You can follow our publication ‘We are Big Health’ on Medium.

--

--

Greg Detre

Advisor and coach. Former Chief Data Scientist at Channel 4, co-founder of Memrise. Data Dig podcast host https://www.data-dig.com/