The latest insights from your peers on the latest in Enterprise IT, straight to your inbox.
By John D. Halamka, CIO, Beth Israel Deaconess Medical Center
This article is by Featured Blogger Dr. John Halamka from his blog Life as a Healthcare CIO
As I have written about previously, CIOs across the country are telling me that expectations for IT delivery are at an all-time high. More must be delivered faster, cheaper, and with greater usability.
After a recent EHR rollout, a number of clinicians told me they were disappointed with the project. I asked them what criteria they used to measure success - their answer was that they hoped to get home an hour earlier, make more money, and be less stressed. Sounds good to me!
The cloud does not solve every healthcare IT problem, but does enhance agility, reduce capital expenditures, and enables IT to focus more on optimization than procurement. Currently I oversee about 250 physical servers in data centers operated by BIDMC and other hospitals. The lease on the building housing our primary data center expires in a few years. My belief is that by the time we move, we will not need to build or operate our own data center. We’ll embrace the public cloud.
Many companies talk about moving to the public cloud, but as one attorney recently told me, they have not read the fine print. Transitioning from your own data center requires careful planning. Here are a few elements of the journey thus far.
I'll stratify the issues into technical concerns, security concerns, and legal concerns.
At the technical level, what are you buying? I¹ve classified types of cloud offerings as:
Infrastructure as a service - your stuff hosted somewhere else;
Platform as a service - your apps running remotely on someone else¹s software development kit;
Software as a service - you are buying transactions run by someone else;
Outcomes as a service - you are a paying for a result to be achieved. It just happens that technology is part of it.
Each of these approaches requires service level agreements (what happens when their technology fails), disaster recovery plans (what if their cloud is below sea level in New York City and Hurricane Sandy floods it), local replication in case of an internet outage (such as a denial of service attack), and ability to retrieve your data should the hosting arrangement not work out (who owns the data).
Security concerns can be enumerated by an independent audit of the cloud partner. Do they have a multi-layered defense to protect against hackers? Do they have physical security in their data centers? How are their staff trained and what protections against employee misbehavior is in place? Encrypting data is sometimes seen as a panacea, but if we study the major security breaches of the past year, we'll find that most accesses occurred at the application level, not the data level - encryption of data at rest on servers in data centers would not have helped.
Legal concerns include business associate agreements, indemnification for costs associated with a breach, and clear definitions of roles/responsibilities so that when something bad happens, it is clear what is to be done by whom and who pays.
Of all of these, the legal concerns are the most difficult to resolve. Many customers will ask cloud vendors for an indemnification clause without a cap - the vendor must cover all costs associated with a breach including third party law suits. No cloud vendor will sign an agreement without a cap. What is the current benchmark? The Cloud Council offered this white paper which suggests a cap of 12 months of fees is typical.
What do I suggest?
Get your cloud vendor to sign a business associate agreement that gives them a legal mandate to protect privacy.
Try to negotiate a cap of at least three years of fees.
Try to get your cloud hosting vendor to agree to cover federal fines should the vendor be at fault - the HIPAA Omnibus rule really requires business associates to be accountable in the case of their mistakes.
Try to get your cloud hosting vendor to cover notification costs, credit monitoring costs, and call center costs in the case of a breach. These can be expensive.
Even with 3 years of fees, federal fines covered, and reporting costs covered, there still may be expenses that go beyond the cap. Consider cyber-liability insurance for these excess costs. No cloud vendor will cover everything.
Your legal and compliance departments will be important partners as you have the discussion with Board members and senior management about acceptable risks.
I was recently asked the following question - do you believe that your internal staff can manage operating system patching, network/server/storage configuration, and technical security as well as a cloud hosting company with thousands of employees dedicated to that task? Are you really taking on more risk by moving to the cloud? Interesting to speculate.
Here¹s a list of milestones for our next two years of cloud migration effort:
1. Move community hospital inpatient services to a single cloud hosted instance of Meditech's mobile web platform (we call the project CommunityONE).
2. Move ambulatory services at several sites to Athena’s cloud including the clinical record, practice management and billing.
3. Use public cloud services such as Amazon for an increasing array of hosting - disaster recovery, development, test, and production.
4. Use cloud hosted apps such as Gmail and Google docs as long as they can be operated securely under a business associate agreement.
5. Use cloud hosting companies such as Dell for infrastructure as a service.
The cloud is the right thing to do and as with any change management activity, there will be a process. Over the next few weeks, I'll be presenting cloud ideas in many Board and senior management meetings, discussing risks, mitigations, and legal agreements.
Step by step, year by year, we'll get to the point that IT no longer provisions services, but instead procures them from cloud vendors.
Originally posted on Life as a Healthcare CIO.