David Barton, Principal UHY Advisors, discussed the new OCR Audit Protocols and explained appropriate application for risk assessment against the standards and safeguards of the HIPAA Security Act.
When: November 20, 2012 @ 2 P.M. ET
Who: David Barton, Principal UHY Advisors
What: Applying OCR Audit Standards to HIPAA Risk Assessments
Description: David Barton, Principal UHY Advisors, discussed the new OCR Audit Protocols and explained appropriate application for risk assessment against the standards and safeguards of the the HIPAA Security Act.
April: Hi, everyone. Thanks so much for joining us for today’s Tuesday at two webinar. We’re very pleased to welcome back David Barton. David is a principal and practice leader of the Technology Assurance and Advisory Services Group at UHY Advisors. David has had decades of experience in information systems and mitigating technology risks and auditing controls. He is here with us today to share his experience using the OCR audit guidelines as a means of performing a HIPAA risk assessment and to share with us some of the impact for the covered entities and business associates who are looking to use the OCR audit guidelines as they look to modify or inform their risk assessments for the upcoming year. David, welcome and thanks so much for joining us today.
David: Thanks very much, April. I do not have a whole lot of slides today because I’m hoping that this will be very interactive. If you have a question, there is a control panel with the webinar where you can ask a question. April will be able to read those questions and so will I. If you have a question, please type that question out, and I will do my best to answer it.
Just a little bit about how I got involved with the OCR Protocol. I do a lot of IT attestation and risk assessment type work for a lot of different clients and basically haven’t found – up until the OCR Protocol was introduced – any real good HIPAA-based risk assessment tool and stumbled the OCR Protocol as I was looking for a way to provide some structure around the HIPAA regulations and how to convert that into some type of an audit program. That particular protocol was put up, I guess, just about six months ago. Six to nine months ago is when I found it on the OCR website.
I’ve used it since then, and it’s become one of the tools in my tool kit for performing any kind of attestation against HIPAA regulations on healthcare related covered entities and business associates. Just to give you guys a little bit of background. The audit protocol itself basically was created to provide a way to analyze processes, controls, and policies, of covered entities pursuant to the HITECH Act audit mandate. Many of you know that HITECH was basically an add-on to the original HIPAA legislation that was passed in the late 90’s.
The HITECH Act is what actually gave the HIPAA regulations some teeth, as well as that also provided a means for the government to provide funding to certain healthcare organizations that wanted to implement electronic health record systems. In order to apply for the funds, you had to show meaningful use in terms of the system being used for electronic health records and basically in providing healthcare type services. So that’s what the HITECH Act was about.
The audit protocol itself is basically divided into three different elements: the privacy, the security, and the breach notification elements. Only a covered entity would truly be held to all three of these elements. Business associates, depending on the kind of work they do and how they’re involved with a covered entity, would be evaluated based on what they’re doing. A combination of all those requirements, again, they vary based on the type of covered entity selected for review or the type of business associate. That, like I said, is the basics of the protocol.
Actually, section 13411 of the HITECH Act requires Health and Human Services to periodically audit the compliance of HIPAA covered entities and their business associates with privacy, security, and breach notification rules. Basically, the OCR implemented a pilot program, which is currently ongoing, at least through the end of this year, and they have been in the process of performing 115 different compliance audits, all different sizes, shapes, and types of covered entities. There is a PowerPoint presentation out there on the Web that provides some of the early returns. I believe KPMG is the big floor firm that was selected to do the pilot program.
Once they conclude with the first round of the audits, KPMG will then evaluate the overall program, evaluate the protocol itself as to how good a job it does at identifying risks and weaknesses and so on, and then they will, I’m assuming, make some adjustments to the protocol. Then it will actually go into more widespread use. Again, in that PowerPoint that I viewed at some point, it shares the fact that business associates will not be actually formally audited by Health and Human Services until some later point, which they didn’t really define. Any questions at this point? As I said, please type your questions.
April: David, I was wondering if you could speak a little bit about some of the audits that have been used as a proxy in the past and maybe explain a little bit about why UHY chose to incorporate the OCR audit protocols as a new way of doing risk assessment for the healthcare industry.
David: Okay. Sure. April, there are a lot of options when it comes to providing some kind of third party attestation around security confidentiality and privacy. I think most of the folks who are listening today are probably going to be familiar with PCI, which is the Payment Card Industry standard. PCI is very prescriptive. It is very regimented in its approach to security and to the privacy of cardholder information, but it’s certainly not in alignment 100% with the HIPAA regulations. There are a lot of elements of HIPAA that are not covered by PCI, obviously.
NIST – the National Institute of Standards and Technology – is a government agency, and they have an information security protocol or framework that they distribute that has a lot of different elements to it. Again, it is primarily meant for information security. As we know, HIPAA has a lot of privacy considerations embedded in the regulations as far as how to maintain that privacy, what to do if that privacy is breached, etc. Other types of frameworks include the AICPA that has something known as SOC 2, which basically includes 5 different principles and criteria within those principles. That includes security, availability, processing integrity, confidentiality, and privacy, with privacy having its own completely unique set of criteria that an organization has to meet if that particular element is selected for third party attestation.
Again, the AICPA SOC 2 criteria are pretty high level. They are not prescriptive at all. They’re basically just a list of criteria – things like the entity should maintain a data classification process. It doesn’t explicitly describe how that data classification policy should work, what the procedures are around it, any of that. Again, high level and not very prescriptive. A lot of companies get requests, particularly now – it’s becoming the new de facto standard, I guess – a lot of healthcare agencies I know get requests for SSAE 16 reports, and there is a lot of confusion around why that would be applicable to healthcare organizations.
The short answer is it’s not, unless there is some financial relevance to the transactions being processed by the third party. If you’re a healthcare provider, there is certainly no reason for you to get or to produce an SSAE 16 report. If you are a third party administrator working for one of the providers or insurers, then it’s a different question because then at that point you are actually providing services that have an impact on the financial reporting controls of a given customer or organization.
Generally, none of those are specific to the HIPAA regulations and don’t really do a good job of addressing the specifics of the HIPAA regulations, which is why when our firm found the OCR protocol, we basically said, “Ah, great. The government has finally given us some kind of a framework to perform an audit or a third party attestation around HIPAA. Again, it’s specific to HIPAA, and it’s scaleable such that some of the elements apply only to the very large healthcare providers, and you can basically slice and dice it depending on whether you’re working for a true covered entity or whether you’re working for a business associate that has very specific services that they provide for a covered entity. So that was the primary reason that we decided to put the OCR protocol to use.
April: Thanks, David. What were the main differences that you found? Were there any surprised or differences in approach that your firm had to take to incorporate those audit guidelines into your risk assessments for healthcare organizations?
David: Not really. There weren’t really any surprises. Again, it was well organized and flowed very nicely and covered the different elements of the regulations. For the clients that we’ve used it for, it’s very easy to say, “Okay, this particular part of the protocol does not apply to this particular organization for whatever reason.” for example, the privacy aspect. If the business associate is a data center or a cloud provider of some type, generally through contractual arrangements, that cloud provider or data center is not responsible for the actual privacy of the information. In many cases, they don’t even have access to the information itself. They’re merely providing a safe haven, so to speak, for the physical portions of the system, the network infrastructure and the servers and disc drives and so on.
From a privacy standpoint, they really don’t have any impact on the privacy of the information. They don’t have any of the paper that flows through, and the transactions that are flowing through are completely under the control of the customer to that data center, the actual business associate or the covered entity that’s using those cloud or data center services.
April: So is this something that covered entities should expect to see from their business associate or for business associates who are trying to evaluate whether they will perform a risk assessment against the OCR audit protocols? What are the benefits, if any, to using that audit protocol to perform risk assessments if they’re not a provider themselves?
David: Okay. Good question. Looking at slide five that’s on the screen now, “Who will be audited?” basically OCR has said that any covered entity is subject to audit. Again, right now they’re in the midst of this pilot program for all these different audits. Once they get through that and once they’ve updated the protocol, then at any time a covered entity is subject to an audit. Obviously, if you’ve had breaches and you’ve had complaints filed against you, then more than likely you’re going to get audited, not unlike an audit by the IRS.
If you haven’t filed your returns and you have wildly fluctuating numbers on you returns from year to year, you’re more likely to be audited by the IRS. Likewise, the same thing applies for covered entities, business associates dealing with HIPAA compliance. Again, the business associates, they haven’t really said when they’re going to start reviewing those, but here’s the deal: If you are a covered entity and you have business associates that you rely on and contractually you have attempted to cause them to comply with the HIPAA regulations and that’s part of your contractual arrangement, obviously you would like to have some kind of third party attestation around their ability to do that, to comply with the HIPAA regulations.
The scoping becomes the real key to all of that. That’s where, again, the OCR protocol is great because it’s broken up into the sections – the privacy, the security, and the breach notification sections. Using those three, you can kind of trim down a scope to something that’s manageable. A SOC 2 audit is okay because you can cover confidentiality and privacy in a SOC 2. Again, it doesn’t line up one for one with the HIPAA regulations, and there’s a lot of gray area. However, if you use the OCR protocol and you say, “Okay, I’m going to evaluate this business associate based on the OCR protocol for security,” because that’s really all that they impact, you’ve got a really good idea that they are either going to be able to comply with the regulations or there are holes. Those holes will be evident because the testing that’s done in order to basically provide evidence of compliance is not going to be there.
April: That’s great. Thanks, David. You mentioned that there is some overlap, but it’s not complete between the SOC 2 and the OCR audit protocols. I’ve spoken with some healthcare CIO’s who have requested documentation for an SSAE 16 or even the old SAS 70 reports. Is there any overlap or hope that an SSAE 16 report would have a close approximation to the OCR audit protocols, or are they pretty far off?
David: Well, here’s the dirty little secret about SSAE 16 and its predecessor, SAS 70. A lot of people are under the misconception that SAS 70 and SSAE 16 have some sort of criteria, that there is some pre-defined standard that you have to meet in order to pass one of those audits. The dirty little secret is there is no criteria. When you begin the process of an SSAE 16 audit, the controls that will be tested is a blank sheet of paper, and the controls to be tested are determined not by the auditor, not by some organizational consortium. It is determined by the entity being audited. If you’ve got a business associate that says, “Hey, we’re SSAE 16 certified,” you need to be very careful and, first of all, you need to read the report and understand what is in it because it probably doesn’t cover everything that you want it to from a HIPAA standpoint. Again, the service organization determines what will be tested. The SSAE 16 report was never intended to provide any assurance around security, confidentiality, privacy, any of the elements that are part and parcel to the HIPAA compliance requirements.
April: Wow. So that’s kind of like getting to write your own final exam. I can see why the SSAE 16 has been more appealing than some of the other audits. The OCR audit protocol, is that a more consistent criteria? Can organizations count on that being meaningful?
David: Absolutely because it was developed jointly by the Office of Civil Rights in conjunction with Health and Human Services as it pertains to the HIPAA privacy and security and breach notification requirements. I mean it is very specific to meeting the HIPAA criteria.
April: Great. So what else are other people in the industry using? Is everyone using the OCR audit protocol at this point, David, or this because it’s a little bit newer? Maybe there are some other audits like NIST or SOC 2 that organizations are falling back on.
David: Well, there are a couple of others that I am aware of. There is an organization called URAC, which has a framework for HIPAA compliance. There is also an organization called HITRUST, which the next slide basically gives an introduction of. HITRUST is the Health Information Trust Alliance. The overall goal of HITRUST is to ensure that information security becomes a core pillar of, rather than an obstacle for the broad adoption of health information systems and exchanges. The cornerstone of HITRUST is the common security framework. The common security framework from HITRUST is based on a combination of HIPAA, ISO, which most are familiar with ISO 27001, the PCI type requirements from a security standpoint, the NIST security framework, and the Information Systems Audit Control Association COBIT, which is the control objectives for IT, which, again, is very high level.
That common security framework is something that, again, is directed specifically to HIPAA, directed specifically to healthcare organizations, both providers and business associates. Target clients for HITRUST membership and certification – it truly is a certification – the large healthcare insurers, large hospital networks, and the large third party administrators. Basically, HITRUST was formed by a lot of the large providers and insurers. For example, I know that United Healthcare is one of the members. McKesson is also one of the members. A couple of very large hospital networks throughout the country are also a part of the group that founded HITRUST.
The interesting thing about HITRUST is that they have gone so far – similar to PCI – as to say, “We’re going to maintain a list of qualified assessors. In other words, in order to become an assessor for HITRUST, you have to go to their training and sit through their classroom instruction and then basically pass a certification exam in order to be able to do these assessments. Right now there are only about 15 professional service organizations that are HITRUST qualified assessors. With the combination of the fact that (A) it was an industry consortium that developed it, (B) the common security framework was built specifically for HIPAA compliance, and (C) that they’ve got this pre-qualified list of assessor organizations, you can be pretty confident that the report that you’re going to get at the end of the certification you will receive is going to get you to a point where you could easily pass any kind of a HIPAA HHC type audit.
April: Great. It’s good to know the industry is hopefully coming up with some more un-ambiguous standards and some certifying entities that hopefully will give some reassurance and some type of consistent form of measurement. So what is the primary difference between HITECH and the OCR audit? Heaven forbid the unthinkable happens and the data breach occurs. Which would an organization hope to produce in terms of satisfying the requirements to the Office of Civil Rights?
David: The differences between HITRUST and OCR, first and foremost, OCR is a government agency, so it’s kind of like the IRS. Nobody wants to be audited by the IRS because that’s your worst nightmare. In the financial services industry, you have multiple regulatory bodies – the FDIC and the FFIEC and so on and so forth. All those regulations have to be complied with. If you are unlucky enough to be selected or highlighted for an FFIEC review, the range of assessors can be as different as the number of people living in the United States in terms of their knowledge, their background, their experience, and so on. Some of them are very hard-nosed. Others are more interested in making sure that the spirit of the law is complied with, rather than the letter of the law. Others are just the opposite. They want to find every little thing that you could possibly have done wrong.
From an OCR standpoint, I’ve got a feeling it’s going to be a little bit like that because there is no specific government agency that has said this is the group that’s going to be doing these types of reviews. They haven’t even really firmly established what the audit protocol is going to look like. We have it now. It will definitely go through some changes as a result of this KPMG pilot program. Hopefully the quality will be a little bit better now that you’ve got a big floor that’s actually gone through over a hundred actual audits and can improve both the quality and the reporting aspects of the audit.
HITRUST is fairly well established. Again, it’s more of a self-regulatory kind of approach, much like the payment card industry went through. PCI is not a government standard. PCI has nothing to do with FDIC, FFIEC, or any of the new Dodd-Frank regulations that are coming down the pipe. It was, again, a reaction to common problems throughout the industry in the payment card industry and they said, “We have to get our arms around this before the government comes in and tries to tell us how to do things,” and in their impotent wisdom, do things perhaps not so well.
So that’s really the key difference. HITRUST, being developed by an industry consortium, is very security focused. It is focused on maintaining all the requirements of HIPAA but also getting the processes and the people and the technology all to work together in order to make that happen. The OCR, on the other hand, is a government-mandated program much like the FFIEC IT qualifications are that are out there on the Web.
April: Okay. That helps. We did have a question here, David. Does performing an audit using the OCR audit framework satisfy the HIPAA requirement to perform a risk assessment? Can people feel pretty good about following that protocol that they’ve met the foundational requirement?
David: Yes. If you independently have a third party come in and do a review using the OCR audit protocol, that would satisfy the risk assessment requirement at least for whatever timeframe you’re looking at. It’s always a good idea to have a risk assessment process in place at any organization. PCI requires it. The NIST and several other protocols also require it. It is built into the SOC 2 trust services principles and criteria. A risk assessment is not a one time and done kind of a thing. It should be an ongoing process that you have implemented within your organization to stay on top of new developments, new technologies, anything that can impact the successful processing of transactions in business.
April: We have a follow-up question to that question. Can a covered entity – or maybe we can even expand that to business associates as well – but can a covered entity do their own risk assessment using the OCR protocol?
David: There is absolutely no reason why they couldn’t. Again, using the protocol as a guideline for your risk assessment and say, “These are the areas that I have to cover in my risk assessment,” is a great way to do it. Obviously, third party attestation is useful when you are trying to provide evidence to stakeholders and your business partners and other people that have an interest in an independent assessment. If you are merely trying to seriously get your arms around where are we in terms of our own ability to meet the requirements of HIPAA and other confidentiality and privacy regulations, it’s a great framework to use. It’s not difficult.
April: Great. Thanks, David. We do have a few more minutes here for those of you who may have any last questions. We’ll also be sure to share David’s contact info. David, I have another question for you. What’s your recommendation to business associates in terms of when they should consider assessing their healthcare – the risk to PHI that they may come into contact with the OCR protocol? Do you think it’s mature enough that it makes sense for business associates to consider that today, or do you recommend that they wait and see how it evolves over the next year?
David: That’s really a business decision, and there are a lot of aspects to it. A lot of organizations want to get out in front of this. They want to do whatever they can to create a competitive advantage. By being able to publicize the fact that, “Yes, we’ve already gone through an independent third party attestation of our ability to comply with these HIPAA regulations as it applies to us and the services that we provide,” again, you have to scope the reporting of that correctly. Obviously, if you’re looking at three different potential providers, and one of the three has already gone through third party attestation and offers you up a report that says, “Yes, here’s how we were able to comply with all of these regulatory requirements,” obviously, you’re already well ahead of the game at that point, as compared to the other two who have not gone through that process yet.
Again, business decision. What kind of customers are you trying to attract? The larger customers, the ones who are publicly traded, obviously there is a lot of push from their auditors to have as much information about the third party service providers as possible. Many of them will ask for an SSAE 16, even though that is not the right answer. In terms of the AICPA standards for performing a financial statement audit, there are a number of ways for that auditor to get an understanding of the control environment at a given service organization, one of which is an SSAE 16 report. Again, I think in terms of if we’re talking about a healthcare organization that is concerned about HIPAA compliance first and foremost, the OCR protocol and/or the HITRUST certification would be the way to go.
April: So for providers, is there any reason why they would wait to begin incorporating the OCR audit protocols in their risk assessment frameworks?
David: I cannot think of a single reason why a covered entity would not go ahead and get familiar with the OCR protocol and begin using it either themselves or requesting that their more important business associates also provide some evidence of their ability to comply with those requirements.
April: Super. Thanks, David. One of our guests is sharing with us a note that business associates were required to be compliant with HIPAA since 2009, and the Attorney General is able to hold them accountable, which I guess goes back to your point, David, that we have not yet seen a business associate that has been audited by the Office of Civil Rights. It seems like if the breaches continue, especially with a high involvement of business associates, that it’s probably only a matter of time before we see that happen.
David: Absolutely. State by state, we may see more stringent regulations on a state-by-state basis. They may get ahead of the curve in terms of enforcement. At a federal level at least, the plan right now is for this pilot program to finish up in December of this year, and they will make some adjustments to the protocol itself, and then they will begin in earnest performing audits of, first and foremost, the covered entities and then eventually business associates.
In terms of compliance, the comment that came from the audience is correct. A business associate is required to comply with all aspects of HIPAA where it applies. Just because you’re a business associate and you may have a business associate agreement with a covered entity, it doesn’t mean that you can ignore the security and privacy requirements of the legislation. If you do, you’re simply asking for fines and retribution from customers and the federal government.
April: Well, thanks, David. That’s been really helpful to understand how the OCR audit protocols might be used today and the differences between that and HITRUST and some of the other audit standards of the past. Thanks, everyone, for sharing your thoughts and questions with us. We will be posting a recording of this webinar. If anyone else has any questions, please feel free to contact us or David. David, did you have any last thoughts to share with us?
David: Yeah, just one. Basically, the OCR protocol you can do a Google search for OCR HIPAA audit protocol and you can find the actual protocol itself on a couple of different government websites. It’s downloadable, I believe in and Excel format, so it’s relatively easy to get a hold of and review and begin using either within your own organization or as a means for some kind of a third party assessment or risk assessment.
April: Super. Thanks so much, David. Really appreciate your time and expertise, and I know we’ll be following up with you soon.
David: All right. Thanks much.
April: Have a great day. Have a great holiday. Bye.
David is a Principal and is the practice leader of the Technology Assurance and Advisory Services group at UHY Advisors, Inc. in Atlanta, GA. He is Certified in Risk and Information Systems Controls (CRISC) and received his Certified Information Systems Auditor (CISA) designation in 1988.
With over 25 years practical experience in information systems and technology risk and controls, he is an expert in identifying and reducing information technology risk throughout an organization.
Read David Barton's guest blog post on the Online Tech blog, "SOCs and SASs: The New Standards for Service Organization Controls Reporting."