The number of cloud analytics vendors is increasing, as demand for scalable and affordable systems for crunching clinical data grows among providers who are looking to put the vast amounts of information they are accumulating to work. Security professionals, however, say health care organizations need to take some precautions to ensure their move to a cloud analytics system doesn't create security vulnerabilities.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Public clouds offer a number of advantages over locally hosted systems. They can reduce the cost and technical burden of adding server space, and make it relatively quick and easy for organizations to stand up complex systems. This is particularly advantageous in analytics systems, which require a significant amount of computing power. However, the vast amounts of data going back and forth between a health care organization and its cloud analytics vendor can create a number of points of vulnerability.
Jason Buskirk, chief operating officer and co-founder of health-care business intelligence company Health Care DataWorks, Inc., said trust is the most important consideration. A technology vendor may put in place all the technical safeguards it wants, but if the health care provider doesn't have faith that the vendor will continue to staunchly protect the data going back and forth, it may want to find another vendor. "If I didn't feel comfortable with my partner, I probably wouldn't do business with them," he said.
Build trust -- and encryption -- into cloud analytics vendor contracts
Once that trust is established, providers can direct their attention to deeper considerations. Buskirk said health care organizations partnering with cloud analytics vendors should be sure that data is being encrypted at all stages of the process. This applies to data in motion and at rest. He also advises practices to conduct periodic audits to ensure the vendor is following through on data security protocols.
Jason BuskirkCOO and co-founder, Health Care DataWorks
Still, public cloud analytics vendors might not be right for all providers. Chris Carmody, vice president of the information services division at the University of Pittsburgh Medical Center (UPMC), said his organization has opted to set up its own private cloud to store data and access analytics functions, in part due to security concerns. The medical center has thought about looking at public cloud vendors, he said, but right now the approach doesn't offer substantial advantages over the center operating its own private cloud.
"With a private cloud, you have more control, more say, more flexibility in delivering the computing and storage needs of all our user base," Carmody said. "Security is at the forefront of any decision we make."
Carmody did acknowledge that public clouds offer some advantages. In particular, they are less resource-intensive to configure and get up and running. This is mostly important for smaller hospitals that have small IT staffs.
UPMC will inevitably join a public cloud too, Carmody said. The primary reason is that public clouds offer more storage space than an individual group could acquire. The growing practice of analyzing genomic data, for example, will place a premium on storage space.
Carmody said the data from a complete genome of a single person takes up about 1.7 terabytes of storage. This means UPMC currently has enough storage space throughout its entire organization to maintain the genomic data of about 2,400 to 2,500 patients, just a fraction of the center's 7 million patients. The increasing use of genomic data could push UPMC into a public cloud within the next five years, he said.
Consider storage and data breaches in march toward cloud analytics
If the movement toward cloud analytics systems seems inexorable, there are some ways providers can wall themselves off from risk. To be in compliance with the Health Insurance Portability and Affordability Act, or HIPAA, third-party vendors must sign a business associate agreement with providers. Lynne Dunbrack, an analyst at IDC Health Insights, said organizations can ask that an indemnification clause be included as one of the terms of this agreement. Such a clause would shift all responsibility and accountability for a data breach to the vendor.
However, before providers start thinking that all they have to do is get an indemnification clause in their business associate agreement and all their cloud analytic security concerns will be set, they should know that these clauses are very rare. The health care industry as a whole has spent about $4.2 billion since 2009 making amends for data breaches, Dunbrack said. This works out to about $200 per record lost. That is a heavy financial risk for cloud analytics vendors to take on, and they are going to do whatever they can to avoid it. "That's why cloud vendors are reticent about indemnifying," she said.
But that doesn't mean health care organizations have to choose between accepting the risks that might come with public cloud analytics systems or setting up their own private cloud.
Most providers currently have third-party vendors set up their own private clouds, Dunbrack said. This scenario combines the advantages associated with public clouds, including scalability and rapid setup time, and the higher security standards that come from private and locally hosted systems. In this arrangement, the vendor dedicates server space to a single provider. That setup eliminates multi-tenancy and data mingling, which are possible security risks, she said.
Because of the time and technical resources demanded by locally hosted analytics systems, the trend to cloud analytics systems isn't likely to abate any time soon, particularly among smaller providers. Understanding the risks that could come with such a system and knowing how to mitigate them will be key for providers looking to ensure the success of their analytics initiatives.
Develop a health care encryption plan
Find out what a medical center learned after a data breach