A recent interview with Dan Berger, President and CEO, Redspin Inc.
Q. You mention that there is “more focus on the EHR in stage 2”?. What kinds of things do you think CMS is really looking for?
A. What I think has happened, in comparison to stage 1 where the onus was really basically on a provider using a certified EHR system in order to be even eligible for an incentive program, I think the onus has moved on to one step deeper in stage 2, and now there looking for, not so much that the EHR has certain types of functionality for privacy and security, but that you have actually implemented it and/or are actually using it. And if you aren’t, why not? So there is more of a focus on proactive proof positive as opposed to simply finding potential vulnerabilities or gaps. And I can give you a couple examples. For example, a certified EHR has certain things it has to have the capability of doing, like recording the encryption status of end user devices where PHI may have been sent. There are also a bunch of default settings, users should be able to produce an audit record that basically search and sorts on certain criteria, and then there is also a lot of specifications around access control and authentication. And so again, in Stage 2, I think CMS wants to see particular functionality types – are they enabled in your operation and implemented and can you prove that? And if they are disabled, what are you doing as a compensating control?
Q. Given the percentage of PHI breaches due to theft and loss of portable devices, encryption on end user devices really makes sense. Do you see full disk encryption ever being required in the data center?
A. Great question. In fact yesterday I was on a panel at Dreamforce and we were asked the same question. Whether it be in the data center or in the cloud, will full disk encryption or full encryption ever become a requirement. And I think the long and short answer for both is probably not. And the reason I say that is because something like full disk encryption puts a lot of overhead on the system and it’s expensive. It’s not so much the expense, it’s more the overhead. And when I say overhead what I am talking about is there some kind of end user difficulty in accessing the information, because more than most any other industry. accessibility and availability of PHI data is critically important. It’s very important people have that information available to them when they need it and encryption will just make it so much harder to use and it may interfere with a very important part of security which is when you talk about CIA of security (Confidentiality, Integrity, Availability) it may interfere with the availability side. So security always has to be a balancing act and a trade off between functionality and security. The other thing I would say in that area is that in terms of encryption, full disk encryption and cloud encryption, you really want to focus on what it is your trying to accomplish, what it is you are trying to prevent from happening. And most data centers are fairly locked down in terms of physical security and they do routine penetration testing, cloud providers, particularly the high end ones have 24 x 7 type security as well as even more frequent testing throughout the year. Here is the rub, even if you had full disk encryption one of the more likely vectors of attack are bad guys who hijack the ID of a legitimate user. And if they hijack the ID of a legitimate user and can log onto the system than the data they are going to get is going to come to them unencrypted anyway. So the encryption really didn’t do you any good. You know encryption keeps people out from accessing the data directly but if they’ve hijacked someone’s ID which is the more likely and more worrisome attack right now with all the phishing attacks and clicking on bad links and that kind of thing. So I don’t think it will ever come to pass. I do see a future where there is more and more PHI in the cloud and there may be some layer in between the two that enables you to have the best of both worlds.
Q. We did our security risk analysis internally for Stage 1 and we plan to use an external firm for Stage 2 but that might be for several months. Is there something we should be doing in the meantime?
A. Well what I would say is if you have done a security risk analysis internally, the thing to make sure you are doing in the meantime is that you are actually implementing any of the fixes or remediation that you found as a result of your first risk assessment effort. First and foremost, make sure that the results of the prior risk assessment, whatever that yielded in terms of action items, make sure that those are either done or are being done. That is one thing I know that CMS has been looking at very carefully in some of their recent audits that they have been doing. OK you did the risk assessment but did you do the 2nd part, did you actually implement the fixes? It is also always good practice in preparation for an audit or for your next risk assessment for you to make sure all your documentation is in order, up to date and easily accessible. A lot of times we find when we go on site to a hospital they might have all the documentation but it is all in different places and it is hard to pull it together in short order. And then lastly, being that Redspin is primarily a security company at it’s core we would recommend doing quarterly vulnerability assessments. The cost is not that great and it will give you additional protection as well as additional peace of mind.
Q. What about patient portals? Are these a big security risk?
A. Well, certainly they are. And in Stage 2 there is a greater requirement than in Stage 1. In Stage 1 to provide patient with access to their EHR in an electronic format, and in this case Stage 2 you got to do that through a patient portal. They’ve got to be able to go on line and download their protected health information. So what we really worry about, we don’t worry about the patient downloading the information because if the patient does that, effectively the patient is now in control and responsible for their own information. What we worry about is since that’s internet accessible, that can somebody break into the patient portal, you know a hacker can get in and get access to whole bunch of records. And so typically the patient portals come in a couple different flavors. There is patient portal capabilities in some EHR’s, some people even have customized or even develop their own patient portal. And effectively you need to look at the patient portal as any other web application and web applications have vulnerabilities and it is very important to have those tested. I really would not consider that you actually met the full force and flavor of the HIPAA security rule if you’ve got a patient portal that does not have an application security test.