AG: Sounds like it was very important to partner with the CMO. We hear this is becoming ever more critical to finding success as a CIO. What are your thoughts?
LS: Yes, absolutely. It’s interesting because right before Ben (Williams) left, we had started interviewing for a CMIO that reports to the CMO. So I’ll just give you a quick background. A couple of years ago, we were going to bring in a CMIO on a part-time basis within the IT department, and they were just focusing on doing our CPOE at one hospital at that point. The plan was that we would then take it across the organization. And what we had found is that it was more important to have local ownership since we were only doing one hospital. We ended up using that position for something more broad at that point. But now, as we have started to move our clinical systems across multiple hospitals, organizationally it was brought back up as a very important position to have. We thought that it made most sense to be under the CMO, so that we can balance that CMIO (Clyde Wesp, M.D.) working in partnership with the CIO to jointly take the solutions out to our hospitals.
So that’s a little background. Now I’ll go into my thought process today on how to make that most effective, and I think it is through partnership because we can jointly go to one of our hospitals that’s having a meeting with their physicians and talking about computerized physician order entry or our physician strategy with Stark relaxation. And he can very clearly talk and articulate, from the important of evidence-based medicine, the benefit of consistency in care. Especially when you’re talking to one hospital, they don’t necessarily, don’t take this the wrong way, it’s not as important to them that they’re part of a health system, (what’s important to them is) that they’re doing the right thing for their patients and their local market, where they’re dealing every day. But we also have to show them that just as evidence-based medicine and consistency are important, we don’t want to do waste and re-work, having to reinvent things at every hospital.
So he’s very good on that side. And I can talk from the consistency of implementation, of technology, of strength, of doing things in a consistent manner from a large scale of implementation process, and it’s interesting because of where we meet when talking about the infrastructure, the wireless and the wired, the carts, and everything that comes along with the clinical adoption. We meet when talking about workflow, redesign, and ultimately, real clinical transformation, where you can do things differently because of the technology. And there’s a piece of workflow that the IT group owns because it’s, ‘How do you need to change your workflow so that this new software package fits in.’ And then our CMIO looks at it more from a, ‘Well, how can you really deliver better care, different care than you may have in the past because of this technology being in place.’ And that’s where we kind of meet … in the middle. So that’s pretty exciting.
AG: Where do you stand on the argument between, on the one side, tailoring workflows to fit technology versus making sure technology is tailored to fit existing workflows?
LS: I think you have to have both parties at the table, or both parts at the table. Because we have found that one scenario is that you pull people together, you have them design future state and current state and you do the gap analysis and you try to find the software that will fill that gap. Or you’re kind of doing that at the same time you’re doing your selection process.
As far as our approach, I think I’m a little more supportive of understanding who your vendor software-based partners will be going into that process, because we’ve found two things: if you have the vendor at the table, then they can temper the future state with what can be done within a true realistic time frame, given in the constraints of the software. Because the truth is we don’t want to work with a software vendor that is so flexible they’re willing to act on every whim that we ask for, because I just don’t think that makes good business sense. It may be nice for initial adoption, but with upgrades and all of that we’ll end up getting into a place we don’t want to be.
So the thoughts of the vendor can help, but at the same time, they should be thinking, ‘Okay, if that makes sense, we need to feed this information into our product release cycle.’ What we’ve also found is that having the software vendor involved can be beneficial when defining workflow because they have the expertise. Users can then be made aware of capabilities of the software that may allow a whole step to be cut out of the workflow. So users may define a process, saying, ‘We need this software to support us here in this manner.’ And then the software vendor can say, ‘Well, because of this point of integration, the data is going to automatically pass over to this module, so you don’t even have to do that workflow anymore.’ So I think that was another key benefit of that approach.
I think the last thing that was a little bit more of a lesson learned, but we luckily did it early on, was that when you do the training, you bring those old workflows back to a training session. That way, people can see the old, the current, the future state of workflow changes. It’s important to have those pasted on the walls of your training room.
AG: In addition to the work with Microsoft and Azyxxi (now Amalga), what are some of the main initiatives you’re focused on?
LS: If you take a look at the pyramid (which can be downloaded at the bottom of this interview), you can see the types of systems are off to the sides. That middle section is business alignment, so the initiatives that we’re doing we want to ensure that they are aligned with the goals of the organization or supporting the operation of our caregivers. The two bottom pieces are very important. We still think that IT can bring innovation to the table, and that may not be in every instance, but there are instances where IT can obviously bring innovations and can spawn innovations. We try to categorize those up at the top. So my challenge with the whole department is to say that if you’re not doing something that helps provide excellent service to our customers, supports something directly for the business, or brings some innovation above and beyond to our organization, you probably shouldn’t even be working on this. So that kind of just gives you context.
AG: What are you using for EMPI?
LS: In the first hospital we’re implementing Initiate Systems and CareFX. Initiate is the EMPI vendor, and CareFX is for patient context. Patient context means that if you’ve a clinician working on a PC and you’ve got four applications going — you’ve got a PACS, you’ve got your HIS system, may be you have a fetal monitor system — as you toggle back and forth between those applications and move between patients, all of those applications are synching on the same patient. And that has single sign-on capability with in it. But to have that occur, you really have to have that master patient index so that you are 100 percent sure that it’s the right patient when you’re moving between these applications. You don’t want to be just haphazardly matching on the patient’s names exclusively or something like that. That’s being piloted at one location.
AG: Tell me more about your goals for the Azyxxi product.
Part III will be posted in our Web-First section on Friday
