One-on-One with Virginia Commonwealth University Health System CMIO Alistair Erskine, M.D., Part II
Virginia Commonwealth University Health System (VCUHS) is an academic medical center that has served the Richmond, Va. area for more than 160 years. The VCU Health System’s academic mission supports and is directly linked to Virginia Commonwealth University. As the clinical delivery component of the VCU Medical Center, VCUHS is a regional referral center for the state. MCV Hospitals is the teaching hospital component of the VCU Health System, which also includes several outpatient clinics and MCV Physicians, a 600-physician, faculty group practice. Also included in the system is the 779-bed Medical College of Virginia Hospitals (MCVH) and VCU’s Massey Cancer Center, a National Cancer Institute designated facility. The VCUHS treats more than 80,000 patients annually in its emergency department, which is the region’s only Level I Trauma Center. Recently, HCI Associate Editor Kate Huvane Gamble spoke with Alistair Erskine, M.D., who serves as CMIO and Internal Medicine Hospitalist at VCUHS, about his role with the organization, his thoughts on pushing forward during tough economic times, and how his organization is leveraging technology to improve the safety and quality of care.
KG: So in your case, the HIMSS Analytics rating isn’t a true reflection of where the organization is in terms of IT adoption.
AE: Yeah, and the official letter of the law in terms of HIMSS Analytics is you only need it in one unit to be able to meet the requirement for that stage. So we actually considered putting barcode medication in the palliative care unit; you know, some sort of low-risk unit, just to be able to call ourselves stage 6. But then what’s the value of that? Okay, so we’re stage 6 — so what?
KG: That’s a very good point. Are there plans to deploy barcoded med administration?
AE: We would have it up and running now, if it weren’t for the fact that our capital dollars evaporated with the economy. We have it on the road map and we actually already bought the software. We’re just in a place where we don’t have the capital dollars to implement in right now. It’s kind of sitting on the shelf waiting for us to either get some additional support or wait until we have renewed capital.
KG: Unfortunately, that’s a recurring theme in these times. It’s very frustrating, I’m sure.
AE: Especially because when these things lose momentum, it does take a certain amount of effort to get them back up to speed. So if you stop a project like that, all the people who’ve been involved and preparing and thinking about it and trying to come up with design decisions, come to a screeching halt. And then a year later, it takes a fair amount of effort to get it back up again and going. That can be frustrating.
KG: One of the technologies not stuck on the shelf is a patient hand-off system from PatientKeeper. What’s the status on that?
AE: It’s in the process of being rolled out. We have had some initial very quick successes with a lot of adoption from the people we were rolling out to, almost on their own, which is a good sign, as they’re the ones that are actively involved in trying to make it better. There are a couple of objective measures we are examining that we don’t have results on yet.
One of them involves residency training. There are a lot of rules surrounding work hours, and the ACGME (Accreditation Council for Graduate Medical Education) is the group that basically oversees training programs and will fight organizations if they have residents that spend more than 80 hours a week at the hospital. So what we found, before we move forward with the sign-out tool from PatientKeeper, is that part of the reason that residents would remain in the hospital for longer than 80 hours is because they were spending an inordinate amount of time creating these word for Windows documents to sign out to their colleagues that can e-mail. And those documents had a series of problems with them. Number one, they weren’t always accurate. Number two, they were fixed in time from the last moment they were updated. Number three, they took a lot of time to create. Number four, they were in a location on a shared drive that did not permit users to really know who was accessing the document, which is something that, for HIPAA reasons, you really need to have. You wouldn’t want me to do be able to go and look at somebody else’s sign-out report about a patient without there being some sort of audit trail that I was doing so. And in order to facilitate general accessibility to these sign-outs for clinical reasons, they would put it on the shared drive. A resident will come up with any kind of work-around possible to be able to deliver clinical care. So you can just imagine the variation in ideas — jump drives and shared drives — of how they would share this information.
Trying to solve this problem of making it more efficient and making the document itself more accessible in a HIPAA-compliant way, and making it more accurate so that it was automatically being fed by EMR content, was definitely the goal we were trying to accomplish.
KG: And the plan is for it to tie in to the EMR?
AE: Right now, the way it ties in is not, from my perspective, an ideal state, in the sense that the patient lists that are in our Cerner system do cross over very nicely. All the ADT information in terms of admission, discharge and transfer information is in there as well. Then there are some structured formats such as, follow up on the CBC or check on this x-ray, that the residents themselves can add, as well as unstructured notes about, ‘Be careful with this patient, she may get sick and have these particular symptoms’. So that information is available for them to put in, and then from day to day, that information carries forward.
Now what it doesn’t have but needs, and will be added in the next 2-3 months — we’re still in the validation stage — is all the rest of the clinical information, like radiology reports, clinical notes, laboratory, allergies, medication lists, problem lists, all those genetic components of a clinical record. That is all going to be added to this tool. It’s available now, but we wanted to go through a validation stage of making sure that all the information is accurate before we let it loose to the environment. So it’s just a matter of PatientKeeper building what they call a Cerner bridge, which is a tool that allows direct integration, more so than an HL7 interface; direct integration of that application to PatientKeeper.
Once that’s available, they won’t have to add any labs or anything like that, all they’ll be doing is updating the EMR like they do now and writing the notes, and everything will flow into the sign-out tool automatically.
KG: When you do estimate you’ll be able to start putting in the clinical information?
AE: About two or three months. We have it in our development domain; we want to make sure it’s working the way we anticipate, so that anything that I see in Cerner ends up being replicated exactly in PatientKeeper. I’ll give you an example. We had a lab that would come over, and it was the right lab with the right range of highs and lows with the right number, but it had the wrong date. You don’t want to expose residents to labs that they are interpreting now as being the day before instead of the day of. We want to make sure that the date is accurate along with everything else. So that’s the kind of validation process we go through, just making sure that all the information that is coming across automatically is 100 percent accurate.
KG: Which is extremely important, particularly with the amount of data you’re dealing with.
AE: Exactly. There is one additional significant benefit to us, which is a complex synchronization that PatientKeeper I think has done a really great job with. Every 48 hours after discharge, this information that’s being added by the residents or the attendants who use this tool is eliminated. It’s a really interesting concept, because in an EMR, if I would do my sign-out process in an EMR, all that information is discoverable, anything I put in there. There’s a premise that we and PatientKeeper have made — there’s certain information that really is hand-off related that really is not designed to be a permanent part of the medical record. And because we’re in a foreign system that’s pulling information, and that we’re using that primarily as a communication tool, separate from all the documentation tools, we have the ability to purge that chart of that information, so that, frankly, the residents can be more honest and upfront about some of their comments that they need to make on the different patients — more in medical speak as opposed to official documentation speak.
KG: But it only deletes information that was entered by residents?
AE: Right. It’s nice a way of basically cleaning up that sign-out, so that, for example, if a patient returns a few days later, it’s kind of a fresh slate. There’s no record of all the communication-based information between providers, other than what is officially documented in the medical record off their daily notes.
AE: It was set up in the system in that way based on the feedback they were getting from clients. We struggled with trying to solve that problem in our own system. I’ll give you an example of the workaround that ensued. We would have a sign-out process in our Cerner EMR, basically doing the same thing, but having a form that lets you add comments, and what they would do is write some basic information and pull information and print it out, and then write their real comments on the piece of paper, because they didn’t want it to be a permanent part of the medical record. So what this does is allow us to keep that information electronic, but not permanent.
Part III coming soon
