Over the past year, iPads have become standard equipment for care providers in hospitals and medical offices, making these devices nearly as ubiquitous as the stethoscopes draped around their necks. The use of mobile devices by patients for their own care has also grown just as quickly, with patient portals allowing them to schedule appointments, view lab results, ask follow-up questions they forgot to ask during appointments and more – all from their tablet or even their phone (if they squint hard enough to read it on such a small screen).
With so many care providers using mobile devices at the point of care and with so many patients using the web for aspects of their medical care, there are an awful lot of mobile devices floating around that have access to confidential patient information.
That's a recipe for disaster.
The portability of these devices and the frequency with which they are misplaced, stolen or breached is a security nightmare for healthcare organizations. Each of these incidents ends up being an embarrassing news story at best. At worst, they lead to large fines and lawsuits. Organizations have tried a number of protocols aimed at reducing human error that leads to the loss of these devices, but people are people, and they'll always forget where they set something down. The real solution is in having a technology strategy that protects the data regardless of whose hands these devices fall into, and encryption is a critical part of that solution.
The challenge lies in creating an encryption strategy that won’t add to your IT team’s already heavy workload. And that's possible. No need to add a half-dozen or more action items to your IT department’s to-do list, which no doubt is already a mile long. It’s not magic. There’s no fairy dust involved.
While proving their value, mHealth devices and applications cause stress for health IT teams because of these security issues and the HIPAA non-compliance threat they pose. This was a major topic for discussion at the recent mHealth Summit, where the dialogue centered on the attention that this security issue is now getting from government agencies and industry associations. The healthcare industry is currently working on HIPAA compliance recommendations for mobile devices, which would be enforced by the Office for Civil Rights. And the FCC has created an mHealth Task Force, composed of mobile healthcare IT industry executives, federal and academic experts.
Preliminary recommendations are not technical in nature but instead focused on collaboration and outreach. The FDA is also entering the mHealth space as an enforcing authority. As mobile devices become tools to monitor, report or suggest actions based on a patient’s health, they become subject to FDA regulation like other medical devices. That’s a lot of brainpower devoted to the issue of mobile device security, and it’s a clear sign of how urgent this issue is.
For a scenario like this, encryption is the natural answer because it ensures the security of the data regardless of whether the device is lost or whether the app lives in the cloud. Encryption not only prevents security breaches, but also mitigates risk in the event of a security breach by reducing or eliminating fines, loss of credibility and a whirlwind of other negatives. As an example, if lost/breached healthcare data has been encrypted and the keys remain safe, the responsible organization is not required to report the incident publicly. Think of it as an inoculation against the common data breach.
Encryption is not easy, though. An effective encryption strategy requires a defense-in-depth approach, which may include:
- Encryption in transit via Mobile VPN (Virtual Private Network) and/or Secure Socket Layer (SSL) certificates to create a private, secured tunnel for internet traffic to flow through;
- Encryption at rest in the primary data storage environment;
- Encryption in backup in disaster recovery environments;
- Encryption within the applications themselves;
- Encryption within the database.
Achieving each of these is costly, technically challenging and prone to human error. And that’s just talking about doing it in a traditional corporate data center. The difficulty is a magnitude bigger in a cloud environment with the addition of virtual management layers. Nonetheless, many mHealth applications are built to leverage the cloud, not only for technology reasons but also simply for controlling costs. That is a double whammy for mHealth security, since the cloud has never been synonymous with security and mobile devices are so prone to growing legs, wandering off and getting lost.
Why is encryption even harder to do in the cloud? To answer that, let’s talk about how it’s done in a traditional corporate data center. It’s an approach I refer to as “bolting it on.” Bolted-on encryption involves buying and installing third-party encryption solutions in the data center as a layer that resided between confidential data and unauthorized users. Those devices and the implementations can literally cost hundreds of thousands of dollars, depending on the scope of the project. So the hard costs are really high, and that’s not counting the soft costs involved in ongoing maintenance and time-consuming, error-prone manual management of encryption keys. Encryption is great protection, but many don’t realize that if the keys are lost or corrupted, all data is lost. If the keys are compromised, all data is accessible by the wrong hands. Those are considerable downsides for encryption in a corporate datacenter environment, but they get magnified in a cloud environment — which is where so many mHealth apps live.
Encryption in the cloud is harder because it’s tricky to bolt an encryption solution onto the amorphous server structure of a cloud environment. The “bolted on” model simply isn’t practical in the cloud, so most organizations haven’t done it. Research by firms like the Ponemon Institute has shown that few healthcare companies have adequately deployed encryption in their cloud environments. That’s a whole lot of non-compliance, and pressure will no doubt build to correct that, especially if OCR keeps the promise that director Leon Rodriguez made to look “behind the patient counter” into the IT infrastructure that supports patient record systems.
It doesn’t need to be a painful process for healthcare companies, though. For too long, data center services providers have not shared the burden of their healthcare clients’ regulatory requirements. They have tried to do the bare minimum and sell healthcare companies the same basic service they provide to unregulated companies that sell widgets. But it’s time for healthcare companies to stop taking no for an answer.
An upcoming change in regulations will certainly help. The final Omnibus rules have clearly stated that cloud providers are considered business associates, and business associates will be held accountable for protecting ePHI. That shared responsibility will not only be a major motivator for healthcare companies to schedule serious chats with their cloud providers; it will also be a major motivator for cloud companies to solve this encryption challenge for their clients. If they don’t, they will share liability for non-compliance or lose a lucrative client, or both. Cloud providers need to have skin in the game, and these regulatory changes along with more forceful requests from healthcare companies will do exactly that.
So how does a cloud provider address the encryption requirements of HIPAA?
To support the security needs of mHealth applications that leverage the cloud, providers need to create “built-in encryption” that better supports the needs of healthcare clients. This approach needs to build encryption into the fundamental architecture of the cloud, such as within the SAN itself, to enable encryption at rest while also eliminating performance bottlenecks. This automatically ensures that data is encrypted when written to drives and decrypted when read from drives. This type of back-end encryption ensures there is no risk of stored data exposure when drives are removed or arrays are replaced. This model also eliminates the time-consuming and human error-prone process of manual key management. Done correctly, this can also effectively accomplish appropriate separation of responsibilities to eliminate the risk of a rogue employee accessing the encryption keys or patient information. The bottom line is that this type of approach provides the encryption necessary to make mHealth more secure and achieve compliance with HIPAA’s encryption-related mandates.
Encryption should be built in, not bolted on, and it should be cloud providers who are taking the lead. It should be the responsibility of every cloud provider to address this issue, and they can with technology that exists today. It simply requires a commitment to do so and a willingness to create cloud services that are truly designed to meet the needs of healthcare companies.
April Sage is the Director of the Healthcare IT at Online Tech, which provides compliant data center services to companies in the healthcare industry and other regulated industries. She has been involved in the IT industry for more than two decades.