Editor's note: Dr. David Bates is a Professor at Harvard Medical School, Medical Director of Clinical and Quality Analysis at Partners HealthCare System, and Chief of the Division of General Internal Medicine at the Brigham and Women's Hospital. He is the Board Chair of the American Medical Informatics Association (AMIA), a member of the Institute of Medicine, and External Program Leader, Patient Safety Research, WHO World Health Alliance for Patient Safety. Dr. Bates is one of the world's preeminent researchers in the areas of medication safety as well as the implementation of information technology (IT) systems and their impact on patient safety outcomes. Through his many roles at Harvard, he has also trained and mentored many of the leading lights in the information technology field. He has won numerous awards in the patient safety and IT worlds, including the John M. Eisenberg Award for Excellence in Patient Safety Research and the Award of Honor from the Association of Health-Systems Pharmacists. We spoke to him about the present state of information technology.
Dr. Robert Wachter, Editor, AHRQ WebM&M: Reflecting back to when you started this work 15 years ago or so, what's been the biggest surprise as you think about the way computerization has gone in health care?
Dr. David Bates: I'd have to say that things have gone slower than I thought they might. I think some of the factors that have slowed things down really have to do with incentives that the industry faces with respect to computerization.
RW: Like which ones?
DB: Well, in particular, it's not to the advantage of hospitals today to improve quality or safety. At least it hasn't been to their financial advantage. So that's made it hard for them to justify investing in solutions that do that. On the outpatient front, the big issue is that 89% of the return after a provider starts using electronic records goes to the purchasers and the payers. So that's made it hard for providers to justify making investments.
RW: So, if you were trying to accelerate this pace, would you be focusing on creating a business case for quality and safety, or something more narrowly targeted toward promoting computerization?
DB: It would be useful to do all of the above. I think if you create a business case for quality and safety, that will get organizations to do the right thing. There are some specific things with in-house information technologies that we know work, and some targeted incentives would make a big difference. To be fair, CMS is beginning to think about implementing incentives like that. But they have just moved much more slowly than other countries.
RW: When you look at the slow pace of computerization, how much of it has been because the systems haven't been all that good? I imagine there's a chicken and egg problem: the systems require more users and more investment to get better. How much of it is the nature of the technology itself?
DB: That's certainly accurate. Actually, on the outpatient side, the systems now are quite good. Most industrialized countries have virtually all their primary care doctors using computerized systems. Now, to be fair, they don't include all the things that I think that they should from a safety perspective, or from a quality perspective either. On the inpatient front, the chicken and egg thing is, I think, even more serious because until probably 3 or 4 years ago the systems were not really ready for prime time. Most of the big vendor applications now are sufficiently good that organizations and providers will realize a substantial benefit, although that's probably more true at the high end of the offerings than at the less expensive end.
RW: In the early days of computerization, most of the literature—and most of it came from you and your group—was very positive about all the wonderful things that would happen from computerization. And then there was a shift 3 to 5 years ago, with a lot of literature about unintended consequences and even potential harm. Does that concern you, and has the literature flipped too far the other way?
DB: I can't say that I’m really concerned. I think that the literature on unintended consequences has been very helpful. It has focused people, in particular, on the need to monitor systems, to make iterative changes with systems, and that's the message that I take away from the unintended consequences papers. When you put in any new system, it will create new problems. If you don't go through and find out what those are and serially weed them out, then you won't get to where you want to go. One thing that does concern me a lot is that most of the studies have been done on homegrown systems. There have been relatively few studies done on commercial systems. I think we need a lot more evaluation of commercial systems to see whether the results that you get with them are the same as with other applications. What's beginning to emerge actually is that, with respect to decision support in particular, it's not just what you deliver, but how you deliver it that is really important in terms of getting the results that you want to achieve.
RW: So talk a little bit about decision support. I think there may have been a naïve vision in the old days that you put up a bunch of pop-up alerts and you get people to do the right thing. It seems like it is much more complex than that. What have we learned about making effective decisions for it to work?
DB: We've learned a lot. One thing we've learned is that how to do it best does vary a lot by the specific clinical situation. For example, most of the experiments in delivering clinical decision support for chronic disease management have failed. It's clear that chronic disease management is a pretty complicated area. On the other hand, for medication-related decision support, many more of the results have been positive. And yet even for medication-related decision support, it turns out to be quite important to pay attention to all kinds of human factors issues when you're delivering the decision support. The results that you get appear to vary quite substantially based on how you deliver decision support and what you set as your defaults. Another key issue is whether you clearly delineate to users that the warning that you're showing is an important one, and whether or not you use a pop-up and interrupt the provider.
RW: Ten or twenty years from now, how much of the work that we presently think of as cognitive and the daily work of physicians will be taken over by computers?
DB: I still think that computers are essentially going to be aids for providers. Where we'll be in 10 or 15 years is that the cockpits we have will be much smarter than they are today, and vastly different than they were back in the old paper world. In the paper world, you essentially didn't have any feedback when you sat down and wrote orders, for example. Whereas, with computer order entry, all sorts of information can be brought to your fingertips. Ten years from now, I think the way that we'll be doing that will look quite a bit different. That being said, I think physicians for the foreseeable future are going to continue to do the thinking. Many of the early interventions with computers and medicine were focused on getting better diagnoses, and computers basically did not do as well with that as people do. But what computers are really good for is ensuring that specific things happen reliably. For example, I think that computers will help us make sure that we tick off six items on a checklist when we're doing a specific activity.
RW: When David Brailer became the IT czar, I think he surprised some outsiders by focusing so strongly on the issue of interoperability. He seemed to believe that was a core issue in moving forward the IT agenda. How important do you think it is and where are we in terms of interoperability?
DB: It's a very important area and quite a hot issue. So much of delivering safe care depends on having a complete picture of information about the individual. And today, we just so often do not have that. I also think that improving interoperability will substantially drive down costs—models suggest that the benefits will be very substantial. But the approach that we've taken as a country to moving toward interoperability has been to set up RHIOs—the Regional Health Information Organizations. I have some serious questions about it. We published a paper recently in Health Affairs in which we looked at this. There are only about a dozen RHIOs now in the country that are exchanging large amounts of information, and it's also unclear how many of them are doing well financially. I personally believe that clinical data exchange is extremely important, but that it's likely to represent a public good and that we're going to need some federal or governmental investment if we're going to achieve clinical data exchange on a broad scale. That being said, I think that once we begin to do that, the results will be very impressive and tangible.
RW: What's the mechanism for all the cost savings that come from interoperability?
DB: Most of the savings come from reduction in repeat and unnecessary testing. Patients often get multiple drugs that they don't necessarily need, and so on. There are also major administrative savings.
RW: Does it drive a more competitive market because the cost of leaving one system and going to another goes down as well?
RW: Think about the market. One of the interesting things about health care IT has been its domination by small to mid-size health care–oriented companies. Yet in the last few years, we see Microsoft, Google, and other mammoth companies entering the business. What do you think is happening, and where will that go?
DB: Well, I think that the market is ripe for change and that we could see a large company like a Microsoft or a Google make a major incursion into health care IT. Recently, there's been a strong drive to begin to use a standard and to avoid using proprietary data structures, and that has required a lot of health care IT companies to change their approach. Their old approach was to get a number of clients, to sign contracts with them, and then, by using these proprietary data structures, to lock people in for life. That is no longer a tenable approach. That being said, both on the inpatient and the outpatient side, the markets are relatively immature. You have a very large number of companies on the outpatient setting, a smaller number on the inpatient side, but still quite a number for a mature market.
RW: I wrote something a couple of years ago on what I called the "dis-location" of medicine and observed that one of the things that computerization does is de-tether the provider from the patient's bedside. Here, our residents all write their notes five floors away from the patients because that's where the computers are. People don't go down to radiology to have rounds anymore because they don't need to do so to see films. Do you worry about that, and are there any IT solutions for that unintended consequence of computerization?
DB: I think it's both a benefit and has downsides. It makes providers much more efficient than they might have been, but there are clearly risks too if you don't, for example, go look at the patient. The electronic ICU is interesting in this way. Basically, a large part of what VISICU [an electronic ICU vendor] does is set something up so that someone can look at the patient, or multiple patients, from a remote site. So, telemedicine is one way that we could get around some of this. Another thing we need to move toward is developing software that enables multiple people on a team to rapidly get a sense of who's doing what with respect to a patient and to sort out, for example, what the goals are for that patient. The software that we have today really doesn't enable that to the degree that it should. That's one of the big frontiers in software in the next 5 to 10 years.
RW: If a hospital was thinking about getting into IT and could buy only one thing or needed to figure out what to do first—deciding between electronic medical record, computerized order entry, barcoding, smart pumps, and all the other things that they could do—what would you recommend?
DB: It depends a lot on what the hospital already has in place and what their resources are. There's no simple answer to that question. On the electronic medical records side, there is a pretty clear-cut pyramid of what you should do. So, for example, perhaps the first thing you should do is put in results reporting. Then, the next most beneficial thing is probably a clinical data repository, and then computerized physician order entry. Electronic charting is probably the last thing that you should do because it's the most difficult. However, I think it has a lot of benefits and most hospitals will, in the not too distant future, want to do all of those things. Barcoding is a relatively easy thing to put in, and you could put it in even if you don't have a very fancy electronic record. Smart pumps cause even less disruption than barcoding with respect to implementation, and some institutions already have pumps that can be made smart, while others will need to buy new ones. So there's pretty substantial variation in terms of what it takes to implement some of these technologies, and what to do at a given time is perhaps more complicated than it ever has been.
RW: Let me ask that question another way. If my parents called me and said that they need to go to a hospital in their community, and they want to check out whether it seems like a good hospital based on that hospital's IT inventory, which piece of information technology would you most want to see as a measure that this is a safe and high-quality hospital?
DB: The single thing that I would look for is computerized physician order entry. That is the piece of technology that has been best demonstrated to improve safety. Just because a hospital has implemented CPOE does not mean that they necessarily have the decision support in the application that will deliver benefit. But there is a reasonably strong correlation there. Some years ago, Leapfrog identified CPOE as one of the three things that they thought would most improve safety. Still, only about 15% of the nation's hospitals have implemented it. But I think all hospitals should eventually implement barcoding and smart pumps too, as well as some other technologies.
RW: You have done remarkably powerful and important research in an area of great complexity. What lessons have you learned from your research career that you think are applicable to other people doing research—perhaps not in IT, but areas that look like it in safety and quality?
DB: It's very important to ask what works and not to make too many assumptions. Some of the things that I thought would be really straightforward and would work really well didn't work at all. So it was important to basically ask the questions and empirically look and see how much difference things made. It's also really important to do economic evaluations, particularly in the safety and quality world. Because institutions today have so many different options that, without information about what the return on investment is, it's very hard for them to prioritize. I feel like that's a big gap. Our group has done some work in that area, but I'd like to see it do even more. When I consider from the national perspective what things to recommend to organizations, that sort of information is often lacking.
RW: What are some of the things that you think are going to be especially beneficial in the future?
DB: One is computerized physician order entry. The best evidence comes from hospitals. Another is barcoding. I am excited about smart pumps, although the trial that we did that looked at their benefit was negative. I think smart monitoring is going to make a really big difference, and we'll start to see a lot of work in that area. Perhaps one of the next big things will be looking at smart monitoring in patients who are not in the intensive care unit, looking at their vital signs, and finding patients who are about to deteriorate. Computer-aided notification about critical test results can make a big difference, and that should be used much more widely than it is. I think hospitals should be starting to use computerized monitoring for adverse drug events. When someone does experience an adverse drug event, much of the time there's a signal that suggests that it's happening and that should be more widely used than it is. Finally, in the outpatient setting, tools that help providers track abnormal test results are a really important addition to the armamentarium. That's one of the major causes of adverse events and malpractice suits in the outpatient setting. We should be able to develop systems that ensure that 100% of abnormal biopsies or 100% of abnormal Pap smears, for example, get followed up.
RW: It's interesting that, if you go through that list, it seems that where things might fall apart is when all of a sudden users are getting ten different alarms going off at the same time without it being integrated in a way that they can understand. Do you worry about that?
DB: Absolutely. I think that's critical. And it's certainly an underaddressed area. We're thinking of trying to develop a single in-basket so that all the things that come in that you think you might need to do something about come to one place, so that they're prioritized a bit. It's a real concern that if you have to go to 12 or 15 different places, you just will have a very difficult time managing. But that's the kind of thing that a well-designed information system can really help you with. But it won't necessarily do that unless it's designed in the right way. The other thing is that I think it's very likely that if you deliver too many false signals, that will have very substantial adverse consequences. You have to put in the right kinds of filters. And we're still working out how to do that.