Is (Blank) HIPAA Compliant?

Intro

We all know in the Salesforce Ecosystem that Admins in the Salesforce ecosystem wear many hats. They manage new releases, improve user experiences, provide analytics, and balance feature requests with technical debt. On top of all that, security and compliance often fall under their responsibilities.

Some organizations are extremely aware of their compliance obligations – indeed in some cultures, it’s nearly impossible to talk or think about your Salesforce org without giving space for security and compliance. If you’re an admin at one of those orgs, this post is probably not for you. But if you’re a solo admin or a member of a small team, and when someone says HIPAA you think of a hippo, this post is for you.

What is Compliance?

Let’s start with the basics. What do we mean when we say “Compliance?”

In nearly every industry, there are laws and regulations that businesses and organizations are obligated to follow. Let’s think of aviation, a favorite around these parts. 

Having your flight delayed or canceled is no fun, and most of us have had this experience. You might have heard that this past year the US Department of Transportation enacted new rules which require airlines to provide “prompt and automatic refunds” for “canceled or significantly delayed flights.” As a frequent air traveler myself, my reaction was “Hey, that makes sense!”

This is a great example of a regulatory requirement that certain businesses must comply with… hey, there’s that word again—compliance! “Compliance” is a shorthand term for all the activities that an enterprise might engage in so that they can meet the requirements of a law or regulation that applies to them. It’s a pretty general term, and in some industries it’s a major part of how any organization does business. Aviation is a great example, but many of us are familiar with more… medicine, law, and finance all come to mind. 

What does it mean to be “compliant”?

It’s key to understand that being “compliant” lies in how something is done. 

In our above example, when my flight is delayed or canceled, my airline is obligated by government regulation to issue me a prompt refund. They may do this a number of ways; I recently had a significant delay and the airline used the same ticketing system that I used to purchase my tickets in order to issue me a partial refund. They just sent it back to the credit card I’d used to purchase the ticket. 

So here we have two elements at work:

1. The system used to issue my refund to my original credit card.
2. The act of doing so in a timely manner consistent with the finer points of the regulation. 

Is the system alone “compliant” with this regulation? Can those servers and software issue a refund on their own, without instructions, automation, or any interaction? No, they cannot. Compliance is achieved in how it is used. Compliance is an act; being compliant lies in the manner of usage, not solely in the system’s characteristics or attributes. Sure, it has to be CAPABLE of issuing the refund, but it’s the issue of the refund itself that keeps my airline out of hot water with the regulators. 

“Compliance is an act; being compliant lies in the manner of usage, not solely in a system’s characteristics or attributes.”

You might see where I’m going with this. As a Salesforce Consultant, I’m asked all the time, “Is X product HIPAA compliant?” The best possible answer you’ll ever get out of me is “It CAN be.” Just sitting there by itself, no product or app is compliant with anything; compliance is achieved in how the system is USED. 

What’s HIPAA?

Let’s turn to the regulatory requirement that started this whole thing – HIPAA, HIPAA—one of the most frequently encountered regulatory requirements in Salesforce implementations. 

HIPAA is shorthand for the Health Insurance Portability and Accountability Act. It’s a law, enacted in the ’90s, which has a number of provisions to protect patients, but the subset of the law that we’re usually concerned with is the one that protects a patient’s sensitive health information from being disclosed without their consent. Information subject to protection is called “protected health information,” or PHI. 

Examples of PHI can be obvious, like health care diagnoses or treatment details, but it can also include biometrics like fingerprints and voice recordings, or even an individual’s basic demographic information like insurance ID numbers or Date of Birth. This means, if you’re a nonprofit (or any other organization, for that matter) storing this information, you may have an obligation to protect this information from unauthorized disclosure under HIPAA.*

* I’m a Salesforce Architect, I’m not a lawyer, so I can’t tell you if you have this obligation – see your organization’s legal counsel and/or compliance managers for more information.

So… Just tell me, is (Blank) HIPAA Compliant?

I hope you can see now why this question tends to get the Consulting answer of “It depends.” 

To truly achieve compliance, the system must securely handle PHI by encrypting it at rest and in transit and managing server interactions. However, compliance also depends on users following proper procedures. They need to be sure they use the system correctly, like putting PHI only in the right fields, among other things. 

As the Salesforce Admin, your job isn’t done once you select third party software that has the ability to be used in a compliant way – you’ve got to DOCUMENT that correct usage, train your users, and have a recovery plan if something goes wrong… at minimum. Hopefully your organization has a compliance manager, and you will need to work with them to build these plans and decide how you want to store and maintain them. 

Wow. Sounds suspiciously like… governance!

Summary

Back in my Navy days, I once served in a unit that was accused of mishandling PHI. It was the early days of HIPAA, and everyone was still figuring out that we couldn’t just plaster a Sailor’s Social Security Number on any any document or system without restrictions and leave it lying around. As a result we had to undergo a Compliance Inspection by our cognizant Inspector General. Not the most pleasant experience, but that experience taught me an invaluable lesson.. The (civilian, I might note) compliance inspectors cared DEEPLY how the systems were being used. That the system was capable of being HIPAA compliant was just ONE checkmark on a very, very long checklist that included everything from disaster recovery plans to whether or not the terminals locked automatically when users walked away from them. 

Having gone through that, I learned:

• Compliance is complicated, and depends as much on usage as on technology.
• Having a written plan matters deeply. 
• Every regulation has an enforcing authority, and they almost certainly have a Checklist for when things go wrong… the only way to know you’re good to go is to get a copy of that checklist and run it for yourself. 

I hope sharing this experience with you has helped you become a better Admin! At minimum, I hope you’ve learned that any software vendor who tells you “just buy this and you’ll be HIPAA compliant” is more than a little sus… and that having good governance is the key to establishing and maintaining compliance. At the very least, I hope you now understand why your Consulting Partner responds to ‘Is this HIPAA compliant?’ with ‘It depends…’