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

October 7, 2009
| Reprints
Jeff Cash says PatientKeeper has given his Meditech CIS a sweet looking front end.

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 Medtech 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.

GUERRA: Let’s talk about your strategy towards inpatient ambulatory integration. Everybody wants to tie up the practices they own and make sure they’re integrated, but certainly there’s a lot more nuances and subtleties to integrating with the independent physicians.

CASH: There certainly are some political nuances, and the technical challenges are usually just the host of systems that they would be connecting with. So yes, I agree with that.

 

GUERRA: At a high level, what is your philosophy around that? Later we’ll get into the specifics of your arrangement with PatientKeeper.

CASH: Let me start by telling you what we’re doing with our own clinics and how that extends out to the community. We’re a Meditech shop, and we were previous LSS users. LSS offered us a nice host of integration tools that were built-in, but we wanted to get those back and move away from LSS. The reason that we wanted to do that is it was so tied to the hospital system that we were trying to move at different speeds between the hospitals and the clinics because we’re on what’s called the Magic platform with Meditech.

So when we gave up the ability to use LSS for our ambulatory record, we wanted to do the same thing with the new EMR that we put into the offices, which is from Sage. It’s their Intergy product, and the good thing for us is that Sage is used pretty widely throughout our community. So we thought if we could make this work with our own offices, it would extend nicely out to the rest of the community.

The two integrations that extend themselves out to the community very nicely are processing the lab orders to clinical interfaces and eventually additional orders, such as radiology, and being able to send reports back to the offices.

And then the second thing is to be able to handle an intake for these clinical content documents. The flow of clinical content documents is a one-way feed at this point, but our goal is to bring them in from the community, store them in a repository – in our case it’s going to be PatientKeeper as the repository – and then use them in two ways.

The first way is to bring in acute care information – vitals, allergies, meds, those kind of things that you need in an emergency department setting or in an admissions setting – and make them available to our ED doctors and to our hospitalists. Automatically, we’d like to be able to make these CCDs flow over into the system and then make those CCDs show up as an attached part of the medical record, once you’ve established a treatment relationship with the facility. We wouldn’t be able to use the system as a traditional health information exchange (in the sense that some people are building it) because we would only display them if there was a treatment relationship. That really helps us a lot on the privacy side of the business, knowing that if your data comes over to the hospital, it’ll only come up on your physician’s request, and it’ll only show up upon your request for treatment within the hospital.

We know we can do that with Sage. We’ve done some early adopter trials with them. Today, we’re able to manually send one over and have it show up in our PatientKeeper system and provide the appropriate security for that. What they’re building into their product right now is the ability to automatically create those based on events inside the electronic medical record. As soon as they have that in place, we’ll be able to put it into a production environment and have it automatically show up over here at the hospital.

The reason that’s important is we know that an urgent care provider who would login to your PatientKeeper or medical record and look for information for you to be treated is probably not going to take the time and go out and search for a bunch of CCDs in the community, that’s not their nature. So if that CCD is pre-populated and available, as soon as the registration happens, which triggers the medical relationship with us, it’ll be there as soon as they login. It’s more likely to be used because it’s based on the physician’s workflow, which is why we’re doing it that way. There is a “usability quotient” associated with some of this.

We have a community of physicians that is helping us put this together. There are three practices. There’s the hospital, there’s our clinic group (which is 21 clinics here in the community, about 90 providers), and then the next group that’s been engaged in this is our specialty group; it’s called Physicians’ Clinic of Iowa. They have a little over 60 providers and they’re using the same Sage EMR that we’re using. So it makes it a very easy migration for them to add the same functionality and contribute their CCDs to the hospital.

Page
of 4Next
Topics