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. Is it necessary to include ECG in the same system as other, more complex exams?
- 2. Is this a CVIS application deficiency in that there should be the ability to have multiple levels of access authorization?
- 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!”
