Recently, I was able to sit down with Brian Burton, Healthicity’s new Chief Compliance and Privacy Officer to record an all-new episode of our Compliance Conversations podcast. Brian is an expert in all things healthcare technology, having worked in the healthcare industry for more than 15 years. He's spent most of that time developing, implementing, and providing oversight for Compliance and Privacy program initiatives, working with more than one hundred healthcare facilities. Prior to getting into healthcare, Brian served in the U.S. Army where he worked on a global tactical and secure telecommunications network (more on that below).
Considering Brian’s vast experience in technology and project management, I wanted to focus our discussion on something particularly timely right now: Annual Privacy and Security Risk Assessments. I know these assessments can be daunting to approach or, as Brian put it, “I think a lot of organizations struggle with what does that mean, and how can I accomplish this activity with the minimum amount of effort, but still know that it’s accurate, and that your organization is protected from cyber security threats.”
During our discussion, Brian provided a number of great ideas that will help your organization set up a secure infrastructure and approach your annual risk assessment with confidence.
CJ: Welcome everybody to anther episode of compliance conversations. This is CJ Wolf with Healthicity, and I have an amazing guest today. We’re in the midst of COVID as all of us are experiencing it, so my guest is virtual, I am virtual, I guess we’re real people but we’re distanced and our recording is from a distance, work with us while we work through this. All of us in the healthcare industry, and in compliance, this is old hat now. Getting use to new ways of communicating, but we are so grateful that we can have Brian Burton as our guest today. He is the chief compliance and privacy officer for Healthicity. We are excited to talk to him a little bit, welcome Brian.
Brian: Thanks CJ, how are you today?
CJ: Doing great. Brian, I believe is joining us from the great state of Tennessee, and I am in the Salt Lake City area. Brian, one thing that we like to do, we like to let our guests introduce themselves a little bit, and not just what you’re doing right now in compliance, but we all kind of come to compliance as a career in different paths. I know you have a really interesting path, and I would love to hear a little bit about how you’ve gotten involved in compliance, maybe even your professional experience just before compliance too, and take a few minutes to share a little bit about yourself.
Brian: Sure, thing CJ. For me personally, it was a childhood dream to join the military, and I was able to do that immediately out of high school. I was in the US Army and my MOS was 31-Fox Trot, which meant I worked on a global tactical and secure telecommunications network, and that’s where I really learned a lot about technology. Back in that day we were still using thin net, ethernet was not widely used across the network technology, but that branched into a swinging career in telecommunications. I was on the cutting edge of voice over IP, in the late 90’s. Then through some experiences I was able to transition to a healthcare organization as an IT expert. Worked on EMR implementation, infrastructure upgrades, constructure project building, infrastructure building new hospitals and their IT infrastructure associated with it, and that really led me into project management where I’m currently a PMP through the Project Management institute and I maintain that certification and I love that organization. It’s a tremendous organization with a lot of value.
CJ: Yes, really it is.
Brian: From there I moved into managing more software projects.
Brian: I guess in about 2009, I started working with a chief compliance officer to implement a payment system for physicians. Where we monitored all the monitored all the payments to every potential referral source, so not only the physicians but also their family members, and we created this check and balance through a logical database to make sure that all of those payments to potential referral sources were accurate, and coming out of that project, the chief compliance officer there, offered me a position within the compliance department. So, I really came from a technology / project management background and had this great opportunity to transition into compliance. A couple years later I worked on some compliance projects, implementing some controls and procedures, managing the compliance program, and then a couple years into managing some projects, I ended up as a director of corporate compliance managing 15 hospitals or so across 7 different states.
CJ: Wow. That’s a great, first of all thank you for your service, and I think, you know, I’d love to hear more about how that military background, what skills you learned that might be unique, that somebody that is comping from a technology background otherwise that didn’t have that military experience, that would be kind of interesting. I also find it interesting that you have this technology background that lead you to compliance. A lot of people in compliance, and there is never one path, we all know that, but I’ve seen some trends, and the trends are usually legal. You come from a legal background, you come from an internal auditing background, or you might come from a clinical background.
CJ: Ah! Yeah, HIM, coding, and I think it is awesome that you are coming from a strong technology background because that’s really where compliance is going, right? Healthcare is going in that direction, you mentioned EMR’s, you mentioned the importance of security, and our lives generally are becoming more electronic. Healthcare is going to go in that direction to, so having that strong security background, that is awesome.
Brian: Yeah, it has been really helpful. Understanding the concepts and technology, the simple things like how data is stored, and on what type of the various types of mediums.
Brian: Everything from virtual SAN’s to hardware SAN’s, the virtualization that takes place in the cloud environment.
Brian: Google, Microsoft, Amazon, they all have these huge cloud environments, but when you break it down to the fundamental components you still have an internet service connection, you still have servers, web servers that process and handles the data request, and you still have hard drives that store data.
Brian: And protecting that, in setting up an infrastructure that is secure is instrumental to what we do on healthcare, and what we do on healthcare compliance.
CJ: Yeah, and I come from more of a clinical background, and appreciate the technology, in no way am I an expert there. So, I am really glad that folks like yourself have this background technology and project management. Compliance, a lot of compliance, is managing people, and managing projects, and though you don’t have to be the content expert as a chief compliance officer all of the time, or a subject matter expert, you have to be able to manage that project or manage that issue from start to finish. So that is probably a great skill that you have recognized as well, would you say so?
Brian: Yeah, you are so right. It is so interesting for me to see how often I go back to those fundamentals of project management, the five phases of project management. You initiate a project, plan, execute, monitor, control, and close. You would be surprised at how often those concepts and the tools and techniques used in professional project management and how that applies to your everyday work.
CJ: Yeah, absolutely, and even those things apply to projects at home. Right? Like some of those principles are good for personal development as well as professional. That is great. One of the things that we wanted to talk about today because of your expertise in technology is security risk assessment for HIPAA, retrace assessments, how they differ. Maybe we could start with getting your sense, what is your feeling of the current sate of compliance programs understanding the importance of HIPAA security, risk assessment. I’m still, even though we’re in COVID, and some things have been loosened, some of the regs have been loosened a little bit or maybe there are waivers, OCR is still publishing enforcement and settlement press releases and they almost always talk about how the entity failed to do an appropriate HIPAA security risk assessment, what’s your take on that in general?
Brian: The law requires that every covered MDM business associate that manages and stores PHI that you conduct an annual risk assessment. I think a lot of organizations struggle with what does that mean, and how can I accomplish this activity with the minimum amount of effort, but still know that it’s accurate, and that your organization is protected from cyber security threats.
Brian: And other types of breaches that might produce risks to your organization. For me, the annual security risk assessment is a great tool from the OCR, they have a client based tool, we here at Healthicity have a great tool for managing security risk assessments, and then there are paper based solutions that you can get from various sources on the internet. For me, I think, going through each of the safeguards, the administrative, technical, and physical safeguards. Having that common control framework in place in your organization, the appropriate policies, the demonstratable evidence that you are protecting ePHI. Those are sound principles, and the most important component is to document what you found. I do not think, in my experience, I don’t think the OCR is looking for perfection, they are looking for effort.
Brian: They are looking for organizations to make sure you have the appropriate controls in place, and you are making a thoughtful approach to protecting the ePHI that you have stored in your systems.
CJ: Yeah. I agree with you, I think OCR is that way, right? And in all of compliance, even in other areas where I have spent time in compliance. The government never expects perfection, but they want to see effort, so that is a great way to put it. You mentioned the ATP right? The Administrative, the Technical and the Physical. I see, as I have done reviews, and you are probably doing reviews and work across the country with clients, a variety of things that people fail to do, but do you see any trends? I know jus about anything can happen, right? But do you see trends that people tend to miss? Is it more administrative that they miss, more technical that they miss, or physical? What do you see as some big-ticket items that are most commonly missed, if you even feel like that can be discussed?
Brian: Sure, but without speaking of any specific instances, or scenarios I think that the most common breakdown is communication. That communication between the privacy official at the organization and the IT resources.
Brian: Understanding how those two responsible parties, identifying their responsibilities, what they are accountable for, and then creating a good clear communication between the two groups so that they are protecting the organization. Far too often we find that IT does not understand the business, and the business does not understand IT.
Brian: Finding the right people to help bridge those gaps is crucial when you are talking about completing something as important as the annual security risk assessment.
CJ: Yeah, because you are really calling on a lot of different leaders, right? It is typically not “let’s just give it to compliance, or lets just give it to one person to do,” right? Like you said there’s privacy officers, security officers, IT experts, and sometimes they don’t all speak the same language, right?
Brian: Yeah, absolutely, and another thing, choosing which cyber security framework to deploy. There are six or seven different frameworks that are available here in the US, anything from ISO standard to MIST, you have High Trust, Sock. All these different frameworks that these organizations have to choose from and picking one of those standards and then making that your common language within your organization is crucial to success.
CJ: That is a really great point. How would you recommend or advise people on which framework to pack? Sometimes it is probably mandated maybe. I do not know, or do you have thoughts on that. There is a compliance officer listening to this going “I don’t know what our framework is.”, what would your advice be?
Brian: Have a good conversation with your IT department. Whether that be your CIO or your Chief Information Security officer, have a thoughtful conversation about the framework and the principles used.
Brian: For cyber security. To throw my hat out there and say I like this framework better than this one, I think that depends on your organization. It depends on where you are in your technology maturity, how much PHI you have, and where and how you plan to protect it, weather or not you’re an on premise data center and you manage that physical data center yourself, or you are all virtual or cloud based, or you have some combination of the two. The various frameworks are designed to help organizations standardize their security profile.
Brian: In my opinion there is not a better one than the other, but it is more about which ones going to help you communicate with your business better.
CJ: Okay, so it’s really important for the people, for the decision makers that are going to have to decide on a framework, number one, know their organization well enough, and know the different choices well enough, the different frameworks, so that they can say what might be a good fit and what might work well with our culture and our vision, is that a fair statement.
Brian: It is, and the frameworks themselves, the underlined principles are verifying similar. Some of them have different terminologies, but the basics of blocking and tackling are essentially the same. It just depends on where you are and what resources within your organization, what their most comfortable with, and what fits your technology.
CJ: Right, okay. Good. Anything else on kind of the annual HIPAA security risk assessment that you might want to talk about before we maybe move to a related topic?
Brian: No, I think, communication is key, build a strong relationship with your CIO, your chief information security officer, and if you need help navigating those complexities with team resources that are here to help you.
CJ: Great. Excellent. One of the other things we were chatting about before we started was talking about a data breach risk assessment, and how that might differ. There’s compliance officers, some of us are generalists, so we understand the importance of HIPAA’s security, those sorts of things, but you seem to have some good insights on what are those differences and how should we talk about those differences, between a HIPAA security risk assessment and a data breach risk assessment.
Brian: I think, and my experience, our profession of compliance is growing faster than we can keep up with, and we have new people joining the profession on a monthly or even daily basis. In my experience I have seen a lot of people confuse the two, between security risk assessment and a data breach assessment. Of course, for those of you listening, who are privacy officers, you’re intimately familiar with those differences, and a data breach risk assessment, how does an organization of value weight the risk associated with a breach or potential breach, and we all know that is based on the four factors as defined in HIPAA. There are so many people out there that confuse the two, and they are different. Security risk assessment, or HIPAA security risk assessment is conducted annually, and is intended to assess the risk of your organization’s cyber security program. Where a data breach risk assessment, for those of you who are participating in large health systems, you may be doing a dozen of those a week, maybe more, because you have to complete a data breach assessment for ever instance where PHI may have been compromised. You’re more sourcing and looking for that low probability rating and determining weather or not there is a risk, and weather or not you have to notify the patient, and in some certain cases, depending on the volume of patients effected, you may have to notify the OCR either annually or immediately.
Brian: So I think for new people to the profession those can be confusing, and for those of us who have done it for a while it’s very clear and bright, but we still, I still see IT resources confuse the two, and not understanding that we’re doing data breach risk assessments frequently.
CJ: Right, and even as you were talking, I was thinking, and even messaging up. So, if you are the chief compliance officer and you must give messages up to an executive compliance committee, or executive leadership, they might not know the difference when you’re talking about it. In hearing you, you keep me honest here, and if what I summarize here, if this is what you agree with. It’s kind of like a HIPAA security risk assessment is almost a proactive activity, you schedule it, and you’re assessing your organizations preparedness and mitigation efforts for the overall environment of security to PHI, where as a data breach risk assessment is instanced, meaning it’s based off somebody calling, or you identifying that we left the door open here, or we did x, y, and z, it’s specific to the details surrounding that incident, and you’re assessing weather that particular incident reaches certain thresholds that then requires you to do additional actions, either reporting to OCR or to the local media and those sorts of things, is that a fair summary.
Brian: Yeah, very well said. Could not have said it better. The security risk assessments are a proactive approach to managing your cyber security framework or your cyber security profile, and then data breach risk assessments are occurrence based. When an employee or member of your work force has or suspects a breach of PHI.
CJ: Yeah. That could be a lost laptop, a lost flash drive. A website that is open.
Brian: Misdirecting email, or worse case, you have somebody that has penetrated your cyber security network.
Brian: And exfiltrate data from your systems to somewhere else, or they have compromised your security, and we see a lot of this in the news now, where they are encrypting your data and then holding it hostage or for ransom.
Brian: Ransomware, all those things, in every instance of those occurrences, it is the responsibility of the privacy official to conduct that data breach risk assessment.
CJ: Gotcha. So, on that ransomware topic, I do not know if you have any thoughts of this, I have heard of this at a lot of conferences and in talking to other people smarter than me. They often, I often here this phrase, a ransomware is a presumed breach. Is that a true statement, what do they mean by that? Have you heard that before?
Brian: I have, and I agree with it.
CJ: Okay, what does that mean?
Brian: You have compromised the security of that PHI. So, if a bad actor as infiltrated your network through some means of phishing attempt, and one of your workforce members has downloaded a link that was able to install software, or unapproved software on a device within your network. You’re data has been compromised at that point, and it takes a real forensic analysis to understand what was exfiltrated, if anything, and so there’s a pretty big case, if we were to look at, there was a large health system that had some ransomware, and it took months and months and the cooperation with the FBI to conclude that it was a true ransomware, where they had tried to encrypt but had not exfiltrated any data.
Brian: All those tiny little details, whether they be tiny or major, all those facts factor into your data breach risk assessment.
Brian: To the extent which you were able to mitigate, or whether or not the unauthorized person was able to view or obtain the PHI.
CJ: So, it’s possible that you could start the scenario with ransomware, ransom attack being a presumed breach, but after you do your analysis, your data breach risk analysis, is it possible that it turns out that it doesn’t meet the actual definition of a breach?
Brian: Well, that’s a tricky question CJ. Yeah, is it possible? Yes.
CJ: But not likely?
Brian: But unlikely, because you have to presume that a person, a bad actor in this case, implemented some ransomware and weather or not that PHI was compromised it really takes a fine-tooth comb, and a true forensic analysis of all the data to understand what was accessed, what if anything was exfiltrated from the network. But you still must consider access is still a breach, right?
CJ: Right, that is right.
Brian: PHI does not have to move from one hard drive to another for there to be a breach. If you or I view someone’s medical record, but we’re not responsible for providing the care, or have some other business need to access, that’s a breach.
CJ: That is right. Yeah. That is a great point, and maybe this might be a little bit related to the data breach risk assessment that you referenced. I often hear people talk about low pro co. Which I believe stands for low probability and compromise, that is a part of the analytic assessment, right? When you are doing breach risk assessment, can you comment on what that is and how that’s important?
Brian: Yeah, sure. I think one of the greatest benefits of the way the breach risk assessment is written, it is you still have to apply some qualitative analysis, and unless you have some super forensic detail in your network, or in your network analysis, there’s still some subjectivity to that qualitative analysis and weather or not there was a low probability compromise.
Brian: Whether or not the individual or may or may not have accessed further disclosed the information, and that could be as complicated as someone who conducted a cyber attack who’s compromised your network or you simply have a misdirected fax or email and the recipient sends an annotation to the covered entity attesting to that they did not view or did not further disclose, and all of those things factor into weather into or not you ultimately conclude that there was a low probability of compromise.
CJ: And if there is a low probability of compromise, it is possible that you then do not categorize the incident or the occurrence as a breach that needs to be reported to OCR, is that accurate?
Brian: Correct, as my favorite attorney says, there is no harm or foul in reporting to the OCR or the patient that there may have been breach, but each scenario needs to be weight carefully by a qualified professional.
CJ: Gotcha, yeah, so interesting. We could talk all day, we’re getting kind of towards the end of our time, obviously this is a really important topic, I’m going to give you a few minutes at the end here, if there is any question that I maybe didn’t ask, or if there’s some point that we have not made yet, about either HIPAA security risk assessments or data breach risk assessments, the differences between the two, any kind of parting thoughts that you might have?
Brian: Communicate. Communicate, communicate, communicate. Learn as much as you can, study other examples, there’s plenty of information out there on the OCR website when you can look at correction action plans. Study the details of what has happened to your professional peers, and then take those stories back to your team and use those as the catalyst to communicate, weather you’re the CI listening to this today, or the privacy officer at your organization, or maybe you’re the chief compliance officer. Pull those team members together. Use one of those corrective action plans that are public knowledge and use that as the catalyst for conversation with your key team members.
CJ: I think I; I think that’s a practice we should do in all areas of compliance, not just this area, right?
CJ: I was reading the one in OCR about the City of New Haven, they have a public health clinic, and they had discharged, or separated, or fired an employee left employment there, but they didn’t turn off that employee’s access that they had, when they were an employee it was fine for them to have access, but when they were no longer an employee, you need to terminate that access immediately, and it didn’t get terminated for like eight days later. The employee came back was able to download some ePHI and those sorts of things, to me that’s a good story to take, well not a good story, but it’s a story to take from OCR’s website and maybe talk about this probably falls under our administrative policy, do we have a policy, do we have a procedure in place, that when we’re anticipating separating somebody from the institution that we get IT on the phone, look we’re telling them at 12 today, we need you to disengage their access at 1159 or something like that, right?
Brian: Yeah, absolutely. Funny you said that I just had a conversation with a group of people earlier this week talking about this very point, and the question was, can we give a 24-hour buffer for terminating access? And my advice is no. If you know you’re separating employment with someone who has access to ePHI, we should be coordinating with the privacy official, HR, and the manager, and that should be coordinated and the access should be terminated prior to the conversation with the employee your separating.
CJ: Yeah, and that should be written down in a policy procedure. It is kind of part of what those administration safeguards are for.
CJ: You have it already written down, it’s not a surprise to anybody, look we terminate people all the time, some people leave voluntarily, it doesn’t matter the reason, but if they are no longer a part of your organization, their access needs to be terminated. That was an interesting one that came up on OCR’s website, so I’m looking at those types of things too, so I appreciate you saying that about communicating, about using those stories and settlements as a springboard for conversations within your organization.
Brian: CJ this has been fun, I really appreciate it, it is great, maybe we can do this again in a couple of months. Had a great conversation, maybe on a different topic.
CJ: Yeah, you are a wealth of information, I appreciate your expertise and your experience. Thank you for joining us. Thank you all for listening to another episode of compliance conversations, until next time, take care. Brian: Thank you.