For most organizations, having a CIO with a background as a clinician and a passion for research would be viewed as a plus; at Duke Medicine, however, it’s practically a necessity. Not only did Jeffrey Ferranti meet those criteria, but as the CMIO, he knew the organization well and was prepared to guide it through a major implementation. In this interview, Ferranti talks about how his team created its own set of best practices and applied them during the Epic rollout; how he has benefited from his experience as a clinician; why it was a “really natural transition” from the CMIO to the CIO role; and what it’s like working for an organization where innovation is part of the DNA.
Chapter 1
- About Duke Medicine
- Epic in ambulatory & hospitals
- Applying lessons learned to subsequent rollouts
- Challenges with access privileges — “People didn’t have all the security rights they needed.”
- Post go-live support “when the shiny newness wears off”
- Rapid cycle improvement
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
Podcast: Play in new window | Download (Duration: 11:36 — 10.6MB)
Subscribe: Apple Podcasts | Spotify | Android | Pandora | iHeartRadio | Podchaser | Podcast Index | Email | TuneIn | RSS
Bold Statements
That made a big difference in how the go-live went and how this large change took place, because they had colleagues from Duke Hospital who were at their side during the go-live who understood the system.
When you talk about these more complex workflows where a patient might show up in the ED and then go to the cath lab and then go to the ICU and then go to the floor, managing those transitions in Epic in a seamless way was challenging as folks learned the new workflows.
Opening that rapid cycle improvement command center really changed the energy around the go-live to be much more positive. People felt they were being heard and we were able to really react to any lingering issues that might have been out there.
We had the command center with everyone in one area — we had engaged clinicians, an engaged vendor, and an engaged IT team, and that led to us making some real improvements in the system that people could feel nearly immediately.
Gamble: Hi Jeff, thank you so much for taking the time to speak with us today.
Ferranti: Hi, it’s great to be here.
Gamble: To get things started, why don’t you give us a little bit of background information about Duke Medicine? I know you have the School of Medicine, but tell us what you have in the way of hospitals, things like that.
Ferranti: Duke Medicine is an academic health sciences system. We’re located in Durham, North Carolina. We consist of Duke University Health System, the School of Medicine and the School of Nursing. The health system is made up of three hospitals — our academic medical center, which is Duke University Hospital, and our two community hospitals, Duke Regional Hospital and Duke Raleigh Hospital. We’ve just opened a new surgical and ICU hospital called the Duke Medicine Pavilion, and a new cancer center, the Duke Cancer Institute. So it’s really the conglomeration of all of our clinical activities as well as the School of Medicine and School of Nursing that makes up Duke Medicine.
Gamble: And you’ve been CIO there for about a year, or maybe a little less than that?
Ferranti: Right, about a year. I became the CIO shortly before our enterprise go-live for the Epic system. Prior to that I was the Chief Medical Information Officer here at Duke and involved in a lot of the business planning for our Epic go-live, both on the ambulatory side as well as on the inpatient side.
Gamble: So obviously you were part of the system, and so you didn’t just jump in to the Epic project, which I’m sure helped.
Ferranti: Right.
Gamble: As far as the Epic rollout, where does it stand at this point?
Ferranti: We just finished our Epic deployment. We started in the summer of 2012 going live with some of our primary care ambulatory clinics on Epic. Then in 2012 and the early part of 2013, we had a series of ambulatory rollouts. In the end, we deployed Epic in over 300 ambulatory clinics, both primary care and subspecialty clinics. We went live with Duke Hospital and the Epic Revenue Cycle Solution in the summer of 2013. We’ve been live on that for nearly a year now. Then on March 1of this year 2014, we went live with our two community hospitals on the same day. So now we have basically our whole health system live on Epic.
Gamble: How did that go as far as having those two community hospitals go live on the same day?
Ferranti: It went remarkably well. I think we really began to understand how the system works and put in some great optimizations after we went live at Duke Hospital, so going live in the community hospitals was actually a great experience. I think that the leadership of the community hospitals really came to the table and took ownership of the operational aspect of the go-live. It was a very successful go-live. After we went live at Duke Hospital and we saw how things went both on the clinical side and the revenue cycle side, we made an institutional decision to bump up our Duke Regional go-live from July of 2014 to March of 2014 and to do it at the same time as Duke Raleigh Hospital.
We actually completed the project ahead of schedule because we ended up doing Duke Regional Hospital at the same time as Duke Raleigh Hospital in March. I think because of all the preparations that went into the large academic medical center and because we had time to do a lot of optimization in the six months after go-live, the community hospitals really went well.
Gamble: I’m sure that that was a nice surprise, or certainly a plus, to be able to push that up a few months.
Ferranti: It was great. I think that because we had such great participation from Duke Hospital physicians and operational owners, as well as the leadership in the two community hospitals in supporting the go-live, it was a really great experience, because what ended up happening for the community hospitals was a lot of the at-the-elbow support came from folks who had been using Epic for months and months at Duke Hospital. That made a big difference in how the go-live went and how this large change took place, because they had colleagues from Duke Hospital who were at their side during the go-live who understood the system and understood Duke. I think that’s a different experience then using contract resources to support your go-live.
Gamble: That’s a really nice thing. It’s not something that we’ve heard of happening a lot, but to have your own colleagues providing the support — people who just went through it — has to be enormously helpful.
Ferranti: It was great.
Gamble: With the Duke Hospital go-live, you said you really focused on a lot of the optimization before rolling the other two out. Was there anything that stood out as a lesson learned, either negative or positive, or just a best practice that you wanted to apply to the subsequent rollouts?
Ferranti: There were a few things. I think that security — and by security, I mean access privileges in the system — was a real challenge at Duke Hospital. We learned that in the weeks leading up to go-live we had over 200 different security profiles in Epic, and when we went live, we were hearing from people that they didn’t necessarily have all the security rights they needed to do their job. So we had to on-the-fly modify their user profiles to make sure that we match their user security profiles to the job that they were doing.
I think that’s a common issue that you face in the first couple of weeks after go-live, but we really took that to heart in the community hospitals and set up security check points a few weeks before we went live so people could log in and make sure they had the right access and could check their credentials, make sure they knew their password, and make sure they could find the things they were going to need to find on day one of the go-live. By preempting some of that, we really limited the number of security issues that we had during go-live.
The second issue we had at Duke Hospital was around printing. I think barcode printing, label printing, and specimen ticket printing is always an issue during a go-live, because you have to understand where things are going to print. When you’re working clinically, if you need to print the label or if you need to print a blood form, you want to know where it’s going to pop out. And that’s sometimes hard to match to the operational workflows. At the community hospitals, we did a lot of work upfront to make sure that printing would run more seamlessly.
The third issue that was a challenge during the Duke go-live was really around patient movement. We have a pretty complicated health system, and when you talk about these more complex workflows where a patient might show up in the ED and then go to the cath lab and then go to the ICU and then go to the floor, managing those transitions in Epic in a seamless way was challenging as folks learned the new workflows. We really had to focus effort around these care transitions and patient movement after our Duke Hospital go-live and that certainly benefitted the community hospitals as well.
The other thing we did that I think is unique was around support after the Duke Hospital go-live. Most folks would tell you that 90 to 120 days after an Epic go-live is the time where users have the most challenges, because all the support has left. They don’t have the at-the-elbow support anymore and they have to use the system on their own and manage the system as part of their day-to-day activities. A lot of the shiny newness wears off, and people realize that there are still things in here that we need to change and optimize.
We were hearing more and more of those sorts of concerns about 90 to 120 days out, and so in the late fall of 2013, we started a process called rapid cycle improvement where we essentially reopened our go-live command center and told the folks who were having problems that they can come to the command center. They could file tickets. They can show us where they were struggling, and we would take those things seriously. We also brought in some additional contract resources to help with particular builds that we had to do during this rapid cycle improvement.
In the end, we fixed over a thousand things that were outstanding from our go-live during one concerted six-week effort, and I think that made all the difference in the world. Opening that rapid cycle improvement command center really changed the energy around the go-live 120 days out to be much more positive. People felt they were being heard and we were able to really react to any lingering issues that might have been out there. Because we made all those changes when we went live at the community hospitals post the rapid cycle improvement effort, they really had a lot of great functionality in place.
Gamble: I could see that that’s something that could really work toward satisfaction for the users, because the last thing you want is for them to feel that they don’t have that support, and this is where change management can get really tricky, after the support has left and this is day-to-day life now.
Ferranti: The key was really formalizing it around an RCI initiative and having a command center and having the Epic resources at our side, on the ground to help solve some of the specialty module issues that we were having. Epic was a fantastic partner through the whole process. I’ve really never worked with a vendor as engaged as Epic. When we were going through this RCI initiative, they were in the room with our clinicians, with our team helping us work through some of these issues. I think it worked out very well because we had the command center with everyone in one area — we had engaged clinicians, an engaged vendor, and an engaged IT team, and that led to us making some real improvements in the system that people could feel nearly immediately.
Share Your Thoughts
You must be logged in to post a comment.