Skip to content Skip to navigation

One-on-One with Sibley Memorial CIO Lorraine Fordham, Part III

May 6, 2008
by root
| Reprints
In this part of our interview, Fordham talks about the important difference between interfacing and integrating.

Part I

Part II

AG: So the vendors really have little incentive to standardize, because true interoperability would mean they never have a captive client?

LF: Exactly. That is exactly right, so it is not going to happen but it is a nice dream. But I am going to be interested, as I go into my golden years and start to become a consumer of healthcare, I’m going to be interested to see how it continues to evolve. It certainly has evolved. I mean having been involved in this from a technology standpoint for the last 27 years, I have just seen huge changes, but at the time they were happening they didn’t feel so huge. Looking back in retrospect, they really are: the ability to use physician support systems, to track core measures, to make sure that patient safety initiatives have been implemented, and that the standards have embraced most of them. The ability to say, ‘I have got a patient in the emergency room that is short of breath and coughing,’ and have the system come back and say, ‘Did you think about giving them an antibiotic for pneumonia,’ since the national safety goals are that you get an antibiotic within an hour of presenting in an emergency department with symptoms of pneumonia. Well now you don’t have to depend on the person to remember to do that. The system tweaks them. It doesn’t make them give it, but it tweaks them. That is a big deal.

I just see examples of it over and over again and that part I find exciting. I really get excited about that stuff, because the Institute of Medicine came out with their study on errors in hospitals, and we actually did a flowchart of what happens to a pharmacy order from the time the physician orders it until it is given to the patient. It was phenomenal, and we did this 10 years ago, but there were about 50 distinct steps in that process, and 20-some places where an error could be made from the doctor writing it, to the clerk translating the doctor’s handwriting, to the nurse looking at it and sending an order to the pharmacy. It just went on and on and on, right up to the point of picking the medicine out of the drawer and giving it to the patient at any one of those places. It actually is amazing that anybody ever gets a drug administered correctly, and yet technology has proven over and over again that it can help with that process. It can make sure that you get the right drug to the right patient at the right time.

And so that part of it is exciting, going from basically admitting billing systems, which are pretty boring, to getting into the patient care arena, and seeing all the things that can be done. That has been exciting.

AG: Patient safety initiatives depend on data flow and integration, so how do you handle that? Do you have an interface engine?

LF: We do. Yes, it is Quovadx.

AG: Does having an interface engine solve your cross-vendor integration problems?

LF: It doesn’t solve it. It allows us, to some extent, to solve them ourselves, but it is cumbersome, and it’s a big job. But that’s how we do it. We basically bring something into the interface engine, and if it needs to be tweaked, I have got two people that know how to program that, so that it can be changed to what the other system is expecting. But you have to build the translation tables. Translation tables can be a huge job, especially when you’ve got hundreds of orders and thousands of drugs, and I don’t know how many allergies there are in the world, but it seems like there are a lot. It’s growing every day.

Yes, an interface engine is key. I don’t think you could run an efficient best-of-breed structure without an interface engine. Frankly, not even a best of suite, because you are always going to have some standalone systems.

In our environment, my best example of that is we have a separate vendor for our OB/GYN for labor and delivery for their documentation, but it started as a software that ran off of the fetal monitors. My standard HIS vendor doesn’t have anything that directly integrates to the fetal monitor so that I can chart right on the monitor script what is going on, and that is what they need to be able to do. So that is such a specialized need that a big HIS vendor is never going to have that. It’s always going to be a little standalone vendor.

AG: Unless they snatch up the vendor.

LF: Unless they snatch up the vendor, but even if they do that, it is still going to be a standalone product sitting with their suite of applications.

AG: They are not going to integrate it on their end?

LF: It won’t be fully integrated. They never are. They are interfaced.




If we would just create a standard, and encourage developers to develop to the standard we could build truely integrated, multi-vendor systems. Share my dream at