Requesting the Community input into HIPAA notifications and Jira / Confluence

[Filiberto Selvas]

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...

• One option under consideration is redacting the notification content to the minimum set of information, for example this would translate into an email in your inbox that simply reads "there was a change, click in this link to go and check it"...  Based on prior research we know emails like these are considered of low value, they basically give no information to decide what your action is, they force you to go back to the web client where you can get the detail. 
• Alternatively we are considering to simply disable email and push notifications, this would require you to go back to the web client to check those (which was required any way, given the lack of details). Potentially we can keep a "ping" reminder if we have not seen you visit the client and you have outstanding notifications to be read. 

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 P , @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 

[Phillip Hocking]

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.  

[Jamie Hess]

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.

[Filiberto Selvas]

Agree with the point @Jamie Hess made above, we can likely configure things so that the notification will be bounced in that case, which would mean a lost communication.  Would that be acceptable? 

[Jamie Hess]

I don't want to speak for the whole community but yes, that would be acceptable. If possible, it would be helpful to see a notice or alert about a "misconfigured TLS" to preemptively fix it first.

[Filiberto Selvas]

There are strong indications that PHI in email is simply to be avoided: 

 https://www.securitymetrics.com/static/resources/orange/HIPAA_Compliant_Emails_White_Paper.pdf

SUMMARY
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.

[Jamie Hess]

That is not the case at all. PHI in "unencrypted, insecure" email is to be avoided.

[Kyle Hughes]

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.

[Scott Checkoway]

Excellent thread going on here!  Ultimately clients are going to send PHI in Email, even when asked or advised not to.  It's not enough to just redact information or have encryption (which would be required as indicated above), having the BAA and all the appropriate certifications are crucial to ensure the protections are in place as our healthcare clients expect.  

[Metin Savignano]

I would like to note that, while TLS alone encrypts email during transit, the mail will still be stored unencrypted on the mail server. Therefore, we think S/MIME or PGP encrypted emails are still necessary to fully comply to HIPAA if emails may contain PHI.

As quoted above: "make sure to encrypt all PHI in both rest and transit." TLS encrypts in transit, but not in rest.

[Jigesh.Veetil]

Have you considered encrypting the email notification. I see a ticket on this: https://jira.atlassian.com/browse/JRASERVER-43585

[Filiberto Selvas]

Hi @Jigesh.Veetil , please see the comments on a similar response above and let me know what you think 

[Metin Savignano]

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:

• Implement API for S/MIME Support
• Enabling encrypted mail notifications

[Brooklyn Trumpy]

Some notification needs to be sent. Having a system you have to check on regularly, given most health professionals workloads, is not efficient. Just a notification saying, "there's be an update to your ticket, click here to view" would suffice. We already use that notification functionality with another jira client (as end users) and it works well!

[Michelle Tan]

Hey everyone,

I'm Michelle, the Product Manager who’s been looking after Jira Service Management’s Customer Notifications and Compliance/Regulation features. We're currently working towards HIPAA compliance for Jira Service Management and have rolled out a feature this week that will help you meet your organization’s compliance needs and protect your and your customers' data!

Announcing safe customer notifications in Jira Service Management as a building block for compliance and privacy needs 

I'd love for you to try out our feature and give us early feedback on the user experience as we work towards meeting HIPAA and signing BAAs in the coming months. 😊