you, everybody. I’m really excited to see
such a full room here today to hear us talking about
keeping patient healthcare data secure on Google
Cloud Platform. I’m Joe Corkery. I’m a product manager on the
Cloud Platform team, where I’m leading our efforts in the
healthcare and life sciences space in the product world. I’m very excited about
this particular topic. It’s near and dear to me. I’m actually a
non-practicing physician, and found my way to
Google, and really excited to talk
to you about this. Here’s a bit of an
overview of what I’m going to be talking about today. I’m going to start off by
talking about HIPAA compliance on GCP– what that means. And then I’m going to
transition into best practices for securing healthcare
data on the cloud– how you should configure
your cloud environment to take advantage of
the best practices. At that point I’m going
to transition and invite my co-presenter
Michael Ames on stage, and he’s going to talk
about the work they’ve done at the University of Colorado– how they were able to build the
health care EDW on the cloud and hopefully give a brief
demo of that, as well. And then, finally, because I
know Google Cloud encompasses more than just Google
Cloud Platform, I’m going to touch very briefly
on G Suite and health care, as well. Let’s get started. I don’t know if all
of you have seen this, but we published this
the week before HIMSS. A new guide for HIPAA
compliance on GCP to help people understand
what that means as well as to understand best
practices for configuration. So if you miss anything today,
you can either watch us again on YouTube, or you can
go read that document. Because most of what
I’m going to talk about is also captured in there. So by virtue of this being
a talk about health care, I’m going to assume most
people here know what HIPAA is. But in case you’re
not aware of it, it’s US legislation that
provides data privacy and security provisions
for the handling of medical information. Importantly, there
is no certification recognized by the Department
of Health and Human Services for HIPAA compliance. And what that means
is I can’t go out and you can’t go out
to some third party and get a nice certificate that
says, this is HIPAA compliant, and bring that
around to everybody. So your HIPAA compliance is
really a shared responsibility on your part– well, it’s a
responsibility on your part, and when you’re working
with the cloud provider, it’s a shared responsibility
between you and the cloud provider. What that means is customers
are responsible for securing their data and the content
that they bring to the cloud, and Google is
responsible for securing the infrastructure on which
that data is stored, analyzed, and consumed. This is a high-level diagram
of the spectrum of the shared responsibility model
across SaaS, PaaS, Infrastructure as a Service. And as you go from
the SaaS environment all the way down to
the IaaS environment, the ratio of
responsibility changes. So when you look at a SaaS
model, like Gmail or Drive, ultimately the customer is
responsible for the data and who has access to
the data, but Google has much greater responsibility
on securing everything underneath it. But as you move
to the IaaS model, Google has the
responsibility for securing the infrastructure, but
you, as the consumer, are responsible
for the operating system that you
install on top of it, how you configure your
firewalls, and beyond. I’m going to talk about these
terms a fair bit in the talk, so I’m just going to
quickly define them in case anybody is not
familiar with them. Protected health
information is really health information that
includes demographic info, as well as information
that refers to past, present, and
future medical information, as well as the provision
of that health care, and finally, also
the billing of that. A covered entity is one
of, really, three things. It’s either a health plan, so an
insurance provider, or a health care provider– so a doctor,
physician, nurse, or hospital system, or a health
care clearinghouse. And finally, a
business associate is an institution or a person
who works with a covered entity, does work
on their behalf, and as part of that work,
protected health information is disclosed. And in order for a covered
entity and a business associate to work together, they
have to execute a Business Associate Agreement that governs
how that transfer of data is going to be managed
and controlled. So this is an important point
I want to kind of sell home, because I feel like not
everybody is well aware of this. But Google will enter into a
Business Associate Agreement with customers as
necessary under HIPAA. So in this context, if
you’re a hospital system, you’re the covered entity,
Google’s the business associate, and we will
sign that agreement so that you can bring
protected health information to the cloud. And we’re able to sign this
because of our approach to security and privacy design. The cloud platform was
built under the guidance of an engineering team of
more than 700 security– over a 700 person
security engineering team. Which is larger, and most
likely significantly larger, than what most people
can have on premise. And furthermore, our approach
to security, privacy, data protection is well
documented in a number of white papers,
design overviews that you can go to this website,
our security page, and view. In fact, earlier in
January we published a well-documented
security design. I would highly encourage
you to go review this– it’s really quite detailed– and then share it with
anybody in your organization who you think really needs
to understand the security practices that Google
brings to bear in the cloud. We’re really excited about this. It got well over 50,000 views
in the first couple of days. It’s worth looking. It’s worth sharing with anybody
who has an interest in that. But it’s all well and
good that we actually perform these security practices
and that we document them, but you as customers also want
to verify that, to validate it. And so as part of
that, we participate in a number of external
third-party audits on an annual basis to get SOC
2 compliance, ISO 27001, 27017, so on. So that way you can
know that somebody else has gone in and verified the
designs and the practices that we say. As I mentioned before,
there is no certifying party for HIPAA compliance,
so I can’t put that on that list over there. But it’s because of
these compliance audits that we go through, as well as
our own security and privacy designs, that we feel
comfortable being able to offer a Business
Associates Agreement. The Business
Associates Agreement covers a number of things. In particular, it covers the
infrastructure– all regions, zones, network paths,
points of presence– for these related services
that are listed here. There are 10 services right now. It’s grown significantly
over the past year or two and will continue
to grow over time. And when you sign the
Business Associate Agreement, it covers your utilization
of these products. There are a couple of really
unique, interesting features, though, as a result of
our security practices feeding into our BAA. And because the BAA covers
the infrastructure underlying these products and not just a
secured set of infrastructure to run just that in a
HIPAA compliant fashion, it means you don’t have
any regional restrictions. So you get security,
operational, and scalability benefits
of having access to the entire infrastructure. It means you can have
multi-regional redundancy. So if, for instance,
you’re storing a lot of healthcare
data in the cloud, you don’t have to be
limited to one data center. So you can store the data
in GCS on the East Coast and on the West
Coast, and if you have temporary unavailability,
you can fail over from one to the other relatively easily. Furthermore, as
part of this, you can use any of the
VM instance types. So you can take advantage
of preemptible VMs, which are very useful in terms
of saving a lot of money for batch workloads,
where you’re tolerant to the VM
coming down and being able to easily restart it. With all that in
mind, and because we don’t have to actually build
out and maintain a completely separate infrastructure
stack in order to offer you a HIPAA
compliant environment, we can offer the same pricing. There are no additional
fees, charges, taxes, commitments that you
have to make in order to operate under the BAA. Let me talk a little
bit now about some of the specific customer
responsibilities. I have two questions
that you really need to answer before we move on. And the first one is, you
need to answer for yourself– are you a covered
entity, or a business associate of a covered entity? And then you also
need to answer, does the workload that
you want to bring to cloud require that you have a Business
Associate Agreement with GCP? I can’t answer these
questions for you. Hopefully you already
know these answers. And if you don’t,
I would encourage you to seek legal advice. Now, if you answered yes
to both of those questions, this is what needs
to happen first– first thing you
need to do is you need to execute a
cloud platform BAA. And that’s done in the context
of a larger services agreement. And then for that environment
that you’re working in, you need to ensure that you
can disable or otherwise ensure that you’re not using
Google Cloud products that are not explicitly
covered by the BAA when you’re handling PHI. And finally– and this goes back
to that shared responsibility model– you need to ensure that
anything that you build on top of this
infrastructure also meets the HIPAA requirements. So any applications
that you might install, as well as your use
of that application. So let’s talk a little bit
more about individual best practices. I’m going to start off with
identity and access management. The first real
principle to be aware of is this principle
of least privilege. And this is the idea
that nobody should be granted permissions
beyond what they absolutely need to get their job done. So you should not be granting
permissions to everybody in your organization
to the data. You should not be
giving everybody owner roles on the projects. Instead what you
should do is you should put the work together in
as small projects as possible, grant specific roles to
those individual projects, and only give people
who have a business need for that those
particular roles. As part of that, we encourage
people to use groups. And what you can do is you
can take groups and assign a permission to go to
that group as opposed to assigning a permission
to an individual user. And what that means
is you can say, OK, this is our
security admin group. And people in security admin
group have these permissions. And if I remove you
from that group, you lose all those permissions. You don’t have to go and
change your whole IAM policy for your project to remove you. It makes it very
easy, especially with people moving around. But part of that
means you also need to tightly control who has the
ability to change identities and policies. So you want tight
configuration over who has user management, group
management, and IAM policies. In addition to that, you also
want to audit policy changes with some frequency. In particular, you want
to go and look and say, were the changes that
were made appropriate? What you can see
on the screen right now is a screenshot
of the activity panel on the cloud console, which
is showing you an IAM policy change. And I’ll talk a little
bit more about auditing a little further on. And then this last
bit with regard to IAM is we encourage people to rotate
your service account keys. Or if you’re not going to
actually do the rotation, to have a plan in
place for how you’re going to rotate those keys
if you need to do that. And this is important
because the service account key is what allows you to
authenticate as that service account. So if that key
gets lost, you want to be able to rotate
it very quickly, so that nobody has access
to that service account. Encryption– this is kind
of an easy story for us here, because all
customer content is encrypted at rest on
Google Cloud Platform. We’re the only cloud platform
to provide that by default. What I need you to
ask yourself then is does your organization
have any other encryption requirements beyond what
is required by HIPAA? And if you do, we
have options for you. And they run along a spectrum
from highly automated– of the everything is
encrypted by default– to the more managed key
management service, as well as the ability to provide your own
customer-supplied encryption keys. I’m going to talk
briefly about storage. So if you’re using
cloud storage, we encourage people to
use GCS Object Versioning, because this is very useful
for building a Data Archive, as well as protecting
against accidental data deletion– which I know is often
an important requirement when handling healthcare data. There is a tool that people
use with cloud storage called gsutil. And there are a couple security
and privacy configuration things that you should
be aware of there. First of all, you never
want to share credentials. Everybody should bring their
own credential when they use it. And that’s important
because sometimes secure sensitive information can be
captured in the configuration file for that application. And so you want to
tightly protect access to that for whoever is using it. And more importantly,
if you’re going to use this in a
production environment, use a service account credential
instead of individual user credentials. It’s easier to control. Audit logs– these are what
allow you to know who did what, where, when on your platform. Very valuable, especially
when you’re working with health information. There are two types
of audit logs. There’s the Admin Activity
Log, which basically captures all the actions that you
take that make a change to a resource or your service. And then there’s
the Data Access Log, which captures all
the requests to read, as well as all the interactions
with the data managed by that service. So if you were having
a database service and actually touching
the data, that’s where those logs
would be captured. I have a couple of examples
of typical operations as they would be classified,
one or the other. You can see up here
right now there are two ways that the audit
logs get surfaced to the users. On one hand you’ll see the
cloud activity console, which provides you a high-level
overview– basically tells you what are the important
points and makes it really easy for you to see. On the right is
the raw log being able to be seen inside
of StackDriver logging logs viewer. So if you want the full
details to actually look at the individual logs, you
can see them right there. Let’s talk a little
bit about some of the best practices for
audit logs when you’re working in this environment. What we encourage people to
do is we encourage people to, first, set up their
export destinations. So you want to send your logs to
another location for long term archival. You can send them to GCS
for long term archival. You can also send
them to BigQuery and use that for
archival, as well as forensics and analytics. I’m seeing a lot of
interest in using BigQuery as a tool for log analysis. We also want you
to configure access to the logs in a way
that’s appropriate to your organization. So as I said earlier on the
topic of least privilege, you only want to
give people who need to see the logs the
right to see the logs. And actually there
are three permissions that you should be aware of. There’s the logs
viewer permission. And the logs viewer
permission grants you access to the admin activity logs. There’s the private
logs viewer permission, which grants you access
to the data access logs. And we decided to give
them an extra permission, because we thought
perhaps that data might be a little
bit more sensitive, and you might want to
break out who could look at one versus the other. And then the final permission
that you should be aware of is the logs config
writer permission. And a person with the logs
config writer permission is a person who can set up
new export destinations. And this is a pretty
powerful permission, because it allows you to
take your logs out of here and send them somewhere else. So you should not– the person with that
permission should be very few. And finally, as I
talked about earlier, you want to regularly
review these audit logs. And you can do them inside
of StackDriver logs viewer. You can do it inside of
BigQuery or with a variety of third party tools. So we support
exporting your logs to other external destinations. So you can take
advantage of Splunk, Netskope, Rapid7 log entries,
as well as Tenable Network Security, to use those
for log analysis. And this is my last
topic on best practices before I hand it off to Michael. And this is what I like
to think is ideally a commonsense thought– but please don’t include
PHI or security credentials in your resource metadata. Resource metadata often
gets captured in the logs, and that’s really
not a good practice. So as I said– and actually
I want to emphasize this– the audit logs themselves
never contain the data contents of a resource. But by virtue of capturing
the actions that happened, they often may
capture the metadata associated with that resource. So in best practices,
don’t name your buckets after your patients. Don’t name your objects
after your patients. Use other identifiers. So with that I want to step down
for a second and transition. Michael, please come on up. Thank you. MICHAEL AMES: All right. Health care people are the most
dedicated people in the world. It is 4:30 PM. It’s been a long day. This room is almost full. Thank you for being here. I hope that by the end
it will be worth it. Now, I can’t see
you really well, but if you’ll do this
for me– raise your hand if right now your
organization has protected health information
on the Google Cloud today. OK. Now put your hand down
if you work for me. OK. Now raise your hand
if you would do it if you could, if you could
get over the organizational and the security hurdles,
if you could talk your people into
saying, yeah, we can do this– put your hands up. Great. OK. This presentation is for you. And this is a great time to be a
healthcare-related organization looking at a move to the cloud. And I’ll tell you, part
of why it’s a great time is a year ago– I was here with my team,
and my team is here. Thank you. I was here with my team and
talking to everybody I could find– from Google,
other customers, and the leadership circle– saying, hey, we’re trying to
get our PHI up onto the cloud, and we want to do it right. Where is the HIPAA
security playbook that’s going to tell us how
to do this in a way that is safe and secure, and is going
to protect patient privacy, and keep us all out of jail? And everybody was like, you
know, that’s a good idea. We should get one of those. Right? But it wasn’t there. And we spent a lot of time on
our own, working with our team, working with external
partners, with Google, trying to figure out
the right way to do it. And what Joe has just presented
is that playbook that we wished had been here a
year ago that isn’t. And you have that now. So this is a great time to
be embarking on that journey. And what I’m going
to talk to you about is what our journey
looked like, and then go back and talk specifically
about some things that you might take back to try
to win this battle for hearts and minds within
your organization, to allow you to take this
step– move to the cloud, enjoy the technical
benefits that we’ve been learning about here, and do
it in a safe and secure manner. So part one– what we did. This is a little bit about us. My organization is on the bottom
of that right square there– Health Data Compass. We’re an enterprise
health data warehouse within a larger organization,
the Colorado Center for Personalized Medicine. This is a great organization
that was formed just recently, collaborative between UC Health,
Children’s Hospital Colorado, CU Medicine, and the University
of Colorado School of Medicine, who got together and
said, what could we do better than we’re doing
today if we put all of our data in one place? And specifically,
what can we do to help to advance this field of
personalized medicine? For those of you for whom that’s
a new term, or a vague buzz word, for us what it means
is let’s gather as much data as we can about every patient
at the clinical level. Let’s then go in and
gather everything we can learn about them from a
molecular, genetic standpoint. Let’s put that together
and analyze that data and see if we can figure
out how to deliver targeted diagnoses
and targeted therapies based on everything we can
possibly learn about you– not just the
handful of questions that the doctor is asking when
you show up at the bedside. So that’s our job. And specifically within
Health Data Compass, we are tasked with
that integration of these vast amounts
of data in a way that our researchers and
hospital administrators can use it to serve a
wide variety of purposes. I’m going to give you a little
bit of company history now. This is our affectionately-named
“Compass Hope-O-Meter.” Because we are data
people, we like to put numbers to our emotions. And you can see here, we kicked
off in the summer of 2013 with a pile of money
and a huge mission. And as we began to
work on this project, going through the stages of
figuring out our requirements, developing an RFP, putting
that RFP out there. I remember the day– I still have the photo– that we were able to finally
look at these 20 thick binders, with proposals from different
vendors who were going to come help us solve our data
integration project. We were so excited. And we launched. We chose our vendor. We started to launch our
building efforts in the summer of 2014 with high hopes. And then what happens? Right. Many of you have been
through this cycle where once you get your
hands on the technology and you start to work
with it, you realize– this is harder than we
thought it was going to be. That sales pitch
sounded so good, right? And now, as we’re working
with it more and more, we’re finding ourselves a
little bit more disappointed. But we did, by the
skin of our teeth, reach our go-live in
the spring of 2015. Now, notice how much time
passed between our go-live and our Hope-O-Meter
dropping to all-time lows. About three months
was all it took. We were having some trouble. We were drowning
under the weight of maintaining what turned
out to be a very heavy, very brittle, very error-prone
on-premises infrastructure. It was a top-to-bottom
stack, all of one brand, supposedly tightly
integrated, and was going to service all of our needs. And it was possible to
achieve that but only at tremendous effort
and expense that, to us, felt like constantly
having to go back and flip on a really heavy, really
costly light switch. All it did was keep
the system running. And we were spending
resources on those activities that we would much rather have
spent on value-added activities for our stakeholders. We expected the server to
blaze right out of the box. We had a lot of
off-the-shelf software we expected was
just going to work. And what we had hoped was
that by investing so heavily– in what, honestly,
was the most expensive of that big stack of
binders and proposals– that we would be
able to accelerate to business objectives. The reality is that
wasn’t the case. And that presented us
with a problem and was, frankly, quite depressing. And then we had an
interesting day. So this is my good friend Mary
Anne Leach, whom some of you may know. She is a great– International Women’s
Week– another of these great
visionary women leaders in health care, whom
we’re celebrating. She was CIO of Children’s
Hospital at the time. And she had this idea,
she called me up, and she said, hey, I just
got invited to a thing to go learn about
the Google Cloud. Do you want to come? At which point I
rolled my eyes, right? Because she’s a visionary,
she’s a thinker. And the thing about visionary
people with great ideas is they have a lot of ideas– they’re not always good, right? And she was one of these. And I thought,
[GROAN] I don’t know. Until she said it’s
at a fancy steakhouse. Google legal made me redact
the name of that steakhouse, all right, but we went
to a fancy steakhouse. And I thought, OK, I
could be persuaded. And so we got together and we
went to this Google Cloud Sales pitch downtown,
wherein we discovered that there was no steak. No steak at all. There were only canapes. Do I look like a guy
who was happy to be served a piece of
fish on a cracker when I thought there was steak? No, I am not that guy. But what we did do is we
spent the day learning about the Google Cloud
from Doug Daniels, who’s here in the second row. And he was talking
about BigQuery. And he was talking
about Google Genomics. And he was talking
about this concept of operating on a completely
serverless architecture. And think about where we were,
drowning under the weight of maintaining our servers– our minds were blown. Do you like my
classy diagrams here? So we started to think,
well, this would be amazing. And where was this two
years ago when we started? How come we didn’t
know about this then? And we realized,
as we considered this question about
could we shift our operations to the
cloud, that there were some things that had changed. In those couple of years,
there were significant advances in cloud technology. There are new attitudes
about cloud services. When I started at the
University back in 2009, you talked about putting
data in the cloud, they would laugh
you out of the room. And people were
starting to think about this as maybe a reality. We understood better the
potential of the business case, and we had learned some
things, and we thought maybe we could do this. But I want to tell you a
little bit about the challenge that we had to overcome. Like I showed in
that first slide, there are four separate
legal institutions involved in our organization–
two major hospital systems in Colorado, a
university, and a physician practice plan. Which, even though many
of them have their roots in the university,
are literally now separate legal institutions. One does not operate the other. Each of them has their
own security officer, privacy officer, legal officer. We have a steering committee
consisting of executives from all of those organizations. And put yourself in my shoes– going in front of
this group of people and asking for a do-over just
a few months after our go-live. But we felt like– given the
experiences that we were having and our responsibility to our
stakeholders and our patients– that we needed to take
care of every opportunity that we could. So here is how we
strategized this. We said, lets do with
Google what we could not do with our original system. It took less than
six months for us to realize that we were
having serious problems. And we set out to do a
detailed pilot project on the Google Cloud platform– in six months, in stealth
mode, not telling anybody who didn’t need to know– while we continued to build out
and operate our legacy system. Now, how is this possible? We’re going to talk in a little
bit about zero-depth entry, and pay-as-you-go models,
and how it enables this kind of thing, where
traditional models do not. And we laid out this plan,
and we executed this plan. And we did it with the intent
to answer these questions. We wanted to find out, is
it compliant, legal, safe? Can we do everything
we need to know? We literally built all of the
components necessary to operate our data warehouse. Because we did not– I can ask for one do over. I can ask for two– at which point I
sharpen up my resume and I go find other jobs, right? We only had one chance
to do this a second time. So we had to make sure that
we were getting it right. We wanted to make sure that
the capabilities were there, and also measure costs
and long-term benefits, so that we could make a
compelling case for why our organization should
make this change. Which we did, and we
built this in six months. So you can see here
our data sources coming in from our
hospital partners and from the Colorado
Department of Public Health. Because one of the things
that we wanted to prove was the effectiveness of this
platform in integrating data that came from sources
other than our own. We load that data into
the Google Cloud platform, through Google Cloud
Storage, Google Genomics, into Google BigQuery. We transform, we
clean, we harmonize, we do all of the work
there in the cloud. So, again, follow
me– for those of you who work in data
flow architectures, we load the data as unchanged
as possible into the cloud, and we let the
scalability of BigQuery be our friend in doing all
of the transformations that are necessary. And then we deliver
reports via Tableau. We have since
continued to build, and we continue to have a vision
of building out additional data sources. There’s probably a list
of 20 other data sources down there that we’re
working to integrate. In addition to these
applications that we’re exporting data to, my
outstanding analyst and BI team spends a lot of time delivering
one-off data extracts to researchers. These people who stay
up late at night, and they come to
us in the morning, and they’ve got an idea
for a research project. And they just want to
know, do we have the data? Do we have the patient
population to support this? Very specific, ad-hoc questions. And they ask us those, and
we provide those to them based on this platform. So we built this thing, and
we measured the results, and here are some
things that we found. On the left side is an ETL
performance comparison. Now, it’s tough to do
apples-to-apples ETL comparison when you’re dealing with
on-premises systems versus systems that are
sort of hybrid– moving from an on-premise
system up into the cloud. But we figured the
most honest way to do this is to look
at end-to-end ETL. So we start with
extracting data on one end. We end with when it has reached
its final destination up in the cloud. And as you can see there, we
achieved a 50% performance improvement, even
including the time that it took to upload that
data through the internet from our campus
up onto the cloud. And here is an outlier,
but just to show you some of the things
that are possible. And in fact, I’m to
come back to this. But any of you operate
a master patient index? Know what I’m talking about? A few of you. We had a big win
there, but we’ll talk about that a little
bit more in a minute. When I show these costs
I’m always asked– and Google legal asked– are there real
numbers behind this? There are. These are our annual
infrastructure costs. I’m not giving you
the real numbers, but the ratio there is correct. You can see that having
moved from our legacy system to Google BigQuery,
we anticipate spending 60% less on
annual infrastructure cost. And we’ve operated this
now for close to 10 months, and we have actual data to
validate those numbers for us. Projecting that out
over five years, you can see that year
over year we experience reductions in cost and a
cumulative total infrastructure reduction, again, of around 60%. And if I was being
totally honest, that reduction would
even be higher. Because you can see in fiscal
year ’20– that big red bar represents end-of-life equipment
for our on-premises system and the need to replace that. If we were really
doing it right, we actually would have done
an expansion of our system in fiscal year
’17, and that would drive that ratio even higher. So we did this pilot, we
got these great results. I want to back up
now a little bit and talk about how you take
on the battle for hearts and minds. So we have this committee. I told you about these
four institutions. And each of them has a
security officer, each of them has a privacy officer, each
of them has an attorney. And once a month, they literally
get around a boardroom table that looks just like that for us
to bring our questions to them. Now, Google legal– I normally present
this slide with a bunch of cropped-out pictures
of Nancy Reagan’s face. Think about it. With all respect to our lovely
and elegant former First Lady, we call this the Nancy
Reagan committee. Because the security
officer, the privacy officer, the legal person, all have
just one job description, which is–? AUDIENCE: Just say no. MICHAEL AMES: Just say no. Right? And we had to persuade
this group of people that it was safe for all four
of their institutions to have their data moved to the Cloud. Here’s how you go about this. Recognize that the risk
that they’re looking at is three-fold. They’re concerned
about the cost, because the cloud is unknown. They’re very concerned
about security, because that’s paramount. And in general, the
cloud is unfamiliar. And these are the problems
that you have to tackle. There is, in the
end, only one thing that will make a difference. And that is the
business case that proves that the
rewards are going to be greater than the risks. And you’re going to answer cost
by demonstrating that there’s going to be increased
revenue, or cost savings, by moving to the cloud. You’re going to answer
security by saying, the security is going to be
better when we get there. We will fulfill our
responsibility to our patients more fully by taking
advantage of those 700 security and
compliance engineers that Joe talked about. And you’re going
to answer concerns about the unknown
with opportunities to innovate that you’ll
be able to take advantage of in the cloud that you
won’t in other places. Here is part of a
helpful way, I hope, of talking about
cost versus value. Because in the end, the
money aspect of this matters. So that blue area
represents investment in infrastructure
capacity, which has this stepwise function. That red line is your
usage on that capacity. And let’s just assume that
it’s going up kind of flat over time. You can twist and warp
this model all you want, but it gives you the same
results, more or less. As you approach
capacity, you need to expand upon your
infrastructure. And you make a big investment,
and you deploy out new servers, and then you do that again
after some period later. And the thing that happens
is the infrastructure that you had invested
in that you’re not using– that time between when
you first make the purchase and when you start to reach
capacity is considered waste. That’s money that you’ve
spent that you aren’t using. And look how that
adds up over time. That orange line shows how
that wasted area accumulates. This has a dramatic effect
on total cost of ownership. And the model, when you
move to an infrastructure where you can scale up
more closely to your usage changes this significantly. So here’s a
pay-as-you-go model– only investing in the
infrastructure that you need. With systems like BigQuery,
that stepwise function is even flatter, because
you’re literally only paying for queries
as you execute them. But even if you’re
deploying virtual machines, and you’re able to gradually
scale those out and build them up, we have the same usage. We have the same slope. But the mean is much lower. And look what happens to
the accumulated waste– it is much, much smaller. This has a dramatic effect on
your total cost of ownership, and in my opinion, is one
of the strongest arguments for a move to the cloud from
an economic point of view. I want to verify with our
folks that this clock is counting down. It’s telling me how much time
we have left in the session? Yes? OK. Great. I was confused for a second. Second thing– it’s time
to change the conversation. So this was a release
from about last October from HHS on HIPAA
and cloud computing. The question of, oh, will
the government get mad at us if we put data in
the cloud any more? The answer to that is no. This guidance exists. You can go look it up online
on a government website. You can read it. It has very specific,
very helpful guidance for how to engage effectively
with a cloud service provider. And my recommendation
is that you stop talking about this,
like, gee, I don’t know if we can do this in the cloud. But the fact is
the advantages are so strong that the
conversation needs to be– how quickly can we get there? A little repeat from some
of what Joe talked about– recognize that in
terms of security there is a joint responsibility. Google owns physical
infrastructure, platform, and Software as a
Service level security. You still own everything
top to bottom, and this is important,
again, in this battle for hearts and minds. Because you have your security
and compliance officers, they need to have
confidence that you know what you are talking about. And the moment you
go in and say, oh, we’re going to
move this to Google and they’re going to
take care of security, they will know that you don’t
know what you’re talking about. You have a responsibility
to understand what your responsibility is. And you need to be able
to speak this language. You need to understand
what it really means to be HIPAA compliant. You don’t need to understand
how encryption algorithms work, but you need to understand
where the responsibilities lie, and the difference
between technical security and organizational
level controls, and to be able to define– here’s what we’re going
to get from Google, and here’s what we’re going
to have to do ourselves. If you can’t speak
that language, find somebody who can,
and get them to help you, get them on your
side, and have them help you to advocate for
the security of the cloud. Here’s another way to do it. This is Fort Knox. Google legal made me go back
and get a non-copyrighted photo of Fort Knox. Google has built Fort
Knox in their data center. It is literally true that the
South Carolina data center has alligators on the property. Not as a formal part of
the security mechanism, but they sort of moved in. And Google said, that’s fine. We’ll leave them there. And they put up some “beware
of alligators” signs, and it’s going to help. How many of you have alligators
outside your data center? Not many. You still have this
responsibility. You can build the strongest
vault in the world. If you leave it unlocked, you’re
going to have problems, right? So those orange bars– your responsibility. Again, what Google
does, what we do. Joe already talked about all
of the different compliance and certifications of– my HIPAA with the
asterisk here– just to repeat
what he said, there is no HIPAA certification. If somebody tells you that
they have one, they’re lying. What they have is maybe a
third party auditor who said, yeah, we think that
this is HIPAA compliant. But the government
hasn’t set a checkbox way to say that you’re
HIPAA compliant. So there is some judgment
that you’ve got to take there. It’s going to feel
like you’re never done. That’s fine– sleep
is for mortals. Recognize that Google is– I’ll be honest. One of the things that brought
comfort to our legal folks was recognizing that in
the event of a breach that was Google’s fault, Google’s
got a lot of resources that in the event
of a lawsuit, we’re confident they could
probably cover our expenses. Right? If that had to happen. We hope that never happens. But there is work here
for you to do as well. Map those various
compliance certifications to whatever requirements
your organization has. If you want to throw independent
pen testers at it to make people comfortable, do that. In fact, one of the early things
that we sort of said, wow, I think we’re going down
the right path is– again, I asked Doug Daniels– I said, if we wanted to
have our in-house white hat hackers go after
this thing and try to penetrate BigQuery,
or something like that, could they do that? Or would we get in trouble? And he’s like, go for it. Because Google is doing
this always themselves. They’re giving out
money to people who are trying to
hack their system. You can build hybrid monitoring
and alerting systems. If you have local
systems, or if you’re using Splunk, or
Nagios, or other systems that your security people
are comfortable with– fine. Let them have those things. And build mechanisms that allow
them to use hybrid approaches to monitoring and alerting. And watch the contracts. I was going to
make a whole slide, but there’s probably
another hour on making sure that
your contracts are unambiguous and appropriate
liabilities are set up. Finally, to the
innovation point. Please think beyond
the lift and shift– let’s get our virtual machines
out of our data center and onto Google. There have been a
lot of discussions here and in the keynotes about
how you do this incrementally. Fine to take an
incremental approach, but don’t get your VMs
out of your data center and into Google’s and
consider yourself done. Because the greatest gains are
to be had in the cloud 2.0, cloud 3.0– thinking beyond virtual
machines and into SaaS and PaaS offerings. So here’s one. Couple of super
smart guys on my team here work together to see– hey, every time
we do a data load we have to take these six
million patient records and do this big fuzzy
match cross-join. We want to find out if Bobby
Peterson at the Children’s Hospital is the same as
Roberta Peterson at the adult hospital with
10-year-apart visits. That’s a tricky problem. It’s a huge
computational challenge. And any of you who
operate systems like this, you know it’s not
a small effort. Our legacy system had
an expensive application and server that this
ran on, and to do that six-million-record
fuzzy cross-join took about eight hours. They reimplemented
this in BigQuery, using BigQuery’s user
defined functions, using JavaScript in order
to do the fuzzy matching. Ran it, and it finished
in about 15 minutes, and it cost us about $1.50
every time we ran it, in terms of BigQuery
computational power. That is the kind
of win that you can get when you look beyond just
moving your virtual machines into the sky and
say, what can we do with some of these
scalable, serverless tools that are out there? What could you do if suddenly
you didn’t have to keep asking, do we have enough storage space? Do we have enough compute power? What could you do
with zero-depth entry? That six month pilot
started in about March. In about June, my
wife came upstairs and said, why do we have
a multi-thousand dollar bill to Google on our
personal credit card? Because back in March, I sat
on my couch, in my pajamas, and signed up for
our Google account on my personal credit
card and didn’t notice it for three months. Because as we were starting
to load data in and work with the system in
this stealth mode project that costs
were negligible. And it wasn’t until
we started deploying lots of data and lots
of virtual machines that it even hit the radar
on the credit card bill. Don’t do that. Google legal doesn’t make
it easy to get that back. But we did get it back. Thank you again, Doug Daniels,
and apologies to my wife. So we got that done. But the point is,
the fact that you can make that
mistake accidentally certainly means that you
won’t need CFO authorization and a big CAPEX spend in
order to start playing around. I think everybody here
has got a $300 credit. I think they’ve extended
the period from six months to 12 months for
the trial period. Get in and start with this
zero-depth entry approach, seeing what you can do. Think about cloud-first
architectures. So we’re taking our
data, we’re pushing it into the cloud unchanged, and
we’re doing all the work there. What could you do if people
could get to your data from all over the region
or all over the world? What can you do with the
integration between your data in the cloud and these amazing
cloud-based analytical tools that are out there? And given that you will
hopefully save money, what do you do with that? You take that money,
you don’t give it back, and you redirect that toward
value-added activities. For us that means
hiring more analysts, bringing in more
data sources, working on improving our customer
relationship management approaches, and building
a better organization that is much more focused
on delivering value. I’m not going to
repeat all this. This is summarizing
what we just said. You’ve got to build
the business case. You’ve got to make sure that
you can speak to the security. And you’ve got to
focus on innovation. That’s all I have by
way of information. I wanted to give some thank
yous to the folks on the screen here who really helped us in
building these things out, figuring out our
security approaches, helping us with processes,
architecture design. Huge thanks to my team,
most of whom are here, and who really were the
hands on doing this work. And let me just ask
Joe– do we have time? Do we want to hit that demo? We’ve got 12 minutes
left on here. JOE CORKERY: Yeah. MICHAEL AMES: OK. So we just want to prove that
we’re not making stuff up here. Here’s our Twitter handle
if you want to follow us. We don’t tweet a lot,
but there’s stuff there. Maybe we’ll make friends. Couple of screenshots
and then a running demo, if it works, of actual things
that we have actually built. Here is a dashboard in Tableau
that shows top 10 disease diagnoses for one of
our hospital systems, with lots of information about
the distribution across sex and race, co-morbidities,
distribution over patient age. And the fun thing is you
can click down on that list, and you can see this refresh,
and the numbers change. Scanning 133 million
diagnosis records, and it refreshes and does
all that recalculating in about 10 seconds. Here’s a static copy of the
thing I’m going to show you that tells us a little bit
about how the flu is spreading in the Denver metro area, year
over year, and time over time. And I’m told that
for this to work, I have to come click on this. This works, right? That moves. Check it out. This is in Tableau. And you can see on
the left in that map, those dots are our
various clinics, and we’re seeing the rate at
which the flu is spreading. And we’re comparing
that year over year with each of those
columns on the right. Again, kudos to my
team and to our great BI developers and
analysts who figured out how to put this thing together. We’re going to let that
flow for just a minute, because at the end something
really cool happens. One of the unexpected
side benefits of moving to Google
BigQuery is being able to take advantage
of Google’s efforts to bring public data
sets into BigQuery. For those of you who haven’t
worked with BigQuery, the interesting
thing is it’s sort of like one great
big, shared DBMS. You have data, other
people have data, and assuming that the
permissions are set correctly, you can join across
to different data sets with literally one join
statement in your SQL command. So you’ll see this thing
come to the end of its period here in just a minute. Look at that big spike in 2014. The scientists got the flu
vaccine wrong that year, and we’re a little
bit nervous about what 2016 is looking like. But now, just to see
what’s possible here, the magical mouse is going
to move up, click a button. We’re going to color code
those trends on the top according to weather. So that is blue when it’s
cold, and red when it’s warm. And that data was brought in
almost instantly with one join to a public data set from Google
that talks about daily weather station data. So we build real
stuff with this. And that’s all I have. So thank you. [APPLAUSE] JOE CORKERY: All
right, I’m going to go through this last part
pretty quickly, because I want to make sure we have time
for Phil to join us on stage. So in addition to
Google Cloud Platform, G Suite is a popular tool
in the healthcare business to provide secure productivity
tools to help you help others. I’ve always enjoyed this quote
here about G Suite from Roche– and actually I think the
original quote says “apps” because that’s when they adopted
before it was called G Suite– saying, “G Suite will allow
our employees to focus on what matters most– saving patient lives.” Much like I talked
about earlier– HIPAA compliance guides. We also have one for G Suite. If you go to the
G Suite site, you can get that information there
on how to properly configure that environment to bring
PHI to the cloud for use in these productivity tools. And with that, I
wanted to invite Phil back up to talk about
the work that Veritas is doing to help customers with
their G Suite in healthcare. Thank you, Phil. PHIL YACCINO: Thank you. Hi, everyone. I’m Phil Yaccino with Veritas. What Veritas is able
to provide for G Suite is really a Software
as a Service product that helps you move to the
cloud and helps you be compliant with HIPAA regulations. So what we do, essentially, is
provide a compliant repository for your mail data. So your Gmail information
that comes to you, it gets brought into
our EV.Cloud product. EV.Cloud makes what we refer
to as an immutable copy. So it can’t be deleted,
it can’t be altered, it can’t be changed. What we’re then able to
do is provide a workflow that allows you to do search
and production for legal matters or compliance matters. So if you have needs
to prove that there is data that has user-based
information in it or patient-based
information, you can search for that
and output that for the need that you have. Additionally, you can
also do the same thing for court matters. So it gives a lot
of flexibility, and it’s all within
an audited process. So you’re able to
have chain of custody, you have legal
discovery, and also be able to respond for requests
for patient data as well. So it gives you those– covers those three areas and
allows your HIPAA compliance at the same time. And really, that’s the goal. It allows you to
simplify your workflows. It allows you to meet
regulatory and legal compliance, and able to improve your both
IT infrastructure and also your eDiscovery
productivity, as well. So basically what
we’re able to do is a “better
together” scenario, be able to improve what G
Suite already has in place, and give you a product that
allows you to be compliant with regulatory needs. [MUSIC PLAYING]