AHLA's Speaking of Health Law
AHLA's Speaking of Health Law
How Is Public Law 116-321 Impacting OCR Investigations?
Signed into law on January 5, 2021, Public Law 116-321 requires HHS to take into consideration certain recognized security practices of covered entities and business associates when determining potential fines, audit results, or other remedies for resolving potential violations of the HIPAA Security Rule. Dawn Morgenstern, Chief Privacy Officer and Director of Consulting Services, Clearwater, speaks with Aleksandra Vold, Partner, Baker & Hostetler LLP, about Public Law 116-321’s impact on OCR investigations, how covered entities and business associates are approaching the question of recognized security practices, and recommended frameworks for meeting the expectations of Public Law 116-321. Sponsored by Clearwater.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
Support for ALA comes from Clearwater, the leading provider of enterprise cyber risk management and HIPAA compliance software and services for healthcare organizations, including health systems, physician groups, and health, it companies, their solutions include their proprietary software as a service based platform, IRM pro, which helps organizations manage cyber risk and HIPAA compliance across the enterprise and advisory support from their deep team of information, security experts for more information, visit Clearwater compliance.com.
Speaker 2:So on today's podcast, we will be talking about how public law 1 16, 3 21 is impacting OCR R investigations, or maybe whether it is, uh, I am Alexandra V. I am a partner at baker Hostettler and I, uh, work on instant response, privacy issues, uh, both preparedness and responsively, uh, for covered entities, exclusively, uh, I should say covered entities and business associates. Um, they matter just as much with these questions and the OCR investigations, uh, and it is a pleasure to, to be able to service our healthcare industry and really work with some of the most, uh, preeminent and, uh, really awesome organizations in the country.
Speaker 3:And I'm Don Morgan stern. I'm the director of consulting services and I'm the chief privacy officer with Clearwater. And we are a cybersecurity risk management and HIPAA compliance solutions company. And we are focused exclusively on the healthcare industry and my team specifically partners with our customers for privacy and security assessments and remediation, OCR support in investigations and corrective action plans and vendor risk management. And our goal is not as an auditing organization. Our goal is to partner with our customers in order to help them mature their programs and help them better respond to OCR inquiries, whether it's an investigation or providing, uh, documentation around their corrective action plans. So today, uh, we wanna set the stage a little bit by first reviewing what is public law? 1 16, 3 21 on January 5th, 2021, HR 78 became public law 1 16, 3 21. And what it stated was that the secretary of HHS shall consider whether the covered entity or business associate has adequately demonstrated that it had for not less than the previous 12 months security practices in place that may assist HHS with mitigation of fines results in the early or favorable termination of an audit and mitigating the remedies that would otherwise be agreed to in the settlement agreements with respect to resolving the potential violations of the security rule. It also introduced the term recognized security practices, which means the standards, guidelines, best practices, methodologies, procedures, and processes developed under section two C 15 of the national Institute of standards and technology act. Uh, the approaches promulgated under section 4 0 5 D of the cyber security act of 2015 and other programs and processes that address cyber security and that are developed, recognized, or promulgated through regulations under the, uh, statutory authorities. One thing that we do wanna point out is that, uh, the recognized security practices is not a safe Harbor, a HIPAA safe Harbor. We've seen that a lot in news articles, even though you may have re uh, heard it referred to this, the law still states that nothing in the law shall be construed to limit the secretary's authority to enforce the HIPAA security rule or to supersede or conflict with an entity or business associate's obligations under the HIPAA security rule. So just keeping in mind that it is not a safe Harbor. So how is public law 1 16, 3 21 impacting OCR investigations. And as both Alex mentioned, and I mentioned, you know, we work closely with our clients who may be under an OCR investigation or corrective action plan. And so we put together a series of questions. So the first question is, are we seeing recognized security practices asked about a hundred percent of the time in the investigations? And my experience is yes. So I'll turn it over to Alex to, to give her thoughts on what she's seeing on her side.
Speaker 2:Yeah, absolutely. We are definitely seeing this. This is it. The, the last question in these OCR investigations used to be, you know, how many beds do you have? What's your full-time employee count? This is now the last question in the investigations. And I'd say just about a hundred percent of the time we're seeing these, um, even where maybe it doesn't make a ton of sense. We've seen some with, um, investigations into right of access requests. We were kind of surprised about that because, um, it's really not, not the purpose, but as we all know, uh, yeah,
Speaker 3:It doesn't quite match, right.
Speaker 2:It doesn't quite match, but OCR investigations can really go down whatever, uh, hole they want to, and, and looking for information. Um, but we definitely aren't seeing them, uh, even where<laugh> even where it doesn't necessarily match, uh, or where it's a, it's a fairly small event that, you know, it's just over 500 or right. We've got a complete
Speaker 3:Excessive. Yeah, exactly. And I know on, on, on my side, what I have seen a lot too is, is where you, to your, to your point, you know, the last section was really around, do you have policies and procedures provide us with copies, but now it's getting much more complex. And even within the recognized framework, what I've seen is originally they were saying, oh, just which framework have you adopted? And, you know, provide us with an explanation. And it wasn't anything elaborate, but now we're seeing, uh, in that recognized security practices section, probably at least what, maybe 10 or so questions mm-hmm<affirmative> around which framework you've adopted ha and providing evidence that it's been in place for the 12, the previous 12 months and training materials, and, you know, a whole list of, uh, you know, policies and procedures that, that document that you have a recognized framework. And so it's really started, I'm seeing it really start to expand out in that regard.
Speaker 2:Yeah, absolutely. I think one of the interesting things about these investigations is, you know, as we've seen over the years, the, I think the investigators, I always say there's a, you know, each office has a flavor of<laugh> exactly. You know, we've got New York specials, we've got LA specials. Um, but you know, also particular investigators have a style as well. And we, I think we've really seen those become more technical over the years. Um, but now to your point, you know, with these, did you just be one question, no subpoints, and now we've got doc, you know, I'm looking at one of these sub-questions. They want documentation showing whether the recognized security practices and quotes were developed under 2 15, 2 C 15, or, uh, or the cybersecurity act of 2015 and, or, you know, something else. And a lot of the, a lot, a lot of the time and energy spent in these investigations bef even before this was being asked, is finding, figuring out how to provide documentation or evidence of implementation. It's a little hard with technical stuff, finding documentation of, of the fact that you've developed a particular practice pursuant to a particular framework. Like that's very hard to find, I don't know that anybody sends an email, we should do this because it's, you know, specifically drawing back to this particular sub you know, subset of the stand of a, of a framework. Um,
Speaker 3:And that kinda, that kinda leads into the question about, you know, what we saw in a lot of the older investigations too, because you bring up a good point about documentation showing. Um, when we look at some of the older investigations, I mean, I, I went back and looked at some of, of ours and it's always about provide a copy of the administrative policies and procedures provide a copy of breach notification mm-hmm<affirmative>, uh, that was provided, provide documentation of corrective action, uh, plans. And so it was never, uh, you know, when they say documentation, you know, it has taken on, it seems like compared with these older investigations, a whole new meaning. Yeah. Um, as it relates to what entities are having to compile to respond.
Speaker 2:Yeah. I think that's right. I mean, the, the it's also because of the, you know, enhanced technicality of, of the request before this last question, we're doing a lot of that legwork already, when we're, we're coming up with evidence to show implementation of, you know, log reviews or, um, you know, whatever, it may be a lot of the responses to this, this last question to this recognized security practices has really, that evidence has already been provided because they're asking for, you know, evidence of a, um, you know, monitoring system or, or like I said, log reviews, right. Email security, things like that. You know, we're, we're providing that, but I think<laugh>, the blood pressure goes up a little bit, the importance of this question, um, or at least the perceived importance. And I really hopefully the importance of, of these questions around recognized security practices and, and what it could mean for covered entities. Think what we see is we've, we usually deal with this one last, right. We've got, we work with clients for weeks on gathering the evidence they need for everything else. And then we say, okay, what can we use from above mm-hmm<affirmative> to populate the response to the recognized security questions and as robust as so many of our clients are, they're always like we have more, we can definitely provide more
Speaker 3:<laugh>. Yeah. And there's that, that fine line between, you know, what, what you are putting together. And so let me ask you, uh, ask you a question. So I know our approach has always been, you know, OCR asked for this laundry list in their data request, but it really doesn't tell a story. And so from our perspective, that's one of the things that we advise our customers is, you know, tell that story up front and tie everything together because sometimes the, the list of items can be disconnected. Mm-hmm<affirmative>. And to me, uh, when I've seen responses where somebody just goes down that laundry list, it, it tends to leave gaps that were not intended to be left, but just because yes, we're answering this question like literally, and then they move on to the next one. What are your thoughts on and your recommendations for your clients?
Speaker 2:Oh, yeah. I mean, that's a great question. A lot of times, um, I shouldn't say a lot of times, so we do hundreds, hundreds of these a year. I have a great team that works on, uh, only healthcare, just like myself. And sometimes our clients will say, we're gonna take the first pass. They say, okay. And we get, we get things back<laugh> and, you know, the question will be, you know, provide, you know, the easier questions provide, um, your policies and procedures related to authorized access. Right. Right. And they'll say there, the draft says attach it's, they're attached as, you know, exhibits one through five, no explanation, you know, no, this policy is here, this policy is there. Right. And similarly with the more technical questions, it's even worse because they'll, they'll lean on their extremely knowledgeable it teams who are used to talking the talk with people who talk the talk. And so they'll just say like subnet evidence, you know?
Speaker 3:Right. But nobody knows what that
Speaker 2:Yeah. See, yeah. See the, um, you know, what, you know, whatever it is, use Splunk exhibit six. And so I, a hundred percent agree from the very first, you know, after we do our initial intro, we all, you know, feel we need to do to set the stage. Then, you know, we talk about the entity first, you know, before we actually start answering questions and really a hammer at home on there's this culture of compliance and com you know, culture of, of, um, you know, planned security and we keep hitting home. And so we never, we will never send out a OCR request that just says, the exhibits responsive to this are X, Y, Z attached. It's always, this is what the we're gonna, this screenshot shows this, this is what that thing does. This is what it's called. Right. And we'll define it because I think this is the case with any regulator, anyone you're trying to persuade, if they don't understand what you're talking about, they're not gonna use it to your benefit. So I think running through running the, it, running the, it team's answers through someone who doesn't do it is really important because they're gonna say, what does this mean?
Speaker 3:Right. You
Speaker 2:Take same approach.
Speaker 3:No, I, I was gonna say, I think that, uh, that has always been successful for us too, because we probably tend to put it more in those layman's terms. And as you mentioned already, each, each regional office, each investigator has their own flavor. And I know in my own experience, we've run into situations where the investigator is overseeing the, the, um, mm-hmm,<affirmative> the investigation, but nine times out of 10, depending on what the type of situation is, they're then turning all these documents over to a technical reviewer mm-hmm<affirmative>. And I, I don't always think that the investigators are, you know, much like, you know, someone who is not the, in the trenches security person as well. Don't always understand a lot of that as well. So the more we can make it so that the OCR investigator understands it. I think it works better on the back end, too, because when we've seen questions come back, you know, we wanna understand what OCR is asking for as far as any follow up documentation. I don't know that what the, what the technical reviewer is asking for is always easily translated back across. So I think that's where that story comes in play of the organization and what each of those elements in the response mean.
Speaker 2:Right. Have, have you seen, um, any investigators come back yet to ask for clarification on even taking it outta the context of, of 3 21, you know, and thinking more about just security questions generally, have you had a back and forth on, on security, um, practices yet? Or do, does it seem like they're, the investigators are more focused on the privacy and the administrative pieces
Speaker 3:In the few that I have done now, granted, you know, these were pre some of these were pre the recognized security practices, um, requirements in the data request. But I have seen where they have come back, um, to certain customers who had some sort of a cyber incident. And a lot of times they're gonna do it in, at least I've seen them that they'll do it informally. So it'll be a phone call back, or it'll be an email back. And so there's sometimes a lot of back and forth, because again, when I talked about the technical reviewer's level of expertise is different from the investigators. And so trying to bridge that gap between what the technical expert is looking for versus how that's pushed back, that takes a lot of, um, coordination to make sure that we are giving them what they're asking for. I have seen them come back for, for those types of things. Um, I don't know that we're far enough into the process now of the recognized, uh, security practices that there, I haven't seen yet, anyone coming back asking for additional evidence, because in most cases, organizations, at least the ones I'm working with are still in the process of understanding what 1 16, 3 21 is. And now that we're getting some idea of what OCR is asking for, they're having to reevaluate where they are in that cybersecurity, um, ecosystem to determine how they wanna approach it.
Speaker 2:Right. And maybe let's talk about that a little bit about this approach. And, you know, I don't know the entities I've worked with, um, they are not strictly missed. They're not, they're not a lot of times they're not strictly anything that, because right. There's just different needs for, for different types of, or I guess, pieces of their infrastructure. And so grabbing kind of getting a hold of the evidence, they need to show recognized security practices is a, a bit of a, a<laugh> I dunno, I dunno what you call it. Some kind of like grocery shop and game show, perhaps like grabbing things and talking to lots of people and it kind of putting everything they can into their response. Have you seen kind of, I guess one question is, is that normal, which by the way, for listeners, I feel like half of, um, kinda the reaction to these recognized security practices, questions from clients is, are we normal?<laugh> cause no one really knows. Right. Um, what everyone else is doing. And I wanna talk about the request for information from the OCR put out last line a little bit in, in a second. Yeah. Yeah. Um, but you know, one, do you feel like there are, there are entities that are strictly missed and they will, it's easy for them to show this or do you two feel like it's a kind of a cobbling together?
Speaker 3:So here. Yeah. Here's what I've seen, especially since, you know, we are pretty much focused with, in the healthcare sector with business associates and covered entities. I mean, I think gone are the days of just having HIPAA policies and procedures, right. Especially for the larger entities, the hospital networks, the large practice groups, the more sophisticated entities I think gone are the days of just having HIPAA policies and procedures. Um, for those of my customers that I've worked with over the course of many years, I've watched them, you know, transition from that very HIPAA based approach to incorporating the N requirements into their whole cybersecurity ecosystem. But I think back to your point is that it's still, it's still a blending and I don't even the more sophisticated ones I think, uh, from what I've seen are really, it's still a work in progress with the N standards. So for example, if you, if you, even, if you just look at a couple of those, uh, N standards, so like the cybersecurity framework, there's, um, you know, 23 categories and 108 subcategories mm-hmm<affirmative>. And so that's not an easy task. And so, you know, to what extent they're adopting the cybersecurity framework, some are looking at it from a N special publication, 800 dash 53 perspective, which is even more challenging. Um, within that alone, there's 189 controls. Now it's dependent the controls that end up being applicable minus those that have been withdrawn or incorporated into other controls is whether or not they're looking at whether they're going to be low, moderate or high. And that drives those controls. And they', I think that entities are embracing N more and more, but it's still a blending with HIPAA because ultimately HIPAA is the regulatory requirement and N is, is, you know, a framework that they can achieve that
Speaker 2:Mm-hmm<affirmative>, I think too, I mean, as is the case, I feel like with any compliance program documentation and keeping everything all in one place is, is part of the, of the hurdle. So one of the things we've seen too is, you know, they'll say the we've got NC that say yes, you know, we, we work off of the N framework. They've got, um, you know, one of my recent ones, they have this great dashboard with all of their yearly attestations. And, um, you know, they're kind of keeping things as a cross hook, but to your point, like demonstrating that in depth, yes. Is one, we don't necessarily want OCR to see all of the hair on there because there's lot of comments and reactions, not, you know, not, not offhand reactions, but we need to do this. This needs to be delayed. This is, you know, needs to be bumped up and then nothing happens, whatever it may be. And so what we've done because, um, because of cybersecurity act is just a little easier. We, we do generally kind of provide evidence that they're, that they do follow the N framework, but not necessarily give them all the documentation, because like I said, it's not always something you wanna open, you know, open to OCR. And so then we do that more narrative, user friendly approach talking about the, the, the standards, you know, email security, um, you know, logging you all, all of the kind of 10 standards. And we, we take that approach, which I feel like, like I said, is, is a little more user friendly then and less risky and flopping
Speaker 3:That brings, that brings up another good question, because, you know, in many cases, I think the organizations that have gone down the path of incorporating the N requirements into their everyday security practices goes back to what you mentioned, um, previously about following the N guidelines, as opposed to have they actually adopted and implemented those particular guidelines. Mm-hmm<affirmative>. And I think that that's where I, I, I still see that it's a blending and I, I still see that even the more sophisticated organizations are still struggling with, uh, the N based approach, just because it's so large mm-hmm<affirmative>, and it covers so many different things. And to the extent, to your point, to the extent that OCR is going to want to see how at what level. So I think that when we see that, um, from my perspective, I know one of the first, uh, things that some of my clients have been concerned about is the level of detail. And maybe that will go back to talking about the RFI from April. Um, but the level of detail has concerned them because not just because it's a monumental task to pull all that documentation together, but then to what extent does it further expose them? Not only cuz some of that information is confidential, it's proprietary. It may even contain some trade secret information. And we know in the past that the responses to OCR are subject to the freedom of information act, right? So how can that information be used either by other bad actors or to the extent that it exposes the organization's vulnerabilities with additional class action lawsuits? What are your thoughts on that?
Speaker 2:Yeah, I mean, I think operational security is always a big concern for us when, especially when we are in the midst of an instant or, you know, we just had one and we're going through the, the, um, the investigation everyone's on heightened alert about, you know, what is, what is being said to the public and the immediate aftermath mm-hmm<affirmative>, but then there's that tale of, like you said, the class actions and you know, we, we don't have the ability to say no. Um, when we are right, said responding to OCR, the plaintiffs will ask for any communications with regulators, they're not privileged. Um, and unless the regulator, sorry, go ahead. No,
Speaker 3:I was gonna say, which brings up another issue too, about in the while you're in the investigation phase, especially from your perspective, working with a law firm and being an attorney, a lot of that works sometimes gets done under attorney client privilege. And then when you have to, when you move to the stage where you're having to provide evidence to OCR about the incident, you know, and about your security practices, at what point, you know, does it end up waving that attorney client privilege from the investigation?
Speaker 2:Right, right. I mean, we are so careful and we keep that absolutely top of mind because, you know, it's, it's tough there, there are a lot of cases out there that, that make it more difficult to assert privilege over investigations, but it's not by any means impossible. Uh, and so when we think about the final production of a report, for instance, um, we generally speaking, we will think about whether we even want to call the report privileged or whether we want it to be work product, which in, I, I think the most places it's waivable document by document, as opposed to waving the entire investigation mm-hmm<affirmative>, um, or if we maybe even just wanna call it confidential, knowing that we're gonna have to give it to OCR, we're going to have to give it to our state regulators. And if we call something privileged and it's an uphill battle to say that we haven't waived it later. Right. And so we keep it very factual. You know, we keep things that you, we keep keep, um, the privileged pieces of the investigation where we don't have the forensic evidence to say something definitively. It doesn't get said because that's, that's no, that's not a fact. Right. That is an opinion. And so, um, yeah, I mean, everything has to get to the plaintiff's attorneys. I will say. I think a lot of times the plaintiff's attorneys, similarly to the investigators don't have the technical know how to understand what is being said or even what's missing. Right. Right. I think, I think if, you know, I'm, I'm looking at a response we worked on with a client recently it's 15 pages. And the only question asked it was a follow on to a, a, it was a, it's a three year old investigation at this point about snooping. And so now they are asking, they sent us one question with lots of subparts about recognized security practices and it's 15 pages just to answer that<laugh>. Um, and so I think if, if you're giving that, that story, I don't, I think both OCR and plaintiff's attorneys are gonna have a hard time understanding what the gaps are, but if, if there is a breach at the plaintiff's attorney or at the OCR, and those types of documents are, you know, become you in the hands of a bad guy, that's just so much network intelligence. That's so much, you know, good stuff around, you know, how do I ment their controls? Well, you can't circum exactly. You know that exactly. They're laying it out. So that's problematic.
Speaker 3:Yeah. And
Speaker 2:That's other things, oh, sorry, go
Speaker 3:Ahead. No, I was just gonna say, and that's really a big concern that, that, that my clients have had is that, you know, to the extent that they're exposing themselves to additional attack, because now that information is publicly available, so to speak. Yeah. Um, that has been a big concern.
Speaker 2:Well, and I think coming from your position, this is a, an interesting question I was thinking about this morning. So, you know, another place we see clients be very concerned is around their security risk assessment or risk analysis. And, um, and that's what I was referring to as the enterprise wide, you know, full, full evaluation of where Phi is. Right, right. And they always are concerned, what is my risk? How does this look, et cetera? And my responses, everyone, if they don't find something that's a red flag, so you're gonna find something. Right. Um, and also you want them to, nobody
Speaker 3:Is risk free,
Speaker 2:That's risk free, and you want them to find something because then that's something to work on. Um, one of the things I was thinking about this morning, though, and I'd be interested to hear your thoughts is in the RFI OCR, uh, explained that implemented must. I'm gonna quote from them must. I think this is quote, yeah. Demonstrate the prac that the practices are fully implemented, meaning that the practices are actively and consistently used, uh, in used by the covered entity or business associate over the relevant period of time. So what came to mind this morning is we've got our recognized security practices that, you know, for instance, we have MFA on all email accounts and then our security risk analysis comes out and its highlights the fact that we are missing MFA on maybe 1100 out of our 50,000 user accounts for whatever reason.
Speaker 3:Right.
Speaker 2:And I'm wondering what your thoughts are and, and we, we haven't pre-game this. So I, I apologize, but whether you think, and again, I think OCR is very much still getting its arms around how they're gonna deal with these things. But if, how we're gonna deal with those inconsistencies on, you know, complete, full implementation. I don't know if there is such a thing as full implementation. Um, if that's not gonna jive with our, our RSA or sorry,
Speaker 3:I think it, I think it, the, the, the word and I'm using air quotes full implementation is, is a tricky term because it's just like somebody who says, oh, we're a hundred percent compliant. And<laugh>, I know from my perspective and I'm sure, you know, from your perspective, no organization will ever be 100% never. So the question becomes, you know, and this is really a, a, a thing that we plug, especially when it first came out, we actually had done a webinar on 4 0 5 D H I C P like two days after the RFI came out. And so we made sure we encouraged our clients to actually provide comments back to the RFI because when they start using terms like that, I think that it can become a slippery slope because if they use the term fully compliant to your example, if it was two systems that didn't have multifactor authentication, then you could not state that you're fully compliant. Right. And I think that there's a, a risk there that that kind of terminology totally, uh, goes against the whole, uh, premise about reasonable and appropriateness too. Mm-hmm,<affirmative> absolutely within HIPAA. I mean, you can, it's just like human error. You can train until people are sick of hearing about fishing attempts, but there is still that one person that's gonna click on that email and potentially allow in an opportunity for ransomware. And so again, it goes back to, you know, using terms like that. So again, you know, we look at them, them soliciting feedback on, you know, around the recognized security practices and how you adequately demonstrate that. Um, I think that's where our clients can provide valuable insight back to OCR about the operational practicality of that.
Speaker 2:Absolutely. Yeah. We've, we've been strongly encouraging and are working with some of our clients to prepare comments back, uh, because I feel like this is really, um, a unique, I mean, it only comes around now, you know, every 10 years or so, and maybe less to have the opportunity to really form these, these truly impactful pieces of HIPAA. And yeah, if we're, if we sit, if we sit here and say nothing full implementation is gonna mean full implementation
Speaker 3:And right.
Speaker 2:I don't know how they define, like what's an, what is full implementation if it's not truly full, like they also have a slippery slope that they're gonna have to deal with, which is, is it a percentage, is like, if they truly listen to people that, or commenters that say full implementation is a fallacy, well then what, right. What is gonna be enough? And I think that's gonna be tough on them. Um,
Speaker 3:Because if you're, yeah, because if an entity is, you know, doing their, their technical testing, their and their non-technical testing, and they're doing their risk analysis in accordance with the nine elements of an OCR, uh, risk analysis and listening to Lisa Pinot's last, um, statement around what is a thorough and accurate risk analysis, you are, you are going to find risks no matter what. Now, the level of those risks, whether they're critical high, medium, or low are obviously going to be, um, you know, displayed, but also too, in your risk management plan and your risk manage management remediation, there are some of those risks that you would accept that are in line with operational, uh, practices, and again, but may not rise to that same level of being fully implemented. So if you have a low risk that you've accepted as, as it is, then can you ever say that you've fully implemented that control,
Speaker 2:Right. And that's, I mean, that's a wild
Speaker 3:It, yes.
Speaker 2:It's a wild thing to think about because the, I think the, the SRAs then become fraught with even kind of more risk is an overuse of that word, given that what we're talking about, but truly, I mean, there's already so much, so much concern around what that says about us as a, as a covered business associate. And then if it has the ability to undermine our, our showing or full implementation, I think that's, that's really something you need to talk about. You listeners covered entities and business associates, talk about with your security risk analysis vendor and making sure everyone's on the same page with definitions and not having these reports come out that are gonna blow, blow things up completely. Yeah.
Speaker 3:Yeah. And out there, because I mean, risk analysis is, is a lot of our bread, bread and butter, and you'd be amazed how many organizations still haven't grasped the concept of what is a thorough and accurate risk analysis. Many organizations are still doing it, um, on a controls based perspective. Some, and this is in, in, in Lisa Pinos comment was that a risk analysis is not focusing on your electronic health record. It's focusing on all of your E P H I and your E your systems and applications mm-hmm<affirmative> and, you know, take a hospital that not only do they have, you know, their core systems, but then they have medical devices and they have all different categories of medical devices. Mm-hmm<affirmative>, and some will never be able to meet the security requirements just because of the technology or the age. And, you know, for example, uh, you know, one of my customers has a piece of medical equipment. It's a niche type of equipment. It's not something they can just throw away and get something new, and it costs millions of dollars. And, you know, that is a case where they have to look at what are the risks involved with that system and how do they put in compensating controls, but they'll never fully eliminate the risk mm-hmm<affirmative>. And so it all goes back to really helping, you know, encouraging our customers to comment, to help drive that narrative around the implementation of the recognized security practices and what is considered adequate to at least educate OCR or HHS on some of the things that our clients are experiencing that you listeners may be experiencing in the real world of application.
Speaker 2:Yeah. I think that's, that's absolutely right. And, you know, part of this is so tough because compliance officers have a lot to look at too, right. We've got, we've got it. Departments separate from compliance departments, most of the time for good reason, because both are, are massive full-time jobs. And so I think one great thing to do is add another, add another meeting to your schedule. Yeah. But you know, truly to make sure, you know, where this, I feel like one of the only places this really comes out where there is this, we are, we in compliance are okay, or we are in it are okay. Accepting a particular risk. And, and then all of a sudden there's a massive diversions, right. That, that creates a significant fork in the road on kind of go go forward events. Um, I feel like we really see that in two, two places, one is too late, which is during, during OCR investigation. Um, and you know, there's some misconceptions around, um, you know, what risk was okay. And what the true impacts of that risk was. The other one is the right time, which is when we are doing even tabletops. I mean, it's, that's still a limited, a limited exposure, but, uh, kind of a breach simulation where we're talking about, okay, you know, uh, someone called this morning to your sock and said they can't, their, you know, files are encrypted. What happens next? So we kind of go through things. And a lot of times when we are going through these simulations, we take it first hour by hour, and then day by day,
Speaker 3:Right.
Speaker 2:People in the room that range from HR and marketing communications to CFO to it leads, someone says, well, don't, we have blogs for that, right. Or aren't we monitoring this? And they say, no, you decided that we didn't need it. Or we couldn't get that budget. Or how are, you know, the train training's being monitored implemented. Right. So we know who, who is more susceptible to this. No, we have not been tracking that somebody left and that person wasn't replaced. So I think testing things is very important, even if it's a breach simulation, or even asking your, your regular privacy council to just give you a sanitized version of an OCR investigation that you could see how you'd answer. Those questions is a really, a much better time than your own investigation to identify
Speaker 3:Right.
Speaker 2:That divergence
Speaker 3:Better, better than, than in the midst of an actual investigation. Right.
Speaker 2:Right. But we don't,
Speaker 3:And we are seeing that more and more where, um, we are getting more requests from our customers to conduct tabletop exercises for not only, uh, not only a breach incident, but we are seeing requests for, uh, technical testing when it's an assumed breach just as an exercise. And we're also seeing more, uh, requests for doing tabletops for business continuity and disaster recovery too. Uh, largely because of the, the significant number of ransomware attacks last year that have resulted in, uh, organizations that haven't been able to reproduce the data from their data backups. So we're seeing a lot more of that, so that I think is encouraging, but I still think there's a long way to go. And I still think that, that, you know, a lot of the organizations that we support as our customers and our clients really would benefit from really starting to embrace that we are now moving beyond just the basic requirements when it comes to HIPAA, because as technology changes as the attack cha uh, the attack, uh, surface changes, more and more organizations are having to imple implement these specific controls. And then that way on the back end, if they do have an incident, they'll be in a much better place. That's for sure.
Speaker 2:Yeah. And, you know, along along those lines, you know, about being prepared and, and having even a mature cyber program, are you seeing any, any parts of, and I, if I say this, I mean, that's a huge framework, but yeah. If we just go to kind of our 10, you know, practices, is there anything you're seeing, or I guess, any security related questions asking for proof of implementation, are you seeing even, or how do I say this? Any patterns of difficulty in kind of meeting expectations or providing evidence of implementation on any particular kind of common security standard? So, you know, things to me like MFA is fairly easy. You can take a screenshot, right. And send it, you can print a PDF, the email that you sent to all of the workforce saying as of Monday we'll be using MFA, but right. Um, anything you've seen that has been more difficult for entities to, to provide evidence of,
Speaker 3:Uh, I don't think it's an issue of it being more difficult. It's just that it, because it goes beyond policies and procedures and the typical documentation that you would have available under the, the HIPAA requirements. I think where the challenge becomes is how you show that you have implemented a lot of the requirements. So one of the recent letters that I had basically ended up breaking out every security requirement and asking for documented evidence of that. So for a, for example, uh, in the letter, you know, the typical one is they ask for, um, they ask for your risk analysis and, and that's usually a pretty straightforward one, but they're asking for documentation of implementation around, you know, security measures, sufficient to reduce threats and vulnerabilities. So it's, it's not so much that you have a security, um, incident, an event management tool, a SIM it's showing proof that you have all those things. And I think that's where the challenge comes in, cuz gone are the days where you could simply say, oh, we, we have a SIM in place. We have a 24 7 sock, that's monitoring the logs and monitoring the activity. We're getting alerting. How do you prove all that? Mm-hmm,<affirmative>, that's the challenge. And I think that's just where the challenge is in the new direction of providing all this additional documentation. Cuz again, it's, it's more than just policies and procedures, you know, how do you show that you've implemented policies and procedures on reporting security instance?<laugh> right. Well, yes we do say in our policies and procedures that, you know, workforce members should report it to the security office or a generic email or in training, but what exactly is the threshold for proving that implementation? Mm-hmm<affirmative> like, how do you prove that you've created and maintained retrievable exact copies at me?
Speaker 2:Eh, would you like to see our EMR? Right. Like, well,
Speaker 3:Exactly. Do I have to show you my backup log? Uh, my backup of, to show that I have a previous version that is a retrievable exact copy. So I think that's really where it gets challenging.
Speaker 2:Yeah. I think one of the places we're seeing, uh, a tough time is with log review specifically because you know, even if they've got a SIM, even if they, you know, they're using Splunk, if they have a sock mm-hmm,<affirmative>, it's still kind of showing that someone's looking at those, you know, about at those logs and correlating things. And one of the only ways we can show is, is an incident report. And then we're like, okay, find us a, a, a good one, one that wasn't anything. Right, right. Because
Speaker 3:We chose
Speaker 2:Another incident, uh, went to OCR.
Speaker 3:Yeah. And even implementing a SIM is a challenge because you have to tune the environment right. Of what to look for. And so I know a lot of, you know, and this is just an example, but a, but some of our customers, you know, that's, that's a, not, it, it's not a plug and play here. We've gotta assume we're done Boohoo. Mm-hmm<affirmative>, you know, it, there's a lot of work that goes on in the background of tuning that environment to get those alerts and making sure. And, and when they get alerts, then they still have to do a manual process to determine, you know, what type of alert, you know, what type of activity was occurring? Was it a false alert? Is it a positive alert, those types of things? It's just an example. But then again, it is an implemented practice, but how do you show all that?
Speaker 2:Right.
Speaker 3:That's where the challenge, that's where the biggest challenge, uh, comes in. And I think, um, as we close out, you know, I thought one of the things that people would probably be interested in is, you know, what would be a recommended framework that you would implement in order to meet the expectations of 1 16, 3 21? And I thought a little bit about this because I think that it really is going to depend on the organization's cyber security, maturity level, as far as which type of framework they, uh, are adopting. And, you know, we looked at, we looked at 4 0 5 D H I C P, which is it's a, is a different approach, looking at things from practice groups that are scalable based on the size of the organization versus a cybersecurity framework, which as I mentioned has 23 categories and 108 subcategories versus missed 853 that has, you know, up to 11, uh, thousand 1,189 controls. I mean, what are your, I, I kind of look at it as a, uh, a building block mm-hmm<affirmative> so HIPAA is our foundation. And so what's the next building block that an organization can achieve. And I think it's where that maturity level comes in, where 4 0 5 D H I C P I think is something that is more achievable to a large percentage of organizations versus N that's not to say NT would be a long term strategy, but I, I, I, I almost look at it as is it's the ability to have these building blocks of starting, you know, you've got your HIPAA foundation next, you're gonna build off of the 10 practice groups in the 4 0 5 D H I C P. And then your long term strategy, which part of 4 0 5 D H I C P will meet those same MIS requirements. But it, I think it's, that becomes your long term strategy because of the complexity. What are your thoughts on that?
Speaker 2:Yeah, a hundred percent. I, I, I think you're right on the money with the four or five DBA, just much more attainable and, and also, you know, user friendly. And I I've said that a couple different times, but truly if, if you're too bogged down in tracking all of these different, subparts, you're never going to act on anything. And so, right. I think it's really good for, especially for less mature entities going through those 10, um, those 10, uh, uh, areas control, right? I mean, it's there it's email security endpoint, uh, security access management, uh, DLP, uh, you know, data loss prevention, it asset management, network management, vulnerability management. I just reading'em here in case people know, security op center, insert, response, planning, medical device, security, and cybersecurity policies. A lot of that, you're gonna hit by being HIPAA. You know, like you said, your HIPAA's your first building block. You're gonna have your cybersecurity policies. You should be, you know, having ways to monitor your, your end points and your, and the pH I in your system. Right. And I think going through those 10 and saying, how would I answer this? How would I show we're doing this? That's really gonna show you, you know, you shouldn't have just one thing probably for, for any of those. Um, and then you can really start to assess and likely with probably a third party, uh, because it's, it's just a big project. Where does that match up with N and what can we really do if we're, are we 10% of the way there? Are we 75%? And how do we get to a hundred? Because yeah, this really one, I feel like once you get there, the upkeep is it's important, but it's certainly not as cumbersome of getting fared in the first place. So I would recommend first 4 0 5 D and then, and then really assessing how much further you can reach.
Speaker 3:Um, and I think, yeah, I think no matter which, uh, framework in the end, um, you know, much like how we documented HIPAA, we've documented that in our policies and procedures, so we can show evidence that this policy has been in place since 2005, or, you know, it's been reviewed, it was reviewed last year, so we can show that kind of historical evidence of, of implementation. And so I think that similarly with a lot of these other, uh, controls, uh, whether it's using 4 0 5 D H I C P or the N uh, N uh, based approach, that definitely there's gonna be a little bit more work in order to document that because you may implement certain technologies and certain things within, let's say the four or five D H I C P framework that you are not putting necessarily in a policy mm-hmm<affirmative>, but yet you wanna capture when you've implemented that. So,
Speaker 2:Yeah. And I think just one point on that, too, just remembering that the, the goal is not to be able to show that you're compliant with this, that's a byproduct, right, right. Object is let's prevent incidents from happening before they happen, not, you know, not react. Right. And I think, you know, it's great that now we are gonna be able to use this, you know, in a different sense, your compliance, a different sense. Uh, we'll be able to hopefully mitigate or help to mitigate fines if they were gonna come. But really you're, you're setting the organization up to just be in a much better position. Um, and the other thing too, just about, you know, why even, why follow a framework generally? I think I, I got that question the other day, I was reviewing an incident response plan, and I was like, this doesn't, you know, follow this. It doesn't follow anything that I can really identify. And the client's like, and, and I said, well, it can't be like, remember a law school teacher said, it's not the law. According to Alex, you know, you have to, you have to have something that says, this is valid. This is, this is what is acceptable. Right? And so to some extent, it is a hodgepodge, but being able to track, at least this is compliant or, or meets the standards of this. This is based on 4 0 5 D but saying, this is good enough for us is not a winning strategy. No, you know, I think it's a really smart idea. I shouldn't say it's not a winning strategy. It's a more difficult strategy to defend. Um, and it's better if you're drawing from something, even if it's not, you're not holiness compliant and you're not wholly on board with 4 0 5 D
Speaker 3:And I think to close out our, our podcast today, you brought up a very good point about, you know, leveraging this and public law. What, what is occurring as the result of, of public law, 1 16, 3 21 to really drive organizations to do what's right. With regard to ensuring that they are protecting the data from bad actors, whether those are internal or external and putting the right things in place, because it's the right thing to do.
Speaker 2:Mm-hmm,<affirmative> absolutely. Yeah. The, the, uh, the, the request for funds, I've had a lot of clients when they're going to the board for the budget request and the, in the, you know, uptick and spend they've provided these sanitized OCR investigation requests to show, look what other entities are doing, look what we're gonna be expected to do. And we can either spend money now, or, or you're gonna be asking what, how we're gonna be fined later.<laugh> exactly, you know, getting that, that support through these mechanisms I think is, is a great idea.
Speaker 3:All right. Well, it was great talking with you today, Alex, any closing remarks on your side?
Speaker 2:No, thanks for listening. And, and, uh, may you all be secure going forward and never need us?
Speaker 1:Thank you for listening. If you enjoyed this episode, be sure to subscribe to ALA speaking of health law, wherever you get your podcasts to learn more about ALA and the educational resources available to the health law community, visit American health law.org.