Transcription:

Caitlin White (Host):  Brad Trudell is MetaStar’s HIPAA Privacy and Security Lead. He is an attorney with over 20 years of experience focusing on HIPAA privacy and security compliance. Brad has conducted hundreds of HIPAA Security Risk Assessments in 45 states for a variety of hospitals and other healthcare providers, health plans and government entities. Today, he’s sharing information with us about HIPAA Security Risk Assessments.

This is MetaStar Health IT Radio, the podcast from MetaStar. I’m your host, Caitlin White. So, Brad, thanks for coming on. Let’s start simple here. What exactly is a HIPAA Security Risk Assessment or SRA?

Brad Trudell (Guest):  Thanks Caitlin. It’s a pleasure speaking with you today. The HIPAA security rule first came out back in 2005 and depending on how you count them, there are between 85 and 90 maybe 95 separates parts and pieces of the security rule with which health organizations must comply. These requirements include such things as data encryption, antivirus software, system access controls, data backups, and disaster recovery planning. But the very first requirement of the security rule is to conduct a Security Risk Assessment or SRA.

The SRA is really a gap analysis and it’s designed to determine which parts of the HIPAA security rule an organization is in compliance with and which parts they are not. For those parts with which you are in compliance; you are expected to provide documentation as proof of your compliance, such as written policies and procedures or screen capture to show that you have certain settings in place.

Host:  So, who needs to conduct an SRA? Is this something that I should worry about or what?

Brad:  Virtually all health plans and healthcare providers which are called covered entities under HIPAA are required to conduct a Security Risk Assessment or SRA under the HIPAA security rule. A health plan under HIPAA is any plan that pays the cost of healthcare. And this can include an individual plan, an employer sponsored plan which is fully insured or self-funded and also government plans such as Medicare, Medicaid and Obamacare.

On the provider side, any provider that conducts healthcare transactions electronically which of course is virtually all of them is required to comply with the security rule and periodically conduct an SRA.

Host:  Can I do an SRA myself?

Brad:  Well nothing prohibits you from doing an SRA in-house by yourself and a few folks do just that. We’ve seen practices that have created their own Excel spreadsheets or Word document tools that they use to track their compliance with the HIPAA security rules requirements. But of course, this type of a method would require a fairly robust level of technical knowledge regarding the use and disclosure, the storage and the transmission of electronic data.

I should also point out that the federal government has put together a free tool that can be used to conduct an SRA. The ONC which is the Office of the National Coordinator for HIT. The ONC has developed a free tool and made it available for download directly from their website. While they have improved their tool over the past few years, it should be noted that the ONC tool is still missing some significant pieces. For example, it doesn’t come with any type of support staff to answer questions you may have. It provides no sample policies, procedures or other documents that you may need. And it does not contain an action plan with advice on how to mitigate or fix those risks that are identified in the final report and your SRA.

Because of these shortcomings, most organizations do choose to use a third party vendor such as MetaStar to help them conduct an expert assisted assessment of their potential security risks. The benefits of doing so would include having expert support staff on hand to answer any questions you have, having access to sample templates such as policies and procedures, secure Cloud storage of your SRA responses and supporting documentation, the production of a detailed final report containing a prioritized listing of your risks as well as advice on mitigating each of the risks identified. And then of course, you also want to have an interactive action plan or a risk remediation plan to help track and tackle those risks going forward in the weeks and months to come after the SRA itself has been completed.

Host:  You mentioned a bunch of apps and tools. So, how should an SRA be conducted?

Brad:  The security rule does not mandate that any specific method or methodology must be used to conduct an SRA. And as a result, there are several different methodologies out there that can be used. However, most healthcare experts would recommend using a straightforward nine step process called the NIST SP 800-30 to conduct their SRA. NIST stands for the National Institute for Standards in Technology which is a federal agency under the US Commerce Department. NIST created the 800-30 way back in 2002 as a way to look at a system and its weaknesses or vulnerabilities as well as the main threats to that system and the controls put in place to thwart those threats.

The end result of this process is a final report containing a prioritized listing of your risks which represent your gaps in compliance with HIPAA. Of course, we want those risks to be prioritized because not all risks are created equal and we want to give you an understanding of the biggest most immediate risks to your patient data. And hopefully some of those higher rated risks can be addressed without too much staff time or other resources.

Host:  You know I think of healthcare as an annual thing, something I have to do yearly but how often should I conduct an SRA?

Brad:  The HIPAA security rule requires providers to conduct a security risk assessment and then implement security measures to reduce their risks and vulnerabilities, but the rule does not say how frequently the SRA must be conducted. As far as best practices under HIPAA, ideally all providers would be doing SRAs on an annual basis. Medium and large sized organizations in particular should shoot for doing an SRA each year. For smaller providers, this may not always be possible, but they should still be doing an SRA at least once every two or three years while continuing to work on their risks identified in the most recent SRA during the off years.

When it comes to attesting to Meaningful Use; providers are required to conduct or review an SRA during each attestation period. Unfortunately, the Feds have issued no guidance on what would constitute a review so the strong recommendation is to simply do an SRA each year if the provider will be attesting to Meaningful Use.

Host:  So, we are shooting for annual reviews. What are some common findings when we go through an SRA?

Brad:  I would say that the lack of adequate written documentation, written policies and procedures is the most common SRA finding. As I said earlier, there are maybe 85 to 90 separate requirements found in the HIPAA Security Rule and you must have written policies and procedures that address each one. And of course, those policies must be periodically updated, whenever there is a significant change at the practice or when a law changes which it does do from time to time.

Encryption is another common finding. There are two types of electronic patient data; data at rest which is sitting on a machine or a device and data in motion which is flowing over an open network such as the internet. HIPAA requires you to use different tools to encrypt both types of data and some folks are simply failing to do so.

Lack of emergency preparedness or disaster recovery planning is another common finding. HIPAA requires you to sit down and determine what the most likely threats are to your patient data, then come up with written plans for how you would handle those situations. Anything from the power goes down for an hour or you temporarily lose access to the EHR all the way up to maybe a major storm hits and damages your building to the extent that you need to close down for an extended period of time. Your planning documents should lay out what would happen in each of those types of situations and who would do what.

Also issue with unattended workstations as HIPAA not only requires you to use and protect unique complex passwords, but also to install inactivity timeouts which log off or lock the workstation after a certain period of inactivity. This protects PHI that might otherwise be visible on an unattended workstation.

And then finally, mobile device management is a common security issue. One single device might contain both data at rest and data in transit so multiple encryption methods might need to be used for that one device. Also, two factor authentication should be used in case the device gets lost or stolen as well as having the ability to remotely wipe that device so any data on the lost or stolen device can be completely erased remotely.

Host:  So, that’s a pretty long list of common findings. What happens when I get all of these? How do I handle them and what use do I put them to now that I have all of this knowledge?

Brad:  That’s a great question. The SRA process really has two parts; the SRA itself culminating with a final report and as I mentioned earlier, that final report should contain a prioritized listing of your risks. And then the second part of the process is an action plan or a risk remediation plan which is an ongoing plan mapping out how you will fix or mitigate the risks identified in the SRA. If you are lucky enough to get a visit from a Federal HIPAA auditor down the road, they will want to see not only your most recent SRA, but also you risk mitigation plan showing the progress you have been making on the risks identified in that report.

And what we are talking about here is really a classic action plan for each risk that’s identified. There should be a name, and a target date associated with that risk. The person assigned to each risk doesn’t necessarily have to be the worker bee who will actually remediate the risk; but the person should at least have oversight responsibility for making sure the risk gets fixed eventually. The action plan should also be used to log the progress being made on your risks, who did what and when, including any policies, procedures or other documents that you may have created to mitigate that risk.

The SRA findings may result in having to write or update policies, procedures, workflows, also software might have to be updated such as encryption software, antivirus or operating system software. And finally, your SRA findings and whatever work you’ve done to mitigate the risks associated with those findings may require you to implement or tweak your HIPAA training and awareness program. Because it’s one thing to have good solid policies in place, but if you aren’t communicating those policies to your staff through periodic training; then from an auditor's standpoint, those policies don’t really exist.

Host:  I feel like we could talk about this process for much longer than the 10 minutes we have. But where can we send listeners to go for more information or assistance on Security Risk Assessments?

Brad:  For additional information you can visit www.metastar.com/podcast. That’s M-E-T-A-S-T-A-R.com/podcast.

Host:  That was attorney Brad Trudell, HIPAA Privacy and Security Lead at MetaStar. Thanks for checking out this episode of MetaStar Health IT Radio. And if you found this podcast helpful, help us out and share it on your social media channels. Also be sure to check out our entire podcast library for other topics that may interest you.