The Hallmarks of a HIPAA-Compliant Embedded BI Solution

Sep 23, 2019

Mike Brody

Since the Final Omnibus Rule was added to HIPAA in 2013, software companies serving the American healthcare sector have grown used to double-checking their business partners for compliance with federal privacy regulations. Where once only healthcare providers, insurers, and other “covered entities” (CEs) were held accountable under HIPAA, now any business associates (BAs) and/or business associate subcontractors (BASs) involved in the handling of medical records are equally liable. The diagram below explains the relationship between these types of organizations.  

 

hipaa entities

Source: “Summary of the HIPAA Privacy Rule” (https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html) and “HIPAA Compliance Checklist” (https://www.hipaajournal.com/hipaa-compliance-checklist/)

 

Penalties for violating HIPAA are severe, so healthcare IT providers must be vigilant about acquiring security assurances; but many are at a loss for how to approach a technology like embedded business intelligence. By HIPAA’s definition, SaaS vendors serving the healthcare sector qualify as BAs, so would that make embedded BI providers their subcontractors, or BASs? Are embedded BI vendors directly liable under the law?

It all comes down to who is hosting or otherwise possessing the electronic protected health information (ePHI) in question. The majority of embedded BI providers do not host SaaS customer data and therefore do not come to possess ePHI. For this reason, embedded BI providers generally do not qualify as either BAs or BASs under HIPAA and are not directly liable.

There are, however, some exceptions to this rule. Since some embedded BI providers who do host SaaS data or may otherwise come to possess ePHI, SaaS vendors should always consult with their legal teams and evaluate partnerships on a case-by-case basis. In the event an embedded BI vendor is found to meet the definition of a BA or BAS, it will have to grant assurance of its compliance in the form of a written contract.

In most cases, however, a healthcare SaaS vendor can simply evaluate any prospective embedded BI providers for safeguards that will facilitate their own HIPAA compliance. Here are some important capabilities and policies to look for.

Here are the HIPAA safeguards your embedded BI vendor should have in place.

Access Control: An embedded BI solution should facilitate data tenanting at the user level. Each individual user’s access privileges should be configurable and based on a unique username and password. If the BI solution sits behind the host application’s authentication protocol, then it should have a means of authorizing credentialed users and barring third-party access. Otherwise, it will need to handle both authorization and authentication. The application should also support data masking so that sensitive information, such as the first five digits of a social security number, is obscured for personnel without full clearance. 

Training Employees to be Secure: SaaS providers should inquire into what happens to any electronic PHI (ePHI) that comes into the BI provider’s possession as part of technical support and other services. This might include how staff are trained to handle sensitive data and how it is disposed of after service has been rendered. Keeping record of which workstations and devices were used to temporarily store PHI may also be part of such training. 

Alternatively, the BI provider may have a mandate stipulating that all services be rendered using sample or “dummy” data. Vendors taking this approach should nevertheless have a process in place for disposing of ePHI in the unlikely event they come to possess any.

Encryption and Decryption: Encryption of ePHI is what HIPAA refers to as an “addressable” safeguard — something strongly recommended but not required where there are better alternatives. Most embedded BI solutions read rather than write to databases, so if the solution in question doesn’t have a built-in decryption feature,  the host application can resort to a third-party encryption/decryption tool that utilizes approved algorithms. The BI application would then connect to the decrypted data. Additionally, any information (e.g., connection strings) the BI solution uses to access data should be stored in a secure format and/or location.

Activity Logs and Audit Controls: It’s important for host applications to inquire into what data is being accessed through its embedded BI. The BI solution should facilitate this with activity logging and audit control features.

Reporting Security Incidents: The BI provider should have a process in place for notifying the host vendor of security vulnerabilities discovered in the software and obtaining a workaround while a fix is in progress. Because BI vendors don’t typically host or store data belonging to the SaaS provider or its customers, breach notification responsibilities do not fall to them. Security vulnerabilities can, however, result in data breaches and should therefore be reported in a timely manner that will allow all affected BAs time to assess the situation, contain the damage, and alert CEs.

In addition to checking for the above safeguards, SaaS providers looking to license an embedded BI solution should ask about precedent. Does the BI vendor in question serve other HIPAA-liable businesses? It is common practice to ask for references and other forms of validation.

SaaS providers should also note the quality of service they experience while evaluating and testing the embedded BI product. How are security concerns addressed, and how promptly? Is the BI vendor accommodating, trustworthy, and reliable? In the event of a security incident, these qualities will have a significant impact on any written HIPAA agreement. Professional integrity and respect for personal privacy underpin the safeguards necessary for a successful embedded BI partnership.


Originally published with Dataversity.

Schedule a Demo

Leave a Comment