2
HIPPA Compliance
Question asked by John Marx - 7/24/2024 at 9:51 AM
Unanswered
I was talking with a client about security of SmarterMail today. What compliance, if any, does SmarterMail have? 

I know no matter what transferring healthcare/personal information violates but "assuming" (love that word!) this isn't done what compliances are there?

They mentioned secure email during the conversation.

Additionally, I know things like GDPR, California Protection Act, Colorado Protection Act, etc. may also apply.

If this isn't there, can I suggest this be added to the developer list as HIPPA is becoming more important for many companies on today's new business rules the governments are pushing.

4 Replies

Reply to Thread
1
Douglas Foster Replied
HIPAA is specific to companies that are involved in electronic health transactions in the U.S., as well as any of their business associates that might have access to patient data.    Security is the responsibility of the s=data owner.  For electronic communication, security is the responsibility of the sender.  The responsibility is to ensure that no data leaks to someone who does not have authorization to see that data.   The scope of data is comprehensive, anything that is personally identifiable and is not specifically authorized for release by the patient or necessary for release as part of proper healthcare operations. For example, it is a HIPPA violation for you to for anyone at Doctor Jones' clinic to say, "I took care of celebrity <name> today at work.   Some people have lost their jobs doing so.

Patients have control over their own information, and can release it to whomever they want.  Consequently, my healthcare company accepts incoming emails with concern about whether it has sensitive data or is transmitted with encryption.   But when we send back out, we send the response to the patient's portal account and the portal system sends them a generic message that new information is available when they log in.  

As a safety measure against reckless employees, we also require that all outbound email be encrypted in transit.  This is implemented in our outbound gateway product; if STARTTLS is not available or not successful, the message is deferred until it times out.   The workaround for those recipients is to configure that domain to be forwarded through the vendor's secure web relay product.  That ensures that the message is encrypted in transit from  us to their server, encrypted at rest on their server farm, and encrypted at pickup using an HTTPS web session.

If you might handle HIPAA-protected data, you will know it, because your client will make you sign an assumption of liability document that will put you on notice.

So, if you are a mail hosting service, it is your client's job to ensure that they do not use  your service in a way that releases information, and that pretty much means not sending sensitive data through email at all.

FYI:   Faxing is considered secure, as long as you don't send to the wrong phone number.

0
John Marx Replied
We have that covered with the BAA for their website and their CRM that we built for them for sales and service tickets. They want to know all that is done email wise.

  • Securing outbound: yes
  • Hard drive encryption at rest: yes
  • Backup encryption: yes
  • Archiving In/Out emails: yes
What else is there? Yes, they have to "not be stupid" and they grasp that. They want to know from the mail server side as when they had Office 365 they were "HIPPA secure" and now they want to use SmarterMail IF it can be as well.
1
Hey John, I have previously worked in a medical research facility and Hospitals. 

HIPAA also includes physical access. Who has access to the data, to the server itself and where is it stored.  Records need to be behind 2 separately locked doors with, limited access of only who needs access to it. And, really, a log of who accesses it and when. Is your server a virtual machine or physical machine ? where are they and who all can access them ?

Oh, and it is HIPAA, not HIPPA

"Secure Email"  Is a thing where the email never actually leaves their / your servers. Instead, the parties involved (maybe have a gmail or yahooot account) get a generic email and in the body it says something like : "click here to read your email from John Marx" - Then when they click on it they are taken to the clients (or your) email server where they have to : create an account (on that server) to actually read the email if it is the first time getting one from them, or log into their account  they created before. But the body of the email itself , nor the subject line, is ever sent out. this helps to avoid accidental client data exposure.

I proposed this in this thread : 
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
1
Douglas Foster Replied
SMARSH.COM
The architecture that Curtis proposes has been implemented in a solution from www.smarsh.com.   That vendor targets financial services, where every communication has to be logged for regulatory reasons.   Their system accepts incoming client email from anywhere, but all outgoing mail is converted to "you have an important message from...".     

We experienced this recently:  Unexpected message "click here to get an important message from ",  It sent up red flags since we did not recognize smarch.com as a trusted server farm.   We sent a new email message to the friend:   "Hey B, is this legit?"   We get a second message back from the same system "You have an important message from...".   When we researched the company with a we search, we relaxed and logged in.  Of course, the second message contents were "yes, it is legitimate!"  This is an awkward user interface.  For most of us, this solution seems like overkill.   For email hosting services, I don't think it is your market.

HIPAA
HIPAA provides grace for small, innocent, and inadvertent disclosures.   The hammer comes down for breaches and for reckless behaviors.   So not getting breached is also part of the planning.  Paper and electronic logs also help.

PCI DSS
If you accept credit cards at all, and most everyone does, you are subject to the PCI Data Security Standards.   These have four levels, depending on the way that you take payments.   The strictest requirements are level D, and the standard provides a comprehensive checklist of things to do.  If you are a level D vendor, you have to assert full compliance to all, or you lose the ability to take those payments at all    A summary of the standard is that you must have a perfectly implemented infrastructure, which is perfectly protected with defenses, with all symptoms perfectly logged, and every log entry evaluated, to ensure perfect utilization of any information in any log entry.   (Like maybe deploy Crowdstrike!)   I consider the standard to be unrealistic, but there is a lot of good food for thought.   "What element of our processes and infrastructure should be strengthened next, in a process of continuous improvement?"

If you can make PCI DSS happy, HIPAA will not be a problem.



Reply to Thread