We completed a really fun project this past week for a client of ours involving our CRM and WhatsApp integration.
To WhatsApp's credit, they do not want to become a spamming engine for the entire globe. Because of this, navigating their API process is quite complicated. The API itself is super simple. But how to get approved, how templates are approved, and how templates are used for initiation make for a complicated integration. We are glad we are on the other side of that now and have the understanding of how all that works.
But it got us thinking about another area we are highly versed in:
WhatsApp is great because it is end-to-end encrypted by design (which text messaging is not). So does that make it HIPAA compliant? As Steve Adler's great write-up in HIPAAJournal.com points out, no, not as it is traditionally used.
He's right, except for one thing. He assumes the only way to use WhatsApp is from phone to phone.
As Mr. Adler points out there are three issues that prevent WhatsApp from being HIPAA compliant on the surface: Access Controls, Audit Controls, and Termination Controls. Let's look at why these are problems for phone to phone messaging, but not within an application like Vy Healthcare CRM™ to Phone.
If you use WhatsApp phone to phone, you lose ability to control who can install that account onto a phone. Thus you have no access controls and that is a big HIPAA no no. But if you never install the application on a phone, this isn't an issue. If your WhatsApp messaging is built into your Healthcare CRM, and it does the sending, you have the same level of access controls as the rest of your application.
Likewise, if you just use WhatsApp phone to phone, you have no ability to keep an audit trail of conversations. However, the very nature of integrating the WhatsApp API into your Healthcare CRM, will produce the same audit trail of communication as you do with any other method of compliant communication. We'd argue you actually get better audit controls because of the verified feedback you get from WhatsApp on the status of the message (i.e. you know whether it was delivered and not read or delivered and read).
Lastly, termination controls are achieved just like the rest of your Healthcare CRM termination process. Unlike in a phone to phone situation, where if you remove the app from the phone it removes the data, all the historical data is saved, access is terminated, and everyone goes on with their life.
I do agree with Mr. Adler's assertion that a BAA is not necessary because by the nature of how WhatsApp built their platform and the underlying technology, the data never gets stored on their servers and the data is always end to end encrypted with keys WhatsApp doesn't have. If someone tells you that you need a BAA for WhatsApp, then you better get one with the United States Postal Service because a lot more PII is available to every letter carrier in this country than WhatsApp has available to them. That being said, you may have to sign a BAA with a third-party if you use them as your API gateway, but that is usually a pretty straight forward process, and certainly not a reason to not use WhatsApp.
Tools like WhatsApp coming together in Healthcare is exciting. So even though it isn't HIPAA compliant out of the box (or phone), it can be a solution if implemented correctly. If you have questions or ideas on how you want to implement it, feel free to reach out to us.
When I first started developing HIPAA compliant software I had been developing custom software for 9 years. But I had never had to develop a HIPAA compliant solution. Like a lot things in life I figured, no biggie, I'll do some research and figure this out.
Boy was I in for a surprise how nebulous the law is and how wide the varieties of interpretations were.
This blog will feature HIPAA extensively in other posts, but today I wanted to share what came to be called the Pillars of HIPAA.
Eight of these were developed pretty early on. Five more were added over the course of the next six years.
When we went for HITRUST Certification, we were positioned pretty well with just these pillars. Yes, the Certification required us to codify a more formal IT Policy. And in no way am I saying these pillars are the equivalent of HITRUST Certification. But I do believe the 105-page IT Policy that ensued doesn't do that much more than these 13 pillars below did to secure data in a HIPAA compliant system.
- Encryption in Transit - all data is encrypted and transferred using a 128-bit SSL secure connection.
- All access is controlled by an individual username and password for every employee.
- Every page view and action is logged - including date, time and IP address.
- PHI is always hidden unless an employee purposely chooses to see it, in which case a special entry is logged.
- All PHI is stored in the database in an encryption at rest state - i.e. a social security number of XXX-XX-XXXX would be encrypted and stored as WhvNDTdXAPJYzWajhkXegzfX...
- All PHI (which is already encrypted) is stored in a separate table from other identifying information. As an example, names and addresses are stored in a separate location than Social Security numbers and Medicaid IDs.
- Permissions for all employees are set on an individual level using the Principle of Least Privilege - access to information is reviewed and granted on an individual level.
- All member related data is not accessible outside of our internal network without the use of 2-Form Authentication via Google Authenticator and a proprietary key. This conforms to algorithms specified in RFC 6238 and RFC 4226.
- All reports are generated with minimal information needed.
- The server can only be accessed via SSH/SCP - since FTP connections are unencrypted, they are not allowed on the server - SSH/SCP is more secure than FTP and SFTP.
- SSH/SCP access is only granted via security keys (no passwords) - thus preventing brute force attack attempts - this method is much more secure than a traditional username and password method.
- Our firewall only opens the following ports: 80/HTTP, 443/HTTPS, 22/SSH to the outside
- All versions of Linux, PHP, Apache and MySQL are long term stable (Ubuntu 18.04.x LTS / PHP 7.2.x / Apache 2.4.x / MySQL 5.7.x).
After going through HITRUST Certification for one of our Customer's systems, I would add the following four as well.
- Force logoff system after 15 minutes of inactivity
- Include warning messages on all systems (Web or SSH sessions) that informs an individual they are entering a system with PHI and their actions are monitored
- Implement a DLP solution for Email that includes the ability to send secure
- Implement annual third party penetration testing and risk assessment
Need help with hipaa compliance? It would be fun to discuss. Contact us.
- api (1)
- business (12)
- christianity (1)
- cobol (1)
- core-values (9)
- core-values-series (8)
- crm (1)
- culture (8)
- customers (2)
- database (2)
- doing-right (1)
- efficiency (1)
- employees (2)
- erp (1)
- health-insurance (1)
- healthcare (5)
- hipaa (2)
- hipaa-compliance (1)
- hitrust-certification (1)
- lamp (1)
- learning (1)
- margin (1)
- mco (2)
- meritocracy (1)
- owners (1)
- people (1)
- results (1)
- rpg (1)
- software (4)
- systems (1)
- technology (13)
- value (1)
- whatsapp (1)