All good things eventually come to an end -- even contracts with your cloud PACS provider. When it does, you need to be prepared, according to Melissa Markey of law firm Hall, Render, Killian, Heath & Lyman.
Using the cloud for healthcare data requires navigating a host of privacy, security, regulatory, and contracting matters. And when it's time to end the relationship with your cloud services vendor, a transition plan is needed. That's especially true with PACS, Markey said.
"The one kind of [healthcare] data that scares me to death going to the cloud is PACS," Markey said. "If you've got your PACS data up in the cloud, that could take months and many multiples of months to migrate back to another provider. I start thinking about that and I get really scared."
Markey and Margaret Marchak of the University of Michigan Health System Legal Office spoke about how to manage issues related to risks and protections for healthcare data in the cloud during a session at the Healthcare Information and Management Systems Society (HIMSS) meeting in Las Vegas.
Benefits of the cloud
Cloud computing offers a number of benefits in healthcare applications, including lower initial costs, 24/7 support, speedy deployment, decreased capital requirements, scalability, security, and disaster recovery, according to Marchak. But the model also comes with its own risks.
These include a lack of control over data, security concerns, and reliability issues. It's also an immature field, and the financial and operational stability of vendors must be considered. Customers must also deal with the possibility of unrealistic expectations, integration with local applications, the geographic location of the data, and a potential lack of an exit strategy, Marchak said.
The cloud raises concerns over the confidentiality, integrity, and accessibility of data, which require consideration of technical, physical, and administrative aspects, according to Marchak.
Some cloud providers might not want to sign a business associate agreement (BAA) because they believe they function as a conduit, she said. According to the HIPAA Privacy Rule, a conduit "transports information but does not access it other than on a random or infrequent basis as necessary for the performance of the transportation service or as required by law."
"As we know from HIPAA, a conduit doesn't have to sign a business associate agreement because it's similar to the post office, just transporting the data," Marchak said.
BAAs require that the business associate notify the institution of any improper use or disclosure of healthcare data. Those self-protection measures are removed without a signed BAA, Marchak said. Clarification from the U.S. Office for Civil Rights (OCR) is expected this year as to whether the lack of a BAA with cloud computing providers is a viable option for users.
Even if regulators clarify that a cloud computing vendor is not a business associate and does not require a business associate agreement, it's still important to know if they've seen the data, said Markey.
"I'm going to suggest to you that you're going to deal with that issue in your base agreement with your vendor, whether or not you deal with it in your BAA," Markey said.
State law related to privacy and security must also be considered and addressed during contract negotiations, Marchak said. A security risk assessment is extremely important, and customers must decide how often it will be performed.
In developing a contract, any kind of healthcare data needs to be addressed by HIPAA and the Heath Information Technology for Economic and Clinical Health (HITECH) Act, the Gramm-Leach-Bliley Act, the Sarbanes-Oxley Act, the Payment Card Industry Data Security Standard (PCI DSS) if money is being collected, the Fair Credit Reporting Act, and the European Union (EU) Data Protection Directive, Marchak said.
Data breaches can result in government fines, lawsuits from state attorneys general, private lawsuits, reputational harm, and forced remediation costs, she said.
It's hard to tell sometimes where your data actually is in the cloud, and sometimes vendors can't even tell you where it is, Markey said.
"[This is] because some of the algorithms that vendors use for load balancing bounce data around among their various data centers," Markey said. "That means you may be dealing with international transfers of data, even when you don't know you're dealing with international transfers of data."
This can raise jurisdictional issues. In the European Union, the EU Data Protection Directive covers international transfers of private data and contract provisions. The India IT Privacy Law is applicable to data outsourcers, while in Mexico, the Mexico Privacy Law states that data are owned by the subject of the data.
"So it becomes very important to talk early on, as you're thinking about going to the cloud, with your potential vendors about where your data is," Markey said.
Request for proposal
A number of tools are available to help institutions assess whether or not a cloud vendor will meet certain security requirements, Marchak said. For example, the Department of Veterans Affairs (VA) recently issued a cloud services request for proposal (RFP) to determine whether the industry would recommend the use of cloud computing for four different scenarios: sharing protected health information (PHI) between VA physicians, sharing nonsensitive educational health information, use for email, and sharing PHI between the VA and the Department of Defense.
That RFP includes approximately 50 questions that institutions could find helpful in developing their own RFPs for cloud computing services, Marchak said.
The U.S. government's Federal Risk and Authorization Management Program (FedRAMP) has also provided a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.
"We'll see the government very actively engaged in setting standards," Marchak said.
Part 2 of AuntMinnie.com's coverage of Markey's and Marchak's talk will delve into vendor selection, contracting issues, and disaster recovery concerns.