Behind the Scenes Episode 378: Electronic Healthcare Records with AWS FsX NetApp

Welcome to the Episode 378, part of the continuing series called “Behind the Scenes of the NetApp Tech ONTAP Podcast.”

2019-insight-design2-warhol-gophers

The more healthcare companies start to digitize their records, the more they realize they need more capacity to do it, but they don’t always have the resources to manage it. That’s where the cloud comes in.

The Amazon AWS FSx NetApp offering provides a plethora of features that help enable EHR workloads to perform better, save space and provide a viable and efficient disaster recovery plan with immutable backups for better protection against ransomware.

NetApp healthcare expert Brian O’Mahony (omahony@netapp.com) and AWS healthcare SME Randy Seamans (seamansr@amazon.com) join us to chat about all the benefits of ONTAP, AWS and FSxN for EHR workloads.

For more information:

Finding the Podcast

You can find this week’s episode here:

I’ve also resurrected the YouTube playlist. You can find this week’s episode here:

You can also find the Tech ONTAP Podcast on:

I also recently got asked how to leverage RSS for the podcast. You can do that here:

http://feeds.soundcloud.com/users/soundcloud:users:164421460/sounds.rss

Transcription

The following transcript was generated using Descript’s speech to text service and then further edited. As it is AI generated, YMMV.

Tech ONTAP Podcast Episode 378 – Electronic Healthcare Records with AWS FsX NetApp
===

Justin Parisi: This week on the Tech ONTAP podcast, we talk all about EHR in the cloud with Brian O’Mahony and Randy Seamans.

Podcast Intro/outro: [Intro]

Justin Parisi: Hello and welcome to the Tech ONTAP podcast. My name is Justin Parisi. I’m here in the basement of my house and with me today, I have a couple of special guests on the phone to talk to us all about EHR and the cloud. To do that, we have Brian O’Mahony. So Brian, what do you do and how do we reach you?

Brian O’Mahony: Hi, my name is Brian O’Mahony. You can reach me at omahoney@netapp.com. That’s O M A H O N Y. I am a business development in healthcare. I’ve been in NetApp for 13 years. Good to be here.

Justin Parisi: Also with us today, we have Randy Seamans. So Randy, what do you do and how do Iwereach you?

Randy Seamans: Well as you heard, I’m Randy Seamans. I am a principal storage specialist at AWS. You can reach me at seamansr, that’s S E A M A N S R@amazon.com and I’ve been doing all things storage for many years, too many to admit, in fact.

Justin Parisi: All right. So we should have a good conversation here about storage as well as the EHR industry.

So to do that, we want to level set and talk about EHR in general. So what is EHR?

Brian O’Mahony: Yeah, electronic health records you’ll also hear electronic medical records or electronic patient records, essentially taking patient data instead of writing on a piece of paper with really bad handwriting, you put it into a computer system.

The Affordable Care Act had a big influence in the U.S. in requiring that all electronic records be digitized. There’s also initiatives in other countries like in Europe, in the U. K. that are going through the motions of putting all the patient records and digitizing it. There are still tons of paper and CDs and DVDs lying around. You know, faxing and old technology out there. Healthcare doesn’t change quickly and we’re still in that process. But we’ve come a long way. The majority of hospitals in the US have been digitized.

Justin Parisi: And what sort of players do we have in the industry? What sort of applications, what sort of software is out there?

Brian O’Mahony: There’s tons. Epic, would be probably the biggest and then Cerner, and Meditech. They all have varying advantages and features and functionality. In the U. S., for larger hospitals, you’re going to see a lot of Epic. For some of the smaller hospitals, you’ll see a lot of Meditech.

Justin Parisi: So tell me a little bit about how this data set is constructed. What does it look like when you’re laying out an EHR on a storage system?

Brian O’Mahony: You’re going to see a lot of commonality between each of the systems. You have this central database where the data records are read and written to.

Most of them will have multiple copies of that for disaster recovery, or you might want to offload your copy of your database to run reports against. And then, with a lot of databases that store documents and images like SharePoint, you can move those documents and images, which take up a lot of space, into blob storage. So you end up with a lot of SAN a lot of NAS and lots of different tiers of storage for the production database. You’ve got the client data, you have the blob data. It’s a pretty complex ecosystem of requirements for each of the EHR systems.

Randy Seamans: Yeah, I’d like to jump in there. So typically the database of record or the production database might be somewhere on the order of 10, 20, 30, 40, 50 terabytes. But because you have many environments that leverage that database, perhaps your total need for high performance storage, may be 100, 200 terabytes. And as Brian mentioned, the surrounding ancillary sort of processing, there’s quite a bit of it too.

So those are anything basically not directly involved with the operational database. So those may be two, three, four, 500 terabytes as well, depending on the size of the organization.

Justin Parisi: So you have databases that are very large and then the images themselves, I guess they’re not stored in the databases.

They’re stored externally and you have to kind of reference them elsewhere. Is that how that works?

Brian O’Mahony: That’s exactly how it works. So you want to extract those images and documents into the blob storage. For example, Epic uses web blob and it’s usually a NAS share and you have pointers from the database to pull that up when you’re accessing somebody’s records, there’s images and documents. It pulls that data.

Justin Parisi: So you’re dealing with very large databases and then very large data sets of files. And I’m guessing the databases generally will they reside on SAN and then the files themselves will reside on NAS? Or is there a mix of the databases being on SAN and NAS?

Brian O’Mahony: No, a vast majority of the databases will be over a SAN protocol.

Predominantly right now, it’s the fiber channel in the cloud. You’ll see a lot of iSCSI in the cloud and NVMe over fiber channel is showing great promise. 30 percent increase in performance, reduction in compute requirements. It’s starting to become mainstream, but we’re a few years away from everybody transitioning to NVMe.

Justin Parisi: It’s too bad there’s no storage operating system out there that can do both SAN and NAS.

Brian O’Mahony: Man, if we could only find one.

Justin Parisi: If only.

Brian O’Mahony: Well, one of the key advantages of ONTAP, it does file, block and object. If you look even beyond EHR, there’s a massive ecosystem surrounding EHR, all of these other applications that integrate into it.

And they’re built by different people with different processes. And you end up with this siloed inefficient approach. If only you had an operating system that does file, block, and object together and has multiple tier performance capabilities and you can manage your SLAs? ONTAP is that. 25 percent of healthcare spend is really wasted on that inefficiency.

So it’s a huge cost savings to simplify and to consolidate so that you have one strategy for your data management.

Randy Seamans: Well, not only one strategy, but with ONTAP, you’re actually optimizing each one of those three abstraction levels: the file, block, and object. So you’re operating in each of those domains in an optimal efficient manner versus, oh, I can just do those abstractions of storage levels.

Brian O’Mahony: Performance obviously is important and the databases are very large. But availability is critical. When you talk to each of those EHR vendors, it’s life and death for them. Lives have been lost because EHR systems are down.

And when you look at everything, the NAS piece is as important as the SAN, because either one of those go down, you’re losing access to your data and you’re disrupting patient care. So availability is a huge part of it. And that’s why you have so many copies of the database for DR and shadow copies, et cetera.

Justin Parisi: Yeah, that’s how the old saying goes, the best ability is availability. So, traditionally the EHR workloads have been on prem, but now there’s a push to move more and more towards the cloud. So talk to me about that transition. What started that initiative?

And what are some of the challenges for these EHR environments?

Brian O’Mahony: Yeah, so there is a big push for healthcare organizations to get out of managing the data center. It’s very challenging for them and they’d rather focus on improving patient care. So, if you look today for various EHR systems, around 70 percent are still on prem, meaning traditionally deployed.

But if you look at new deployments over the last five years, 70 percent of them, over 70%, have actually deployed it outside of their data center. Either hosted at the ISV or in the cloud at some other data center. So there is a trend and it’s moving in the direction of the cloud.

Randy Seamans: Let me jump in there and say some of the reasons why this is occurring.

The clients are able to reduce their total cost of ownership of their environment that they’re running. They’re also able to scale their environment easily and right size, which means, of course, the opposite of scale. If you had a shrinkage of growth, which is usually not the problem in health care, be able to turn the knob down and save some expense. And of course, you have the mergers, growth and acquisition normally that’s going on in EHR. So the cloud allows you to respond to that in a more granular manner. You don’t have to look 3, 5 years down the road and predict what your performance and your storage capacity would be because it is pay as you go.

That’s the whole reason the cloud exists. And don’t know if you’ve seen the press lately, but there’s a lot of stuff around AI and we’re getting a lot of traction here. This is the third coming of AI. So I’m so old, I was in the second coming. The first coming was in the fifties or sixties, then it was very popular again in the eighties.

And now we’re finally have the compute and storage power to be able to make very practical business oriented AI apps, and a lot of that is in health care. And so an easy way to be able to leverage that instead of having to build out an AI infrastructure and compete with the big boys for getting GPUs and talent is to leverage the cloud.

So, that’s why a lot of people are thinking about getting a second copy of their EHR environment in the cloud, or maybe a DR copy. We’ll cover that a little later in the use cases. But that’s a primary mover that we’re seeing.

Justin Parisi: That’s interesting. You said a second copy. So that sounds like they’re looking at doing work in both arenas, like having a hybrid cloud approach.

Randy Seamans: Well, sure, that’s a very popular one. That’s probably the most popular, that and backup are a second copy in the cloud. But let’s don’t move off of this question you had about challenges of moving EHR to the cloud, because our audience may be thinking hey, but… How would I do that? Some of the challenges that we see when customers first start looking at the cloud are they have an assumption that they’re going to provision using the same methods as they’ve used on premise for years and years. And that’s based in a capital acquisition process versus a pay as you go.

So the first thing you have to do is look through the lens of on demand and rid yourself of the notion that growth is painful because if you configure your environment correctly in the cloud, growth is literally push the button and you’re able to double or quadruple your performance and your storage at the drop of a hat.

So no longer do you have to worry about the 3 to 5 year horizon for your growth. What happens if your hospital acquires another facility? How do you plan for that? The other challenge that I see is that cloud services are consumed differently, so it requires a little bit of new knowledge, and that’s why FSxN is such an easy path to be able to leverage the cloud because you can leverage your existing knowledge base on prem, your staff, they know about block, they know about file, and perhaps they’ve heard about object, but ONTAP really manages all of that complexity for them.

Brian O’Mahony: So Randy, I want to layer on top of what you just said. So there’s wonderful advantages by going to the cloud, like DR, right? You can do a pilot like deployment, save tremendously right size, all that stuff you just covered. One of the big challenges is when you have that critical application, your EHR application, That’s the big anchor, right?

How do you run that in the cloud? So you can’t take advantage of all that unless you have this platform that can run effectively, reliably, your EHR system. And that’s what FSxN allows you to do. The lift and shift component for simplicity, yes, there’s a lot of cost saving and everything else, but EHR application vendors are very strict on requirements and FSxN bridges a lot of those gaps.

Justin Parisi: All right. So you said the magic word of FSxN, so what is that?

Brian O’Mahony: Yeah. So that’s a very good question. That’s what we’re here to talk about. Let’s get into what actually it is. So ONTAP is NetApp’s key storage operating system. It’s been around for over 30 years. Dave Hitz wrote that it was software defined from the beginning and being software defined, allows us to run ONTAP anywhere.

You can run on your laptop, in VMware, up in the cloud, on our engineered systems. So, over 10 years ago we started deploying ONTAP on virtual machines in the cloud using cloud storage. It’s the same operating system, same capabilities, same everything else. And we had Cloud Volumes ONTAP for many, many years. AWS decided to sell FSxN, essentially build their own version of ONTAP as their own product. So essentially all of the built in capabilities for ONTAP, snapshots and cloning and replication, ransomware protection, all those wonderful things that we provide helps AWS bring applications like Epic into the cloud.

Randy Seamans: Let’s talk a little bit about how that actually plays out in AWS. I’ll demystify if I can what the cloud is. So if you’re an on prem guy and you’re used to running your application in data centers, you may have a primary data center. Perhaps you have a secondary data center.

Let’s talk a little bit about the terminology you see used in AWS and other cloud providers. You may hear a term called a region, which is a geographical location. Maybe it’s the Northeast, the United States, the West Coast, the central U. S. or something like that, which is a geographical area where the cloud provider has data centers.

And instead of using the word data centers, we use the word availability zones because in fact, each region will have multiple availability zones and an availability zone in fact is similar to a very closely held small area where there are one or more data centers that are high speed interconnected.

You could think of them as a campus sort of data center. That is really what an availability zone is. And a region is made up of 3, 4, 5 of those availability zones. Now FSx NetApp can run in a single availability zone with multiple copies or servers, that’s called a high availability option, or it can run in AWS spread across multiple availability zones.

So that would be akin to having a primary and secondary data center within maybe a few milliseconds of each other. So Brian, let’s say that customer wanted a primary and a secondary or multi AZ for their ODB database or their production database of record and they wanted really strong DR capability, maybe to another region. Does FSx NetApp provide that capability as well?

Brian O’Mahony: Yeah, it can be deployed in a single AZ or multiple AZ. So when we look at an application like EHR, obviously availability being the most important thing, being able to withstand an availability zone going down is huge.

So you’re adding more nines of availability. And FSxN has that capability. It keeps the data synchronized between both AZs. And if either one of them goes down, you remain with access to the data with no disruption.

Randy Seamans: And you could even further indemnify that by going to a SnapMirror relationship to a different region, correct?

Brian O’Mahony: Correct. So the multi AZ is available. And then for DR, most EHR applications will require that you have three copies and one copy be in a remote location. And so another AZ would be a remote location. It depends on the application. You can do database replication, which is most common. Or you can do SnapMirror and let the storage replicate between AZ.

And if you need to fail over to it, you can break that mirror and bring that environment online very quickly.

Randy Seamans: Yeah, you intimated there about replication methods. So generally speaking, there’s three ways to replicate to the cloud or between premises. Application layer, which many EHR environments do have a ability to replicate their database and other ancillary workloads at the application level. Then you have the storage layer, which is very interesting, with SnapMirror between NetApp and FSx NetApp. And then a third level you could say, maybe we’ll call it the infrastructure level, meaning that you can replicate it at the block or file protocol level but independent of the storage vendor or the application. So that would be somewhere in the middle of the stack that you would have some shim that fit in the stack for file or block and it would replicate there as well. That’s less typically used. The most popular course being the storage layer and application layer replication.

Brian O’Mahony: Yeah, in EHR, you have a combination. You’re going to have application replication and you’re going to have storage replication. For most cases, you need to do both. And the storage replication, there are very strict requirements, like under 15 minutes, and that’s very challenging for most replication applications out there.

SnapMirror, very easy to meet any of those requirements and we know at the block level what has changed and only that gets moved. It’s encrypted at rest and in flight, securely moved into the cloud. For example, some of the blob storage with a single command, you can fail, not just the data over, but the whole environment over into the cloud and bring it online very, very quickly and easily.

Randy Seamans: Yeah. So we’ve talked a little bit about DR. Let’s tick off the rest of the use cases that we see for customers leveraging FSx NetApp in the AWS cloud. DR obviously is very interesting. You want to say a couple of words about backup?

Brian O’Mahony: Yeah, so most EHR systems have a 3 2 1 backup requirement. They want indelible and immutable backups. The databases are very large. Some of them are over 100, 150 terabytes moving towards 200 terabytes. And it’s very challenging to back up. And streaming backups normally doesn’t cut it when it comes to databases of that size.

So built into ONTAP, you can back up those databases by SnapMirroring into object in the cloud, and you can enable object lock in the cloud. So you check all the boxes. You’re taking your data off of ONTAP to another platform – S3, and enabling object lock you’re making it indelible. And those are key features that electronic health record vendors are asking for with their customers.

Randy Seamans: Yeah, that checks the ransomware box. So even if you have a bad actor or you get compromised, there’s no way that they can destroy the backups in that environment. So that’s really cool. Let’s talk a little bit about dev/test.

So in the cloud, that’s a good use case for customers to get their feet wet. So maybe they’re running production on prem. They would like to test out the cloud and FSx NetApp, if you will. So dev and test. How would that work if a EHR customer would like to explore that?

Brian O’Mahony: So part of the EHR systems, you need multiple copies of it. So there’s production copy, you’ve got your DR copy, there’s a report copy, but then you need other copies for the support organization, for managing upgrades. You’re testing the next release.

And various people need access to full copies of your 50, 100 terabyte database and some of them get refreshed every day, right? You can’t really meet those requirements without things like snapshots and cloning capability. You can orchestrate refreshing environments in 15 minutes, as opposed to trying to copy 150 terabyte database that might take you a couple of days. You have to integrate and take advantage of the storage system, and FSxN has all of those capabilities built in.

Randy Seamans: I’ll finish up talking here about workloads. You mentioned WebBlob earlier. Have you seen customers who have only put their web blob in the cloud and meanwhile they’ve kept the rest of the production on premise as a step toward cloud utilization? Have you seen that before?

Brian O’Mahony: Yeah, we’ve seen quite a bit of that. Again, SnapMirror is key for replicating the blob storage. We have a capability called SVMDR, which is used a lot. So not only is the data getting replicated, you can run a single command and the identity of that NAS server gets cut over as well, so the networking, the name of the server, all that stuff. You can either keep the IP address or change the IP address. Very simple. Very popular.

Randy Seamans: The SnapMirror pre-assumes, if you will, that on premise the storage of record is NetApp and then you’ll be using the SnapMirror to replicate to FSx NetApp in the cloud. That’s the unsaid statement that we haven’t mentioned here, but we probably need to do that. Is that correct?

Brian O’Mahony: Yeah, that is correct. If you do not have NetApp on prem obviously SnapMirror is not an option. So, you would look for… Another replication technology to keep those in sync, and there’s multiple out there.

Randy Seamans: And I mentioned those earlier, but if you have any questions about those you can certainly contact me. That’s what I do on a daily basis is help customers replicate from disparate storage to AWS.

Brian O’Mahony: Yeah, you bring up a good point, though. You can use FSxN for EHR in the cloud with not having NetApp on prem. That’s always an option. You can take advantage of the database replication or some third party replication tool.

Justin Parisi: Yeah. In some cases you might have your database on a different storage and you might have your actual data sets, the image files on a NetApp, right? That’s a pattern I would imagine you see a lot out there.

Brian O’Mahony: Oh, yes. Some people purchase a SAN solution and a separate NAS solution. We obviously can do both together and we offer some simplicity there, but it’s common. And the EHR system is very important. Whatever they’re running their SAN on for EHR tends to become the de facto SAN solution for customers and equally on the NAS side.

Justin Parisi: And earlier you touched on ransomware in healthcare and DR is one part of that solution, but I know ONTAP has automated ransomware protection. Does that carry over to FSxN?

Brian O’Mahony: Yes, it does. And I think it’s the number one thing that keeps CXOs up at night, right? Is the fear of ransomware attack.

It is happening. Healthcare is the number one target, because health records are very valuable. So how do you protect against ransomware? We have SnapLock. And now there’s SnapLock Enterprise and SnapLock Compliant, which there is no backdoor.

You can’t call NetApp support to go and delete your snapshots. Truly indelible backups is what you need to incorporate into your solution. And again, that’s built into FSxN. We have lots of customers. You know how things happen, right? You don’t buy a snowblower until it snows.

There was customers in regions where a local hospital gets attacked and all of a sudden they’re reaching out to augment their solution. And FSxN is ideal for that. Very simple to deploy and implement and manage.

Randy Seamans: Now let’s dig on that a little bit about the simple to deploy and manage. FSx NetApp is a first party service. So what do I mean by a first party AWS service? I think Brian talked a little bit about it was a true AWS product. That means that It is fully integrated to the AWS cloud infrastructure. So all the management plane, the logging, and interoperability, with all the rest of the services.

That’s there. And part of the thing that we do when we provide a service is we make it very elastic. So there’s a button on your screen when you’re creating or you’re managing a FSx NetApp and it controls the amount of performance that the FSxNetApp can get.

There’s another button that controls the throughput and you literally, as I mentioned earlier, can click the button and double or quadruple that more easily. That’s on demand so no longer are you in the mode of planning and acquisition and installation and having to worry about that in a production environment. That’s what we mean by first party service.

Brian O’Mahony: Simplicity to me means a lot of things. Cost obviously and managing cost. FSxN comes with efficiencies, tiering capabilities, snapshots and cloning. They all reduce the cost of running in the cloud. But EHR has very stringent requirements and having a platform that can meet all of those built in without going to third party software is critical for simplicity, and that’s what healthcare is looking for.

Justin Parisi: Yeah, and you mentioned earlier having that 3 2 1 approach, so that’s going to make you think more about where you’re putting your stuff, right? And you’re not going to put it all on the same FSxN platform, but you can put it on other FSxN platforms because you have things like SnapMirror. You have things like FlexCache. So tell me a little bit more about some of the features that allows you to keep that three, two, one approach, but stay within the NetApp FSxN ecosystem.

Brian O’Mahony: The biggest advantage that we have for these large databases is the ability to back up to object.

We make that very simple. And 3 2 1, the two is two separate platforms that you need to have your data on, right? So object would be that separate platform. So that’s very simple to build in. You can automate quiescing your database, taking your snapshots and unquiescing it. There’s consistency groups built in.

Even if you scale out to multiple HAs, you can coordinate a consistency group snapshot. And then after that’s done, you can initiate that SnapMirror into object. And the key thing is delta’s forever at the block level. It’s the least intrusive way of backing up your data. That’s all built in. Randy talked about test dev. If you have a 50 terabyte database that you’ve got to refresh every day, you need to leverage snapshots. You need to leverage cloning and those capabilities are in there and can be all managed via API. Very simple to implement, be it Ansible, whatever automation tool that you want.

And most databases replicate at the database level, but as Randy said earlier, it’s the blob storage. You have a combination of storage replication, application replication. You can deploy FSxN in multiple regions. So you can check pretty much every box when it comes to deploying EHR in the cloud.

Randy Seamans: Hey, Brian, you mentioned how easy it was to leverage those objects. Yeah, so the customer really doesn’t have to understand object technology. When you take an FSx NetApp snapshot of your environment, let’s say it’s the production database or maybe it’s web blob or something like that. That snapshot occurs almost instantly. And then what happens to it? The FSx NetApp will actually transition that off to S3 automatically, will it not?

Brian O’Mahony: Yes. So every time you do an update, all the new backups that you made, the deltas of those will be at the block level replicated into the S3 bucket.

You can also use SnapMirror from FSxN to FSxN. I mentioned earlier ransomware. At the destination, you can enable SnapLock on that so that it becomes immutable and indelible and nobody can delete it. So there’s lots of different ways to augment your solution and make it better.

Randy Seamans: Yeah, so those snapshots are stored on S3 and essentially that’s 11 nines of availability. So it’s very durable. I’m sure your listeners are very familiar with S3 object technology.

Justin Parisi: All right. So if I’m an EHR application consumer and I like what I’ve heard here, what do I do to get started?

How do I get NetApp FSxN? How do I get onto the cloud? Tell me all about that.

Brian O’Mahony: To get started on EHR from the NetApp side I work in the industries group under healthcare and we have experts in each of the EHR systems and you can engage us omahony@netapp.com. We have a large team of healthcare experts which would be very happy to help you on that journey.

Randy Seamans: Yeah. And you can get started at AWS with healthcare and life sciences. If you just go to the AWS website and look up healthcare and life sciences, you’ll find a plethora of information there. And you can contact me, Seamans

Justin Parisi: All right. Excellent. Well, thanks so much for joining us today and telling us all about EHR and AWS and Amazon FSxN.

Brian O’Mahony: My pleasure.

Justin Parisi: Alright, that music tells me it’s time to go. If you’d like to get in touch with us, send us an email to podcast@netapp.com or send us a tweet @NetApp. As always, if you’d like to subscribe, find us on iTunes, Spotify, Google Play, iHeartRadio, SoundCloud, Stitcher, or via techontappodcast.com.

If you liked the show today, leave us a review. On behalf of the entire Tech ONTAP podcast team, I’d like to thank Brian O’Mahony and Randy Seamans for joining us today. As always, thanks for listening.

Podcast Intro/outro: [Outro]

Leave a comment