The IT team at one of the largest healthcare providers in Oregon had to tackle transformation while dealing with COVID-19 and the impact of spreading wildfires last year, says Lee David Milligan, senior vice president and chief information officer for Asante.
The Asante health care system includes three hospitals, as well as other medical facilities, which serve some 600,000 people across southern Oregon and northern California. He says Asante sees more than $1 billion in annual revenue, 100,000 emergency room visits per year, 75,000 urgent care visits, and because of COVID-19, there about 8,000 telehealth visits per month.
Milligan spoke to InformationWeek about the new considerations his team had to address in the face of the pandemic, the threat of wildfires, and how they use resources such as communications and collaboration platform Halo Health as part of their forward-looking digital plans.
What was the IT strategy for Asante prior to the pandemic and how did it evolve?
Our system was doing a dual approach to healthcare in southern Oregon. We were doubling down on population health, this concept of how to keep our communities healthy so they don’t need acute care. At the same time, our acute care needs were really booming. Right now, we’re in the process of building a regional cancer referral center. Fairly large, $90 million project. In addition, our flagship hospital that has just south of 400 beds, we’re adding 350,000 square feet to it. We’re doubling the number of operating rooms; doubling the number of vascular suites.
To support that, IT is all-in. All of these things involve IT -- networking, telephony. We had six separate telephone systems because of the combination of hospitals we had built and acquired, so we had a lot of legacy stuff going. Now we’re in the process of converting those six old, legacy scenarios to a unified Cisco system. That’s a multi-year process.
In the midst of all this, COVID happens.
I was already planning on doing this to allow us to be more of a team and have more rapid communication. We had certain silos happening within the teams, so I was going to launch a daily standup, a simple concept. I was in the process of formulating that when COVID hit, so I launched that immediately.
At the time, we had people dropping like flies, getting sick with COVID. I needed to know basic information -- who’s available to work? We have 300 employees in IT, I needed to know which teams were impacted and which ones could move forward. A lot of it was about organizing our personnel and leadership so we could continue to be effective.
In terms of what we did for the organization, every single thing we did had a significant IT lift associated with it. The organization stood up an incident command. In this case, we were dealing with a worldwide pandemic and we didn’t know when it was going to end. Our incident command consisted of our CEO, myself, the chief medical officer, the chief financial officer, and number of key individuals. On a daily basis, myself or one of my directors attended to report out issues we were dealing with from an IT perspective and understand what the plan was.
The other big thing was the switch to work-from-home. We sent 1,300 people home to work. There’s tons of information security implications to that. There’s ergonomic implications to that. One of the examples of the clinical things we did that was really effective was we were the first system in the state to launch a centralized area for testing. We stood up the network for it, the Epic [electronic medical records software] build and all the technology associated with that within 24 hours.
Were there options or technology you considered putting into play, then decided to go in a different direction? Did things fall into place and work as expected?
It was so agile; none of this was waterfall. All of it was agile. The closest thing that we launched that didn’t get great traction was we had screeners at the doors of the hospital. At the time we were trying to figure out if it made sense to do temperature checks. We instituted a QR code scan scenario where folks could answer questions on an app and that would allow them to come into the facility or not. That wasn’t a great scenario. I don’t know that it as totally effective at doing what we wanted to do. Ultimately, we had to hire a large number of people to be these screeners. We were hoping technology was going to step in there and eliminate that need but it really didn’t.
In the west, we deal with wildfires every summer. One of our locations usually gets hammered with smoke pretty hard. This past year, we lost 2,500 homes [across the area], burnt to the ground in a matter of hours. Many of our employees lost their homes. I think about 100 employees in our health system lost their homes; everybody was affected on some level. It made me rethink our approach to disaster recovery.
At the time, prior to the wildfires, we thought we were pretty good. We had two [data] sites that were geographically disparate to some extent. The wildfires, when they were encroaching on our flagship hospital [Medford?], we were minutes away from evacuating. When that was happening, we also got word that fire was also encroaching on our hospital in Grants Pass. It turned out to not be as close as initially thought, but at the time I had this vision that both our data centers were at risk.
That led to us thinking about cloud migration for disaster recovery and particular our Epic data.
What needs had to be met for that cloud migration?
When I looked at this previously, I took the approach that we needed to offload our teams from getting hammered with every new thing that our system has an appetite for. Everybody’s hungry for new stuff or adding stuff on that makes us more competitive. That all takes personnel. I wanted to go to the cloud with everything initially. We’re not an IT company -- we’re a healthcare company; let’s focus on healthcare and get this stuff off our plate.
Turned out it’s more nuanced than that. It can be expensive to offload to the cloud. You can’t just say, “Let’s go to the cloud.” What I ended up landing on with my team was to take a cloud-first approach as it relates to applications. From a hosting perspective, every new thing we do is going to be cloud-based unless there’s some very specific scenario that requires it to be on prem.
That was helpful because the people I interact with who are looking at projects, they understood it was a cloud-first approach and they could bake that cost into the project itself. From a data perspective, it’s a different story. Data can be really, really expensive. We’re not quite there yet.
How has Halo Health fit in with your digital plans?
Halo is our unified communications system. We’ve been on it since 2015. Prior to that, we had a lot of discrepant ways we communicated, including old-fashioned pagers. We were looking for a better solution and looked at a variety of options. We went with Halo and it turned out to be a challenge because people didn’t want to come off their old systems, whether it was pagers that doctors became dependent upon or individual medical groups using their own secure messaging platforms without IT support. They didn’t want to come off those because it was working for them.
It took some cultural shifts and a lot of meetings to make that happen. Since that time, it’s become our standard and we’ve extended it to a number folks who are not employed by us but use our hospitals. The other huge advantage for us is we use it operationally. I would say 75% or higher of all of our [IT operational] issues are worked through Halo.
What is next on your wish list for your IT system?
On the backend when it comes to IT, I am really, intensely focused on the high reliability organization concept. A lot of that can be solved with automating. There’s a lot of opportunity for automation within healthcare IT. If you look at companies like Olive and other companies that do robotic process automation, they’re focused more on the rev cycle and claims management. I need automation within my world, the IT world, and the work that we’re doing. We do massive testing to make sure we’re not breaking something. It takes up a tremendous amount of time. If we can begin to automate those things, even on the back side, it’s huge.