Securing Images in the Cloud

By: Neil Buckley, VP Technical Solutions, CynergisTek Inc.

November 30, 2012

Take a moment to reflect on the decades of digital imaging development that have produced “public embarrassment 2.0” in the public sector. Digital imaging has showcased people with all the colors of the emotional rainbow and unparalleled stupidity — but also has been an amazing media to improve lives the world over. Now, take a moment to consider the images of our family, friends and indiscretions, live on a global stage, and then imagine what it would be like if the images that your doctor views were to reside on that same global stage.

As you do so, ask yourself how securely Facebook, YouTube, Pintrest, Photobucket, Flickr or Shutterfly are designed to protect the images your doctor uses to diagnose your condition from public view. Also imagine that you have been in an accident and the Emergency Department doctor needs to see your images before he performs surgery. Can Amazon, Rackspace or Google provide the infrastructure to support the confidentiality, integrity and availability required of business-critical image storage?

Of course, you might be thinking at this point, it’s just a picture, right? So, let’s examine that for a moment. The digital image rendered by the camera on your phone can range in size from very small to very large. The larger the photo, the steeper the cost to process and transfer the image. Anyone with a teenager and a shared data plan knows the value of teaching them to send small pictures. Businesses everywhere are running into this challenge, and where there are challenges, there are opportunities. Those opportunities are gaining traction in lowering the TCO of image lifecycle management.

Imaging has been in place at hospitals for decades. Traditionally this technology was a bulky piece of specialty imaging equipment that supported input to the process of a clinical diagnosis. This technology was supported by the development of the Digital Imaging and Communication (DICOM) protocol in the mid-‘80s, which served as a universal standard for image sharing in the clinical setting. When coupled with the HL7 transport protocol, this process became a catalystfor change in the clinical decision-making process. It became possible to support image review remotely. Like most things designed in the ‘80s and reengineered in the ‘90s, it was a specification meant to solve a problem and facilitate a better transaction. Confidentially, integrity and availability were afterthoughts on this solution. Later specifications of the protocol bolted on security to the solution without the same unilateral success as the earliest specifications.

Today, in 2012, our imaging technology has come a long way, but the images are no more secure or private than they were when we started decades ago. Clinicians want the most detailed imagery they can get when making a diagnosis. If we think about sending these large images, we quickly see the magnitude and complexity of the healthcare clinician’s use; these images are only dwarfed by the CGI industry.

As healthcare providers look to reduce their expenses, they will look to outsource image storage and delivery to cloud service providers. That outsourcing process can put patient data at risk. The obligation to keep the data safe, secure and private remains in effect, regardless of the competing demands to lower costs and improve care security, and privacy cannot be sacrificed.

There is no such animal as free-IT; all services, infrastructure and business processes come with costs. They also come with risk. Businesses and consumers utilizing digital imagery need to be aware of these risks. Those risks might seem obvious, but let’s examine the most common and relevant ones for the purposes of this article.

Unauthorized access and disclosure of personal information. Typically at the top of most healthcare IT initiatives, not the clinical initiatives. Migrating private services to a public cloud infrastructure will place the data on those cloud infrastructures at greater risk than data supported, administered and delivered internally. In addition, organizations will need to open their infrastructure to those cloud services to ensure that the clinical workflow is not impacted adversely by the transition to the new service offering.

Ensuring the integrity of the data and service. Healthcare typically equates integrity and privacy with encryption. Traditionally, encryption has come in two distinct flavors, data encryption and transport encryption. For reasons I would attribute to poorly written legislation and regulatory guidance, data encryption has become device encryption, and the impact is still being felt on the internal infrastructures of most healthcare organizations across the country.

Managing an encryption model that adequately protects the data while facilitating the demand of the clinical workflow will be challenging for most information security programs. In translation, the security provided by the cloud providers will be accepted and remain untested to satisfy the demands of the clinical data, and the images will be at risk.

Availability of clinical data is a risk to the business for a whole host of reasons, but for the purposes of this discussion we’ll focus on patient safety. Cloud services utilize the Internet and shared infrastructure to keep the costs of their services lower than what your practice could theoretically reproduce them for internally, though I think we’re too soon to tell whether the ROI on the cloud services industry has been properly calculated. The risk to organizations is that the Internet or Amazon EC2 is down (well, it did happen). This will translate into potential patient safety issues. If you can’t process the image, it will be tough to render a clinical decision.

Of course I’ve used an example that will undoubtedly raise some eyebrows as to why folks would even consider this service as a cloud candidate. Consider for a moment; healthcare- clinical data is regulated and must be retained for a period of no less than 7 years

Now ask yourself if this is core business to healthcare? It’s not, taking care of sick people is. To accomplish the improvements demanded by the people, healthcare will need to be able to take advantage of these cost savings.

Well, damn the torpedoes, we’re going to do it, we’re out of options, our budgets have been flat since 2008, patient census is down, referrals are down, and we need to reduce costs so we can ensure the continuity of the mission to take care of sick people!

Take heed. Prepare the battlefield you’ll be fighting on. Shape it as much as you can to ensure victory (if that’s even possible). Ensure that you understand the risks and exposures of the cloud architecture options in painstakingly technical detail. Ensure that you understand the use of images to support the business of healthcare. Ensure that you have the support of the clinical community. Most IT practitioners in healthcare spend very little time in the point-of-care areas, and this can be disastrous when migrating an internal workflow to an external workflow. Embrace the SLA, be the SLA, and please use a seasoned contract professional to ensure that the provider is contractually obligated to deliver on your needs and requirements.

So, what should you do first?

Businesses should invest in the proper training and support staff to assist you in transitioning from an internal infrastructure to a cloud-based infrastructure. This means that you’ll need to accept that you’ll need to cultivate, hire or partner with the right talent. Given my experience on the inside of a large healthcare IT shop for a decade, I would advocate for hiring or partnering to deliver the right solution to your community.

Get educated and keep your eye on the next-generation horizon. The next-generation cloud service products that look to support an SLA model that embrace confidentiality, integrity and availability as part of the base feature sets, not a bolt-on, not an afterthought in response to pending legislation. CIA is actually considered part of the base specification and as history has taught us, when features are considered part of the base specification, and implemented smartly, our lives just become easier.

Consumers should just be cautious and smarter about the images they post. There is no privacy or security in the cloud or on the Internet. If you wouldn’t shout it in a quiet public setting like yoga, church or a high-end restaurant or perform it in the middle of the park on the busiest day of the year, don’t post it. It’s that simple.

HITECH Stage 2 Rules Unveiled

EHR Incentive Program Regulations Address Encryption

By Howard Anderson, August 23, 2012.

The two final rules for Stage 2 of the HITECH Act’s electronic health record incentive program, which address encryption and other privacy and security issues, were released on the Federal Register Electronic Public Inspection Desk Aug. 23. Both rules from the Department of Health and Human Services are slated to be officially published in the Federal Register on Sept. 4.

The meaningful use rule spells out the requirements for how hospitals and physicians must use EHRs to qualify for a second round of incentives, beginning in 2014. The software certification rule spells out the requirements for EHR applications that qualify for Stage 2.

The HITECH Act incentive program, part of the economic stimulus package, is providing billions of dollars in incentives to hospitals and physician groups that meet the requirements for meaningfully using EHRs. The incentives are slated to be paid out in several stages.

Meaningful Use

The Stage 2 meaningful use rule, developed by HHS’ Centers for Medicare and Medicaid Services, requires that participants conduct a risk assessment, as was required in Stage 1. However, the Stage 2 rule specifically requires that the analysis address “the encryption/security of data stored in CEHRT [certified electronic health records technology].” The rule also requires providers to “implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.”

“We did not propose to change the HIPAA Security Rule requirements, or require any more than is required under HIPAA,” an explanation within the rule states. “We only emphasize the importance of a [physician/other professional] or hospital including in its security risk analysis an assessment of the reasonable[ness] and appropriateness of encrypting electronic protected health information as a means of securing it, and where it is not reasonable and appropriate, the adoption of an equivalent alternative measure.”

The Privacy and Security Tiger Team, an advisory group that recommended the provision, said it was necessary to help call attention to the importance of protecting “data at rest” because so many major health information breaches have involved the loss or theft of unencrypted devices that stored patient information.

The meaningful use rule “continues to reaffirm the importance of doing security assessments and mitigation,” says Farzad Mostashari, M.D., who heads the HHS Office of the National Coordinator for Health IT. “People really rely legally, and in terms of the professional ethos, on an expectation that their providers will keep their information confidential and secure. And as they’re transitioning to electronic health records, they have to make sure they’re following all the administrative and physical safeguards, as well as technical safeguards.”

Software Certification

The Stage 2 software certification rule, developed by Mostashari’s office, requires that EHR software be designed to encrypt, by default, electronic health information stored locally on end-user devices.

“The general policy we express in this certification criterion requires EHR technology designed to locally store electronic health information on end-user devices to encrypt such information after use of EHR technology on those devices stops,” the rule states. The rule also states that locally stored “is intended to mean the storage actions that EHR technology is programmed to take (i.e., creation of temp files, cookies, or other types of cache approaches) and not an individual or isolated user action to save or export a file to their personal electronic storage media. … We have clarified that in this scenario, the EHR technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users.”

The rule points out that an EHR technology developer would not have to demonstrate that its EHR technology can encrypt electronic health information locally stored on end-users devices “if the EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops.”

(Marianne Kolbasuk McGee contributed to this story).