Sibley Memorial Hospital is a non-profit, full service 328-bed acute care community hospital serving the Washington, D.C. area. The hospital’s campus is also home to its assisted living residence (Grand Oaks) and The Sibley Renaissance which houses the Center for Rehabilitation Medicine, Sibley Senior Services, skilled nursing care and a residential Alzheimer's unit. Recently, HCI Editor-in-Chief Anthony Guerra had a chance to chat with CIO Lorraine Fordham.
AG: Good to talk to you. I think these interviews are helpful to CIO in showing they are not alone with regards to the challenges they face.
LF: I think I find that most interesting about any articles I read on healthcare and technology these days. It is very clear we are not alone and we are all struggling so much with the same issues. Some of us are struggling better than others. That to me is interesting. How much of it is the leadership of the hospital and how much of it is the IT department that influences the success or failure of those projects.
Anyway, we are a busy little IT shop for a small community hospital. We are just a stand-alone acute care community hospital. We haven’t been absorbed by any health systems or anything yet, and we’re still very profitable, which is a good thing.
AG: How many beds do you run?
LF: We’re licensed for 362, but we really only run about 240. They have taken one or two nursing units and one they have turned into a VIP unit, which they could convert back if they ever had to, but don’t need to. It is one unit for one person if the need arises, which it does in Washington about four times a year. I think the other unit ultimately was turned into a same-day-surgery type unit. But that was years and years ago. They hang on to their licenses. When we opened our rehab unit, they gave up some of those 362, so I think we are actually only licensed for maybe 340 right now, but we run about 240 active beds.
AG: When did you get the CIO position at the hospital?
LF: I’ve been at the hospital probably most of your life. I started here years ago as the programming manager. And then I left and I was gone for a couple of years, and then they asked me back to be the director of IT. I started in ’76. I was here from ’76-78. I was gone from ’78-81. I came back in ’81 as the IT director, and then I was promoted to CIO about three years ago.
Prior to that point, we didn’t have a CIO. I was still the main IT person for the hospital, but the CIO position didn’t exist. Subsequently, since they have created it, we also have an IT director that works for me. I also, at that time, took over communications, all the communication stuff, and all the audio visual graphic stuff for the hospital; those departments came in to me.
AG: Any change in your outlook or responsibilities from when you got promoted from IT director to CIO, change of focus?
LF: Oh, sure absolutely. As the IT director, I was involved in strategic planning but more in day-to-day operations, because we were doing just more day-to-day operations. As the CIO, I’ve been given the responsibility for the IT vision for the hospital now and into the future, developing that strategic plan, developing the roadmap for how we are going to get there. I spend a lot of my time doing that when I’m not evaluating products, when I’m not involved with teams that are doing system selections.
We have a pretty set system-selection methodology that we’ve used for probably the last 20 years, and we tweak it, depending on the size and impact on the hospital that the particular system being evaluated will have. We may not go through all the steps if it’s a standardized departmental-type system but, generally speaking, we involve a lot of people in the selection of the systems. My experience has been that if they don’t have a say in the selection of it, and they don’t have a say in the implementation of it, then they don’t own it.
We’ve changed our philosophy a lot over the years. When I first came to work here, we were a mainframe shop. We had very little out in the clinical areas. I think when I first came in we had a pharmacy system running, but it was on an old IBM mainframe, and I had computer operators, and keypunch operators, and we sort of controlled everything. We ran the reports, distributed the reports, we said when something got done and when it didn’t, that kind of stuff.
Then over the years, as we have evolved, and we have brought in the clinical systems, I have found myself changing my job description. Interestingly, my department has not grown in size very much over the years, but the level of complexity of the jobs and the subsequent salaries have all changed quite a bit. I’ve gotten away from computer operators and keypunch operators, and now I have network engineers and PC specialists who are responsible for keeping all of this infrastructure up and running. Our focus has shifted away from supporting applications, because usually the vendors do that, and more towards supporting the infrastructure, making sure that things are secure, making sure that the networks are running, that there is redundancy where there needs to be redundancy, that we have a good disaster-recovery plan and it’s tested on a regular basis. All of those things, which are transparent to the users, are equally as important as they come to rely on the technology more and more.
AG: You mentioned the importance of getting people involved in the selection process so they feel a sense of ownership. Tell me more about the system selection methodology, both in terms of involving unit users and making sure what you put into place syncs nicely with your overall IT direction.
LF: I think that starts with the strategic plan and some guidelines, some rules, which we did years ago. We said we’re not buying any proprietary systems. We are going to buy systems that use standard databases, that use standard programming languages that can run on whatever platforms we are running on that year, that kind of thing. So we decided that a long time ago, when we first started going, moving into the clients sever and acquiring patient care systems, when we realized that there was no vendor that had all the systems that we wanted. We were going to be having the interface.
So it starts with that and making sure that you have got a good interface engine in place. Those were the things that we hit with those guidelines years ago. With those guidelines, when a department decides for whatever reason that they need technology or they need to upgrade technology that they already have, they first come to the steering committee. We have an information systems steering committee which is the main system users, the biggest stakeholders, like the director of imaging services and the technology services manager, who is responsible for the networks and stuff, all the C-suite executives, the CFO, the CMO, the CEO, the COO, they're all members of this steering committee. I’m obviously on the steering committee.
So that’s the group that takes the request, so I’m not put in a position of trying to prioritize. I do it in conjunction with my peers that have developed the hospital’s organizational plan, because what we found years ago is that they develop a strategic plan for the hospital and it didn’t necessarily dovetail with my strategic plan for technology, and that was a challenge. That was a challenge to get everybody vested in, ‘Hey, we all need to be marching to the same drum. If you want improve vascular services and part of that involves implementing a vascular information system, you need to tell me about it so that I can put it on our schedule for the year that you are planning on doing this.’
So that’s why all the requests are funneled first through ISAC (Information Systems Advisory Committee), this is what the departments are asking for, and they give me guidance and feedback, and I give them guidance and feedback. I tell them, for example, last year we decided we really needed an emergency department system. We do admissions in the emergency department. We do orders and we get results, but we didn’t have a bed management system. We didn’t have a good way of tracking our patients, and we certainly didn’t have any online documentation, and we were desperate for it.
It came to ISAC as a request, and ISAC said, ‘Well, we've managed without an ED system all this time.’ So that is where my role comes in. I said, ‘Well yeah, but these are the problems that they're having and these are the things that these systems can solve for them, and, beyond that, 65 percent of hospitals according to the analytics that I had access to already have ED systems. There is a reason for that.’
They said, “Oh, yeah okay.’ And so then that becomes a priority. So it’s really very much a collaborative effort and then we’ll decide if we’re going to go forward with that. Once we’ve decided that we’re going to go forward with the system, then a selection team is formed and it usually consists of key players in the area or areas that are going to be affected by this system. I’ll use ED a lot probably, because that’s one we just finished going through, but in that case it was two emergency room physicians, the nurse manager, and two key nurses in the emergency department, myself, the IT director, and the technology services manager on the IT side, the director of admissions and the management engineer. We were the selection team.
We started developing a request or proposal and a needs analysis, listed all the things that they didn’t have that they wanted to have and prioritized it. We end up with a spreadsheet, and we’ve done this so many times that you can pretty much take the spreadsheet and tweak it to your particular departments needs, and it is not that odious. They will say whether this functionality is necessary, useful, or interesting on a scale of 1-5 and then we put out the RFP. Went to a couple of tradeshows, everybody brought back their wish list. We sent the nurses downtown to a show, and they saw four or five engines, and when it was all over and done with we decided that we would check the KLAS reports to see the most highly rated. We talked to our vendors that we have relationships with, like Cerner and Allscripts, because we were talking to them about other systems, and Picis, which is our operating room management system, and ended up with three vendors responding on that product. I have had as many as seven RFPs go out. We generally wouldn’t let it get any bigger than that.
The RFPs come back. We have a technical questionnaire that we complete on each vendor, which rates them. The users rate them on functionality according to their needs analysis. They give them a score and then we keep the top two or three scores, and start doing site visits, and onsite demonstrations. The whole process can easily take six or eight months to get through all of that but, when we are done, boy are those people invested. They have put some time and sweat equity in this, and we've always managed to come to a consensus with the systems. There will usually be one that rises to the top that everybody feels comfortable about.
We also look at things like the companies philosophy. We do reference checks, and we have very specific reference check questions that we ask that to us flush if they are going to work well with us. They may work really well with an Inova or a Washington Hospital Center, but that doesn’t mean they are going to work well with a little community hospital with limited resources. We look for all of that, and when we are pretty satisfied that we have found a company that is willing to do that, then we get pricing, and we can negotiate pricings to some extent, go back to the steering committee and do a presentation and they say, ‘Yeah looks like you guys have done your homework.’
They validate what we have done. At that point, generally, if something has been approved it has also been budgeted for. Now we just have to go to the board and say. ‘We want to spend this money, and here it is, and this is why.’ While all of that is going on, we are looking at contract wording. I have lawyer that is actually down in New Orleans that specializes in IT contracts. I have worked with him for the last probably 20 years, so I pretty much know what he is going to ask for, and he knows what I’m going to ask for, and so we can get through those pretty quickly. Then we sign the contracts and we start implementing, but at that point that selection team generally transitions into at least the leaders of the implementation team.
You have got a group that is vested in this product. I didn’t pick it. My IT director didn’t pick it. The hospital administrators didn’t pick it. They picked it. And now we have got to get it working. I can say in all my years here we have installed a lot of systems and we have never missed an installation date. We have never had a system that we had to stop and start over again with, or some of the horror stories that I have heard, so we feel pretty comfortable even though sometimes I think the users, when they start out with this process, they feel like it is a little odious. By the end of it, they're glad they have invested the time and the energy in it.
AG: What is that you value when looking at a vendor? The clinical side has already asked for it (in some cases). What is it about the vendor, either from a software or from a company point of view, that will make a company attractive to you or not?
LF: It is really a combination of things, but I would say first and foremost is the fact that they are players. Their product has a proven track record of integrating with other products, whether it is through interfaces or whatever. What comes to mind is a Meditech who doesn’t like to play with other vendors. I’m not interesting in doing business with Meditech for just that reason. They have got a good product, there is nothing wrong with their product and they are really a nice fit for hospitals our size, but the reality is, I hear it from my peers all the time, about they are having horrible trouble with an interface to another system through the Meditech system, so that would be the first thing I look at. Are they on some kind of standard platform and do they play well with others?
Then when I start to do reference calls, and I start talking to people, but what I’m really interested in is how are they long term? Do they listen to your needs? Do they change their software based on your request or their own interest? How responsive are they? How much do they understand your company, your hospital, your organization and its business? Are they used to dealing with smaller hospitals or just great big medical centers? Are you going to be big fish in a little pond or a little fish in a big pond? We don’t want to be a little fish in a big pond. We are a great hospital, and we expect to be treated as such. And you can sense pretty quickly in that process whether the company appreciates you for the things that you have to bring to it. So we’re looking for some kind of synergy with their philosophies and how they do business. We want to make sure it will match up with our philosophy and how we do business. It is not always a perfect match, but often is, and I think that is frankly why we ended up years ago with Compucare (acquired by Quadramed in 1999). Quadramed is now our hospital information system.
AG: So you felt a good fit with Compucare/Quadramed in terms of the criteria you talked about earlier?
Part II coming soon
