We're here today with Doctor Stacy Johnston, the vice President and Chief Applications Officer at Baptist Health Jacksonville. Stacy is also an epic program executive and a practicing hospitalist. Stacey, thank you and welcome to a Healthy data podcast.

But thanks for having me.

So far, listeners who don't know Baptist Health Jacksonville is a health system based in Jacksonville, FL to operate 7 hospitals in 200 ambulatory clinics. The system has 1100 beds and 2400 providers. So Stacey.

I'd you bring a unique perspective being both a clinical being a clinical executive, a clinician and a information executive at Baptist Health and you've just gone through an epic implementation and you work with 300 applications acting as both upstream and downstream data sources and recipients to and from EPIC. I'd like to ask if you would just walk us through some of that process and maybe your application rationalization process and some of the challenges you faced.

And and overcome.

Sure. So we began this project in essentially December of 2019 and at that time I was just named as the Chief Medical Information Officer at Baptist Health here in Jacksonville. And it was really exciting opportunity. They asked me to lead the epic implementation. And at that time we did an assessment with alongside of our epic counterparts and we found that we actually had more third party systems than most healthcare organizations.

In fact, we are on the top 5% and so at that point in time, we realized that we had to not only implement EPIC, but then actually look at each and every one of our applications to discover which ones do we really need? Can we sunset any additional applications? Obviously, we knew we were moving away from our core EHR solutions from a Cerner and patient space and tech works in the ambulatory space into a single consolidated EHR, both acute and ambulatory are going to be on the same system.

And we also knew that we were going to do a Big Bang. So a Big Bang across the entire health care organization. And so with that being said, what we also learned is that the third party aspects of any EHR implementation is is the most difficult aspect of it. So you have to work with each of your third party vendors to get a new contract, new SOW for new interfaces. And so everything that you were bringing into your old.

Legacy solutions now must come into the new solution and be tested, validated and in that third party work actually begins before you even start planning and building your core EHR system. When I first started this, I thought this is really unusual. We compared it to putting the bathtub in, you know, before you put the plumbing in and and so that was just seemed backwards. When we first started working on it. But I I was glad that Epic pushed on us to do that.

Because the third parties are what often delays a go live and we were able to successfully go live on time with July 30th, 2022 is our Big Bang go live.

But that being said, it was right up until the very end that we were still testing some of our third party solutions. Every interface, as I mentioned, has to be tested. So if we're interfacing with another EHR was one of our external partners that also has to be tested. So it's not just data that's coming in, but it's data that's going out to ensure you know that the right data is in the right place at the right time. This is obviously a patient safety, a quality issue, a revenue cycle issue.

And so in doing that process, we started discussing having standing up an application rationalization team. And so I have a dedicated team that I brought in a senior director and they are responsible for what I call application quality assurance. So they are evaluating, do we need this application anymore? Could canopy sunset if we are going to sunset, where is the data going to be stored? How long do we need to archive the data, working with contracting on negotiating contract.

And in buyouts and then in addition to that, there are also responsible for testing and upgrades. So ensuring that we take the quarterly upgrades for EPIC, ensuring that we do all of this security patching for all of our additional third party systems and ensuring that we test each of our systems to the specificity that we need to again to just ensure the overall quality of each of our applications. Epic being our biggest application, but that at the end of the day, that's still.

Only one of our applications that are teams supports.

I think some of our listeners may be interested in hearing what some of the KPI's have been for the application rationalization team that allowed them to determine which apps would sunset, et cetera.

Sure. So when we when we first started this process, there were applications everywhere and some were small, just a single file type of thing all the way to, of course, a big EHR and and what we didn't really have was a centralized inventory of where all these applications stood, who the owners were, what the contracts were. And so that was really the first thing that we stood up was a centralized repository where we could not only.

Put put the business owner of the application but what its use case was and who was supporting it from within IIS as well as who was the business requester. And then additionally gathering up all those contracts that was actually that took about a year to do in itself was just gathering all of the data and putting it into a central repository at that point in time. We then worked with the business owners to say is this something you still use? And if the answer was no, then that was an easy one.

Rationalize we sunset over 120 applications during this epic implementation process, and so that was one of the things we evaluated.

Additionally, we evaluate UM revenue generating revenue loss. So the revenue and the and the total cost of ownership of that particular application. So we do have in our repository the total cost of ownership as well as is there any ROI attached to this particular application. And then if there's no ROI attached and the cost is significant, we also then evaluated that as being a potential application to replace or sunset.

And in doing so, we have discovered that there might be some that would be a natural fit to continue with our application rationalization, one of them being in particular is our breast imaging solution. Epic has a breast imaging solution and when we began our epic implementation, we decided to hold off on it. We felt that it wasn't quite where we needed it to be, but our clinical end users are now asking to have that whole centralized breast imaging module.

Umm.

To be centralized with the other patient data that they are managing. And so again looking at is there ROI tied to the prior application and since there there is not any we can then look at rationalizing this into our approach which we call why not Epic. So if Epic offers something we are then evaluating can we replace additional applications with EPIC and or some of our other big vendors that we partner with.

So transitioning to the epic post live optimization process and in consideration of your why not epic approach? How has your team been handling integrating data that is external to Epic and leveraging that to provide the to the provider at the point of care for example referrals, images, lab work, et cetera.

That's that's honestly still been a struggle for us. So we when you implement EPIC, there's a significant amount of reports and data repository reports that are available and we brought in most mostly foundational reports and we aren't even touching the surface of what's available on Epic in terms of using the data to the fullest extent. So we did hire a Vice President of analytics and data science and one of.

Her tasks is to evaluate our data repository is actually on Cerner and then looking at how do we integrate that data into Epic and vice versa, how do we get our epic data into the Cerner healthy intent? So we have just recently migrated that EPIC data into healthy intent and then that data repository is able to push out some of the reports. And then we are able to draw that data back into EPIC in order to push reports. So really and.

Enabling Slicer Dicer, we do have Slicer Dicer turned on. However, it's being fully underutilized, so at this point in time it's about training so the data is in the system for Slicer Dicer, but the clinicians aren't using it fully to its fullest extent, and so we've put together a training program for Slicer Dicer to really ensure that not only is the data there and it's correct, but that then our end users know how to use the report writers and creators, and also how to get the reports at their fingertips. So.

Umm.

That is training, but then some of it is the ease of access to the reports and making that as seamless as possible, especially for the senior leaders, the hospital presidents, they they need it to be as easy as possible to get the the data at their fingertips. So sometimes it's about access and location of the reports and then sometimes again, it's about training. But at the end of the day, we need to make sure all the data is correct and that it's in the right place at the right time.

Sure. You mentioned on that clinicians are driving a lot of the development of workflows and in fact Epic made a recommendation at you empower those who use the system to make decisions regarding build and workflows. I'd like to ask now that you are live with Epic, what are some of the greatest use cases and needs that you've found have been requested by clinicians? You spoke about centralizing breast imaging. I wonder if there are any other use cases that you're seeing great demand for. Again, I ask because many of our listeners.

May be interested in seeing if they're clinicians also have a similar request.

Sure. So we when we went live, when we built the system, we were doing it all at virtually during COVID. So right or wrong, that allowed us to add more people into the implementation process. So a typical work group might have 12, we might have had 50. And so we had over 1100 people participating in the build of the system. We had over 300 doctors participating in the build of the system and 100 of those became specialist training specialist users.

So we really felt like we had great physician, physician and clinician engagement throughout the entire implementation. What where we struggled within was change management because we were in this virtual environment of how do these decisions that get made and work groups and get socialized to the rest of the organization, especially since many of our physicians may not be employed by Baptist. And so how to get that word out to our partnering physicians as well too. So we did struggle with change management.

And we had to bring in extra at the elbow support to help us with our go live. But at the end of the day, what we did was we we put the system in.

And and the 1st 30 days is really just about stabilization. Making sure people have access, making sure that all the interfaces are pointing in the right direction, making sure that there aren't any broken workflows that the medications that you're ordering are the medications that are delivered. We had to do a lot of work on the labels that go live the medication labels because they're the print was different than they were expecting into medications, were being delivered to the wrong location. So that's first 30 days, you're just running at.

When a hamster wheel just trying to keep you know patients safe and that you know that end users you know as as you know and as in the loop as you can of all these changes that you're making on a daily basis and then after that you're really focusing on stabilization of the system. So you know ensuring the quality, making sure that those workflows are being trained. But then you know about six months and you start to realize there are some opportunities in your workflows that you originally built you know a decision that was made.

Before the system was built, may not actually apply to the workflow that they were anticipating, and so then it's time to really look back at what workflows do you have opportunities around. One in particular that I feel like we have a lot of opportunity around is for our OB and we we implemented a new perinatal monitor strip monitor solution at the same time of our EPIC implementation. And this was a necessity so that we could have bidirectional interfacing.

Between the the fetal monitor strip as well as epic, and so it was the right decision. But at that time we didn't realize the impact to the end users of monitoring the the scripts remotely. And so in this particular case, it was much harder for the end users, the physicians to monitor the laboring moms as in from a remote location. And so that was a major clinician dissatisfier and they felt was a patient safety event, so in.

Mm-hmm.

Doing so, we looked at other solutions and we were working with our current vendor to see if we could develop an application that they could view on their phone. But and and that was possible. We just felt that there was a need right now. So we decided not to move in that direction. So for a longer goal, application rationalization was actually not going to meet the needs of the clinician. We needed something right now. So we are in the middle of implementing an airstrip, which is a fetal monitor.

Mm-hmm.

Application that the clinicians can have on their phone to be able to just pull it up quickly, see what's going on with the laboring moms, see what's going on with the you know, the baby, and then make this clinical decisions from there. So that's an example of where we went live with something and we realized it wasn't meeting the clinical or the patient needs. And so we had to quickly make adjustments based off of the clinical feedback.

Got it. As we approach the end of this podcast episode, I'd like to ask you about lessons learned specifically touching upon some of the topics we've been covering today. So for example, you just, we've been speaking about application rationalization, perhaps you might tell our listeners how you plan on potentially avoiding the application proliferation that you saw in the past moving into the future. Possibly there's another topic that you've learned from epic implementation. I'd love to ask you what sort of lessons have you learned over the last few years with Epic implementation?

Your application rationalization effort and ensuring that your digital strategy aligns with provider needs.

So the biggest thing now that we're in our optimization period is and this happens at every health care organization, the appetite for new new software, new vendors is is there. And so it. So in order for us not to be five years from now where we were before we started, we have to have governance. And so you have to have governance in place. You have to ensure that there's a strategy moving forward. So you know, what is our AI strategy?

What is our automation strategy? Do we have certain partners, certain vendors that we're willing to partner with on some of these strategies and in in doing so, if you set these parameters in a governance model in place, it's not to slow you down. It's just to make sure that you have the right path forward. So our goal is not to slow ourselves down, but really just to ensure that we are keeping the purity of the system as well as keeping that kind of why not?

That bag or why not? The vendors we already have chosen approach as a, you know, look at them first and then if they do not offer something that you absolutely need, then we can evaluate another vendor. So really having that governance and places, my biggest advice.

Another lesson learned that I didn't realize was gonna be as big of a deal as it was was our Pammy reconciliation, and that's problems, allergies, medications and immunizations.

And in in the way in the result of pandemic we of the pandemic, we had staffing shortages, nursing shortages as well as medical assistant shortages, primarily in our ambulatory spaces. And because of that, the Pammy reconciliation from their legacy system. So from Touchworks into Epic is is a manual process. We have the care everywhere. We have the HIE's to bring it in. But at the end of the day, that data still has to be reconciled into your new EHR.

And most health care organizations recommend that your current users are the one to do that Pammy reconciliation. And we we started to do that and we realized it was too overwhelming. My, my physicians that primary care docs were staying up until midnight every night doing this family reconciliation. And then they were coming in at 5:00 in the morning to do it. And it was just, it was causing this burnout to our clinicians. And so we ended up having to bring in a third party.

Group of folks to help assist with the manual third manual reconciliation of the Pammy data. But one thing I know that's out there is there are some AI solutions that assist with the Pammy reconciliation. I wish I had vetted that earlier in the process. We're doing that now, but if I had known the overwhelming burden, then it was gonna be to my primary care doctors. I would have built an AI solution to assist with the family data.

Into our implementation from day one so that we had planned for that, but unfortunately that was something I didn't realize the extent of the Pammy reconciliation and the burden that it would be for my clinicians.

What we've covered a lot of ground today going through application rationalization to 2 1/2 year row out of EPIC.

EHR at Baptist Health Jacksonville. We've spoken about different use cases generated by clinicians and opportunities for.

Meeting clinician and patient needs, but also assessing the impact of the full epic Go live implementation on patient care. I think we've covered a lot of ground and I appreciate your contributions today. So for a listeners, this has been doctor Stacey Johnston of Baptist Health Jacksonville, the vice president and chief applications officer at Jackson Health. Stacey, thank you so much for joining us today.

Alright. Well thank you for having me.