HIPAA Compliance - It’s OK if I receive the FAXes into FAXPro as long as I don’t E-Mail them - if I receive them into the machine and then move (and delete) them into EMR I am perfectly good with compliance since I control the server and it is behind the corporate firewall. And for the belt-and-suspenders crowd out there, I have a CRON job running every night to clean up the leftovers (the .tif and .pdf files in /var/spool/asterisk/fax) so there is only the working product on the server at any given time.
Request - I REALLY need to have E-Mail notification of a new FAX because my clients don’t want to watch UCP - they want to be reminded to check UCP by getting an E-Mail when a FAX is received, but the FAX can’t be attached, or it’s PHI in E-Mail and I am non-compliant!
So, what we need under User Management for FAXPro is to have a E-Mail address for receiving the Notification + the FAX attached (what it is now) and an E-Mail Address for notification only so that I can notify about the FAX, but not attach it and get busted.
I would happily pay $200 for this feature right now! Not enough? Ok, what would it cost to add this?
Just out of curiosity, why does having the fax attached as a PDF and sent via email result in non-compliance? More than 99% of sip trunk providers do not secure the RTP. However, more than 99% of email servers communicate with other servers and clients over TLS.
I feel like whoever wrote those rules did not take into account the digital fingerprints every file transaction can leave behind. What’s stopping someone from using the good old fashioned photocopier and leaving a copy of someone’s medical record out “in the clear”?
It’s the E-Mailing - you can not E-Mail unencrypted PHI whatsoever - and having PHI in the E-Mail system at all opens up all kinds of requirements for your E-Mail system that are a real pain - so it’s best practice just to never have it touch E-Mail.
And really, PHI in E-Mail is low-hanging fruit for a HIPPA violation - it’s easy to identify, and the penalties are HUGE!
What’s stopping someone from using the good old fashioned photocopier and leaving a copy of someone’s medical record out “in the clear”?
Oh, it’s worse than that - You have resting encryption requirements and then you have GREATLY increased access requirements for the whole E-Mail system - and you also have to have tech in place that looks for outbound PHI and blocks it - it’s a mess.
I could be wrong but I don’t think FreePBX uses a server side encrypting file system? Is that why you have to run the Cron script to scrub those files? Because of the resting encryption requirements?
We don’t encrypt PDFs because there are tools online to get rid of the encryption quite easily. I think by encryption I mean that weak password requirement on PDFs there are probably other stronger forms I’m not currently up to speed on I just know i have used those decryptors before when people send me documents and I can’t remember the password.
I was referring to the encryption of the entire operating system/HDD. That whitepaper specifically refers to encryption at rest. Seems even if the PHI PDFs or TIFFS are not attached to an email, if they are accessible via UCP then they are on the HDD somewhere “in the clear”.
Yes - that is the “Processing” Window - just like the FAXes would be sitting on the FAX machine in previous methods until someone pulled them off and scanned them into EMR (or if you go back far enough, put the physical paper in the physical file!).
You have to be practical - processing, as long as it has a defined flow that is policy, can allow the FAX to sit on the PBX long enough to be processed into the EMR system - but the resting requirement is why you have to clean up, and why the device has to be behind the corporate firewall and secured.
What you can’t do because of no resting encryption is use the PBX as storage for PHI - even though it is tempting. But moving them through the PBX is fine.
I should also say too that with LUKS, you could encrypt the /var/spool/fax folder pretty easily - then your resting encryption requirement would be satisfied - although then you would have the additional task of providing the unlock code for the encrypted partition at boot time - but there are secure ways to do this also.
If I was into writing commercial modules for FreePBX, I could see the value in writing a “data at rest encryption” module for the /usr/spool/asterisk/* directory tree, especially if one were to write it specifically with HIPAA requirements in mind,
If I started out as a “bounty” project and then morphed into a commercial module, one could even justify the possibility of splitting the initial development cost with the person providing the bounty.
