HIPAA Compliant Slack: Quick Thoughts and Uses

Mark Olschesky
Change Agent
Published in
5 min readFeb 3, 2017
By Slack (https://brandfolder.com/slack) [Public domain], via Wikimedia Commons

In response to Microsoft’s announcement and release of Teams, today Slack announced it’s own enterprise suite of tools for the popular business communication app, called Enterprise Grid. Of particular note for Digital Health enthusiasts, Slack announced that Enterprise Grid was HIPAA compliant. Under a light glow of retweets, clinicians looking for a reprieve and using tools they have heard about from their colleagues outside of healthcare, Slack sounds like the savior for patient and care team coordination. Can it be? I’ll drill down into the details of things that organizations will still need to figure out to use Slack in a patient-care context.

HIPAA compliance isn’t the end, it’s the beginning.

One of the common leitmotifs at Datica is that HIPAA compliance is purely the table stakes for a successful company that works with covered entities (hospitals, payers, employers, etc.). An effective product that moves the needle in healthcare makes the product work for a large amount of organizations. Organizations are going to need a good strategy around the management of personnel in Slack to reduce unnecessary access to PHI. The Security Rule of HIPAA indicates covered entities must “protect against reasonably anticipated, impermissible uses or disclosures.” This typically means that organizations will attempt to limit access to PHI by staff, within reasonable limits.

Usually this means that PHI access is restricted within a department or office and then further broken down to people working on a given encounter. So, how does this apply to Slack? Slack has a variety of ways to organize data, including differing organizations and channels to discuss given topics. Those organization techniques could be used to limited PHI exposure to relevant parties. I think that other than a #general channel for organization-wide announcements, that an organization would split all “departments” into their own channel. For example, there would be #gastroenterology, #familymedicine, #emergencyroom, etc. An organization might also create some cross-org channels for discussion as well, like #residents, #outcomes and #analytics. Some other people have even suggested creating channels for individual patients like #MarkOlschesky, which models how clinicians discuss patients using WhatsApp in countries without regulations like HIPAA. From there on out, I’d feel like most patient-centric conversation would need to be done either in DMs or in ad-hoc channels for patient discussion. I’m not sure how else to limit who had seen what patient data.

This leads me to a few words of caution:

Pulling patient data into Slack and the perils of casual communication in patient settings.

Clinicians could be looking at patient data in the EHR and then manage the communication about the patient in Slack. It would be as simple as someone posting to a channel “Hey, did you see Steve’s A1C? 7.1 too high? What should we tell him?” and then having some discussion. Many secure messaging services work like this today, but there’s some risks to this though, notably:

  1. Positive patient identification. How do clinicians make sure that they’re talking about the right Steve? How do they manage the multiple pieces of data of discussion about a patient to make sure that everyone is talking about the right person? The good news is that I think that the newly released Threads functionality makes this more of a reality. Clinicians could make a thread about a patient/task in Slack, and then discuss the patient there. This would reduce the likelihood of incorrect documentation and would also organize conversations better for compliance.
  2. Proper tone in patient-centric communication. We’ve been using Slack now for about three years at Datica. While it’s helped us with cross-team communication, one of its biggest weaknesses is that it encourages users to say something fast that can be interpreted variably. I know I personally vigorously up-button and edit things that I’ve said pretty much one in every ten messages. We’ve even had to institute rules-of-thumb to have complex conversations over the phone or in person in order to ensure the message is clear to all participants. If you can say one nice thing about patient communication tools, like inbaskets and inboxes in EHRs, it’s that they are so clunky they require some thought before sending a message out. This is important because….
  3. Patient-centric conversation is part of the Legal Medical Record. No exceptions. Patient centric communication can’t just be disposed after the fact. It needs to be maintained, forever. It’s the one limitation of HIT systems that paper didn’t have… if a clinician wrote something down that didn’t read well they could just throw the paper away. Do organizations want totally fluid patient-centric conversation at the risk of a litigator bringing up Slack at a case for malpractice? I don’t say this to be a downer, but this was something that was brought up to me EVERY DAY while I was installing communication and documentation tools with the EHR. I would be afraid of the loose communication about patients being taken the wrong way if I were a hospital compliance officer. This isn’t to say that it’s impermissible or wrong; just that it’s something that needs to be accounted for before it can be deployed in a patient care setting with a solution which isn’t purely technical.

EHR integration is key.

Since patient-centric communication is part of the Legal Medical Record, it needs to go back into what is defined in the Legal Medical Record for an organization. It’s 2017, that is usually the EHR. As such, any application managing patient communication would either need to document the conversation back in the EHR manually or through some integration. It may be something as robust as the text of the thread, or maybe just a link to Slack indicating that there was a conversation. At any rate, this seems like a hard requirement which we have a pretty good handle on at Datica. It would also be neat to pull patient data into Slack using slash commands similar to how Slack can pull data from Salesforce or Lever. This is something that could be facilitated through new API frameworks like FHIR.

Overall…

Better tools for communication in healthcare are a good thing! It’ll be interesting to see who or what swoops in to fill in the implementation gaps for Slack in healthcare. If you’re looking to integrate Slack with your EHR, like Epic or Cerner, contact us for more info.

--

--