One-on-One With Mercy Medical Center CIO Jeff Cash, Part II | Healthcare Informatics Magazine | Health IT | Information Technology Skip to content Skip to navigation

One-on-One With Mercy Medical Center CIO Jeff Cash, Part II

October 28, 2009
by root
| Reprints
In this part of our interview, Cash says the big acute EMR vendors aren’t all that interested in a hospital’s CPOE problems.

Mercy Medical Center is a fully-accredited 445 licensed-bed regional hospital located in eastern Iowa. After surviving flooding in 2008, vice president and CIO Jeff Cash had to figure out how his organization was going to survive a move to CPOE and electronic documentation with his Meditech Magic system. Cash wound up turning to PatientKeeper as a way to enhance Meditech’s front-end user interface while keeping his core system intact. Recently, HCI Editor-in-Chief Anthony Guerra had a chance to talk with Cash about these and other issues.

(Part I)

GUERRA: Could give me a quick tutorial on a major versus a minor upgrade?

CASH: Sure. So, an application upgrade would be our existing servers storing the next version of Magic, for example. A major upgrade would mean converting from Magic to a new version of Meditech, like Client/Server or Focus, but only some of the data converts. So there was a period of time when you may have had to keep both systems running in parallel. They’re fixing most of those upgrade challenges by going to the Focus platform and giving you a migration patch. We haven’t done the new planning exercise to know what that looks like. So the dependency would have been: how does your clinical data move? How did all your reports migrate over?

Today, we’re heavily interfaced with Meditech, so how do we migrate all of those interfaces to the new system? It does change the technical infrastructure quite a bit in the sense that, right now, everything from Meditech runs on a suite of about seven servers. In the new environment, it’s more typical of what you’d find in a different health information system architecture, in that there are significantly more servers that you need to run the system because they break out different pieces of the system. They have background processors and reporting servers, and they use different pieces that add a little more complexity to your architecture. That really didn’t put us off. We would’ve been okay with that. It was the conversion itself that we weren’t quite prepared to take on.

I’ll give you an example of another important element. We were using Picis before Meditech had a full surgery suite. Picis writes their applications integrated into a particular version of Meditech. So we were on the Magic platform of all the Picis applications, and that was a pretty expensive migration to get them all to Client/Server; and we could not migrate Meditech’s Magic without migrating all the attached Picis products, because they were version-dependent. Picis is written in such a way that you can migrate it to their version of Client/Server and they’re backward compatible with the Magic version of Meditech and the new version of Meditech, but their old versions, like their Magic versions, are not forward compatible with Meditech’s Client/Server.

So as we looked at our migration path, we had to migrate not just Meditech, but we had all of these connected applications – if you want to think about it that way, predominantly the Picis products at the time – that we had to migrate in one fell-swoop. And we had LSS, which was the physician component that we use in our practices, which would have to migrate at exactly the same time as well.

When we looked at this simple physician request of, 'give us a different interface before you start putting all of your information online,' we knew we would have to migrate all 90 of our physicians and the LSS system that they use, our operating room, our quality group, our dietary group, our medical credentialing group – they would have all come along at the same time just because of the way they interfaced with the Meditech Magic system. So that was a much bigger process than just migrating Meditech by itself.

GUERRA: What would the upgrade have to offer in order to warrant all that work?

CASH: Primarily, for me, it would be the workflow for our clinicians. One of the things that they’ve done with the newer versions of Focus – and a little bit with Client/Server, but primarily with Focus – is they’ve changed that interface significantly for the clinicians; they’ve really flattened it out. So, for example, if you’re in the Magic version, you can go into nursing, or you can go into medical records or you can go into lab, things like that. So you’re kind of moving around between the different applications to find the data and work with what you need. With the newer versions, they’ve flattened that out quite a bit, so all of the related applications that you may need to get to – when you need a bit here and a bit there – are all generally built around a common user interface.

I think there’s significant advantage of the clinicians being able to access more information from a single screen, and make it more intuitive and more navigable for them. And that would be the reason that we would jump forward. To a large extent, Meditech Magic works really well for us in the hospital. It’s stable, it’s relatively inexpensive for us to manage now because our investment is now just in support, along with adding some applications, and the good thing is they keep enhancing the Magic application.

Two weeks ago, we got them rolling out the whole bedside medication verification program, and it went very smoothly. And I think that there are many hospitals with much more robust health information systems that haven’t really taken on some of those challenges. So, we’re still doing awfully good with our Meditech Magic system. It really would have to be driven by the clinician workflow and the clinician interface, in my opinion, of why we would want to make that leap; or if they chose to stop investing in, and stop expanding, the Magic platform, which they’ve said they’re not going to do for at least the foreseeable future. There are just too many customers still on this system.

GUERRA: But you’ve largely solved that issue with PatientKeeper?

CASH: For the physicians, absolutely we have.

GUERRA: You mentioned that PatientKeeper is a database of information, and it has a nice front end for the physicians. What does Meditech do that PatientKeeper can’t?

CASH: Great point. PatientKeeper is really a compilation of data that was created in Meditech and other applications and shipped over to PatientKeeper. It’s then put back together in a very user-friendly access method for the physicians. So you’re not going to go into PatientKeeper and make significant changes to Meditech.

For example, if you were a nurse, you wouldn’t login to PatientKeeper and do nurse charting or nurse documentation. PatientKeeper is developing those pieces of their product very nicely, so for example, we’ve just recently signed a contract with them to add a new physician documentation component.

They’ve got structured documentation now built into the system which takes information that already was contained in the medical records, puts it into a pre-templated form – including labs, vitals, all of it – and they’re able then to go in and just fill in the remaining pieces to create their progress note. And then tomorrow, when they go in to update their progress note, it takes today’s progress note, migrates it over, and just shows them those areas that they need to target their updates for, based on the conditions of the patient. Very, very nice workflow.

The way PatientKeeper works with us, I’m sure they do it with other hospitals as well, is if our doctors are interested in a feature like that, they come out and spend time with their development team in the hospital, and they round with our doctors, and they sit with them in their offices and watch what they do. And they learn from their workflow. And then they go back and build a product to support that.

I think that’s largely why they’ve been successful in the physician field. We’ve just signed a contract to do physician documentation with them, and we are currently working with them to try and develop a CPOE program that would be the front end for the physicians through PatientKeeper. It would then integrate back into Meditech. So we would still keep the doctors in the same system that we have them doing everything else in.

Just to finish the complete list of what we’ve done with PatientKeeper, it does a lot more than just Meditech. If all we did was ask our physicians to come in and look at clinical results from Meditech, they would probably do it, but it really wouldn’t create any reason for them to come to the system. So what we’ve added, for example, is that if you login to PatientKeeper, you can drill into a camera in the critical care center. If you’re an intensivist, you then have camera control; and you can look at anything from the monitor interfaces that are at the bedside to the patient, all the way down to their eye color. You can see the line placements, the whole bit.

That’s just one little thing we’ve done. We’ve added directories of information for the pharmacies in town that are easy for them to access, directories of provider information. When they’re on-call, they have access to that. We use Gold Standard which is the pharmaceutical reference, and they can be looking at a medication and drill immediately out to that.

Our electronic signature is all done through PatientKeeper, not just for better transcribed reports but, because they’re still handwriting their orders, we scan those orders into a product from Meditech called Scanning and Archive. Those scanned orders then also need to be signed after they’re written. So we pop an image back through PatientKeeper and they can, in a single workflow, sign those transcribed reports. They can see their images. They can sign off on the scanned images of their orders. All that is done in a single workflow.

So it’s more than just patients, it’s more than just Meditech information that we’re offering them. If they want to get into a system inside the hospital that doesn’t integrate nicely into Meditech, then they use a little function where they can open up an interface into that system. It passes their credentials and allows them to login to the foreign system and, although they would still have to navigate that user interface, it makes it far more convenient for them to get access to that system, and there’s only a handful of those left.

We used a different system in our OB area. So if they want to get in to look at an online fetal monitoring strip and do their sign offs from home, they’ll login to PatientKeeper, click a button, boom, they’re into the GE QS system, and then they can go into those annotations and monitoring. The same thing applies if they wanted get into Trace Master – we’ve created a SharePoint physician portal for them as well; all their section notes, all that stuff goes in there. They can link out to that from PatientKeeper.

So, again, the story I was trying to build for you is that if all you do is give them access to the Meditech information, that would probably be okay, but it doesn’t give them access to really everything they need with a single user ID and password. So had we only made Meditech look better for them, we really wouldn’t have solved the problem. We wanted to tell them, “Come to this one place and you’ll have everything you need to do business with us.” So that’s partly why it’s been more successful.

GUERRA: Do you see PatientKeeper ever becoming a competitor to these core clinical systems like Meditech?

CASH: I don’t think so. I think they could become a competitor with particular applications; and I would guess that HIS systems may be a little challenged by that, like structured documentation and CPOE. But, at the same time, if the HIS vendors embraced them the way we have, I think what they would find is they add significant value to those HIS systems, because it takes a lot of pressure off that vendor to create that physician portal which isn’t really their core responsibility or competency. I can’t imagine Cerner or Meditech or Epic, or someone like that, building what PatientKeeper has built, in terms of that really robust physician portal. They’re not going to go out and work with all the third parties that PatientKeeper will, to pull all the other pieces of data into a common portal for them.

We would have had to make a different decision with our Meditech Magic system three years ago if there wasn’t something like PatientKeeper; if we really wanted to go online with our clinical documentation. Now, there are competitors to PatientKeeper that are out there and there are a number of them. We looked at quite a few; so they’re not the only game in town. For us, they’ve been a very supportive group; and their platform has really done everything we’ve asked it to do. If I had to do it over again, I’d probably go down exactly the same path.

GUERRA: You don’t think some of the core clinical vendors will see this as another vendor coming between them and their customer?

CASH: Some will. But again, I think that’s really dependent on the vision they have for their own system and how they want a community hospital to be successful with its physicians. The HIS vendor is not coming into town to make me successful with my community physicians. They’re coming into town to provide me a hospital information system that gives support for my finance group, my lab group, my pharmacy group, my nursing group, my med records group, my quality group – that’s what they’re here to provide. They want to give me a full-service, hopefully, turn-key system that I can manage my complete operations with. It takes more than, sometimes, they’re willing to provide to create my relationship with the physicians that allows us to be successful.

I haven’t found a HIS vendor, necessarily, that’s geared that way for a community hospital. If I was in a university teaching hospital, it would probably be a different story, because I’ve got a more controlled audience. But in a competitive situation between community hospitals, we end up with four or five different applications to solve a problem. The HIS vendor’s not inclined to integrate all those.

When we looked at PatientKeeper, we invited our HIS vendor in and said: “Look, this is what our physicians want, this is what we need to give them, just to get clinical information. Can you compete with it, and do you have the same thing?” And, at least at that time, the answer was, “No.” Now, that may be changing for some of the HIS vendors but again, at that time, their goal was to provide physicians’ access into the data that they maintain and support, not access to all of the stuff that we want the physicians to use to make them really avid users of all of our systems. It’s really a big differentiating factor, and it’s sometimes hard to make the HIS salespeople understand what we need.

Part III

The Health IT Summits gather 250+ healthcare leaders in cities across the U.S. to present important new insights, collaborate on ideas, and to have a little fun - Find a Summit Near You!


See more on

betebet sohbet hattı betebet bahis siteleringsbahis