Got HIPAA?

HIPAA is pretty awesome! Well, that’s not entirely true. HIPAA has some significant drawbacks, like being interpretable and having some massive penalties for violating it. It has also developed a reputation in healthcare and even outside of healthcare.

HIPAA technically only applies to covered entities, such as providers, payers, clearinghouses, and business associates that are doing business with those covered entities. There are debates in Washington to extend HIPAA to PHR systems like Microsoft’s HealthVault, but for now those services do not consider themselves to be business associates and technically are not required to follow HIPAA.

The biggest problem with HIPAA is the knee-jerk reaction of, "Oh, HIPAA, that’s a pain to work with or around," or, "The data is stored the cloud — that may be a problem.” The latter statement is thankfully becoming historical. Another problem is all the claims made about being "HIPAA Compliant."Ann Farrell offered a good comment on this in my last post.

I’m curious how developers, both inside and outside of enterprise, are approaching HIPAA. For mobile or web app developers, cloud storage and virtual servers are essential to creating full-featured apps. Some apps are and will always be purely local (only use mobile device storage) but those are few and far between. They also are certainly not the most engaging or useful apps.

Apps need a way to do remote storage, user log-in, and collection and storage of data, along with a few other hosted functions. If I look at the home screen of my phone, every app (with the exception of Camera+) requires cloud connectivity. Camera+ connects to cloud services for storage of photos, but it’s not required.

Interestingly, the biggest name in cloud services, Amazon, recently announced that it will start signing business associate agreements (BAAs). That is great, though I e-mailed Amazon Web Services (AWS) five days ago to see how to get a BAA signed for our AWS account and I haven’t received a response yet. Amazon is not exactly rushing to expose itself to financial risk from a breach. Considering Amazon can’t assure the software restrictions put in place by developers that use its services, I’m betting the BAAs Amazon signs will only apply to hardware and data center access. It’s a good step by Amazon either way, but from a panacea.

HIPAA is interpretable is because it’s not necessarily prescriptive, at least it’s not 100 percent prescriptive. This interpretability could also be seen as a positive, as it builds in a degree of judgment and a “one size fits all” solution isn’t the only option. But it also means that lawyers, compliance folks, and regulators can spend much time and energy debating it.

My experience has been that HIPAA, in practice, is prescribed as a “one size fits all” regulation and set of requirements, despite the actual rules that state, "In deciding which security measures to use, a covered entity or business associates must take into account … The size, complexity, and capabilities of the covered entity or business associate … The costs of security measures … The probability and criticality of potential risks to electronic protected health information." I’m curious if other app developers, especially startups, have had similar experiences working with covered entities.

HIPAA as it’s written isn’t that hard. Or at least it doesn’t have to be. It’s not rocket science from a security and a privacy standpoint, but it does require judgment and justification regardless of if and how it is implemented. It can require additional time to configure technology and there are the additional costs of audits, something very few small vendors can afford.

Back to my original question. How are developers, especially smaller developers, dealing with HIPAA? I’ve spoken with startups that are ignoring it because technically they can — they build apps and services distributed directly to users. A good example of this is a mobile PHR that doesn’t connect to any provider or payer systems. Ignoring HIPAA works until you want to sell to healthcare providers or payers.

I’ve also spoken to lots of developers that read and interpreted HIPAA, then implemented servers with access controls, encryption, auditing, and a few other configurations mapped to meet the HIPAA Security Rule.

The thing about HIPAA is that it is just the tip of the iceberg. As I wrote about last week after hearing somebody talk about HIPAA being only one regulation, there are many privacy standards emerging. Many of these extend beyond the covered entities and business associates to which HIPAA applies.Regardless of the regulation, if developers are looking to work with healthcare enterprises, those enterprises are going to hold them to the same standards they are held to. In essence, vendors and partners are an extension of enterprises, at least they extend the risk of a breach.

What do you think about HIPAA? How do you approach it today, especially as smaller developers and vendors?

TGphoto

Travis Good is an MD/MBA involved with health IT startups. More about me.

  • kylesamani

    we’re relatively lucky. we’re not going cloud for good reasons. everything Pristine does lives in the hospital firewall.

    so most of HIPAA for us boils down to:

    encrypt at rest

    encrypt in transit

    also, this http://blog.humanapi.co/post/54110271373/hipaa-for-hackers

  • travisjgood

    Interesting. In your BAAs are there specific requirements around logging and archiving? I guess it depends on how you fit in the architecture.

  • kylesamani

    Travis

    We maintain an audit record of every user transaction. Given that we operate in and around the OR, where everything is time sensitive, we needed to build an audit trail as a functional business requirement. It obviously doubles as a HIPAA function as well 🙂

↑ Back to top

Founding Sponsors

Platinum Sponsors