Dublin Methodist Hospital is a part of OhioHealth, a not-for-profit, charitable healthcare organization consisting of 15 hospitals and 20 health and surgery centers throughout a 46-county area. The new 94-bed hospital, which opened in January, can expand to 300 rooms if demand increases in its northwest corner of central Ohio. Recently, HCI Editor-in-Chief Anthony Guerra had a chance to chat with CIO Michael Krouse.
AG: Would you say you were a partner in developing the three-in-one handheld you mentioned?
MK: I think that we worked pretty aggressively with McKesson to standardize all those applications. The Symbol devices themselves were being deployed in other of our facilities, but again to support just a single application. We had to work with McKesson to fold that into taking advantage of the devices that we already had, and then running multiple applications on them, and that's somewhat difficult because the applications sometimes come from different vendors.
AG: That's interesting, and we see that more in the market with large healthcare systems and the CIOs. They're not just buying products, but essentially partnering up with vendors, sometimes it's a formal partnership where royalties or revenues are shared after something is co-developed. What are your thoughts on that as a CIO in terms of the need to get out there and not just buy what's there, but get created what you need?
MK: I'm a big proponent of it in that I think often that to do two things simultaneously — (1) Maximize the investments of the technologies that you've already made, and the devices that you've already made, and (2) to collapse down the simplicity of deploying some of these devices out — to some extent you have to engage in partnerships that lead to custom development.
I’m not a fan of doing one-offs in that way. I am a fan of doing it in a way that represents the natural evolution of the industry. Where I like to do it, is when I know I’m going to be on the front end of the curve, and where I know that what I have developed will be not only desired, but is a key critical component for other facilities to follow behind me. In that case, I like to be out on the front end of the curve and develop in that way.
I don’t like to develop custom one-offs that are so unique to my environment that they’re really not replicable in other healthcare environments, because over time that will cause me grief. Because the vendor themselves will see me as a one-off and difficult to support, etc. I’m selective about where I’m doing it, but I’m doing it for a reason, because I’m trying to get more advanced relative to where I see the direction of the industry going.
AG: Have you ever gone down the road of really formalizing that into shared revenues, really getting the lawyers involved and contracts and that kind of thing?
MK: Not from the standpoint of shared revenues, but when we negotiate the contracts in terms of the upfront costs and/or we say what’s it going to cost to maintain this long term, there are some significant gives and takes as it relates to that. Now we do have within Ohio Health, much like the Cleveland Clinic and others, a research and development arm and an innovation arm that looks for opportunities to take some of this true custom development, whether it be specific to devices in a physician patent or whether it be specific to some component of IT, to manifest itself into a true business that could stand on its own. But that’s a whole separate division within Ohio Health and is relatively new for Ohio Health in the grand scheme of things, but definitely a direction we could go.
AG: You see that as part of the CIO role going forward?
MK: Sure. Absolutely. I think the successful CIO going forward is a nontraditional CIO. By that, I mean they have to be an individual that understands the business well and knows what’s necessary operationally to take the business forward, both strategically from the perspective of how we align more closely to our physician community, how do we keep them incented to stay actively involved with the hospital system, how do we grow, what service areas do we offer to the community.
Today’s CIO has to understand that first and foremost. Once they understand that comprehensively, they can go out and selectively apply solutions. The days are gone of the CIO saying, ‘Hey, you know, I’m hearing about a new OB system, what do you think about implementing it,' without any context as to how that fits into the bigger picture.
For us, for example, there are three things that I constantly will articulate. One, I want to simplify the operating environments for those of us that work within healthcare. Everything from the physician to the associate to the clinician, as well as the patient experience. Simplify, simplify, simplify. Technology should simplify, not bring in new hurdles just because we want to digitize something. The second component is we should be digital. We should digitize every relevant piece of information that we can because it allows us to move that information to get it into the hands of multiple people simultaneously for the provision of care. And the last one is you’ve got to connect. Connection can start certainly within your own healthcare system, but it will also expand, of course, quickly to the community which is why you see all the RHIO efforts that are going on to varying degrees of success. Those three words really drive everything that we do within IT.
AG: You mentioned about the evolving role of the CIO. One of the trends that we’ve identified is the growing role of the CMIO. You mentioned about the evolving role of the CIO and how important it is to understand business and the community. How important is it for the CIO to understand the clinical environment, maybe not have a clinical background, but how important is it for the CIO to know the environment that they’re placing these systems in?
MK: I think it’s very important. We talked about the business aspect of the environment, but the clinical aspect is probably more important to me. The ability for a good CIO to relate to the physician community is of vital importance. If that aspect of the relationship is working well, many other things flow. If the relationship is very close with the physicians and they’re feeling good about the way they’re being supported, everything from, do I have appropriate governance models in place to accurately provide input and guidance, to the development of the system, but also from an IT perspective. When somebody says, ‘We’re going to automate the way that you do progress notes today,’ do we understand well enough how they practice in their day-to-day lives to be able to develop a tool that can be rolled out that is not intrusive, something that easily picks up with their current workflow.
My belief is that the way to get there is CIOs should be — and I practice this regularly — shadowing our physicians. Everything from trauma to surgery to hospitalists, you should be spending days with them, literally in scrubs following them around, understanding what’s happening to them on a daily basis. Then you should be partnering with physician executives, ideally somebody who is still actively practicing, someone that can bridge that medical terminology gap between a CIO that isn’t medically trained and the physician community. I think you can do a lot without a CMIO if you really focus on your physicians being your primary customer base and getting in and spending one-on-one time with them. They’re more than happy to share that with you. But a lot of folks just don’t give it the time. They don’t have the time to go and shadow and spends days and hours on end just literally following them around saying, ‘Hey why are you doing it this way? What do you experience here?’ and watching and looking and seeing where technology is a hindrance and where it’s working well for them.
AG: Nurses often say that no one hears their complaints, such as the fact, for example, that the batteries on their carts are always dead. Does that information ever reach the CIO?
MK: It doesn’t. At best, what will happen is it gets reported to the helpdesk, and here’s what typically will happen. The helpdesk will say, ‘We need to get a new battery out there,’ and so a battery gets ordered and its gets sent out there. The problem continues to surface and each time the problem is solved by getting a battery out there. Well, if it’s not elevated to the CIO or the CIO hasn’t been in to get the experience, you’ll never realize that what you should be doing is having an entire refresh program developed for all of your mobile carts. That refresh program says that whether they need it or not, we’re going to go in and take 50 of these carts in this particular unit, pull them back, refresh and get them back up and running and deploy them, so that you’re eliminating that problem. That’s a classic example of where the CIO is probably disconnected from a reported task because, at the surface, it looks like the problem is being addressed every time you send out a new battery.
AG: Right. And the danger is that the nurses and other clinicians just won’t use it anymore. They’ll do something else.
MK: That’s exactly right. For people to get excited about this new role of the CIO they have to feel that the CIO really gets it. That they understand their workflow and that they understand the problems they are incurring on a daily basis and encountering in their daily routines. They need to feel that somebody is out there saying, ‘It’s no longer acceptable, don’t accept the fact that you have to go hunt down a new computer on wheels because the battery went dead. Don’t accept the fact that you have to remember multiple passwords to get into systems.’ It’s changing that cultural environment so that you reset those expectations that have long been out there in healthcare and get people really excited.
AG: I’m going to go down a little checklist for you of some different systems and you can just tell me what vendor you’re using and maybe a little bit about whether or not this particular system is integrated with other systems. You said your wireless network is Vocera or is that a component?
MK: Verizon is our wireless network backbone. Vocera is a communication device that runs over the wireless backbone, and it’s the mechanism that our clinicians, physicians and other staff at Dublin will use to communicate with each other. It’s a little bit like its own little server, so today if you place a phone call and you call into an individual facility, you might say, ‘Can I speak to Dr. Jones,’ and Dr. Jones doesn’t happen to be available, so you take a message and you pass that message on to Dr. Jones who then has to call whoever it was that received the call.
Vocera allows you to press a button, and say, ‘Please call Dr. Jones,’ and if Dr. Jones is within the hospital environment, it will say, ‘Finding Dr. Jones,’ and the next thing you know you’re live and connected to Dr. Jones. That, in essence, is what the Vocera system allows you to do. It also has some IT technology and tracking technology on the badge itself, and because each badge is signed in with a specific individual, I can tell you Dr. Jones might be in surgery, he’s not accepting calls. It’s a great little communication tool, but it runs over the wireless network.
AG: And you went with Verizon, which is a horizontal provider. I’ve heard of a couple in healthcare that keep coming up. There’s also the decision to go with a passive or active network. Did you come across any network providers that seem to focus on the healthcare vertical?
MK: No, I mean we continue to work with our Cisco environment and with Verizon as our partners and did not want to run down a path that was more unique or more specific than what we have currently deployed in other parts of our organization. We simply wanted to begin to fine tune what we’ve already got. Again, rather than constantly introducing new vendors and new partners, leverage what you already have.
AG: For the electronic medical record, what are you using?
MK: It depends on how you define it, but McKesson is our product. It’s our core application set, all the McKesson suite. Their product is called Verizon Patient Folder, which is probably the closest thing to a true electronic medical record. But for us, we also talk about electronic health record and that there are other pieces of information that are digital that don’t make it into “medical record.” That’s also been deployed, and that’s a wide variety of systems from Fuji PACS systems to other radiology to other pharmacy, the list goes on. I’m going to guess there are probably 150 different applications that support Dublin alone.
AG: And they’re all through McKesson?
MK: No, they’re through a wide variety of vendors. McKesson is the core suite, so all the clinical documentation, all the order entry that’s done, all of the general finance, patient billing stuff, that’s all McKesson. For example, there is a Tempus scheduling component (owned by QuadraMed) that does all of the patient scheduling. That is not a McKesson product.
AG: Let’s go through a few more.
MK: I’d be happy to do that. For example, we deploy a company called OB TraceVue (from Philips) to support the mother/baby units. OB TraceVue has its own documentation component to it. As long as you operate in that environment, you have to document there, that information has to be pulled out and then populated into the McKesson component so that everybody else that’s using McKesson for documentation of regular patient care can see that information. That requires, of course, work. Interface work, integrity work, and the more you can standardize that to simply be a seamless tool that multiple people are using for different reasons, the better off we’re going to be.
Even though we are fully digitized and fully automated out at Dublin, there are still opportunities for us to streamline the systems environment, such that it makes it easier to maintain and more seamless. Is the information just automatically getting in there or is it being passed through some sort of an interface engine?
AG: I have a terminology question for you, something I’m still not clear on. There’s three terms and I’d like you to tell me if you have different products for each one of them or if they meld. One is electronic medical record, the next one is hospital information system, and then computerized physician order entry. Tell me about those. Do they swirl into each other, or do you have three separate products?
MK: Let’s talk about the electronic medical record within a hospital setting, not within a private practice setting. Within a hospital setting, for us it’s McKesson Horizon Patient Folder. That product is the repository, the end game, of where we feed what you would otherwise know as the original patient chart. So anything you would find in a patient chart would go into HPF. That’s really the digital version of the medical chart.
The second thing you asked was HIS. A healthcare information system in today’s environment can be defined in a number of different ways. It can be defined and stratified against broad categories, like my HIS system can be a finance oriented HIS; it can be a clinically oriented HIS; it might be something different, it might be decision support. It’s really a bad terminology.
One that I prefer is: what is the core vendor that is providing all of the core applications? All of the clinical documentation pieces, all of the order entry components, all of the patient billing, scheduling components, that’s the core system. So when somebody says, ‘I’ve got a core HIS,’ they might say, ‘Well, I have McKesson as my core, all of the key components and everything else.’ Other shops will say, ‘I’m a Meditech shop,’ or, ‘I’m a Cerner shop,’ or, ‘I’m a Siemens shop.’ What they’re saying is that at the core of their HIS, they have a common vendor platform.
I’ll give you a classic example. McKesson at our core has HPF, which is the medical record component. It has Horizon Expert Documentation, which is the clinical notes that are being taken by our various care providers. It has Horizon Emergency Care, which is an application that supports the emergency room physician community. It has Horizon Expert Orders, which is the automated physician order entry component. It has STAR, which is all the general financial components. So that in essence is kind of the core HIS. Plugging into that, like a spoke in wheel, will be things like Fuji Synapse, which is a picture archiving and communications system which is all the digital images. Plugging into that might be other ambulatory-type services. So there is a core and then there is some of the ancillary stuff that’s supported by other vendors.
AG: Is e-prescribing and pharmacy also covered by McKesson in your hospital?
