EHR Risk Management Tips for Physicians
In an interview, Daniel advises practices to "bake in" security technologies and practices from the start of an EHR implementation. He advises practices to ask records software companies tough questions about privacy and security issues, including:
Is the software HIPAA compliant? How does the company handle offering remote support, and does the approach fit the practice's security model? How does the company test for new vulnerabilities, and does it issue patches regularly? Will the company provide copies of past security audits? What type of encryption does the EHR software support?
Daniel is project lead for security services at Concordant, an IT consulting firm based in North Chelmsford, Mass., that specializes in advising physician group practices.
HOWARD ANDERSON: This is Howard Anderson, managing editor at Information Security Media Group. We're talking today with Jack Daniel, project lead for security services at Concordant. Jack will be providing some information security insights for physician group practices that are implementing their first electronic health record systems. Thanks for joining us today, Jack.
JACK DANIEL: Well, thank you for having me, Howard.
ANDERSON: Group practices across the country are preparing to implement EHRs and hoping to receive federal financial incentives under the HITECH Act to help pay some of the costs. As physician groups shop for an EHR system, what specific questions should they ask software vendors about privacy and security issues? And should those questions be different, depending on whether the practice plans to host its own system, or access it remotely via cloud computing?
DANIEL: I would definitely start out with asking if the vendor is HIPAA compliant, and also if the product is compliant....So, if I have other security technologies I need to implement, will the EHR software align with those....And if the vendor can't provide you with proof of their compliance, would they be open to a third-party assessment?
A lot of these companies don't want you coming in digging into their own products. But an option that is on the table is to assess them yourself, with your own information, security procedures and guidance.
Also, I would ask them about remote support mechanisms: How do they come into your environment to support your product if there is a problem? A lot of times, the vendors themselves will actually dictate the standards that they use. And this is actually something important to understand when you are going through this process, because if those mechanisms that they are using to gain remote access into your infrastructure and environment don't fit your security model or your regulatory drivers, then that's not going to work.
Also, ask about the threat and vulnerability management that the platforms use. How do they monitor and test for new vulnerabilities or problems with the system itself, and how do patches get derived from that, and when are they released? Are they released regularly, or is it more reactive later down the road, say, a few months, which could definitely cause some problems that would need to be mitigated within your own environment?
And also, I would ask for customer references when it comes to security, past security audits, vulnerability scans, things of that nature, as well as types of encryption the product supports. Obviously, encryption is a big theme here, and it definitely plays into the safe harbor under HITECH....
Now, obviously, the questions would be fairly similar for a hosted or cloud computing environment with a few additions. Obviously, the compliance and regulatory drivers are still a major concern there. And also you're concerned about the security of the data center...and so you're going to ask for different things that would be in place.....Also, at that point you would be concerned about the recoverability, back up procedures that take place in the data center for your environment, to make sure that you can continue supporting your client base.
A major concern with the hosted model is to make sure that you have dedicated space in the hosted environment. A lot of times, environments are shared. And obviously, if environments are shared, that means information isn't necessarily siloed, and you're relying on lower-level access control mechanisms. So at that point you would definitely want your own dedicated space, so that the space could be controlled and secured adequately, to meet your regulatory and security needs.
Also, you would want to see any audit or vulnerability scan reports that they have had done at the data center on their infrastructure, as well as the product itself, specific to your environment. And if they can't provide you any types of audit reports or past security assessments, at that point, you're going to want to have a third-party assessment done on the product, or conduct one yourself. At that point, you're going to be looking at general information security controls in place, how their coding practices work, network security, all of the policies and procedures that surround their change management process, training, things of that nature.
ANDERSON: For those who aren't familiar with it, could you please briefly describe how encryption works, and then talk a bit about what the HITECH safe harbor means to group practices. Should all group practices implementing EHRs use encryption?
DANIEL: Encryption is the process by which information is transformed using an algorithm. So, we take plain text and then apply a cipher to it, which is the algorithm, which makes it unreadable to anybody without the key. So, essentially, you're making the information unusable to anybody that doesn't have the key to use that code.
The algorithms themselves are very complex, and they wouldn't be able to be computed by a human, or in most cases, by technology within a reasonable amount of time. The safe harbor in the HITECH Act excludes organizations from having to notify patients, HHS, and the media if protected health information is breached....if the information was rendered unusable, unreadable, indecipherable.... So, the encryption that you use has to be in accordance with the NIST Special Publication 800, 111, if it is at rest and FIPS 140-2 if it is in transit.... The NIST guidance really helps, by laying out scoping practices and project management practices around the implementation, and what things to look for when you're shopping for products. The FIPS, or Federal Information Processing Standards, are more granular, in really telling you what you have to do, in accordance with different rules and regulations for different points, when you are shopping for products.
The key management of the system is really paramount. If encrypted data was breached and it did fall into the wrong hands, if the key was with it, then at that point, you would have to report the breach and notify the proper authorities. So, if it is breached, you must be able to prove that the key was not compromised, because if the key was compromised, then you would have to assume that the information was readable and decipherable.
And also, the provisions under the safe harbor also discuss media destruction. In order to make sure that it is destroyed in accordance with the safe harbor, you've got to make sure that none of this information can be reconstructed, whether it is on paper or on digital media. On paper, you would have to make sure that it was shredded...where you couldn't read any of it. And, on magnetic media, you would have to do that in accordance with NIST standards, as well, by shredding the magnetic media, or by overwriting media multiple times.
I think it's vital that all practices really do implement encryption. And more so than that, it is really necessary to limit the amount of data you store. The less you store, the less you have to worry about securing. So, only store what fields and what information is absolutely necessary. Encryption, however, is definitely something that all practices should use and implement, and really come up with a strategy that works for them, that aligns with their business model.
DANIEL: Please describe how two-factor authentication works, and should physician groups consider using it?
ANDERSON: Two-factor authentication is using two things to actually authenticate someone to use a system. There are three types of categories. There's something you know, which would be a PIN or a password; something that you have, a token or a smart card or certificate; and then also, something you are. So, typically, biometrics are used in this case, such as a retina scan, a fingerprint scan.
Two-factor authentication would be a combination of two of those items. This is something that has been going on in the banking world for a number of years. And actually, there are a lot of common misnomers out there about two-factor authentication, or multi-factor authentication. A lot of banks, in initially trying to implement these types of technologies, found that it was very hard to implement, and not cost-effective, because it's hard to push...authentication out to someone at a cost-effective level.
I would recommend, at any point in time, if a practice is going to implement a security technology, that they bake it in from the beginning. It's always going to be more cost-effective and it's going to align with the business, as well as the technologies the business chooses to use, if they discover that up front, when they are determining the requirements around what they are trying to do.
You know, it's really a common occurrence in health care IT security that security becomes an afterthought to operational concerns: Let's get this product up and let's get it running, and then let's worry about how to secure it. And then, when a lot of companies and organizations try to do this, they realize that it is a lot more difficult at that point, and there are a lot more moving parts and pieces that they are concerned with, and they really have to figure out how to integrate these two technologies, the security technology and the EHR system seamlessly, and it becomes a lot more difficult at that point.... I think it is absolutely necessary that if clinicians have to access that information remotely, from home or from another office, that they use two-factor authentication.
ANDERSON: What other security technologies and strategies should group practices consider as they implement electronic health records?
DANIEL: Some key ones...are technologies that can identify where the information is, and give them vision into their security posture. So, we're talking about things like data loss prevention, that tells you where all that electronic health information is. Typically, practices like to think that it's all in a specific place, but sometimes information ends up on a file share somewhere, or a USB key or on a desktop in a spreadsheet. It's very important to understand where that information is. If you don't understand where it is, or how it's used, then you're not going to be able to truly secure it.
Also, technologies like vulnerability and threat management are important. If the EHR system is available from the Internet or from the public-facing world, then it is going to be critical to understand what that perimeter looks like, in terms of vulnerabilities and what types of threats are actually out there that could harm that system.....So, the goal here is to log practically all pertinent events that would take place at the perimeter: Who is accessing information, what are they doing with the information, who is amending the information, and...what are administrators doing on the system. This can really provide different types of controls in a lot of different scenarios....
It's going to be critical if a breach does take place, that...you can go back and figure out exactly what happened, so you can prevent that from happening in the future.
There is something along the terms of encryption that a lot of practices and organizations in general don't think about, and that is the encryption of mobile devices. Encryption of mobile devices is absolutely critical: cell phones, PDAs, netbooks, things like that. Those devices really have a lot of exposure, and sometimes they kind of fly under the radar. Someone, a clinician or even an administrative employee, may try to access some of this information from their phone, because they get a link in an e-mail, and they're just trying to look something up quickly. Well, now that information could be stored in the memory on the phone, or it could be cached in a browser....
Removable media, like external hard drives, and thumb drives, go missing quite frequently. It's not always with malicious intent, but they are small items, and they get lost. If those devices aren't encrypted, then there's huge capability for loss and reputation damage.
Also, governance is absolutely important in all organizations, really making sure that security has the highest buy-in in the organization, whether it be at a board level, or a presidential level within the organization. Only then will security be taken seriously....
ANDERSON: How often should a practice conduct a risk assessment? And how should it be conducted?
DANIEL: There are two different risk assessments that should really occur at a practice level: An in-house life cycle or an ecosystem approach to risk assessments, as well as a third-party approach, where you have an objective party come in.
For an in-house assessment, at a practice that has less technology and less data, this process would be a lot quicker and happen less frequently. But, in-house, I would say a minimum of once a year. What I would recommend is that organizations break up the tasks of their risk assessments quarterly, or monthly, depending on what works best for the organization. That way, they are constantly looking at the security, the risks, and the threats that are posed to the organization, and really evolving that program. Also, whenever major changes or upgrades occur, or adoptions of new technologies and services, you should update the assessment.
I would definitely recommend having a third- party annual review of all of the security and controls that are in place . This really gives you an objective view....
Risk assessments should definitely be conducted in accordance with some sort of best practice framework that is adopted by the organization, such as the National Institute for Standards and Technology. I really think that it's important that organizations adopt a security framework that they can live by. These frameworks provide a full spectrum of security controls and risks that apply to the organization.
So, once you have this comprehensive framework in front of you, it's a lot easier to map to what you have in your environment, and truly understand the risks that exist....
Then you can start creating an actionable plan... for how the business is planning to use technology. Once you've...really quantified security gaps or weaknesses, you can recommend or implement the correct and appropriate technologies.
ANDERSON: Well, thanks, Jack. We've been talking today with Jack Daniel of Concordant. This is Howard Anderson of Information Security Media Group.