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.
The other reason that’s important – and the reason PatientKeeper is important – is that we have a competitive hospital about 10 blocks away, and when we engaged PatientKeeper to be our physician portal in front of Meditech, we worked with them (and with some physician nudging along the way), and they ended up adopting PatientKeeper to sit in front of a different HIS system. So we now have these two PatientKeeper integration platforms in both hospitals. So if we build something and it works for the community offices here at Mercy, the same process would work over at St. Luke’s, our competitive hospital; they just need to turn on the same bit of application functionality. So that really was our starting point behind this.
We’ve got a variety of other locations that also use the Sage EMR here in the community, so we knew that was an easy one to go after. As the other two community offices have the ability to auto-create and transmit a CCD to us, we’ll be able to accept those as well. We’ve had a number of offices that are interested in doing exactly that. We just need to build the mechanism for them similar to what we’ve done for Sage. That’s our CCD story.
The second piece of that CCD story, which is a little bit different than providing urgent care, is that we’d like to bring those CCDs in. We don’t actually have all the politics worked out on this one yet, but I think we’re pretty close. We’d like to bring the CCDs into the clinical repository that we have here and perhaps bring in a slightly more robust CCD, and then make that available only to the providers that submitted those CCDs. They could potentially see that information in a locked repository that they would have sole access to. This would allow them to also use that as some form of downtime solution if they lost the EMR in their office for some reason.
So the advantage to that is we’re already pulling CCDs over, only displaying them once a treatment relationship is established, but if we create that mechanism to bring their CCDs over anyway, we’d like to be able to offer that value-added service. Such a service would be valuable if they have only a single EMR server, for example, and perhaps it’s down for some reason, or as in the case of Cedar Rapids when we were flooded last year, a lot of our offices had some real challenges. This would allow them to avoid paying for all the backup mechanisms they would otherwise need.
Our second phase of this, I believe, will eventually be a community-based health information exchange, but there’s a lot of work being done at the state level right now to provide one. So as opposed to us trying to develop a solution via local community-based health information exchange, I think what we were planning on was developing it to meet our needs. The goal is that when you show up at the hospital, we can take care of you appropriately with that one-way push into us, and then as the state rolls out its own health information exchange, we would simply attach to that for routing between primary care offices, for example.
GUERRA: Have you done much under the Stark exemptions?
CASH: We have not. These are independent Sage purchases by the office, and we’ve not used the Stark law as a vehicle yet to provide an office-based EMR to anyone here in the community. Most of our offices are already EMR-enabled on their own. We’re coming down to the last, very small offices that are left, and there are three MSO (management services organization) providers already in the community that seem to be doing a good job taking care of most of those smaller offices.
So that’s really been the community strategy today. We do offer MSO services to some of the facilities, but it’s a cost-based model as opposed to an offset model to start.
GUERRA: Let’s talk about Meditech. How long have you been on Magic?
CASH: We’ve had Meditech’s Magic system for about 20 years now. Our Meditech relationship goes back pretty far. When you say that, you’d think we have a 20-year old system in place, and that’s not really the case because it’s very new. We’re actually on the newest versions of their software, and we’ve done quite a little bit with the software itself.
GUERRA: What version of Magic are you using?
CASH: We’re on a version called, I believe, 5.63 which is about the newest version they have on the market for Magic. So we’ve done a lot with it. For example, we recently implemented the EMR and the bedside medication verification products and we’ve got it heavily interfaced with clinical monitors in the hospital. In our critical care units, it’s interfaced with glucometers, with i-STATs, with all the types of medical devices you would expect.
The challenges we really had with Meditech is that, in the beginning, the physician interface wasn’t going as well as we would have liked because, in the Magic environment, it’s not as robust as you might find with some of the new physician portals. So although it worked okay, it really wasn’t drawing physicians in. That was the first part of a three-way strategy we had for putting PatientKeeper in – to give the physicians a different way to get access to Meditech that was more user-friendly.
The second part of the strategy was to use it as an integration platform, so that anything they needed from the hospital, we would either give it to them in the PatientKeeper view or we would let them find it through PatientKeeper (which would reach out to whatever system housed the data). So they would only need one password, one user ID, one starting place, and they have access to virtually everything they needed.
The third leg of that strategy was that because we have 400 providers in our community, who generally work in both hospitals very fluidly, we wanted to have something that both hospitals could use. So if you’re trained in one location, it works in the other location. It really has changed conversations with our physicians. They’ll ask us about upgrades and enhancements now, but we don’t spend our medical exec meetings talking about how difficult it is for them to use our technology. We now talk about the things you would think we should in those meetings, which would be quality issues. So that’s the CCD PatientKeeper piece.
GUERRA: Is Meditech Client/Server a separate product?
CASH: They actually have two more versions beyond what we have. I don’t know the exact numbers. You might have to get this from Meditech, but I think about 60 percent of their customer base is still on the same platform we are – Magic. A growing number have converted, or almost all of their new installations are on Client/Server and they have recently leapfrogged that again to a kind of third-generation of their platform that they’re using – a product named Focus. You can go from Magic and upgrade to either Client/Server or to Focus. Many like us are waiting because Focus is really only installed in a few, big hospitals. Right now, it’s in an early release process. Although it’s production-ready, a lot of us are waiting a couple of years to see the evolution of it and how well it works before we commit ourselves to migrating. I suspect in the next few years, we’ll be making the commitment of migrating our Magic system to Focus.
GUERRA: Is Focus the same thing as 6.0?
CASH: It is. Honestly, I don’t know if there’s a Client/Server 6.0 or not. I think Client/Server’s ends at a 5.something and then Focus 6.0 is the next version. I believe that they’re selling it to a lot of new customers coming in on a smaller scale. The harder part is really to convert us bigger legacy customers, with everything that we’ve done to the Magic platform, into that new environment.
GUERRA: It sounds like PatientKeeper is a way to improve the physician interaction with your core clinical system. Did you debate between going to Meditech 6.0 or Client/Server because you wanted a more attractive physician interfaced on the one hand, or staying on Magic and layering on PatientKeeper, on the other?
CASH: We were very much embedded in that debate, Anthony. About three years ago, when we decided to take all our nursing documentation online, we put a whole plan together and pulled together a group of physician advisors to give us some guidance. We heard that they didn’t really want to use the system as it existed, just because they said it was less friendly than it needed to be. So we were also concerned at that point about our nurses using it.
What we took from that was, “Boy, if I’m having a hard time with it, my nurses are probably going to have a hard time with it. I’d rather have them spend time doing patient care than worrying about a health information system that’s less than intuitive.”
So it was really challenging for us. At that time, we had to add some additional graphical user interfaces for our nurses on Meditech. So we used a suite of products from Iatrics. We gave them a flow sheet and a visual status board, and some things like that.
Since then, we have migrated nursing back off of most of those because Meditech has really enhanced their nursing product quite a bit on the Magic platform. So they’re very comfortable now using that. And what we said was, “We’re not ready to take the leap into Client/Server with Meditech, because that’s probably at least a two or three year project because of all the dependencies.” We didn’t want to wait that long to get our clinicals online.
So PatientKeeper turned out to be the easy way for us to give the physicians what they wanted, keep the system we had in place, and insulate them from it. So to them, they no longer know we really have Meditech. We could move to another brand of HIS. We could do an upgrade. And they really won’t know the difference because PatientKeeper is a separate repository of clinical information. We put six or seven years of data into it, pretty much everything they need, and it runs independently from Meditech.
So if Meditech is down for an upgrade – which we do once or twice a year – we’ll be insulated from it because PatientKeeper sits between us and the doctors.
As a matter of fact, there was one point in time where our hospital was flooded about a year ago and we did take Meditech down for a short period, for just a few hours, out of concern that we would lose power distribution through the whole facility because we took a lot of water in the bottom two floors of the hospital. We didn’t want to take a chance on crashing Meditech; so we’d already moved all the patients out of the hospital and we purposely shut it down. We had PatientKeeper load up our patient information out of their facility in Boston, and that was the portal the physicians could use for all our transferred patients, which was an interesting way to continue to use that database.
PatientKeeper is a separate clinical database of the same information that lives in Meditech and it works independently. So everything went to PatientKeeper, and we really don’t have to talk to Meditech and vice-versa.
