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.
Core Values Series: This is the second of an eight part series
highlighting the backstories to our core values
highlighting the backstories to our core values
In 2005, my first job out of college was being a Videographer for a church in Alpharetta, Georgia. That is where I met Allen Hunt. He was the Senior Pastor of that church.
Unbeknownst to me when I graduated on a Saturday and packed up and moved from Los Angeles to Atlanta by Tuesday, was that Allen Hunt would become (and continues to be) a huge influence in my life.
I also didn't know at the time that he and another individual - Glenn Davenport - were starting a talk radio show aimed at talking about faith in the mainstream (not on Christian radio).
I spent the next six years working side by side with Allen. The show started as a side project of our church and eventually we struck out on our own: just the two of us.
It is where I learned a lot about running technology for an operation because we had no budget and a lot of needs. I was responsible for everything - from the networking to the website design, database management, CRM, graphic design, satellite uplinks, audio editing. You name it, everything.
But while I self-taught myself a lot about tech during my time with Allen, I also learned a lot about life from him. Looking back, it would be amazing if everyone spent the first six years of their professional journey with someone like Allen.
Allen would have this saying that there is a "difference in being right and doing right."
I always loved that. Not because I was particularly good at it. I like being right. If you know me for more than five minutes you know I like being right. I grew up in what I would call a multi-generational, extended-legal family. In three generations I can count seven lawyers and one politician. And that doesn't even count the two intense businessmen. It breeds into you the ability to think creatively and stand your ground. Which has its benefits some times.
But this was added as one of our core values partially because I am not good at it and I need the reminder, but also because - no pun intended - he's right. It is better to do right than be right.
Sometimes that means swallowing your tongue. Sometimes that means doing the right thing regardless of whether or not someone is right to have asked of it. Sometimes it means just having empathy.
It also makes a lot of sense given our industry. There is something about being in Technology and being in Healthcare that makes this all the more important. There are a lot of egos. There is a lot of dysfunction. A lot of times it just takes someone stopping and asking the question, what is the right thing to do, and then doing it.
We probably will not be successful at this at all times. But we strive to be.
Thank you, Allen Hunt. We will do our best to be like you.
We have a customer that is growing very fast in the Healthcare space. Two years ago their Member database was around 200,000 members. After 2020 Annual Enrollment Period settled, they are now over 5 million members. This growth is a very good problem to have.
One of the features of Vy Healthcare CRM™ is something called "IntelliSearch." This feature enables a quick and easy ability to find members when names are not always the same or when it is not obvious which MCO they are with (something that can be more difficult than you'd think - but this is a topic for another day).
The problem with IntelliSearch is that while it makes it very user friendly for Call Center agents, it is way more taxing on the server, especially as that database grows.
Another feature of Vy Healthcare CRM is that we process discharge/authorization files as soon as they come in from the MCO. This is of course great for the MCO, our customer, and ultimately the member getting served, but it is also pretty taxing to be processing through thousands of discharges and comparing it to millions of Members in the middle of the day.
So when average page load times went from 1.2 seconds to 7 seconds in January, something needed to be done and needed to be done fast.
It was initially proposed that we need to remove IntelliSearch and that file processing should be moved to an overnight job because that is where the problem lies.
The problem with this is that it would severely impact usability and also provide worse customer service.
And therein lies the problem. For those outside of technology (looking at you CEOs and CFOs), all "tech people" seem the same. But there are a lot of different types of technology people. In a perfect world you have:
- Database Administrators
- Server Admins
- Network Admins
- Security Specialists
- Project Managers
- And of course, an Executive over all of them that understands all of this
If you have an appetite for all that, Vy Technology may not be for you (that's at least a $1 million in payroll right there). Even if you can afford it though, finding and retaining is a whole other issue. So what most small and medium sized businesses do is they hire a single Network/Server Admin type, put them in an IT Director position, and turn to them to make big picture decisions. If you found that diamond in the rough that can wear all those hats and you can keep them happy, great! But if you don't have that, you can't leave operational business decisions up to the wrong type of technology person.
In the end, we went with a replicated database solution that processed the searching in one database, the discharge files in another database, and left the master database free to do everything else (at no additional cost, no operational impact, little work for the internal IT department, and in a matter of two days).
This absolutely was more work. Did it "ruin a weekend," yes. Was it the easy way out, no. But there is no doubt this was the right move to make for the business. And putting the business over the IT department is what good businesses (and IT departments) do.
Need help with keeping functionality as you grow? Don't be a stranger then. Let's talk.
One of our core values at Vy Technology is that We Know the Difference in Being Right and Doing Right. What we mean by that is, being right is important, but doing right is far more important. When those conflict, choose doing right.
Even though most of our core values reflect what I naturally gravitate to in business, this, in full disclosure, is not one I naturally gravitate to. Out of all our values, this is one that I personally struggle with the most. I think a lot of technology personalities struggle with this. It's why it's important it's there.
Living out this value of course can manifest itself in many ways. One recent way was looking at helping a customer of ours come up with a solution because their customer didn't have the ability to provide consistently formatted data.
This story may get a little complicated so I will go ahead and call our customer Good Food Company and I will name their customer Homestead Insurance Company (neither are their real names).
A standard need for Good Food is being able to process hospital discharge files. This usually entails processing through the discharge file, comparing MemberIDs to a previously loaded eligibility file, and then proceeding on if a match is found.
This match is important because after the member has been served, the reporting needs kick in and there is a lot of metadata associated to that member from the eligibility file that needs to be reported back to Homestead.
The problem lies however in the fact that you would think the MemberIDs in the discharge file would be in the same format as the MemberIDs in the eligibility file. For most MCOs, that is the case. But for Homestead, that wasn't the case.
Now we could have rightly held firm and said, you need to get your two files to match. We would be right saying that. But that isn't necessarily doing right given the situation.
Why? Because we know that Homestead will take months to get this resolved. We know that Good Food will be missing out on revenue while Homestead sorts through that. And most importantly, we know that Homestead's members will be missing out on a benefit they very desperately need when they are at their most vulnerable.
So how does a "doing right" versus "being right" mindset solve this issue? Simple. Vy Technology proposed and then wrote an algorithm that tries 896 different combinations of MemberIDs to find a match.
So if a MemberID is 123456789-01 in a discharge file, then we try 12345678901, and 123456789*01, and 00012345678901, and 123456789, and 892 more variations. The computational impact on the server is measured in milliseconds. The coding effort was measured in 2 to 3 hours. Good Food is happy, Homestead is happy, and Homestead's members are happy.
These are the types of issues you find when doing business in healthcare. And this is the type of creative problem solving you get with Vy Technology.
Need help with creative solutions to complex problems? It would be fun to discuss. Contact 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? We'd love to hear from you. Reach Out.
- 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)