Joan McFaul, VP/CIO, Glens Falls Hospital, Chapter 2

To most insiders, Epic’s installation in the ambulatory facilities of an organization with a different inpatient system augurs ill for the incumbent. But according to CIO Joan McFaul, that’s not necessarily the case. She said Epic and Cerner are coexisting peacefully, at least for now. To learn more about what the future might hold for Glens Falls’ application environment, and to hear about McFaul’s other projects at the health system, healthsystemCIO.com recently caught up with the New York state CIO.

Chapter 1

Chapter 2

• What it means to have “credibility” as a department
• Defining customer service
• The CIO/CMIO relationship
• The importance of post-implementation support and optimization
• The vendor’s role in a successful install
• The CIO as fiduciary

LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED

Podcast: Play in new window | Download (19.2MB)

Subscribe: Apple Podcasts | Spotify | Android | Pandora | iHeartRadio | Podchaser | Podcast Index | Email | TuneIn | RSS

BOLD STATEMENTS

… you have to be honest about what you can’t do and not overpromise — nothing frustrates people more, whether they’re physicians or administrators or clerical staff, than if you promise things and you can’t deliver.

He’s the kind of personality that we needed to help regain and restore the confidence of the docs. He has a lot of credibility.

I think the lesson learned there is that you can’t just install these systems and then walk away or install them without a lot of support, because they’re complex and they’re life changing.

Guerra: You mentioned the idea of a department having credibility. I think that’s very interesting. Just because you’re in a certain position on the org chart and because it’s the IT department doesn’t mean it’s got credibility with the rest of the organization. If a department doesn’t have credibility, how does that impact their ability to do their job?  What happens, practically speaking? How does that play itself out? Give me an example of how that could be detrimental.

McFaul: Well, you wouldn’t get support for funding, would be one of the big ones. No money, no mission, as the old saying goes. If you’re going to have support for keeping staff or expanding staff or getting money to launch and complete important projects, I think people have to believe that you have the wherewithal and the skills and the expertise and the work ethic to get these things done. I think that one of the things that we’ve built up, and been very serious about over the last few years, is demonstrating that we have those capabilities.

When people say, “Okay, they seem to know what they’re doing, and they seem to be able to get things done. They seem to be able to answer my questions.” The other thing is you have to be honest about what you can’t do and not overpromise — nothing frustrates people more, whether they’re physicians or administrators or clerical staff, than if you promise things and you can’t deliver. We’re careful about what we say and what we commit to. But when we commit to something, we get it done, and I think that builds credibility.

Guerra: Are you comfortable with the word customers?

McFaul: Very comfortable.

Guerra: I’ve been talking to a lot of CIOs about that word and how relevant it is, how important it is to use that word or other words, but to generate the dynamic that the word customer can help generate, and that, in turn, brings out the behavior that you want from your department. Does that make sense?

McFaul: Absolutely. I’m all about customer service, and I think how you define customer service is important because you can name it anything, but how do you define it and how do you operationalize your kind of customer service philosophy in your customer service definition. I think it’s important to be careful about how you define it and how you implement it. Yes, I think it’s an extremely important concept. I think it helps define things for your staff — here’s the values that we have as a department and here’s how we need to execute on those values. Yes, I think it’s a really important concept.

Guerra: As you give them those values then they’re able to make decisions based on a certain situation within the context of those values. They know whether I’m supposed to go left or right on this because I know what I’m operating under, right?

McFaul: Right. Yes, it does help guide decisions, just like goals do and priorities do. I think that’s part of my job and, as part of the leadership within IT, it’s part of our job to help set the tone. I think, overall, our group does a good job with that.

Guerra: You mentioned your CMIO. I saw that you did a presentation with your CMIO at the CHIME Fall Forum last year, on working with the CMIO, the importance of that relationship. You talk about in the description of the session about how you and the CMIO were able to work together to restore trust and integrity and values after the medical staff had all but given up on technology. It sounds like you came in about three years ago and IT maybe did not have that credibility that it needs to execute, especially the implementation of advanced clinical systems. Is your CMIO Matthew Dunn?

McFaul: Yes.

Guerra: Well, Matthew was there when you came. The environment you walked into sounds like it was maybe nowhere to go but up {laughing} but take me through that, take me through that a little bit.

McFaul: Well, when I came Matt was here. He’s an emergency physician and he was also the Associate Medical Director of the Emergency Department. But he also served as kind of a key expert in the emergency area for the implementation of Cerner. He was considered an expert on the system, and he was very supportive with other physicians. He was trying to work to optimize the system within the Emergency Department. It was clear to me that he had not only the aptitude but the willingness and the drive to be involved in a lot of the details of the systems. He understood them very quickly and in a lot of detail. The opportunities that we had to talk early on, I was very anxious to get him on board in any way I could with our CEO and support of some of the other senior leadership staff that said, “Yeah, he’d be a great CMIO.”

We brought him on board within, I think it became official within six months of my arrival. He has served in that role in a part-time capacity as CMIO, and he continues to work as an emergency physician, but we talk a lot and because he has such a good understanding of how you can use these systems and still practices medicine, it can actually be helpful. He’s the kind of personality that we needed to help regain and restore the confidence of the docs. He has a lot of credibility. He and I have worked together to just sort of pursue that. We’ve taken our time, and we’ve been very pro-active in working with the docs.

Matt now is the chair the physician advisory group and he also attends the Med Exec and gives a report monthly to the Med Exec. He also makes himself available 24 by 7, basically if a doc is having a real big issue or is frustrated or whatever, they are always free to call Matt and get a response. It’s just proven to be a great partnership, and I couldn’t ask for a better CMIO. I just can’t imagine what skill set he could possibly have that would make him any better than he is. He’s really good.

There were two things that happened that were problematic. I don’t think IT was really to blame for any of it. It was just a set of circumstances. The first was when they put in CPOE back in 2007. It was put in properly and appropriately to the best of my knowledge and obviously it wasn’t here, but I think where things probably went a little bit awry was in the implementation support and post-implementation support and probably the support for optimizing the system.

Those kinds of things were never really addressed and part of that was because they didn’t have a CIO. They had a director and she did a good job. She knew what she was doing, she was a very talented person and it was no reflection, I don’t think, on IT. I think there was just an overall lack of sophisticated understanding on how you implement these systems successfully. It kind of started off badly, and then they just stumbled on the recovery. It just was – I don’t want to say bad luck because it was more than that. It was just probably lack of deep experience in implementing these systems. Not that I’ve installed a million of them either, but I think the lesson learned there is that you can’t just install these systems and then walk away or install them without a lot of support, because they’re complex and they’re life changing.

I think that may have been part of the problem, and so there wasn’t a lot of credibility as far as many of the physicians were concerned, in terms of the support for the system and the capabilities of the people that were implementing it to properly support them. They didn’t like it, frankly, and so that’s part of it. Then the other thing that happened is that there was a revenue cycle product to put in. That went live prematurely – the testing was not completed all the way, and they ran into some problems with the product for the first six months. It was a challenge. I think that further planted a seed that, “Oh my gosh, do these people know what they’re doing?”

Well, there’s probably a couple of reasons. One was that probably the system, as it was installed at that time, was not the best choice. Also, I think that there was some sense of urgency around getting it up come hell or high water. Again, I wasn’t here, this is just what I’ve heard, but I do know that it was recognized by everyone that it was not a good install. You kind of had two in a row there. It just didn’t go well. I don’t think you can point a finger at anyone, personally I just think that there was a lack of appreciation for how complex and difficult these systems are to put in, and because they hadn’t done it before. They put in a lab system a number of years ago, and that seemed to go okay. They put in a radiology system a number of years ago and a PAC system, and those things seemed to go okay.

I think when you get into really affecting the workflow of clinicians, nursing and physicians and physician assistants and technicians and revenue cycle people, it’s a big, big deal. But I think that they learned their lesson here, and I think one of the things I was most interested in is: “You know what, no matter what we do at this point in time for physician practices has to be successful. We have to do a good job. We have to have credibility. We have to show that we can do these things.” We’ve done a couple of upgrades to the server system and the mantra was, we’ve got to get this right. We got to support people and show them that we know what we’re doing. It’s a lot of the same people that were here before. It’s just that the level of understanding, I think, at the senior leadership level — and it’s the leadership of the physician practices and with the CMIO — has just expanded and the experience is different.

In some ways, I landed here at a good time because they had learned a lot of lessons. But at the same time, there’s a lot of pressure to get it right, which there always is. I think that’s what happened. I’m sure there are many other organizations that have been through a similar experience and you learn. The important thing is that you learn from these difficult lessons and you improve and you move on and that’s what we’ve done.

Guerra: When you were talking about the revenue cycle system, that was Centricity, right?

McFaul: Actually, it was IDX.

Guerra: Okay, but that’s the GE…

McFaul: That’s right, the GE IDX System.

Guerra: Do you think the vendors involved with the installs you described could have done more to help the organization be successful?

McFaul: Again, I wasn’t here and so for me to throw stones at the vendor, I wouldn’t feel comfortable doing that. I can tell you that different vendors, in my experience, different vendors have different philosophies. They also have different business models, how they approach their business, and how they approach installs, and how they approach upgrades, and how they approach not only philosophically but practically these major installations. There are some vendors who probably under sell on the front and over sell on the back. By that I mean, “Yeah, we’ll sell you the software and we’ll sell you the services to go along with it.” But what you don’t really get is the full picture of how involved it’s going to be on the back end, and how much you’re going to have to do and invest in order to optimize the systems. I think some vendors do a better job of painting that picture than others.

Guerra: You mentioned your organization didn’t have a CIO. It had a director. Would a CIO’s experience have been able to bring about a better install? Does that make sense?

McFaul: Yes, it does. I’ve been in this business a long time, and I’ve worked for different kinds of CIOs. I’ve worked for very business-savvy CIOs, and all of them have been business savvy, but I mean those who really excel on the business-savvy side and those who excel on the technology side. I’ve learned from both, and I’m grateful for those learning opportunities because I think, when I came here, I had maybe a little bit of a different view and a broader perspective of what it was going to take to implement these systems.

The organization here embraces that but, yes, I think whether you’re a CIO or anybody else, one of the things you learn as you grow in your career is that you’ve got to face things with a little bit of skepticism, but you also have to understand the big picture. Understand what it takes to implement systems, understand what it takes to have a good relationship with the vendor. Also, understand what some of these modifications mean to your organization and what the benefits are and so forth. I thank my lucky stars that I’ve had some great leaders in the past that I’ve learned from. I’ll tell you this — going through this experience here at Glens Falls over the last three years, I’ve learned a lot more. It’s changing so quickly, and there’s so many demands on IT these days. It’s always an eye opener. Every day is an eye opener but, hopefully, you have enough experience that you don’t get overwhelmed by it.

Guerra: We talked about terms. Do you like the term partner when talking about a vendor?

McFaul: I do.

Guerra: You do. I don’t know. I wonder if it makes you take your guard down a little bit too much sometimes. If you stop thinking of them as a vendor completely and think they’re a partner, well, they’re not your partner totally as in a traditional partner. Well, what are your thoughts on that?

McFaul: I think you work to develop a relationship with whatever vendor you have that is as trusting and open as possible, aways understanding that it’s just like any stakeholder, so you’ve got stakeholders in your own organization that have their own agenda, not that it’s a bad agenda. I have an agenda. The medical director of the cancer center has an agenda. Everybody has their agenda and, to some degree or to some extent, wants to be able to serve the interest of their own area. I think when you look at any kind of partnership, you have to understand that there’s sometimes different agendas, but I think as long as you’re open and honest about what those agendas are, it’s okay. I don’t think you can go into these things and be completely naïve and think they’re only going to do what’s in your own best interest. But I think as long as the organization, the partners, are honest with each other and understand each other and have built a certain amount of trust, I have absolutely no problem calling a vendor a partner. As a matter of fact, the more I trust them, the more likely it is I’m going to want to partner with them.

Chapter 3