nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Requesting the Community input into HIPAA notifications and Jira / Confluence

Fili

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

Comments

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.

opsgenie notification.PNG

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)

jsm no permission.PNG

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.

fidelity notification.PNG

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.

Jigesh.Veetil

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

Metin _savignano software solutions_

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:

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.

Fili

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?

Fili

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

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.

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