Healthcare data is breached at a rate of more than once per day. According to the HIPAA Journal, there has been an upward trend in data breaches over the past nine years. And it’s not just from hacking incidents—users view data that they’re not supposed to, they send it in plain text emails, they download it onto their laptops, they leave their computers unattended and assume that the application has timed out, and so on. Even an accidental breach is taken very seriously by regulators, with fines of up to $50,000 per record.
If you’re providing software to covered entities under HIPAA who have access to electronic protected health information, you are probably very familiar with the requirements that apply to you under the HIPAA Security Rule. These requirements extend to the analytics capabilities such as dashboards, reports, and business intelligence features that are embedded in your application.
If you’re working with a third-party vendor to add dashboards and reports to your application, your embedded analytics platform needs to adapt to and mimic your native HIPAA-compliant solution. However, few analytics vendors make this an easy process. Here’s what you need to know:
It’s All About Security
Analytics is tricky in the places where it intersects with compliance. If you have analytics in your application, it may need to process vast reams of data that’s sitting in a warehouse, and some of that data—which is freely available to the application—must be kept hidden from specific end users. HIPAA compliance in an analytics context is dependent on a high level of granularity when it comes to security.
Some key questions you’ll want to ask your embedded analytics vendor include:
- Does your embedded analytics vendor provide granular data security, down to the cell level? If one of your end users is allowed to see everything except a specific cell in a specific table, can you create a rule for this scenario? For example, if a doctor is viewing a list of patients in a specific unit, she may need to see the entire list of patients but only view blood test results for the patients assigned to her.
- What about object-based security? This means that for a given object—a report, a record, or a database—users may have a certain level of privileges. Authorized users will be able to view, create, edit, and delete these objects. Other users will have fewer permissions. These permissions must be robust—if an individual doesn’t have viewing privileges for a dashboard or report, including a chart or a table, they shouldn’t even be able to see that it exists. A hospital administrator may view a dashboard with aggregated information about patients and insurance details but they should not be able to view a visual inside a dashboard that shares test results for patients.
- Are there time-out settings? Like most applications, your application probably times out after a period of inactivity and automatically logs out of user accounts. Your embedded analytics platform should have time-out settings that work seamlessly with your application’s settings.
- Does the embedded analytics platform have activity logging? Your customers should have the ability to access and review system activity by user—what has been viewed and executed? This helps identify breaches and will be necessary during an audit.
- Does the platform support SSL encryption of delivering your analytics to end user devices? Your application should be able to deliver content through https. Does the vendor support SSL encryption of delivering your analytics to the end users devices? This prevents unwanted third parties from capturing traffic between you and the end user and viewing information in plain text.
You need to ask the right questions to ensure that you have the technical safeguards in place as outlined under the HIPAA Security Rule. The HIPAA Journal provides a helpful compliance checklist for ISVs providing software to the healthcare industry.
Building and Testing HIPAA-Compliant Security Models
HIPAA records can be breached through both accidental exposure and malicious exposure. Unscrupulous employees and external attackers will try to steal personal health information, and any software provided to a covered entity needs to resist these attempts.
You’re probably creating your solution with the principles of secure development in mind, but you also need to validate your security through testing. A penetration test is one way to do this. Your pen test should begin with a dependency checker—an automated, high-level test that checks to make sure your application isn’t using any software that contains known exploits.
The core of the penetration test includes vulnerability scans that go well beyond checking for known exploits. This helps to ensure that the embedded analytics vendor is aware of HIPAA requirements and resistant to hacking attempts. Although HIPAA doesn’t specifically require penetration tests, running these tests—and providing results to your customers—is a great way to prove your security bona fides.
Preserving Your Security Model
Ultimately, if you build a robust security model, every analytical query—every call that retrieves data from the system—should have security in it. You’ve invested significant time and effort in designing your security with HIPAA in mind. Partnering with an embedded analytics vendor that leverages your existing security model will minimize your development efforts and impact your ability to maintain it over time.
The right evaluation criteria can set you up for embedded analytics success. For more information on evaluating business intelligence and analytics vendors, read our BI Buyer’s Guide >