At mentioning many community members that have shown interest in HIPAA before
We would appreciate your input into this question, trying to figure out what is best for our customers.
Context: Jira and Confluence notifications, as you know these can be quite rich and include content captured in Confluence Pages and Jira Issues, because of this we have to be concerned about PHI in Notifications (email - push), we can't control end to end security for it.
We are considering what is the best way for us to ensure PHI is properly protected...
Appreciate your comments - thoughts about these or any other suggestions you want to offer
@Thomas B , @Ankit Maheshwari , @Martin Hanna , @Fernando De Oro , @Zvika Ekhous , @Craig Tucker , @Teresa L Coakley , @Jaswanth Padigala , @Craig Tucker , @Xiaofeng Guo , @Jenn Winship , @Lloyd W Mangnall, CISSP, CHCIO , @Anna Coffey , @Lovekush Gangwar , @Gene McKenna , @Brian Reavey , @Ram Tummala , @Phillip Hocking , @Kyle Hughes , @Tim Fostik , @Jason Michaud , @Scott Checkoway , @gillamc , @Harold Wong , @Jamie Hess
I think simply disabling notifications entirely would be disastrous for engagement. While we all know that especially in a HIPAA context, email even with TLS end-to-end does not meet the requirement Microsoft handles this incredibly well with their Microsoft 365 Message Encryption offering described here: https://support.microsoft.com/en-us/topic/learn-about-protected-messages-in-microsoft-365-2baf3ac7-12db-40a4-8af7-1852204b4b67
In this instance, we are simply presented that someone has sent an encrypted message and are given the option to sign-in natively with a supported email/identity provider, or to have an OTP code sent to the email to verify that the person who received or is viewing the notification of an encrypted message is the addressee.
I received a message from Opsgenie Support via Jira Service Management earlier today, and this notification does not disclose anything that would be personally identifiable and requires for me to sign in to see the particular update.
Ironically enough, I was unable to see the actual issue it was referencing because I did not have permissions (despite being the person who submitted the request)
but that is neither here nor there. Notifications can be rich and inspire interactions without making disclosures about their protected or personally identifiable information.
Earlier today, I received a notification from Fidelity about a change to the status of my linked bank account that, while informative, did not have my (entire) bank account number or the name of my financial institution, nor my brokerage account number/username/other specifics of the change - yet the notification still was rich enough (and important-seeming enough) that I clicked and signed in via my password and OTP token sent to my phone, and validating the workstation for five days.
Here is an actual HIPAA entity, one of the largest hospital providers in the world, sending me a push notification about an appointment:
To those of us who live in the HIPAA compliance space, we all know firsthand that the processes never will be perfect, disclosures can, do, and regularly happen, and it is a practice just like law or medicine - you do the best you can to be relevant, reduce the blast radius of breaches, but still ensure your service participants have actionable data and are more engaged in the process of using your online platform to collaborate and coordinate in their care more effectively. This isn't our first rodeo even though it may be yours - the same way that Microsoft signs a blanket BAA with anyone who has Microsoft 365 services... only endorsing the products, when used appropriately with adequate organizational safeguards and in the proper application - meet the *technical* requirements for HIPAA compliance... despite the ability of the users of the products to violate HIPAA regularly with them.
The specifics of what that looks like will be different to every organization and their own relationship with their stakeholders.
With all that said, what we need is SMS notifications, a rich client portal, multitenancy to be as robust as it can be in a cloud SaaS application, encryption-at-rest, the ability to support *REAL* MFA not just sending SMS notifications - however, don't even think of rolling out the HIPAA real-world version of the product without an 'easy' MFA mechanism that at least hypothetically checks the boxes after someone enrolls in their own portal with their own email and their own cell phone number to manage their own contact preferences and set their own unlock questions/answers.
Offload absolutely as much of this as you can onto the end-user because their own disclosures of their own information e.g. they are locked out of a portal and they just send you an email or something, you aren't penalized compliance-wise for that... that's *their* disclosure not yours. The more you can encourage the stakeholders and service participants to engage and get more examples of how folks have overcome this hurdle at scale, you'll succeed at this.
Great response! I would echo this entirely with one minor exception. If both email servers support and encrypt via TLS and only send when a TLS connection can be established, then TLS is HIPAA compliant. It is not TLS per se, that is not HIPAA compliant, it is the implementation of TLS.
There are strong indications that PHI in email is simply to be avoided:
Do not send emails containing PHI outside of your network. Instead, use secure services like patient portals. However, if you need to send emails, avoid using free Internet-based email services and make sure to encrypt all PHI in both rest and transit.
Thank you for the detailed response @Phillip Hocking. I agree with a lot of what is being said here as trying to make it as rich without sharing ePHI or other sensitive information. I'm sure something could be configured as there are systems out there that scan the data within emails for either SSN or ICD-10 codes/references to build a score to determine if enough meets ePHI to auto encrypt. We use a system like this for our emails where we can define what needs to be automatically secured. My concern is how do you control what data goes into notifications that allow the rich information without exposing ePHI when an end user could enter it within the summary or description or any other field that is configured to display within the notification.
I'm not sure any of that provided valued feedback, but like @Jamie Hess said, emails unencrypted/unsecured should be avoided at all cost. Our organization targets safe harbor guidelines as much as possible so the data needs to be encrypted in transit and at rest.
There is a solution to this, and it's email encryption. We have published an app that provides email encryption, and we know that some of our customers use it specifically in order to comply to HIPAA. The ticket @Jigesh_Veetil mentions also refers to our app, and that ticket was one of the reasons why we decided to develop our app. (Another reason was that we needed email encryption ourselves.)
However, while our solution works well for Server and Data Center, we do not have a solution for Cloud yet. This is mainly because Atlassian does not yet provide any way for apps to access email notifications before they are sent which is what we would need in order to be able to encrypt them. We have filed a feature request with Atlassian since long, but it remains on status "triage". If Atlassian were to work with us on behalf of this, we would be happy to provide our app solution for Cloud.
Public tickets on behalf of this:
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events