> As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice.
Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community.
> If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine.
This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine.
* Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI.
* Conversely, client-to-server does not automatically make the use case allowable.
Maybe it's because I use Qwant, but my search results for HIPAA end to end encryption gave articles about actual E2E encryption for emails (since they typically pass through a third-party email server). So I'm starting to think the term isn't being misused even in the HIPAA community.
And sorry, I meant client-to-client with the assumption that there's a server between the two. And sure. I think it's safe to assume that SSL/TLS is perfectly fine for a client-to-server situation. But like I said, let the company read the actual regulations and consult their IT team.
Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community.
> If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine.
This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine.
* Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI.
* Conversely, client-to-server does not automatically make the use case allowable.