<v Jordan Cooper>We're here today with Oliver Galicki, the associate vice president of EHR implementation at Memorial Hermann Healthcare delivery system. Oliver, thank you for joining us today.</v>

<v Oliver Galicki (Guest)>Absolutely. Thank you for having me, Jordan. I appreciate it.</v>

<v Jordan Cooper>Yeah.</v>

<v Jordan Cooper>Sure. So for our listeners, memorial Hermann Health System is a 19 hospital 4300 bed health system headquartered in Houston, TX. And today I'd like to talk about the migration from Cerner to a single instance of epic at Memorial Hermann Health System.</v>

<v Jordan Cooper>We are Memorial Hermann migrated from five other regular scheduling systems as well in addition to Cerner 2A single instance of EPIC and is replacing another 45 systems including document imaging systems, a blood bank, a medical device, integration vendors and others.</v>

<v Jordan Cooper>Uh, all of our like to ask if you wouldn't mind speaking about some of your goals with this migration and any sort of complications and problems that your team has encountered over the course of this migration?</v>

<v Oliver Galicki (Guest)>Absolutely. So I'll, I'll start, I think, which by setting the stage of where we are currently in the project, we are concluding what is known as Epic build way of #1. So we're early on in our configuration phase with the EPIC implementation. So we certainly have lofty goals to achieve a lot of standardization across our system and elevate both our provider clinician experience in the clinical space as well as our employee experience in our back office spaces with that focus on our consumer experience as well some of what we're looking to achieve here really comes with.</v>

<v Oliver Galicki (Guest)>Being on a legacy system for a number of years and and not just specifically around the Cerner instance, but really several of our platforms have been with the Memorial Health System, Memorial Hermann System for quite some time. And so the opportunity to take a fresh look at our technology stack, bring in Epic and the best practice methodology that that typically brings with it is something that we're looking to to really benefit from as an organization. I think what you hit on in terms of scheduling and registration, platform standardization.</v>

<v Oliver Galicki (Guest)>Certainly is something that we see as a very achievable and and desirable goal and one of our guiding principles that we have to achieve in this additionally with that the opportunity to have the single billing office between our physician network as well as our hospital billing operations is another satisfier, both internally from being able to manage our operations as well as ultimately to the patient experience. And then I think everyone in the industry knows where my chart stands in terms of a patient engagement, consumer experience platform.</v>

<v Oliver Galicki (Guest)>And so leveraging that with all of our other initiatives and that space is also at the key platform that we plan to take advantage of.</v>

<v Jordan Cooper>Yeah. So I appreciate you giving us an overview of where you are keeping in mind that you haven't yet concluded the migration to epic. I know many of our listeners have either recently completed are considering undergoing or are like you in the midst of a migration to epic.</v>

<v Jordan Cooper>What are some of the complications or problems and the reason I ask is because I think many of our listeners who may either be considering to going down this road or currently in the midst of doing it, may like to listen to some of your particular scenarios and potentially learn from some of the lessons that you have gleaned over the course of this migration.</v>

<v Oliver Galicki (Guest)>Sure. I I think one of the the upfront challenges everyone has to figure out is, is the financing and how do you pay for EPIC. And I think that's what any large capital investment you have to go and do the research and due diligence behind that. One of the opportunities that we really one of the challenges we faced early on was really articulating the the financial was overcoming that perception that it is such a cost barrier to enter into to bring epic up in such a large system at our scale.</v>

<v Oliver Galicki (Guest)>But ultimately what we were able to do is go through a very thorough application rationalization process to really understand what do we spend across our IT infrastructure today. What does it look like if we host internally versus hosted Epic and start thinking about the realities? We wouldn't sit still and do nothing if we chose not to move to EPIC, we would make other investments into other platforms moving forward. So that hurdle to clear once you start telling the story of what all we will gain and what that really looks like over time and putting it in perspective of other large capital initiatives that we do.</v>

<v Oliver Galicki (Guest)>More routinely, so building a new tower, expanding OR suites. And where does this capital investment fall into that we were able to overcome that through some of our due diligence process. I would say a second hurdle that everyone is probably focused on in today's world is staffing and how do you find the amount of talent you need to staff your epic project? So with that, we really had several different approaches going into it. How would we do this? We assume we have a very strong tenured team at the memorial. Hermann.</v>

<v Oliver Galicki (Guest)>Information Technology Department today they've all because of that, tenure had a lot of experience with our existing platforms and so there was an honest pause to say how do we bring everyone along on this journey and use the skills that they already have in the epic world. And so I think going in our assumption was we'd have to go find contractors to fill the entire roster of the project and then ultimately over time try to acquire that knowledge.</v>

<v Oliver Galicki (Guest)>All what we were able to do though, and ascertain as we went through that staffing process with EPIC, was we, we have a lot of the talent we need internally and so leveraging internal talent got us over that hump of fighting everyone else in the market for contractors having to open up FTE positions long. That would obviously extend and have a long term expense as you carry that forward. So we've taken an opposite approach and really chosen to invest in our own team to overcome that hurdle.</v>

<v Jordan Cooper>Interesting. I. Yeah, I now with the staffing is has actually been one of the greatest challenges facing large health systems in the United States. So in fact, size doesn't matter. It's a big challenge regardless of of where you are. I think the story of leveraging internal talent is an interesting one. Did you find that there was available, did you have to kind of increase their hours or did you destash them and deprioritize other projects? How did it affect the overall mission?</v>

<v Jordan Cooper>And strategy of the teams that to which they were previously assigned.</v>

<v Oliver Galicki (Guest)>Yeah. So I'll I'll walk through a little bit of the thought process. So obviously, we knew the number of seeds we needed to fill on the implementation team. We, we didn't expect to fill all 200 seats with 200 existing employees. We knew some sort of expertise embedded within those teams would be needed. But we started with basically a call to action, a call for interest from our existing IT employees. So this is your opportunity, if you'd like to be part of the project, if you would like to be on the project and maybe have an interest in a specific application that you do or don't work in today.</v>

<v Oliver Galicki (Guest)>Maybe you're not in applications, but you have an applications interest and so that gave us our denominator of who who was interested, who is ready for this journey. We obviously articulated what that would look like from a from a pace perspective of this is a two to three-year effort. It really doesn't have any lulls in between on all of that. Once we knew that we used the epic stinks assessment that they developed to really benchmark our staff against the skills that would be needed to be successful at least in the implementation window during that pace.</v>

<v Jordan Cooper>Umm.</v>

<v Oliver Galicki (Guest)>And from there we were able to staff those positions two applications based on their complexity based on what the person's talent, their internal performance reviews etcetera to build out our full project team. And yes, we did fully distaff them from the moment they stepped on the plane to go to training with the at epoch. We removed them from their day-to-day jobs and epic training and certification became their full time job from the get go. What we did was then form a backfill.</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>We've called our foundation team to keep operations running to keep regulatory compliances. We very much believe that both sides of this equation are important. I think having done implementations before, if you're trying to do both then the fire is always win. You have to take care of the fires that are stopping operations and then that distracts from the project. And if you try to do the project then you can't manage the business and the business will go out and find other IT solutions that come in and change your scope ultimately. So we've made a focus commitment of.</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>Of aligning but splitting the actual work efforts of the two teams, and it has been incredibly successful up to this date in terms of certification rate and that's really where that came in as we need people to get certified because we're making this commitment, we want 100% certified build team at this point. We're hovering around the 98% mark. So we're nearly done with that with that goal of certification and it only would have happened, it only could happen if we if we did that split.</v>

<v Jordan Cooper>Got it. So was it more, is it more difficult to backfill operations roles or to hire for Epic implementation team members and the grocer members?</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>Yeah, that's an interesting it's it's an interesting question and I think it honestly depends a little bit on the module or the application you're looking to fill. I think for example, we had several of our analysts who focus a lot on our oncology radiation oncology platforms. They moved over to the Epic Project team and they left a void of knowledge on the Rad ONC space and that is a very niche application space. There's really only two major vendors out there and we happen to have both of them in house. And so to find an application analyst in the consulting world who could go in and fill that bucket on our operations team.</v>

<v Oliver Galicki (Guest)>Was challenging. I mean we we ultimately did, but that wasn't something that you can go post on LinkedIn and get 50 hits.</v>

<v Jordan Cooper>Yeah.</v>

<v Oliver Galicki (Guest)>UM, on the other side of that, there's a very, very tight market for some of the ancillary consultants in the epic world. So specifically thinking about Beaker specifically, Radiant cardiology, Cupid, those are a little bit more nuanced. And to get analysts in there that will commit for the time frame that we needed as well as ideally have some familiarity with the third parties that we're using in those spaces, whether it's GE packs or Agfa from a cardiology perspective.</v>

<v Oliver Galicki (Guest)>Uh, so I think it depended. In general though we were able to.</v>

<v Jordan Cooper>Got it.</v>

<v Oliver Galicki (Guest)>To fill the the the void on both sides of the equation that was left. So either the the delta we couldn't fill internally and the feeds vacated.</v>

<v Jordan Cooper>So for CIO's listening to this particular episode and there's, let's say they're saying, OK, so our organization is thinking about moving to a single instance of epic and we have to learn how to staff up and recruit for this endeavor. It sounds like if they were to follow your recommendations, it might be, let's pull some. Let's not start from scratch with either side. Let's pull some of our operations, get them up to speed on epic, then we can hire additional epic people. But we won't be starting from zero, and we're not gonna decimate.</v>

<v Jordan Cooper>They're OPS team will take only a certain level. There will have to be proficiency with this with the Sphinx certification from EPIC, but Even so, we're not going to take everybody. We're gonna leave a certain amounts that the base operations can get done. We're gonna get a certain amount of people for the unepic side who are already current employees. Memorial Hermann. And they're gonna get up to speed. And once you're at a certain percentage of capacity on each side, then we'll try to hire up the fill the gaps so that we can kind of scale up over time as that is that an appropriate kind of summation of what you've.</v>

<v Jordan Cooper>Right, but an operation.</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>Very much so. That's a great summation. I think you articulated the thoughtfulness around it too. I think our leaders in our IT team were very thoughtful around how do we do this and understanding that there might be more people who want to be on the project team than can be on the project team. There's only so many seats for right now. Our ultimate vision though is that these teams come back together as one and we bring certification along for everyone. And so that's the benefit here too is we'll have our own team training up who went through the implementation training and bringing on board the rest of our team. And we come back together as opposed to.</v>

<v Oliver Galicki (Guest)>A whole void of knowledge leaves and moves on to the next project out out in space with another organization, and we have to fill a lot more holes moving forward.</v>

<v Jordan Cooper>Yeah, I think that your strategy allows for a conversion or a translation of institutional knowledge.</v>

<v Oliver Galicki (Guest)>Right.</v>

<v Jordan Cooper>As opposed to weaving a void, right, I think a lot of organizations have a challenge of a lot of the expertise that's necessary for a certain role in one or two people's heads, and they're oftentimes, many organizations are struggling to create processes that convert individual knowledge into institutional knowledge. And it sounds like your processes are designed to facilitate the creation of that institutional knowledge.</v>

<v Oliver Galicki (Guest)>Agreed 100% and I'll give a real time example. It's not just what I see coming when we transition and go live and move back to normal operations. It's actually happening in real time during the course of the project, so.</v>

<v Oliver Galicki (Guest)>An actual example is a consultant on our Epic team that we had augmenting the team they due to medical reasons had to withdraw from the project and we have a slot and certainly based on the EPIC staffing guideline, we need to fill that spot well. We're now given this conversation around can we hold on this spot for three months and bring someone else over internally to come join that team. Instead of this, we have to go fill it with the consultant. So we've created a where we have balance on both sides and depending on the team and the need, how long are we OK with the build with existing resources.</v>

<v Jordan Cooper>Umm.</v>

<v Oliver Galicki (Guest)>We're making decisions to go ahead and say, OK, you're you're you're coming over early from side A to B and we're going to get you trained on epic and you'll Join Now and then that essentially translates to another person internally knowing the epic product, but also we're only doing that when we can manage the demand on our foundation side, so.</v>

<v Jordan Cooper>Umm.</v>

<v Oliver Galicki (Guest)>Alt every everyone embarking on this project hopes that your intake of new work decreases as you go on in the project, and so our vision would be moved more people over as the work decreases for our run and maintain foundational team. As we branded in.</v>

<v Oliver Galicki (Guest)>Sure.</v>

<v Jordan Cooper>So I would like to well I guess, but change I'd like to pivot a bit. Let's go back to the epic migration and away from human resources. I'd like to ask you about the technical challenges of migrating interfaces, archiving Cerner instances you have. You spoke about justifying the need for 45 external vendor applications where there's real phthisis that's living in those applications.</v>

<v Jordan Cooper>How do you scale down as applications consolidate archive, make it available for future needs? What's up? What are some of the technical challenges associated with migrating to a single instance of epic, and how have you been attacking those challenges?</v>

<v Oliver Galicki (Guest)>Yeah. So one of the biggest shifts for our organization just conceptually is that today, our Cerner platform is not our legal medical record. We have an independent document management system that receives all the feeds from Cerner and other subsystems. So in a sense, it is our legal medical record, our document management system. With that being said, Epic certainly has a different philosophy where epic is the legal record.</v>

<v Oliver Galicki (Guest)>And so that sets the stage for a lot of our archiving and rationalization decisions on where data needs to go. So from a technical perspective, obviously everyone wants to convert everyone in operations certainly wants to convert all the data and get it into EPIC. So it looks and has everything you need. We've taken a measured approach with clinical input to really take the epic recommendations on data conversion for X topic, whether it's lab, radiology, etcetera, adopt those best practices and focus on getting that data in within creating an.</v>

<v Jordan Cooper>Umm.</v>

<v Oliver Galicki (Guest)>Context sensitive launch to an archive solution. So our vision is we take our existing document management system, convert that to an online archive and then have a patient context sensitive launch from EPIC to get to that archive. That being said, not everything is in that magical archive or document management system today. Some of those applications that are out there that serve a very specific purpose. So we've actually created what we're calling our Sunset tracker and what that does is that's helping us identify systems.</v>

<v Oliver Galicki (Guest)>Invalidate systems with Phi systems that currently go to our document management system. Systems that go to our fair warning because archiving our security logs for these systems that might go away. Equally important to our privacy office and so through this tracker effort we've essentially been able to then scope out what do we need to move into that archive Maria up the MPI so that it can be accessed from Epic ultimately. So our vision is that we don't have 40 systems that are sitting in virtual machines that we have to power on power off for the next 10 years.</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>In order to access archive data, we really have seen the archival as part of the project because I think anyone who's done this before knows that if you just leave things running and say you'll decommission them, the next meaningful use or the next, something comes along and you move forward and then truly right now we have a some Turner Classic systems from 2006 that we have to power on and off from time to time to get data out of. So that's not the future we're trying to address that here and now. So from a technical perspective.</v>

<v Oliver Galicki (Guest)>It's really more around.</v>

<v Oliver Galicki (Guest)>Understanding the scope and identifying what resources are needed to get data out of these systems and then balancing that with some of the SAS platforms that might go away where we can't just tap into the database like we can with on Prem systems.</v>

<v Jordan Cooper>Right. Have you thought about consolidation consolidating the number of interfaces and if you thought about any sort of cloud migration?</v>

<v Oliver Galicki (Guest)>Yeah. So, so one of the big shifts for us just from a platform perspective for Epic is Epic is going to be hosting our instance of epic. So we're currently a self hosted Cerner customer today and now so this is a big shift for organization to say we will be reliant on Epic and their hosting services to keep our operation up and running. And obviously partner with that from an interface perspective. Yes, our goal is certainly to rationalize the number of interfaces we have just thinking about our existing registration scheduling platforms that we have today.</v>

<v Oliver Galicki (Guest)>That's where the bulk of your messages come from, and so the fact that we are currently working with with four or five of those different Reg sketch systems, that's huge amount of interface and message traffic that we all run through our engine and route and ultimately map to a single MPI well. You put epic in the driver seat of that and you just reduce the complexity of that equation significantly. So we we do expect to see that decrease. We just finalized our interface scope. And so I don't have a form of former full count to say you know, X to Y.</v>

<v Jordan Cooper>Mm-hmm.</v>

<v Oliver Galicki (Guest)>But when we decrease that number of interfaces then the complexity I think on the other end of this, we'll certainly have a a more nimble approach to being able to add something on. I'd also just throw out there the native epic integration from epic epic instance, I mean tick the Texas Medical Center area, the Houston Metro is an epic heavy.</v>

<v Oliver Galicki (Guest)>UM, part of the country and so some of our interfaces are with other partners in the Texas Medical Center, specifically UT Health, who's also on EPIC.</v>

<v Jordan Cooper>Umm.</v>

<v Oliver Galicki (Guest)>I the numbers over 30 of interfaces that we have bidirectional exchanging data with them today and the move of mortal Herman to Epic and having native care everywhere function will get rid of, I would guess certainly 50 to 75% of those interfaces on the other side. So maintenance goes down of those interfaces the quality goes up because it's epic to epic and so because of our alignment with UT, especially at our Texas Medical Center campus, we see huge value just right there.</v>

<v Oliver Galicki (Guest)>And in some of our transitions of care and patient management.</v>

<v Jordan Cooper>Right, OK. So we are approaching the end of this podcast episode and one of the topics you wanted to cover was enhanced interoperability with aligned partners of care everywhere. And you teach you. I'm glad we got to that topic. You'd also mentioned and I'll leave this to you because we are approaching in the episode. If you care to address the parallel Enterprise Imaging foundation and how that's playing into this migration or if you wanna just kind of elaborate on any of the topics we've covered here before.</v>

<v Oliver Galicki (Guest)>Yeah, I I think I can give you a quick couple minutes on that and then we can we can wrap. I I think just to say other organization out there, I'm sure in in a similar position over the years we've acquired a number of different imaging solutions. Some of them are mainstream radiology solutions and cardiology solutions, others are very niche packs and systems for ophthalmology or for dental exams, endoscopy, et cetera. And one of our challenges we are faced with really with the EPIC implementation was, are we going to integrate our three or four different viewers that we have today.</v>

<v Oliver Galicki (Guest)>Into epic, and even though we might maintain those solutions is having four viewers ideal, the answer is no. You you don't need four different viewers where you can't see all the images in one view. So we have a really a fledgling DNA program that we were at enterprise imaging program with the DNA that we just stood up. It was really only radiology centric. So in parallel to Epic, we're dipping our toes into bringing some of those other oology images together so that we can then take the step forward of hey with epic, there's one single viewer.</v>

<v Oliver Galicki (Guest)>For images from someone who's launching from Epic, and I think it's a bit of a, I don't wanna say scope creep, it's certainly planned, but you get further and further into the imaging space and there's more and more technical dependencies that open themselves up for upgrades and storage migrations, et cetera. So we're watching it very closely to make sure we do what we need.</v>

<v Oliver Galicki (Guest)>But ultimately have to come out of this with one viewer because we're we're choosing not to do the others. And so there's certainly some work to go there. I think I don't I don't regret that decision right now. I think as a project team, we're comfortable with it, but we have a lot of work to do to balance out that effort in conjunction with EPIC and some shared resources and some not.</v>

<v Jordan Cooper>Well, Oliver, I appreciate the conversation we've had today. We've covered a lot of ground from migrating from Cerner and archive based system with 45 different vendors through the single instance of epic tracking. The have a sunset tracker to view how those things will be moving offline and keeping our PHP secure. Just speaking about reallocating staff within the organization and trying to handle the HR recruiting staffing model, that is.</v>

<v Jordan Cooper>Required on and the extent to which it's gonna be internal, the organization versus pulling in external consultants and trying to perpetuate sense of institutional knowledge. And then we even spoke about partnering with external entities, both with care everywhere and then also well to lesser extent non epic players and interact with those. So and then we even got into enterprise imaging. So I think we covered a lot of ground. Thank you for your time today and.</v>

<v Jordan Cooper>For our listeners, just has been all of our galicki, the associate Vice President of EHR implementation program and Memorial Hermann Health System. Oliver, thank you very much for joining us today.</v>

<v Oliver Galicki (Guest)>Thank you, Jordan. Have a good day.</v>