Sibley Memorial Hospital is a non-profit, full service 328-bed acute care community hospital serving the Washington, D.C. area. The hospital’s campus is also home to its assisted living residence (Grand Oaks) and The Sibley Renaissance which houses the Center for Rehabilitation Medicine, Sibley Senior Services, skilled nursing care and a residential Alzheimer's unit. Recently, HCI Editor-in-Chief Anthony Guerra had a chance to chat with CIO Lorraine Fordham.
AG: So you felt a good fit with Compucare/Quadramed in terms of the criteria you talked about earlier?
LF: We first started doing business with that company in 1984 when we bought our first order entry results reporting systems, our first ADT systems. The company itself has undergone a lot of different transitions. They were bought by Baxter, then they got bought back out, then they were bought by Qudramed, and now they are buying up some products themselves. They bought the Misys CPR product. The philosophy of the company has very much suited us. They have got an active user group. They listen to what we say. They try to accommodate our needs. That is the company that we have had the longest relationship with, but we use that as a model as we go to look at radiology systems, for example. When we were buy our radiology and PACS systems, our final two vendors were GE and IDX.
It wasn’t a hard choice for us because GE was too big. We didn’t like a lot of things we heard on our references in terms of how they supported their users. They have a good product, but they would come back and say no, that is the way it is. So we said ok, we are going with IDX. Well of course, little did we know that GE would turnaround and buy IDX. We were sort of sitting around waiting on somebody to buy Qudramed while they went and did that. Now we are waiting with baited breath to see which of the products they will continue to support. Right now, they are still supporting both. GE is still supporting the IDX product and the GE PACS, and we are probably going to look elsewhere if they discontinue the IDX PACS because we are not happy. We are not happy right now with our relationship with our vendor for imagining services, and we were very happy with IDX.
AG: Any more on the IT side, in terms of the way an application is constructed making it more or less attractive?
LF: What we will look at there really is: do they use standard interface technology. You hear about HL7 a lot, but I hesitate to ask if they are HL7 compliant because that means a lot of different things. It is not really as standard as we would like it to be, but it is the best we've got. So we will definitely look at the interoperability features and functions of these systems, and if they say, ‘Oh no, we can’t readily implement text data between our systems,’ we will look at that level. Do they use standard reporting?
I have a small staff. It is not that small, but it feels small with all the projects we have got. I can’t have people that are expert in five different database languages and six different report writers. Whether they are good, bad, or indifferent, the ones that we use the most are the ones that we are going to want the other vendors to also play with. And they are standard. They are things like Crystal reports, and SQL, and Oracle.
Most of them do, but if we came across one that didn’t, one that said, ‘Oh no, no we have our very own proprietary database,’ our alarms would go off. We would say automatically they were eliminated, if they had the best functionality and the entire team said they were head and shoulders above the rest, and we can’t possibly go to the other vendor that has what you are looking for, we would probably support them in it, but we would bring it up and we would talk about it. Usually it hasn’t been an issue. Usually we find the vendors that have the technical infrastructure that we are looking and also have the functionality that the users are looking for.
Now the big change, philosophically, in our system selection is that up until last year, we were pretty much letting the users be best of breed, go out and get whatever they wanted, whether it interfaces or not. That interoperability question has become a real issue particularly with the pharmacy, with the closed-loop medication management. I don’t know how much you know about that or have heard about that, but that whole piece brought us up short about a year and a half ago, when we realized we can’t really integrate our order entry systems to our pharmacy in such a fashion that it is going to work efficiently for our nurses. What we really need is a system that has the pharmacy built into it and that is one of the reasons we are going with the CPR product. So we are looking for clinical systems that provide integrated medication management as opposed to interfaced.
AG: I’m hearing more of a lean towards the enterprise approach of having a core vendor and trying to get as many apps from them as you can.
LF: That is exactly what we are doing. We are calling it best of suite as opposed to best of breed. So, for example, we have Lawson for our financial systems. That’s payroll, general ledger, accounts payable. If we go out to buy a budget system, we’re going to look at Lawson first. If we go out to buy a contracts management system, we’re going to look at Lawson first and probably not look any further, if they have at least a C+/B- level product.
The same for the clinical systems, we will look to our clinical systems vendor first, and wherever possible incorporate products. If we do what we plan to do with Quadramed, then when GE decides what they are going to do about their radiology system, we very well may switch over to the Quadramed radiology system. That’s the kind of thing we would do, but we are calling it our best-of-the-suite philosophy.
AG: Why is integration between two different vendor applications so difficult, and it seems to me a good word would be ‘unpleasant’ for CIOs to contemplate or deal with?
LF: It absolutely is. To take it to its simplest level, let’s say you have an admissions system from one vendor and a pharmacy system from another vendor. Now let’s go beyond the regular demographic information which everybody is finally kind of standardized on. Let’s take allergies as an example. As I’m admitting a patient and doing the admitting assessment in system A, I will ask the patient are you allergic to anything, and he says yeah I’m allergic to penicillin. In system A, I might have to put in a code that indicates what he is allergic to, 01 might be penicillin, or as is the case with our current admitting system I just put in text, in which case as a care giver I might spell out penicillin. I might put PCN. I might put anything.
Now I interface it to the pharmacy system, because the pharmacist doesn’t have any opportunity to see the patient, so they can’t ask them again what they are allergic to. The pharmacist receives this text HL7 message and tries to map it to his side, and now on his side let’s say that the allergies are all coded. They are codified. They can’t be spelled out. They have to be a specific thing, so now I have got a problem.
Now I have a problem, because somehow, someway, somewhere I have to translate that information, so that it is understood by both of those systems. Throw in another, say, a surgical management system. They also need to know that, and they might do it another way. And that’s just with one piece of data.
AG: Can you talk about who you are using for EDIS?
LF: Picis, and that kind of fits our best-of-suite philosophy, because we have Picis in the operating room, and we have Picis anesthesia management, and Picis for PACU, the recovery unit.
That’s the other piece I was going to say. Once we got past the concept of the data not necessarily being defined the same between systems and therefore not flowing easily. Then the next issues is having all those vendors, and having to keep track of all those vendors and what they are doing in the marketplace, and who have they been acquired by this week. Those are all reasons the CIOs are pulling their hair out and saying, ‘For God’s sake, give me one vendor and at least if they get sold I’m still only going to deal with one vendor.’ You know what I mean? Those are really the things that are driving me out of my mind. We can’t have an electronic health record that can be passed among hospitals until we get better standardization, and we’re getting there, but boy are we getting there slowly.
AG: Are you looking for more out of HL7?
LF: I am frankly. Yes.
AG: What would you like to ask that group?
LF: First of all, are they going to be players? Are they going to have any say in what constitutes an electronic medical record? There are really two things in my mind. There is an electronic health record which is my cradle to grave, everything you ever wanted to know about me no matter what hospital I go to, and then the other is my medical record which might be specific to a facility. For that one, you don’t necessarily need to know what drugs I was taking 15 years ago for a pain in my foot. So that could stay within that area.
I’m having a great deal of difficulty as a CIO in working with the director of HIM in getting standards that define what constitutes the health record, what pieces of data do you need, and then what pieces of data do you need to stay within the walls of the hospital? And then how does HL7 plan to address that? Are they going to play in that arena? Will they continue to be the standard for passing data, in which case they have got to get rid of a lot of their Z-messages.
We have more of those than we have the standard order messages, and results messages, and ADT messages. Now I am not an interface expert, but I could put you in touch with my integration engineer who has worked here for the last 20 years, and he could sure tell you what his problems are with HL7. He struggles with it daily as he tries to pass data.
Right now we have about probably 20 systems, maybe not quite that many, maybe 17 that have patient data either being collected or stored in them. The concept of getting all of that out of those systems and into a central data repository, that keeps me up nights. I don’t see how without HL7 we can ever accomplish that, so I think they are an important piece of this whole picture. I think we need more standardization from HL7 and less flexibility, which will then, in turn, force the vendors to become more standardized within their systems.
AG: Does HL7 have to balance being too tight with being too loose?
LF: Probably. I would have to say yes. Because the vendors are not in any hurry to standardized amongst themselves. Why would they? Then systems become virtually indistinguishable one from another. So yeah, I think there is probably some of that, and then the requirements are different. Healthcare is a very complex entity, and the more years I spend in it, the more I realize the complexity of it, because physicians have different needs. Physicians want to see data presented different ways than nurses do and all that comes from their training. If they were trained differently they would expect it to be different, but is there any effort to standardized how you document on a patient’s record in the medical schools? I somehow doubt it. At least we are not seeing any evidence of it in our medical staff as they come in. They all still have their own wants and needs, so and yes HL7 tries to be flexible, tries to allow you to accommodate as many people as you can. At some point we have got to quit being accommodating. We really do.
My CEO says that we are not going to move forward with technology in healthcare until there is one standard. I look at him and laugh, and say, ‘Well that isn’t going to happen, not in our free enterprise system.’ All the other vendors aren’t going to say, ‘Okay, well, we will go away now and let you be the vendor of hospital information systems.’ If our government picked one, then that is what they would do. But the government is not going to pick one, just like the government doesn’t pick the system for the insurance industry or the banking industry. Those industries are really not as complex, I don’t think, as healthcare in terms of the quantity, and the different kinds of data that flow through.
AG: So the vendors really have little incentive to standardize, because true interoperability would mean they never have a captive client?
Part III coming soon
