efa-project.org

anything we should be aware about or turn on in EFA to be PHI Compliant when sending emails?

It might help to explain what PHI Compliance is if you want a timely answer.

From my understanding any PHI in unencrypted email is a no no. To encrypt the email requires end to end configuration and not possible without controlling the other sides.

People i know needing that end up using those encrypted email services you have to sign up for, or built-in to the emr.

I also see many PHI portals sending separate emails. One email with a login for example, and a second with a temp passcode but even that seems iffy. in otherwords nothing in one email that can put two and two together.

Now this gets the wheels turning. How can we host an encrypted email service? It would require the recipient to sign in to some portal to retrieve the message and/or reply.

PHI includes but not limited to:
Patient name
Address
SS
DOB
Conditions/Medications
etc.

things can be discussed in plain email as long as no identifiers such as name dob ss address etc.

This is well beyond the scope of EFA.

My guess is you are going to have to use a service like protonmail, for instance.

mattch wrote: ↑22 Apr 2020 18:39 From my understanding any PHI in unencrypted email is a no no. To encrypt the email requires end to end configuration and not possible without controlling the other sides.

People i know needing that end up using those encrypted email services you have to sign up for, or built-in to the emr.

I also see many PHI portals sending separate emails. One email with a login for example, and a second with a temp passcode but even that seems iffy. in otherwords nothing in one email that can put two and two together.

Now this gets the wheels turning. How can we host an encrypted email service? It would require the recipient to sign in to some portal to retrieve the message and/or reply.

PHI includes but not limited to:
Patient name
Address
SS
DOB
Conditions/Medications
etc.

things can be discussed in plain email as long as no identifiers such as name dob ss address etc.

I don't know what governing body's you are under, but here in the US we are under HIPAA for medical related PHI, and standard TLS encryption is sufficient as long as it is forced, it can not be opportunistic TLS.

There is open source encryption gateway's, but without the webmail option it's not really practical. https://www.ciphermail.com/

im not hipaa policy or compliance expert by any means, i do not have any medical credentials either. I should have mentioned this and that not sending PHI externally is only a recommendation that many people seem to follow for obvious reasons. That doesn't mean i know what im talking about, nor that these recommendations are mandated.

Every healthcare client and security officer i have dealt with take PHI very seriously (you guessed none allow it in email regardless). Internal email can have PHI but is not good practice as its to easy to forward that out by mistake, it happens more times than we like to think. Its mere best practices to show best efforts in the event of breach or audit. How do we ensure all relays are using TLS, or if it doesn't negotiate and goes plain text. The other issue that came up allowing PHI is training an array of stuff on how they can send an email. Is your subject line ok, do you have authorization etc. One little mistake can mean a lot to a practice potentially shutting the doors.

Despite being legally allowed to send PHI assuming TLS end to end i have never seen it done before. The benefit of sending phi underweigh the consequences 10 fold in many opinions. Not saying its never been done though but im not taking that chance.

I will tell anyone asking that TLS alone is not good enough for transmitting ephi, sure you can do it but imo better to be safe than sorry.

mattch wrote: ↑23 Apr 2020 15:03 im not hipaa policy or compliance expert by any means, i do not have any medical credentials either. I should have mentioned this and that not sending PHI externally is only a recommendation that many people seem to follow for obvious. That doesn't mean i know what im talking, nor that these recommendations are mandated.

Every healthcare client and security officer i have dealt with take PHI very seriously (you guessed none allow it in email unless regardless). Internal email can have PHI but is not good practice as its to easy to forward that out by mistake, it happens more times than we like to think. Its mere best practices to show best efforts in the event of breach or audit. How do we ensure all relays are using TLS, or if it doesn't negotiate and goes plain text. The other issue that came up allowing PHI is training an array of stuff on how they can send an email. Is your subject line ok, do you have authorization etc. One little mistake can mean a lot to a practice potentially shutting the doors.

Despite being legally allowed to send PHI assuming TLS end to end i have never seen it done before. The benefit of sending phi underweigh the consequences 10 fold in many opinions. Not saying its never been done though but im not taking that chance.

I will tell anyone asking that TLS alone is not good enough for transmitting ephi, sure you can do it but imo better to be safe than sorry.

I work in the government and healthcare field, and I can assure you it's done all the time. Your still being very vague about what regulatory compliance you fall under, but I don't know of any lawsuits or legal sanctions related to email in which TLS was used.

If you work for companies that have big purses and can afford encryption gateway's, S/MIME or other technologies to make email more secure then that is great!...(but then again you wouldn't be here ). But there is a reason those technologies as a whole have not caught on.

It's the constant battle of convenience vs security.

I see your perspective now and makes sense i agree with you. US and practices from 1 to 10 providers with very shallow pockets. To them, instead of spending more money on technology (just for "email" when their emr has integrated portal maintained by software company for secure messaging) or worrying about potential fines it is cheaper and easier to not allow it.

It's the constant battle of convenience vs security.

so true!