Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
Level
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Requesting the Community input into HIPAA notifications and Jira / Confluence

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

3 answers

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: 

 

mychart.PNG

 

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.

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? 

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.

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

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.

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

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.

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

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

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:

 

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Events near you