If anybody tells you health care isn’t moving to the cloud, don’t believe it. While cloud deployment in health
care is progressing slower than some vertical markets, that doesn’t mean it’s not on the horizon. For example, a recent research report from In-Stat suggests the health care market for cloud is a growth industry; specifically, that public cloud spending by health care organizations will pass $1 billion by 2013.
To say this trend makes security and compliance professionals in health care nervous is an understatement, and high-profile incidents such as the April Amazon Web Services outage don’t do much to bolster their confidence. In health care, outages mean more than irritated customers or lost revenue; they can directly impact patient care. It’s not FUD or hyperbole, it’s a fact: Downtime, if not planned for carefully, can have direct health and safety consequences.
For example, consider automated pharmacy systems: i.e., systems that provide automated validation to help make sure patients receive the right medication (meds they’ve been prescribed, not allergic to, and don’t interact negatively with other prescriptions) at the right time. The world doesn’t end when these systems are down (after all, nurses have been making sure patients get the right meds since time immemorial), but they have a role in ensuring proper care. Risk to patient safety is higher when those systems are not available. The same is true for many other specialized health care equipment such as lab systems, electronic medical record (EMR) systems, and diagnostic imaging (i.e. radiology) systems.
So it goes without saying that any cloud move – particularly the public cloud -- needs to be approached with caution, foresight and vigilance in a health care context. This is true particularly as it relates to availability of clinical resources, but also as it relates to other services outside of the clinical space. A long-term outage on the business side can impact care as well if employees don’t get paid and supplies don’t get ordered.
Given that cloud is so compelling from a business standpoint and diligence is required when making such a move, what specifically can folks in health care IT do to accommodate this? What can we do now -- while the industry is still ramping up to cloud -- to make sure our bases are covered from a DR planning standpoint when it comes to cloud computing and health care?
Understand the process impact
First and foremost, it’s important to understand that cloud will definitely have an impact on the process side of your DR strategy, no matter what cloud model you employ. In large part, this is due to portions of technical operations moving outside of direct organizational control. The amount of impact will vary depending on the cloud model you employ -- the more your provider is responsible for technically, the more operational aspects of DR become their job. For example, under an Infrastructure as a Service (IaaS) model, DR operations of the datacenter are the provider’s responsibility (e.g. maintaining fuel delivery for backup generators, monitoring telecom contracts, etc.), as well as potentially technical implementation of OS backup/restoration, network resiliency, etc. Move up the stack to a Platform as a Service (PaaS) model, and you expand the vendor footprint to include potentially middleware-focused DR controls (e.g. backup/restore, redundancy, etc.)
These impacts are important enough from both a regulatory and practical perspective that a cloud transition can be a little scary, particularly in light of the HIPAA requirement (§164.308[a][i]) that relates directly to DR planning. But just because someone else has control doesn’t automatically mean worse. Consider where servers tend to be located in a small or mid-size regional medical center; in many cases, they’re in an onsite server room that lacks the resiliency of a commercial datacenter. In that situation, cloud -- to the extent that it takes the weight off IT shoulders to maintain an “industrial strength” datacenter -- might have some positive impacts.
On the other hand, recovery processes will certainly have to change, in some cases drastically. In the past, when all services were hosted on premises, resumption procedures could use organizational “shorthand” by leveraging the knowledge of internal staff. Now, certain assumptions (like where backup tapes are, where personnel will be located, etc.) need to be considered in light of how internal staffers, as well as personnel at the service provider, will coordinate. Responsibilities should be clearly documented and resumption procedures should contain a full accounting of what needs to be done and who needs to do it. The procedures should be discussed with your vendor and ideally committed to via an SLA in order to make sure your vendor can support your needs. Everything should be ironed out before the event, not during it.
This means not only will you need to reassess DR planning activities for the changing environment and roles, but you’ll also need to go into more detail than you might have done in past planning. It’s also helpful during this phase to check in with medical staffers and make sure they think through their emergency plans (i.e. their fallback procedures for how to ensure care in the event of an emergency) since they might have their own views on emergency mode operations. Their priorities might not necessarily be automatically in line with IT’s. Medical staff might, for example, be easily able to fall back to a paper record when EMR systems are unavailable, but they might find the PACS not as easy to do without.
Understand the dependencies
In addition to re-evaluating existing processes, it’s important to make sure you understand how a move to a public cloud will impact application interdependencies. For instance, if application A connects to application B, which in turn connects to application C, what happens when B migrates to the cloud but A and C stay on premises?
Health care, much more so than any other segment of industry, has very complicated application interdependencies. Protocols, such as those from Health Level 7 International (HL7), allow providers to tie together applications in near-infinite combinations. And, historically, the full implication of how they tie together was already challenging to understand for DR planning purposes, but it’s much more complicated when you introduce cloud to the mix. Adequate planning for DR involves understanding the full dependency chain to make sure critical applications (for example, EMR and the PACS) have the highest probability of staying up during an outage, and knowing that something like network connectivity ratchets up in criticality when critical systems like those that support the EMR move offsite.
It’s imperative to revisit the organization’s business impact analysis or the prioritized application list that HIPAA requires covered entities to have (§164.308[a][ii][E]) to make sure the dependency chain is fully addressed. It’s always good to revisit the BIA every year or so, but don’t let the year you take on cloud be the year you to let it go because it’s the one year you absolutely can’t afford to miss. If you can’t spend the money for a full BIA revisit, consider leveraging HL7 interface maps and network diagrams to chart out application flows technically, at a minimum for clinical applications, ideally for both clinical and critical business applications.
If this sounds like a lot of work, it is. Which is why starting now, before a cloud transition is underway, is a good idea. More and more health care is moving to the cloud, so don’t wait until the last minute to think out your DR strategy and how this changing model will impact it.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.