AHLA's Speaking of Health Law
The American Health Law Association (AHLA) is the largest nonprofit, nonpartisan educational organization devoted to legal issues in the health care field with nearly 14,000 members. As part of its educational mission, AHLA's Speaking of Health Law podcasts offer thoughtful analysis and insightful commentary on the legal and policy issues affecting the health care system. AHLA is committed to ensuring equitable access to our educational content. We are continually improving the user experience for everyone and applying the relevant accessibility standards. If you experience accessibility issues, please contact accessibility@americanhealthlaw.org.
AHLA's Speaking of Health Law
HIPAA Security Rule Proposed Updates: Addressing Increasing Cyberthreats in Health Care
On January 6, HHS’ Office for Civil Rights published a Notice of Proposed Rulemaking titled “HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information.” Wes Morris, Senior Director of Consulting Services, Clearwater, speaks with Jennifer Kreick, Partner, Haynes and Boone LLP, and Thomas Tanabe, Associate, Haynes and Boone LLP, about the proposed updates to the HIPAA Security Rule and the practical impacts for health care organizations. They discuss what is driving these proposed updates and issues related to “required” and “addressable” specifications, sanctions, technology asset inventories and network maps, risk analysis, business associates, and costs and timeline related to implementation. Jennifer and Thomas recently authored an AHLA Bulletin on this topic. From AHLA’s Health Information and Technology Practice Group. Sponsored by Clearwater.
AHLA's Health Law Daily Podcast Is Here!
AHLA's popular Health Law Daily email newsletter is now a daily podcast, exclusively for AHLA Premium members. Get all your health law news from the major media outlets on this new podcast! To subscribe and add this private podcast feed to your podcast app, go to americanhealthlaw.org/dailypodcast.
<silence>
Speaker 2:Support for A HLA comes from Clearwater. As the healthcare industry's largest pure play provider of cybersecurity and compliance solutions, Clearwater helps organizations across the healthcare ecosystem move to a more secure, compliant and resilient state so they can achieve their mission. The company provides a deep pool of experts across a broad range of cybersecurity, privacy, and compliance domains. Purpose-built software that enables efficient identification and management of cybersecurity and compliance risks, and a tech enabled 24 7 365 security operations center with managed threat detection and response capabilities. For more information, visit clearwater security.com.
Speaker 3:Hello, and welcome to this episode of ALA's speaking of Health Law Podcast. I'm Wes Morris, senior Director of Consulting Services with Clearwater and your host today. Joining me today are Jennifer Craig and Thomas tavi . Jennifer is a partner at Hanes and Boone and co-chair of the Firm's Healthcare and Life Sciences Practice Group. She delivers practical legal advice and guidance to healthcare providers and other healthcare industry clients in a variety of regulatory and transactional matters. Jennifer regularly counsels clients functioning as covered entities, as well as business associates on HIPAA related matters, including compliance, breach response, and regulatory enforcement. Jennifer is a vice chair of the American Health Law Lawyers, pardon me, vice Chair of the American Health Lawyers Association, health Information and Technology Practice Group, and is certified by the Texas Board of Legal Specialization in health law . When she's not practicing law, she's chasing after her two girls , ages two and five. Thomas Avi is an associate with Hayes and Boone in their healthcare transactions and regulatory practice group. His practice focuses on helping clients with health law, sorry, with healthcare regulatory and business transactional matters. He's a member of the American Health Lawyers Association and Dallas Bar Association's health law section outside of practicing law. Thomas is busy taking care of his two kids under age two. So today our topic , uh, is the recently published notice of proposed rulemaking or NPRM for the HIPAA security rule to set the stage. The security rule was the first one contemplated for publication back in the late 1990s, but was not actually published in until 2003 with a compliance date of April, 2005 , meaning that we are nearing the , of the compliance in just a few weeks . If we consider the state of technology in the late nineties, and even when the rule was first put into, to , into effect in 2005, the world has changed dramatically in the intervening years. The guiding watch words that have always been used in the security rule, which we've often referred to as being technology agnostic , uh, have been the terms reasonable and appropriate among some other guiding principles. What was reasonable and appropriate in 2005 has changed significantly since those days. So, to start us off, welcome Thomas. Welcome, Jennifer. Let's start off with Jennifer on this because the landscape has changed so much. What's driving this change? Why, why now? And what's really driving the security rule to be changed at this point in time?
Speaker 4:Wes, that's a great question, and thank you for the, the background on the history of the security rule as well. You know, it's been such a long time. I, I , um, kind of need a refresher sometimes. Um, I, I think that there were, and we saw this in the commentary, a a lot of different reasons , uh, for this update. And, and this was not a surprise. We knew that this was coming. HHS had announced it and said, sometime in 2024, we would see this , um, these updates to the security rule. Um, and so, you know, I I , I think, like you pointed out, a lot has changed , uh, um, in the , uh, technology world. Um, this is the first major update that we have seen to the HIPAA security rule a a comprehensive update since 2013, since the omnibus rule came out. Um, I know you remember , uh, reading through that new rulemaking and, and that sort of thing. I, I did as a, as a young attorney. Um, and so , uh, you know, what we've seen is just a change in technology. I think we've seen a change in , um, the number , uh, and seriousness of the breaches and incidents that are affecting the healthcare industry. The healthcare industry is a target , um, uh, for cybersecurity incidents. And , um, and it's , uh, you know, that's something that HHS is really focused on , um, as well as , uh, just, you know, generally , um, uh, their experience with enforcement. Um, and, and that was something that they pointed to over and over , uh, as the, you know, kind of , uh, need for some of these changes. Uh , you know, maybe some of these requirements were already incorporated or implied, but they were not specifically identified. So, for example , um, the asset inventory HHS had commented that that had always been a, an implied , um, requirement because it's necessary to conduct a , an effective risk analysis. Um, but now we see it actually listed specifically as something that , um, is going to be required for or potentially required if this , um, proposed rule goes into effect , um, uh, down the line. And so , um, yeah, so I think there's a lot of different reasons. I, I'd be interested in your thoughts too, Wes. Um, anything that you, you've seen in your practice , um, that, that you think these roles have been trying to address?
Speaker 3:Well, I could , uh, probably opine for an hour on that point myself, <laugh> , I'm fortunate enough to have become a privacy officer in 2003 and a security officer in 2005 with the advent of both of these rules. So I've got a long perspective about what has happened. Um, I'm, I'm interested , uh, Thomas, if I could ask you to give some perspective around , um, the HHS had mentioned way early, back in early 2004 that they were going to publish a rule , uh, in 2004 to make changes to the security rule, but it, there was a, an introductory publication of it right at the end of December, but the actual rule was actually published for public comment in January of 2000 of 25. Um, what happens from here? What now that it's been published, what, what goes on with this rule?
Speaker 5:Right. So the current process , um, at the, as of the date of this , uh, recording for this podcast , uh, we're currently in their public commenting period. So anyone can go onto HH s's website and provide comments and feedback on the proposed rule. And when HHS goes back to re review those comments, they will incorporate them into any , uh, finalized rules that they make. And that , uh, comment period is going to end on March 7th, 2025.
Speaker 3:Right? So it may be that by the time , uh, our listeners hear this podcast that the comment period has closed or is very closed to closing at that point. Um, and so what happens once those public comments are all received? What does HHS do with them? Do you know,
Speaker 5:From my understanding , uh, I'm not privy to hh s's internal policies or procedures, but my understanding is that they will review all of the comments, and when they do come out with a , uh, final rule, or if they do, they will address some of those comments in how they've actually decided to finalize the rules. And , um, they will oftentimes incorporate certain comments or , uh, considerations in how they actually go about things.
Speaker 3:Yeah, I've noticed that over the years it has been practice that when a new rule, a final rule is published, that it will contain a preamble and discussion around each of those major considerations, and we'll tell you whether they accepted or rejected a particular perspective that was offered to them and why. And I find that to be very useful. There are, I've often felt that there are many people who read a rule and simply act upon the black letter language of that rule to say, well, this is what they mean, or This is the intent. But it is critical to read those comments and understand the thinking behind them. Oftentimes, it will change your perspective dramatically. So. Excellent. So when we think about the rule, we think, first of all, one of the things that I, I noticed that's happening in this one is removing a distinction between two different states with certain implementation specifications. Jennifer, would you talk to us a bit about this required versus addressable situation and what they're going for now?
Speaker 4:Yeah, absolutely. So , um, what we saw in the , uh, or what's currently in the rules is a distinction between , um, uh, addressable and required specifications. And essentially , um, that was removed in this final, in this , um, proposed rulemaking. Um, and the intent behind that is really just to make clear to covered entities and business associates , um, that the , uh, these things are not optional. Um, and, and so, and , and that's not a , that's not necessarily a change. I think there was maybe some confusion around , um, you know, the, the language that was used, addressable does kind of seem like it could be mean optional, but that was really never the case. I mean, there was always a requirement if , if you weren't going to , um, be able to meet that specific standard , um, to document that and use alternative measures, reasonable measures, that sort of thing. Um, but on the flip side, it does , uh, potentially , uh, remove some of the flexibility that , um, that covered entities and business associates previously had , um, in , in how they were meeting these , uh, these requirements. And , and that's something that I think we're seeing with this , uh, proposed rule is it is much more specific. So they still, A HHS is not dictating what specific technology a regulated entity must use, but it, but you still have to meet each of these elements. So for example, encryption with very limited exceptions, multifactor authentication , um, and a malware, those sorts of things. It's, it , we have much more specific , um, requirements and , uh, especially with the timing , um, you know, so that , that's another element that I think has changed significantly if this rule goes into effect , um, you know, we, we see very , but previously , um, you had requirements around timing that were much more flexible. So, so you still had to perform a , a risk analysis, you know, when, when there's a change in law or, or significant , um, change in your systems and , and that sort of thing. But that, that doesn't really tell you well, how often now we know the minimum is every 12 months as well as, you know, when your systems change, if there is a, and , and I think in the guidance they specifically reference, you know, if there's an acquisition or, or merger or some, some sort of , um, significant change to systems, you know, that's when another one would be required. Um, I think from a practical perspective, what this means for organizations is that they are going to want to develop timelines and checklists. Um, and really the key here is going to be documentation , um, because that is how we are going to evidence compliance with these requirements. Um, you know, especially when you have the risk analysis might not be that hard, that's going to be documented in writing anyway, it's got a date on it, that sort of thing. But some of these other timeframes, like reviewing a sanctions policy every 12 months, you'll wanna make sure that that review is documented.
Speaker 3:Mm-hmm <affirmative> . Speaking of which, they're talking about moving the sanctions policy to a standard rather than an implementation specification under the , um, security management , uh, standard. Um , from here, I'm gonna just kind of open the floor for either of you to , uh, answer and, and , uh, give your perspectives about this thing. Why turn sanctions into an actual standard?
Speaker 4:So Wes, I think that's a really great question. Um, and I would also be interested in hearing your, I've got some thoughts on this <laugh> , but I'd be interested in hearing yours as well. Um, so I personally, so, so basically what's happening here is , um, this having this sanctions policy is, is one of the standards , uh, for compliance with the rule. And within that they are , HHS is much more specific about what this means , um, what the, what a sanctions policy looks like. Um, and so for example , uh, it is going to include written policies and procedures for sanctioning workforce members. It's going to include a review of these policies and procedures at least every 12 months, and then it's going to actually require appropriate actions against workforce members who fail to comply with security policies and procedures and to document , um, those , uh, sanctions . Um, and , and that's just , it's much more specific than what we had before. I think it puts a lot more teeth into your HIPAA compliance program, and I think this is actually going to be a pretty significant change for organizations who maybe had , um, you know, typically what I see is just a one simple one page kind of policy, or maybe it's even a paragraph around , um, you know, sanctions for workforce members who violate the HIPAA policies and procedures as maybe appropriate. Um, now I think what we're going to see is , uh, mu this is going to look much more like a typical compliance investigation , um, for, for, you know, and , and maybe an entity that has a robust compliance program is not gonna see a lot of change here. But, you know, for some of our smaller physician practices and, and other entities , um, who maybe we're not , uh, kind of having to document and enforce these policies, it , it , it's going to look , look different
Speaker 3:Mm-hmm <affirmative> . So , uh, you ask if I would throw my perspective into that as well. Um , what I have long seen has been that we do much better, and when I say we, I'm referring to the healthcare industry in general, we do much better with identifying violations of the privacy rule and applying sanctions there. Um , and decent sanctions or reasonable sanctions, if you will , uh, use a tiered approach. What was the intent? What was the , uh, situation and what was the damage or harm done in, in terms of determining what kind of a sanction is appropriate? Um, would either of you suggest that that would be an appropriate approach for the security rule as well to use that tiered perspective? Thomas, maybe you have some perspective around that.
Speaker 5:I, I am , to be honest with you, a little unsure whether they should. I think it would depend on the individual organization and how they set up those structures. And , um, uh, I, I think it also would depend on, you know, for example, the size of those entities. Um, a lot of the comments regarding all of these new proposed rules , uh, relate to the, the different sizing of organizations and how they're going to actually implement some of these standards and implementation specifications. And so it will really be up to, and I think an individualized and catered approach to each entity.
Speaker 3:Okay. That's , uh, that's an excellent perspective and I appreciate that very much. Um, would you think that the, the harm or potential harm done , uh, would be appropriate to consider as a , uh, as a part of their tiering? Um, or would you take more of an approach of what the intent was in terms of that? Because we know that technology can be quite tricky and people get fooled into disclosing information and , uh, you know, clicking on bad links and phishing emails and those kinds of things. So what's your thought around the idea of whether harm should be a consideration in the , uh, application of sanctions with the security world ?
Speaker 4:I think that's a really good question , um, and something that organizations are going to need to consider. I think what's tricky about the security rule is you can have, and honestly, I mean, we see a lot of these unintentional violations that potentially could, you know, result in , um, some harm, although you try to mitigate that as much as possible, right? Yes . So what I'm thinking of, for example, is , um, you know, somebody sends a spreadsheet to out outside of the organization unintentionally to the wrong email address. Um, and, you know, maybe that wasn't encrypted and, and it didn't quite follow the policy or the email address wasn't double checked , but now you have , um, some, you know, you've got PHI going outside the organization , um, and it's got, let's say, sensitive , uh, health information included. Um, uh, you know, we , you can take steps to kind of try to mitigate some of that harm. Um, but, but ultimately , uh, you could have a pretty , um, you know , uh, kind of small error, unintentional error that results in the disclosure of a significant amount of information, right? And it gets tricky with the security rule as well when we're talking about , um, maybe configurations or, or something gets , um, maybe pushed , uh, to next quarter in terms of , um, you know, patching or, or , or something like that. Mm-hmm . Um , and, you know, if that results in harm, you know, there, there can be a lot of unintentional , um, violations using the wrong fax number, you know, that sort of thing mm-hmm <affirmative> . Um, but, but I do think the , what is the harm is a , um, important thing for organizations to consider. I think also another one that, that will want to be included or , or taken into account would be , um, you know, kind of di folks , um, continuously violating policies. And, and we see, I see that over and over where you have , um, you know, the policy is to , uh, not remove the PHI or the policy is not to send PHI using a personal email address, something like that. Um, and unfortunately you see physicians maybe doing that over and over and over, even after being reminded that sort of thing. Um, and that can, I think, cause a significant risk for the organization. Um, and so , uh, so another thing that that's going to, you know, you're gonna wanna take into account is , um, kind of these repeat offenders or repeat violations, even if it's maybe low harm, low risk for that one violation. Is it something that's repeated? Um,
Speaker 3:That's a good point, <laugh>. Yeah. Um, and , and there's, I think the key point here is in all of this though, is this, is that the , the entire intent of this section appears to be to give the organization more teeth , uh, and to give sanctions , uh, policies and processes more teeth. And , uh, I do wanna circle back to one little element there. And that is this is that under this new , uh, under these new requirements, you would have to review that sanctions policy every 12 months. So it can no longer be something that gets written and thrown into a desk drawer and pulled out and wiped off every few years. You're going to have
Speaker 4:That , that is a very good point, Wes. I think that's the key there is, that is a significant change for sure.
Speaker 3:It really is. Yeah. Uh , a lot more things like that that are moving in the direction of defined timeframes and those kinds of things. Uh, and one of them, one of the new changes, you, you mentioned it early on , uh, was the , uh, technology asset inventory. We, we know that to perform risk analysis correctly in the way that HHS has defined it, you must start by identifying all of your assets that maintain transmit process or create protected health information, electronic protected health information. Um, and so in the , uh, in the process of doing that, then to, to get to the first real stage of what are the vulnerabilities and the threats and those kinds of things, you first have to know where all of your information lives. So this change appears to be locking that into an absolute you will do this not, and implied you will do this. Would you agree with that?
Speaker 4:Exactly. Yes. No, you're exactly right, Wes. And it is going to be a lot harder than I think it looks on paper. So, you know, theoretically , um, coming up with a technology asset inventory, a network map that is , uh, you know, seems very obvious , um, and, you know, every organization would want to do something like that. I think what gets tricky here is , um, uh, and , and the way, you know, and, and it , it should be this way. Um, but the way that the rule is written, your technology asset inventory and network map is not only going to include your own technology assets, it is also it's going to need to track the movement of PHI into and out of your information systems, you know, whether that goes , um, to the cloud or offshore or something like that, or to a business associate. Um, and that's what's I think going to be so challenging is that the HHS specifically said here that the technology assets that are used by a business associate , um, could affect the confidentiality, integrity and availability of that electronic PHI. And so it has to be included in the covered entities network map. Um, and for an organization that has a lot of business associates or that is changing regularly, so you have, you know, you're contracting with a, a new business associate, you know, every six months or so, or, or even more often than that, that can be a significant , um, re it's gonna take significant resources to develop it and to maintain it. Um, and that was not something that we saw previously specifically required even if , um, you know, OCR believes that it was , uh, kind of an underlying component of the risk analysis.
Speaker 3:Yeah. Um, when we think about that, you mentioned both, both sides of this coin, the asset inventory and the network map, but they're, they're different things and they have to function together, correct?
Speaker 4:Yes, absolutely. Yeah . Okay .
Speaker 3:Uh , so if the asset in the way that it's worded is your item that you operate, you maintain , uh, whatever the case might be, and therefore it's your responsibility to risk analyze that. The network map though could be something that you have to work with your, if I'm understanding correctly, you have to work with your business associate who is using this, this asset on their end that may be appropriate , uh, for you to, to include in your network map. So it's no longer a case of, well, where the walls of our building are, that's where our responsibility ends. And then you talk about business associates and the , and the change to business associate agreements. We're gonna circle back on that in a couple of minutes. Um, what, what risks or concerns do you see with this idea of the BA's network map versus the C'S network map or even upstream and downstream bas? What are some of the risks or concerns that you see around that that will need to be considered by the entities, the regulated entities here?
Speaker 4:Yeah, so I think it's going to , um, take a lot of time to develop. It's going to take resources dedicated to analyzing these , um, issues. I think it's going to , uh, be a challenge to link , uh, functions that are maybe typically fall under kind of the IT side with the operations side to know , um, you know, how PHI is, whether this actually involves PHI and how that is flowing. Um, and I think it's going to take a lot of , uh, communications between covered entities and business associates. And unfortunately, I think depending on the, the business associate , um, or even the covered entity, you know, you might find some challenges with those sorts of communications. They might not have a sophisticated HIPAA compliance program or a dedicated , um, you know, security officer that has the, the type of knowledge that they would need to have in order to answer questions about , um, the, the assets and, and the flow of the information. Um, and, and so I think it's just, it's going to be very challenging for folks to , um, to get this sort of thing , uh, mapped effectively.
Speaker 3:Okay. So , um, I wanna direct this one to Thomas. Uh , uh, this, I think this question , um, might be very helpful there. We've talked about standards and specifications, and we talked about the security management process was always , uh, at 1 64 0.308 a right. And a one was risk analysis as a specification under that standard. What are they doing with these changes and how is that gonna change even the basic layout of the security rule? Thomas, do you know?
Speaker 5:Yeah, I think in terms of , um, you know, the risk analysis as well as with their , uh, technology asset inventory and the network mapping, I think the intent that HHS is trying to get through with a lot of this is addressing what they've seen recently with those cyber , with cyber attacks as well as , uh, breaches. And I, through their , uh, recent audits and as well as addressing some of these breaches, I think HHS has noticed that a lot of these entities that are not in compliance with hipaa , uh, don't have these , uh, strategies implemented properly. And so when they are asked, you know, what segments of your information systems have been , um, touched by these breaches or by these , um, cyber attacks, it's hard for them to quickly identify those issues. And so I , I think part of this risk analysis as well as , um, the technology assets and network mapping is to have those in place so that way , um, entities can quickly address potential breaches or cyber attacks as they come.
Speaker 3:Mm-hmm <affirmative>. Yeah, it makes sense to me. One of the things that I thought about it was that , uh, by, they're , they're talking about making risk analysis, for example, no longer an implementation specification, but an actual standard, which means then it becomes far easier for , uh, the regulators to give implementation specifications below that standard and to add and change those things. Um, you know, as, as they go , uh, any other perspectives that you may have around that idea of how they're reorganizing the rule before we move on?
Speaker 4:Yeah. So I'll, I'll jump into , I think Thomas was , um, pointing out the fact that , um, you know, OCR has really focused on risk analysis or the lack of one in its enforcement actions. It's, it's something that's cited almost every single time. Um, and, and Thomas pulled up some , uh, kind of data on it. And, and I think , um, what OCR said is , um, you know, when they audited covered entities and business associates for compliance with hipaa, only 14% of covered entities and only 17% of of business associates were substantially fulfilling their regulatory responsibilities through specifically this risk analysis for analysis process. And I think to address that issue, what we're seeing with the new risk analysis standard is that they have , um, be made very specific requirements for how to conduct this risk analysis. And in some ways, I think that's very helpful because , um, what, what we were seeing in our practice is that most folks get this wrong. Um, so when you ask, let , let's say you're doing due diligence on a deal, and you ask for a copy of the risk analysis, the HIPAA security rule risk analysis, what you get oftentimes looks much more like a , um, kind of a gap assessment, like a very high level, here's what's missing, here's what's, you know, yes, we've got this policy and procedure. No, we don't have X, Y, Z. Um, and that is not what the risk analysis is really intended to do. And so , um, you know, we have, we're seeing from OCR very specific guidelines for how to conduct one. Um, and then also, again, how often, so now you've got this timing requirement here. Um, Wes, I know you all do , uh, you can assist with the, the risk analysis. What, what do you see? Yes.
Speaker 3:Yeah. In fact, that's a, that's a core function of clearwaters and has been from the founding of the company in 2009. We look at risk analysis as there, there are many ways to define risk, and many ways you can use qualitative or quantitative approaches. You can , uh, start from enterprise level, you can look at business risk. But when you , when we think about risk in the way that it is defined by OCR is , uh, you have to start with an asset based . Uh , it's got to start from where is my electronic protected health information? If you don't start from that place, then there is likelihood of missing things. One of the things that we often see is , um, is someone using a controls based approach of starting by defining what the controls are that protect the information, but they haven't defined what information it's protecting, right. <laugh> Or which systems those controls are over. And in part of, and yes, controls are critical, but they're like the third step. If you look at OCR R'S guidance, you know, it starts , uh, from 2010, it starts with where are your assets, then it's what are the vulnerabilities? Then it's what are the controls, right? And then after that, then you get to what are the threat sources? Or it might be that the threat sources come just above the controls, but it's all right there. You've gotta be examining this from that, that perspective of a triple, you have an asset that can be exploited and a threat source that can exploit that asset, right? Yes. And if
Speaker 4:You've got that, then you gotta Right . And assign the level of risk.
Speaker 3:Yeah . And that then gets you to being able to determine likelihood impact and what risk really looks like. Yeah, yeah. Uh , as you can tell, I'm, I'm , I , I , I don't mean to take away any of your thunder, but I, I really , um, feel strongly about the asset based approach. One point I also wanna make here is this , is that we have for the life of our organization , uh, followed every , uh, investigation or , uh, outcome that resulted in a civil , uh, civil money penalty or in a corrective action plan that has been published by OCR. And we have seen over the years, very little change in this number. It's usually somewhere between 89 and 90% of all of the , uh, investigations have as one of their foundational problems, lack of a satisfactory risk analysis. That's just crazy, isn't it? 90%.
Speaker 4:It's crazy. 'cause it's been there for, so it's a requirement. Yes . That's been there for so long.
Speaker 3:Yeah. Right. And , and, and I think the issue is, is taking the wrong approach or not understanding the foundational nature, we, we at Clearwater have always said, your foundation to everything else in the security role starts from your risk analysis. If you haven't analyzed it, how can you then define where to put your controls, what safeguards to put in place, whether they're administrative or technical, that's really less of a concern, but any safeguard to put it into place. But I'm taking too much of your time for me to tell you my perspective now. So let , let's, let's kind of talk , uh, uh, let's move on a little bit further. Um, when we , uh, look at this now, in the past, the , and we've touched on this before, I wanna give an opportunity to think about this a little bit further. In the past , uh, the approach has been periodic or when there is a change to the environment, now they're saying every 12 months you will, or in response to, so it could be more often, but there is a unique new change in all of this with when you will do risk analysis. Talk to me about that a little bit. Yes . Around the business associates.
Speaker 4:Oh, the, yeah . So , um, you know, I I , I think the , what we're seeing with business associates is a lot , and , you know , and, and with the 2013 omnibus rule , business associates became directly responsible for HIPAA compliance. Yes . And , and that was a significant change. What we're seeing with this proposed rule is a , is more kind of renewed focus on the business associate aspect of the relationship. Um, and you know, I think that's just recognizing the fact that business associates are going to , um, you know, hold and, and maintain and, and have to secure PHI and, and oftentimes that can , um, it , you know, if it's not done appropriately, it can result in insignificant , um, harm to , to patients. And so I think OCR is going to, is making , um, business associates more responsible directly and also making covered entities more responsible for their own business associates. So no longer can a covered entity just enter into a business associate agreement and, you know, hand over their PHI and say, all right , we're done here. You know, we trust you. We're all good. That's not what's going, what you're gonna be able to do with this. If this new proposed , um, rule goes into effect, there are going to be significant , uh, requirements around , um, certifying compliance with the , uh, security rule, and then the covered entity reviewing those certifications. And that factors into the risk analysis aspect as well. So mm-hmm <affirmative> . Um, you know, that, that's OCR highlighted that as a piece , um, that gets incorporated the, the review of these business associates certifications and then a determination of the risk associated with those business associates. Right.
Speaker 3:And yeah, and, and they said in clear language in there, if I read this correctly, was you must assess the risk of continuing a BA relationship.
Speaker 4:Exactly.
Speaker 3:Uh , after you've reviewed the written verification from the ba. So that's now a part of your risk analysis process. What, what risks does do , does this relationship create or add to the risk to my P-E-P-H-I ? Because at the end of the day, who is still responsible for any loss or compromise? It's the covered entity , uh,
Speaker 4:Exactly.
Speaker 3:You know , and not, not the, the , uh, the associate that they give information to. So. Excellent. Um, so we , uh, I , and I think we've touched just a little bit on this, but there is more being required in the business associate area , um, uh, than , than just , uh, the things we've touched on so far. What are some of the other changes that they are placing into the requirements around business associates?
Speaker 4:So, you know, we mentioned this , uh, certification , um, there's a written analysis aspect of it as well. Um, and , uh, so that's going to require , um, you know, reviewing these technical safeguards and analyzing them and then certifying compliance. Um, and that's gonna need to be done by a subject matter expert of the business associate. Um, which is, you know, just kind of an interesting, especially if you are , um, maybe contracting for kind of IT services and, and that sort of thing, just trying to , um, figure out who's the person who can actually conduct that analysis and certified in that on behalf of the business associate. It's gonna be interesting. Um, the, you know, another requirement which gives me a lot of heartburn is notifying the covered entity within 24 hours of activation of a contingency plan. That is , um, you know what , when you have an incident or, or something that , um, requires activation of a contingency plan , um, you know, there is often a lot of sensitivity around that. Um, kinda re reputational harm and, and risk, and especially if you were able to , um, you know, and 24 hours , um, to notify you . At that point, you probably don't even have your arms around exactly what happened or what PHI has been impacted and, and that sort of thing, who's been impacted. Um, and so it , you know, that's, it's going to be a challenge. Um, and then it gets factored in probably to your risk analysis, right? Um, you know, if that was right , if you've had received those sorts of notifications and that sort of thing. Um, and then you've got just the , uh, you know, requirements around now , um, implementing these additional requirements into your business associate agreements. Um, I mean, I just can't imagine the, the resources and the efforts that are to go into updating all of these business associate agreements. And I , and I think we got some indication from OCR that there would be, if this rule goes into effect , um, you know, typically the standard period for compliance is 180 days after the effective date. Um, but there was some acknowledgement that , um, there would be extensions for potentially some of these business associate agreement , uh, requirements just because , um, it is going to take a long time. Um, and folks don't always have control over , um, and terminating an agreement or something is not always an option,
Speaker 3:Right? Uh , I don't recall if they spoke about other types of agreements such as MOUs . Do you recall if that was also addressed in there? Because with certain entities it's an MOU and not a BAA that is put in place.
Speaker 4:Sure. Yeah. That's a good, that's a good point, Wes. I would have to go back to the rule and double check that, whether that was specifically addressed mm-hmm
Speaker 3:<affirmative> . But I think it's an important consideration. The idea is that MOUs are often used. I , I came out of the government services , uh, before I got into working with Clearwater, and we often used an MOU between inner service agencies and those sorts of things because we weren't actually contracting a business associate relationship in the sense of, you know, money flowing back and forth or, you know , uh, remittance and those kinds of things. But these two agencies had to think about how they would establish and maintain their relationship, and they would do it through the memorandum of understanding instead. Um, and I, I think, but I could be mistaken, so no one called me out on this one. Uh , I think that they do touch on other types of documents, but I don't recall if it , it's really clearly spelled out. Uh, I do know that I spent hours, and I know you spent hours and days analyzing the comments and the , the changes to the rules themself . There is a lot in it, just a lot , uh, <laugh>. But when we think about the allot part of it, then there's an additional component that we have to think about. What's the cost of doing this? What are your thoughts?
Speaker 5:Yeah , Wes, so, you know, HHS has estimated that this is going to cost , um, about $9 billion in just the initial implementation for the first year, and then an additional $6 billion a year , uh, each year for the consecutive four years. And this is to , uh, to implement all of these reoccurring compliance activities. Um, but these estimates are likely underestimating , uh, the cost and the amount of time that covered entities and business associates will need to take in order to comply , uh, with these proposed rules. Uh, you know, for example , um, when it comes to meeting those , uh, technical safeguards and producing a verification report for business associate agreements , um, HHS has estimated that it's going to cost roughly around $240 , uh, which would only mean about two hours of work time for an information security analyst to perform those activities. A a lot of commenters already have discussed how these , uh, estimates are not necessarily well grounded in what's being seen in the industry. Uh, additionally, a lot of these estimates do not account for actions entities will need to take to comply with the existing security rule as it already stands. And a lot of hh s's comments throughout the proposed rule was that they're not already meeting the se the security rule. And so those additional steps would be additional costs that they're just not going to account for,
Speaker 3:Right? Because in the publication of the original rule, and with each change to it, they have published a cost table, right? That has said, this is what we think this will cost. So if I'm hearing you correctly, what you're saying is, is is that they assume , uh, that you have , uh, borne those costs in 2005 and in 2009 and in 2013. And so now this new one is, is to be aggregated on top of those, but there are a lot of entities, if I'm understanding you correctly, that you're saying it's gonna be a bigger bite because they haven't been doing some of the things they should have from 2005 correctly yet.
Speaker 5:Exactly. And so, like for one example was with their technology asset inventory, you know, that was something we earlier discussed as something that was always kind of expected of entities to do. So HHS didn't include those estimates to getting , uh, asset inventories up to date in their calculations for how much these proposed rules are going to cost entities. And additionally, I I , I think one of the biggest things that I had seen throughout a lot of the comments was a concern for how these costs and the time to implement these costs are going to affect especially smaller , uh, entities as well as rural entities , uh, and how they can afford and take the time to, to, to do these. I know a lot of commenters have requested there being minimum thresholds or exceptions , uh, for , uh, different sizes of entities.
Speaker 3:Okay? So sort of like they've done with the , uh, 4 0 5 D thing where they talk about small, medium and large practices. Um, and even though 4 0 5 D is not regulatory, but it is a framework that we can work within , uh, to help to understand what an entity looks like. So something that's a little bit more like that , uh, let's talk about the timelines. So one of the first things we have to consider is this, is that , uh, notice of proposed rulemakings are issued that sometimes never come to fruition. The most visible one for my purposes was , uh, in 2020, in December of 2020, a notice proposed rulemaking was issued for the privacy rule that proposed to implement significant amounts of change. And after the comment period, it has just simply disappeared never to be heard from again. Could that happen to the security rule to this NPRM?
Speaker 4:Absolutely, it could. Um, I think right now, you know, we are seeing so much focus on cybersecurity and , um, uh, just safety , um, of health information and protection and privacy of it, you know, with some of the incidents that happened last year, these high profile incidents , um, and I think we're gonna see more of it. It it's an issue that is not going away, I think. And so, you know, it wouldn't surprise me if we saw something go into effect , um, although it may look a lot different. Um, but it's, it's absolutely a possibility, Wes, that we see this one just hang out there, just like some of the others have done, and nothing actually ever , um, becomes effective.
Speaker 3:Okay. So if it is issued, you had mentioned earlier that the standard period of 180 days from date of final issuance until the compliance date, that date is the date. We're supposed to be fully in compliance with every element of that rule. But as you had noted, this is complex, but you also mentioned that there were some exceptions and extensions. What, what was one of the extensions that you thought, or that you noted , uh, that was in consideration?
Speaker 4:Yeah, so I think that , um, we saw some commentary around extensions for, for updating the , these business associate agreements. And we saw that , uh, back in 2013 as well, when, when updates needed to be made to business associate agreements, there were some extensions for around that as
Speaker 3:Well. Okay.
Speaker 4:Um, and so, so I think we would see something similar here and , and there may be others as well that ,
Speaker 3:Well , that makes sense. Um, because many organizations have these , uh, contracts and business associate agreements on cycles, and so to suddenly throw their entire cycle into an uproar and say, you must do it by the 1st of July, or something like that, it would just be very difficult for many organizations to effectively handle, at least the way that I see the world. Alright . We have covered a lot of ground in our time and , um, and there's, we could again spend hours covering even more. Um, we've, we've talked about some of the changes to the structure of the security rule. Uh, the fact that things that were previously implementation specifications would now become standards. That new standards would also be created, the both the sanctions one and as well as the , uh, the , uh, asset , uh, the information asset , uh, not the map, but I think I the map inventory the map as well. Yeah, the inventory and the map, because I think the mapping is also addressed at that same level. So that would be a new standard at what was previously secure security management process. Right. Um, and, and then moving some of these other things such as the , uh, risk analysis and risk management , uh, into their own standard categories along with one that I really find interesting, and that is the information system activity review. I think that many organizations struggle to effectively manage this. Uh, and, and there are two sides to it. You have the administrative side of you must do this, but then you also have the technical side of, and this is how you'll do it, right? And so I would, I will enjoy seeing what OCR publishes around that particular standard , uh, and how they lock that down to say, this is what we expect, because I've seen it all over the place. In fact, I've written white papers to explain that trying to keep all of your logs for six years in a large entity would be an absolute nightmare and take up, you know, terabytes, <laugh> of data on any given year. And so you have to consider what is actually retained for that six year span and, you know, that sort of thing. Uh, this has been an interesting conversation. I would love to give you the last chance to wrap up your perspectives on this , uh, and to, and to tell us what you think is important before we close this out today.
Speaker 4:Well, there's so much , um, that we talked about today and, and I think there's so much in the, the proposed rule itself that we could cover. Um, so , um, you know, I think it's just all about the changing landscape. Um, the, the focus, increased focus on cybersecurity and compliance and , um, the privacy of , uh, protected health information. Um, you know, I think , uh, some of these changes like Thomas pointed out, are not new. They have been, you know, in the rule , maybe just reorganized or made more clicks and clarifying updates, that sort of thing. Um, but I think the overall, what I was left with when I read the , um, the proposed rule was this kind of idea of we really mean it this time, <laugh> . Um , I like that. And so <laugh> , you know, even if some of these changes aren't new, I think they, I think OCR means it, and , um, I think we will see some increased enforcement in this area or continued enforcement.
Speaker 3:You all ,
Speaker 5:I just wanna
Speaker 3:Please your final thoughts on that. Yeah,
Speaker 5:Yeah. I just wanted to echo the, the same things that Jennifer has mentioned. You know, as much as we've talked about this being a proposed rule, I think it would, it , it is still great for our listeners to consider reviewing the NPRM, simply because there is a lot of clarifications in there on existing standards and expectations that HHM has. So even if the proposed rules do not go into effect, they will help entities guide them through HIPAA compliance with this, with the existing security rule.
Speaker 3:That is an excellent point. Um, and , and it goes back to what I mentioned earlier, which is, is that with each publication, they give clarification and it's important to read the clarification , uh, and understand what the intent is, not just the black letter language. And I think you hit on that beautifully to cover that particular point. We will see where the future goes. There is much more that can occur , uh, and of , and of course, how long it takes after the comment period closes before all the commentary is reviewed, discussed, and decisions are made about how to proceed from there. Could be relatively short, could be relatively lengthy. We don't know. It could take quite a while. So it could be maybe this year we would see something, maybe it would be two years from now before we see a final rule published. Or as you mentioned, it could be that it languishes, we just don't know. But I love that point about use this as an opportunity to examine your own systems and your own practices and say, what are we doing well now? And what do we need to change now? As well as what would be imposed upon us if this goes forward. A fantastic way to sort of wrap this up. This has been a very enjoyable conversation with both of you. I appreciate you today and , uh, I'll just wrap it up with , uh, on behalf of , uh, our respective firms and the American Health Law Association. We're gonna wrap it up and say so long and have a great rest of your day.
Speaker 2:Thank you for listening. If you enjoyed this episode, be sure to subscribe to ALA's speaking of health Law, wherever you get your podcasts. To learn more about a HLA and the educational resources available to the health law community, visit American health law.org.