edit: Server-client communication does need to be encrypted which zoom does.
edit: Server-client communication does need to be encrypted which zoom does.
Not that you shouldn't, of course. And you better have an excuse for not doing it (e.g. we don't re-encrypt after the load balancer terminates TLS is a common one). But doctor's offices fax stuff to each other all the time, and that certainly is not encrypted. Perhaps you're thinking of a HITRUST control?
(Minor nit: HIPAA, not HIPPA.)
Generally, Hipaa does require transport encryption from the client to the server processing the request. The importance here is SSL/TLS should be terminated at the app server.
Even though a lot of online sources suggest BAAs are only for Covered Entities, that's not strictly speaking true. The standard form document doesn't require the buyer to certify they're a CE. It makes tons of sense for vendors of CEs, themselves bound by BAAs, to bind _their_ vendors to BAAs! If there's a decent chance your customers put PHI in your service, there's a decent chance they put PHI in your support system, and they don't really care if your support system is something in-house or Zendesk when that happens. There's also a good chance that PHI might end up in your logging system, and from there in your Slack instance, and... before you know it everyone's signed a BAA with everyone.
The life-hack consequence for that is that you can just collect BAAs from anyone who will sign them and now you have disclosure timeline guarantees.
I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms.
Edit: Fixed definition!
depends on your definition of "guarantee".
what you really have is externalisation of risk.
A contract which defined how protected health information will be dealt with by the provider and how HIPAA provisions will be followed (ie: provider will do X but you need to do Y to be compliant).
https://www.hhs.gov/hipaa/for-professionals/covered-entities...