Granting Access: An EHR Security Risk? | Joe Marion | Healthcare Blogs Skip to content Skip to navigation

Granting Access: An EHR Security Risk?

June 1, 2009
| Reprints

I am currently working with a client to review an enterprise cardiology system implementation across a multi-facility IDN. The organization is in the midst of rolling out a new Cardiovascular Information System (CVIS) that was intended to address many of cardiology’s services within one system.

The system architecture involves a centralized database service, with individual sites feeding the database. The goal is for any authorized user to be able to view information across facilities for their patient. The dilemma? The applications were intended to include an ECG application in addition to Echosonography, Cardiac Catheterization, Nuclear Stress, etc. A result is that any individual with authorization can log on and access anything for that patient! So, an ECG technologist with sign on rights for ECG can access any of the Echo or Cath results as well!

A couple observations come to mind in terms of my assessment:

  1. 1. Is it necessary to include ECG in the same system as other, more complex exams?
  2. 2. Is this a CVIS application deficiency in that there should be the ability to have multiple levels of access authorization?
  3. 3. Is this a client-induced situation resulting from inadequate planning and implementation?

All of these circumstances could be valid, and it points out a key concern with enterprise-scale electronic records access – how to control access and avoid security risks? As interest in, and the rush to implement electronic records grows, so does the risk of a security breach.

How can enterprises reduce the risk of a security breach? Besides the usual implementation practices, I would argue that a key factor in controlling security is the initial planning that goes into defining the process and requirements.

If my client had taken the time to better examine and define requirements, perhaps it would have foreseen the potential security risk with ECG on the same system. By examining the workflow and understanding user’s access needs, it should have been a tenant of the implementation that ECG technicians do not need access to everything, and should be restricted from accessing other studies. This should have been addressed with the vendor to have secured agreement and guarantees that the system offered the ability to define multiple levels of rights authorization to avoid this situation.

In addition, up front planning may have addressed the wisdom of one system managing all cardiology data. In this situation, there is very little patient crossover, so the need for a common database was not well defined from the beginning. If there was minimal patient overlap between facilities, what is gained from having a single patient database? Might this have been better served by multiple applications feeding a common information repository? Acquiring applications would thereby be restricted in that users would only be able to access ECG’s. Back-end applications such as an EMR might have tighter restrictions on need to know, and could better control accessibility to multiple datasets from a common repository.

Does anyone else have an example of a security risk? It would be of interest to know how prevalent this practice might be. I can’t emphasize enough the importance of up-front planning to assure that user requirements were properly taken into account. Perhaps this situation could have been avoided with better planning. After all, “an ounce of prevention is worth a pound of cure!”




Good points! I like your point about minimizing damages vs. prevention. The industry needs more education, and perhaps an incentive to invest the effort on the front end. It is why I am also a fan of limiting all but essential access to the primary applications, implementing a common storage solution, and then restricting access with back end (EMR) applications. That way, people may be able to access, but they shuoldn't be able to change data.

Joe, you bring up a great point. In researching an article looking at the privacy and security aspects of the HITECH Act, I was amazed at a few things. One, that orgs are so focused on the money aspects (and of course, figuring out what meaningful use means) that security has taken a backseat.
And two, when hospitals do look at security in relation to HITECH, the focus is more on minimizing the damages of security breaches, and less on preventing them in the first place.
When you consider how much an org stands to lose from a security breach (from lawsuits, fines and negative PR), it's mind-boggling to think that prevention isn't more of a priority.

This makes me think of just how much clinical knowledge a CIO must have in order to understand proper data organization, repository structures and IT architecture. Perhaps the CIO had no idea of the nuances between the types of tests and data that are involved, and that's just talking about cardiology. CIOs need to know about ALL areas of the hospital, and that's just not realistic. This makes a strong case for having a CMIO in place who can help guide the CIO through the clinical data jungle.

does this make a case for having a privacy/security lawyer/expert involved with any new vendor contracts?

Interesting post, Joe. Very real world. We had similar problem with a vendor for an OB ultrasound system who had a security model that scaled well in a single office, but not across multiple imaging offices, sharing the same IT infrastructure. Eventually, we contractually forced the vendor to modify their security framework before we agreed to complete the final payment on a 30%-40%-30% pay-out structure. These situations exemplify the afterthought nature of HIT security infrastructure, both in terms of what vendors provide us, as well as our own awareness of what to assess, before we make purchasing and deployment decisions. Information Security is still not embedded in our culture. It's an add-on afterthought, like that farm house down the road from me growing up that was patchwork of new rooms and floors. In these situations, I a quick risk assessment and ask yourself, "What are the true risks (Risk Probability x Consequence) exposed by this scenario?" If the Risks are high enough to warrant concern, you have two basic choices: Change the vendor's system up-front, or audit the system very closely on the back-end.