Perspectives on Safety—A Decade After HITECH
We also interviewed John Halamka, MD, MS, the International Healthcare Innovation Professor at Harvard Medical School, Chief Information Officer of Beth Israel Deaconess Medical Center, and an emergency physician. He is widely known as one of the most thoughtful and provocative experts on the subject of health IT. We spoke with him about the HITECH Act and the consequences—anticipated and otherwise—of the digitization of health care.
In Conversation With… John Halamka, MD, MS
Interview
Download: (May_2018_Halamka-podcast.mp3 | 13.6 MB | 9 minutes, 56 seconds )
Editor's note: Dr. Halamka is the International Healthcare Innovation Professor at Harvard Medical School, Chief Information Officer of Beth Israel Deaconess Medical Center, and an emergency physician. He is widely known as one of the most thoughtful and provocative experts on the subject of health information technology. We spoke with him about the HITECH Act and the consequences—anticipated and otherwise—of the digitization of health care.
Dr. Robert M. Wachter: You've been quoted as saying this: "We gave clinicians suboptimal cars, didn't build roads, and then blamed them for not driving." What do you mean by that?
Dr. John Halamka: As a person who was involved in multiple health IT standards committees, what we came to realize is that building standards was necessary but not sufficient for sharing data. In essence, we told doctors, you're going to type in all this data and now share it with all the other doctors in the community who need to see it. By the way, there's no address book. When you hear folks at ONC [Office of the National Coordinator for Health Information Technology] or CMS [Centers for Medicare and Medicaid Services] say something like, "Information blocking is the reason Bob Wachter is not sending data to Texas"… well, I have actually never seen volitional information blocking. Maybe people don't know technically how to share data, it isn't a priority, or they don't have the tools and workflow that they need. A similar problem is that, if we don't have a national health care identifier or a nationwide patient-matching strategy, not only do I not know what doctor to send it to, I don't know what patient necessarily we're sharing data about. In my conversations with past and current presidential administrations, I say we should work on a nationwide provider directory of electronic addresses, and a nationwide patient-matching strategy. Right now, if you want to send data from New Hampshire to Massachusetts, you pretty much cannot. There are significant restrictions on what data can be sent across state lines, who it can be sent to, and how it can be shared. We have 50 different privacy policies. That's what I meant. There are no roads. We don't have the tools, technologies, and workflow needed to do this simply. Then to say, "Doctor, you aren't sharing data, you are blocking," is just wrong.
RW: Let's take a step back and look at HITECH as an effort to move from a paper system to a digital system. How well did that work, where did they get it right, and where did they get it wrong?
JH: My traditional grade on the effort is C minus. Why? Did we move from 10% adoption of electronic health records to 90% adoption of electronic health records? Sure we did. But really what did we do? First, what we did was recapitulate in digital form paper processes that have been used since the giants of medicine walked the earth in the 1800s. We didn't think about how technology would enable novel workflows that would improve quality, safety, efficiency, or reduce burden. We just digitized the paper, maybe in some fancy ways, but it was still digital paper. That's problem one.
Problem two, and I sat in on over 200 committee meetings in the Obama Administration, so I saw how this happened. The CDC [Centers for Disease Control and Prevention] says, do you know that syndromic surveillance is really important? Well, it does sound reasonable. Who wouldn't want to combat SARS [severe acute respiratory syndrome]? Here are the data elements that the doctor has to collect. By the way, immunizations are also really important. Oh, of course. Who would want kids to get mumps? We need to enter that. Then the FDA [Food and Drug Administration] would say devices are really important, and we need a universal ID on every device so we can track implants and recalls. Who would argue with that? Before you know it, CMS said there are 40 quality measures, and here are the things that need to be entered. Every government agency had a very good idea. And we adopted all of them, simultaneously, requiring a doctor on average to enter 140 data elements with every encounter in their 12 minutes to see the patient, listen to what the patient has to say, make eye contact, be empathetic, and never commit malpractice. And as you have so brilliantly written in The Digital Doctor, this is not possible.
RW: Thank you.
JH: This is why I give it a C minus. Because the goal was to digitize paper, but along the way it required too much administrative burden by clinicians. Too many goals were executed simultaneously. One side effect of doing this at such a rapid pace is that there was no time to evaluate usability. There was no time to evaluate the impact of what we were doing. We were just on this treadmill of going from Meaningful Use stage one, to two, to three with zero time for evaluation in-between.
RW: I'll push back slightly on that, and I tend to give it a slightly higher grade than you do—maybe because I judge both problem one and problem two as almost inevitable given the facts at the time, which were all of a sudden we had access to $30 billion and we had to get it out the door. Getting to 90% adoption from 10% is extraordinary, not preordained, as we saw in Britain, where a very large investment in digitizing the hospital sector didn't work. These downsides in some ways seem to me to be almost inevitable, and then you're going to have to clean up after them. Tell me why that's wrong.
JH: Well, you have to give me the parameters of the question and what preconditions I'm allowed to change. If you say you have $31 billion that will evaporate in 4 years, well sure. You create a mess and then clean the mess. But if you were to design a program from scratch for a country, how would you do it? Then I would probably focus on fewer things at a deeper level than we did. Say that we believe that the biggest bang for the buck is simply getting a problem list, a medication list, and an allergy list, shared. Let's get those entered, and by the way it doesn't have to be done by the doctor. It could be any member of the team. Let's create a guiding framework for consent and privacy protection—even though state laws might vary—and let's imagine that we aligned incentives. Imagine doctors weren't paid until they actually sent the data to the next provider of care and it was imported. Suddenly you would find that if we focused on a few things deeply with the right incentives, we would have gotten to that end point probably better than we have thus far.
RW: How about the workflow piece? Maybe I'm being too charitable, but the history of technological disruption and innovation in other industries says that people don't understand the workflow and the disruption to communication patterns and job descriptions until after it's in. Then they scratch their heads and then go around fixing it. Do you think we could have gotten that right if we had gone more slowly and been more thoughtful about it?
JH: If you would have said, we're going to do stage one then we're going to take a pause for a thoughtful evaluation before jumping into stage two, then we would have had time to make some midcourse corrections. But again, if you presuppose you have $31 billion, and you have a very compressed timeframe. So I'll agree with you that when we did medication reconciliation at Beth Israel Deaconess, we were the first to actually build our own Meaningful Use–certified electronic health record, and I think we were the only to self-build for stage two. We ended up rewriting medication reconciliation five times. We were able to do that because we were kind of a rapid-cycle agile shop, and the doctors were writing software for doctors. They'd push it live and they'd say, do you know the burden of medication reconciliation? It takes me 10 minutes just to get the medications in, and then 2 minutes are left for the patient. By the time we'd finished the fifth iteration, which couldn't have been known when we started the project, we were down to under 1 minute for medication reconciliation because we knew what to prepopulate. We knew what checkboxes were easy. We understood the workflow. Of course, sometimes in order to get to an optimal solution you have to have several suboptimal solutions along the way.
RW: Speaking of suboptimal, let's talk about the vendors and the systems that came in on the wave of the $31 billion. Obviously there have been two or three big winners. You'll hear people say we should have waited until the systems were better. Should we have? Or did we need to get the systems that were available at the time implemented and then go about trying to fix them?
JH: You ask a very fair question and the answer is probably a little bit gray: Should we have waited until we had a Prius before driving cars? People would say no, we had to go from Model T to a Camaro to Prius, because there's no way to just introduce a Prius in 1909. We had to deal with the state of the art that existed at the time HITECH was passed. The unfortunate circumstance is that what we've now ended up with is a huge capital investment in technologies that are state of the art for 1995. So many of the incumbents at the beginning of HITECH were in client-server technologies that were locally hosted using software licenses—as opposed to cloud-hosted, mobile-friendly subscription models that you could on a monthly basis decide to change if you wanted. It was what we had. It would have taken too long to wait. It is depressing because there's a 7-years, probably longer, in this next replacement cycle lifespan, so we'll be dealing with 1995 probably for another few years.
RW: In the rest of our digital lives when a better product comes out, we ditch the old one and replace it with a new one. What are the dynamics of the digital market that influenced that replacement cycle? Let's say a better cloud-based product came out than the leading vendor enterprise systems today. What's different about that than if that were to happen in a different industry or in our consumer lives?
JH: I'll answer this in two ways. I have switched multiple products out in just the last several years. A number of our clinicians in the 2008 timeframe implemented eClinicalWorks. Then for reasons of population health, care management, data integration, and other reasons, we went to Athena. Let me tell you what happened. In 2008, we implemented eClinicalWorks and uniformly the physicians said, my practice is wrecked. I can only see 25% of my patients. This workflow is so hard and it's not value added. Then say it was 2014, and we said we're going to take away eClinicalWorks and give you Athena. They said, don't take away eClinicalWorks. It's the only way I get my work done. It's fabulous. It's fast. It's efficient. I gave them Athena. And they said, Athena has wrecked my practice. Changing from any vendor to any vendor has a learning curve that makes the initial 6 months hellish. So that's problem one.
Problem two, it's the nature of our discipline that data in medicine is very complicated. If I ask you what is an adverse reaction, you would tell me it's from a substance, which could be a medicine, food, or environmental agent. And what is the nature of the reaction? Is it urticaria or anaphylaxis? Maybe you want a time–date stamp. Maybe you want an observer. Maybe you want a level of certainty. The challenge is every EHR vendor has to interpret what an adverse reaction looks like, and build a data schema. When you switch from Epic to Cerner to Meditechor eClinicalWorks or Athena, there's not going to be one-to-one correspondence in the data schema. Even if you had perfect interoperability standards, if somebody recorded allergies as mild, moderate, severe in Meditech, but they had to be mapped to urticaria and anaphylaxis in Epic, the mapping doesn't work. Even more complicated is that Epic is so customizable that when you have two versions of Epic and you ask if you can send data from one version of Epic to another version of Epic, the schemas, data, and metadata may not cleanly map. Switching is hard and may require a lot of manual data entry. When Brigham and Women's Hospital went live with Epic, it didn't transfer of most of the old data. They just decided to start with a clean slate and repopulate.
RW: Another thing you hear about the big companies is, even if it's not framed as "information blocking," it is framed as the companies have not been particularly cooperative and maybe have not seen it in their business interests in helping to move data around and have held onto data as a proprietary tool and a core business asset. What do you make of that?
JH: Again, I am probably controversial in my belief here. But I spend huge amounts of time with the CEOs of all of our EHR companies. In fact, the CEOs of Meditech, Athena, eClinicalWorks, IDX, and InterSystems recently attended a ceremony in which I received an endowed professorship at Harvard. I talk to these folks constantly. Generally speaking, when I meet with an EHR vendor and they say, "We have embraced the Argonaut Project. We are going to build APIs for problems in meds and labs and allergies and put them live into production." What you might find is that they'll create a production system, but on average from standards development to seeing it in the field is 18 months. You have to wait for software development, testing, certification, and implementation, and then wide rollout. It takes a long time to go from idea to implementation in our industry, and health care doesn't always adopt new changes as quickly as you'd like.
RW: At Beth Israel Deaconess, you still have a homegrown system. I'm hard-pressed to think of another major academic health center that still does. The VA is switching to a vendor-built system. Why are you holding on, and what do you see as the pluses and minuses?
JH: I'll give you two answers to that question. First, Beth Israel Deaconess has a 30-year culture of innovation: Doctors creating software for doctors, nurses for nurses, pharmacists for pharmacists. It's a culture. It is probably unlike any other culture in a United States health care. Remember, we have 32,000 students in our backyard at Harvard, Massachusetts Institute of Technology, Northeastern, and Boston University. Hiring highly talented people who can do creative software development in Boston is really easy. The second issue is Beth Israel Deaconess is considered a great value for the money. Our reimbursement level is more than 20% lower than at the Partners Hospitals. In a very strange way, the profitability that we have had over the last decade has been the dollars not spent on buying a vended software system. So when you ask, do we have a billion dollars to go spend on a vended software system, we don't.
I spend $2 million per year providing inpatient, outpatient, emergency department, and urgent care clinical functionality to 3000 doctors and one million patients at 450 sites of care. From a cost perspective, people look at it and say that's amazing, 90% satisfaction. You've knocked three zeroes off what the budget might have been.
The final reason is it gives us a level of agility so that when an Apple, Google, or Amazon says, here's a new concept, could you test it? We say is next week good enough for you? As opposed to, I hear in 2022 there will be a new version that we'll install that might do that. Our degree of mobile adoption or interoperability across other systems in our community is extraordinarily high because of that agility.
Now let me give you the downside. Do I believe that in 5 years if there is a low-cost, cloud-hosted, mobile-friendly, machine learning driven, evidence-based system that we can buy on a subscription model that we would continue to self-build, the answer is no. We would probably buy a vendored product or a subscription service and innovate around the edges of it. We'll build the cool mobile applications for patients and the workflow enablers for doctors, but rely on someone else's core with the idea that it's increasingly hard to deal with compliance and regulatory requirements as a single institution self-building a product.
RW: You mentioned Apple, Google, Amazon. One of the things that does seem to have changed in the last several years is the entry or reentry of the major digital companies into this space. They've tried it before in some cases and gotten it wrong. Why are they coming in now and is now different?
JH: Let's take them one by one. Amazon has democratized what used to be extremely complex expensive technology for image recognition, machine learning, computing, and storage. Today I have seven petabytes of patient-identified data in AWS [Amazon Web Services Cloud]. Amazon is hosting the storage for me. We use it for disaster recovery. We also use it for development and testing. But it's so good and so cost-effective that we are very likely to move all our production there. Amazon has 50,000 people working on creating a highly secure, reliable architecture. I have five. Why would I want to do that myself? Amazon can do it better, cheaper, and faster. Similarly, Amazon has machine learning services where I don't even need to write code. I can just do some plumbing and write some scripts and suddenly my seven petabytes of data has the benefit of machine learning technology finding patients like the one in front of me. Or looking at novel associations, predicting operating room use optimization, figuring out who's not going to show up to our ambulatory appointments. I have about a dozen projects with Amazon that are very straightforward and inexpensive given their technology. So, Amazon is not getting into the EHR business or into selling pharmaceuticals or devices. It's more that they're creating a set of services that can be leveraged by health care with great effectiveness.
Google thinks of itself as one of the best companies in the world to mine data. Of course, their assertion would be if they had a corpus of data, they might be able to provide better care management, population health, data visualizations, etc. Their team is not so much working on what they did years ago, a personal health record, they're looking at novel ways to assist the health care ecosystem with data mining. Apple, similarly, has no desire to be an electronic health record company, despite rumors otherwise. Apple wants to create a container that makes it very simple for the consumer to be the steward of their own data. We've done extensive work with HealthKit and with applications that layer on top of HealthKit that take Internet of Things data in your home, bathroom scale, blood pressure cuff, glucometer, and move it to your phone. Once it's on your phone, our application can access it, send it to the electronic health record. We can do care management coordination. Apple has given us a toolkit that makes our own development infinitely easier without trying to provide an electronic health record themselves, because they are truly allergic to the idea of hosting patient-identified data in the iCloud. They won't do it.
RW: Is Epic or Cerner disruptable in the traditional sense? Or do these companies continue to build your core and the disruption occurs at the margins of these various tasks with either existing major digital companies doing it, or new companies being built for specific purposes?
JH: Again, I may be considered controversial here. But I believe that writing an electronic health record from scratch that complies with hundreds of thousands of pages of CMS and HHS regulations is a fool's errand. The Cerners, Epics, Meditechs, and Athenas, they're writing this core engine that is making sure that you submit your bills appropriately and comply with every federal regulation. However, this is where I talk about the deconstruction of the electronic health record. Should the doctor's experience necessarily be an Epic product? I would much prefer having Alexa on my desk. The doctor and the patient have a conversation, and then Alexa fills out the chart. That's an example of the deconstruction.
How is it you layer on top of this transactional engine the components that will make the job of documenting, diagnosing, and treating so much easier? And lest you think my Alexa example is farfetched, we have more than 30 Alexa applications already. The nature of our Alexa applications are things like appointment making. Alexa, make an appointment with my cardiologist. I prefer it in Needham. Alexa, when is lunch coming? When will I be discharged? What lab results am I going to have today? We've built all these things, and the way we did it is we created microservices—little application program interfaces with very narrow functionality around the EHR, so if a Google, Facebook, or Amazon needs to connect to them with the right privacy and security protections, we can add this functionality—and if we don't like it we can swap the functionality. That's what 26-year-olds in their garages are going to be working on for the next 10 years, and that's where the innovation is going to happen—not in the core EHR companies.
RW: So, you think 10 years from now I'll still be using Epic, but the magic will be around the edges? The magic will be what happens to the data and from where I sit as a doctor, I think I'm on Epic, but all sorts of other things have happened and other companies have been involved?
JH: Jonathan Perlin has this notion that at HCA [Hospital Corporation of America] no doctor will know what electronic health record they're running. They bought PatientKeeper. The idea being that I just use my phone and I don't know what's actually connected to the other side of the phone. And similarly what we're seeing in care management, our care managers don't really use an EHR. They use something we call the care management medical record, which interestingly enough consolidates data from 46 different EHRs. It's every EHR in the Commonwealth of Massachusetts, and they don't have any idea what they're connected to behind the scenes. So that's this idea of deconstruction. Now company after company is creating novel ways for patients and doctors and nurses to have an experience that is abstracted from the EHR vendors' experience.
RW: A lot of what you're talking about depends on data moving around from your hospital to your clinic or your patient scale to your hospital or Amazon to you or you to Google, in an environment where everybody's pretty frantic about data breaches and security. How does that all get balanced?
JH: I spend $5 million a year on cyber security. Every year, I identify 100 new risks and mitigate the top risks by buying new technology, changing policy, doing education, etc. You are fair in thinking this is a problem that hasn't been solved. It will never be solved because every year the risks will change and you'll have to put in new mitigations. For example, this year we changed every doctor's experience on every device all over the world. You now need two-factor authentication. Because it was no longer acceptable to allow data access with a username and password that could be stolen. And maybe UCSF doctors don't do this, but there are doctors at Harvard that will click on URLs in emails sent by "Nigerian business people." Malware, ransomware, screen scrapers, keystroke loggers. The nature of the threat is more significant than ever before. So, we have changed our software systems that you simply cannot click on a URL that comes in via email. We send it to a third party where it's filtered through an appliance, and only when we guarantee that there's a good website on the other end with no malware do we even let you see the website. That's the kind of thing we just have to do, which is admit to ourselves that privacy and security is hard and you'll never be perfect, and every year you'll invest $5 million plus to try to put in a multilayered solution of defenses.
RW: That's what you're doing at the level of an individual health care organization. At the macrolevel of creating ubiquitous data flow that enables all of this magical innovation we're on the cusp of doing, how do these risks influence the pace of that?
JH: Right. Every time we talk about sharing data, we have to think about security as foundational. It's one of the reasons that I've been spending a fair amount of time looking at blockchain. So here's the question with blockchain: If what you have is a secure, tamper-proof ledger—and most people would agree that blockchain is that—could that be a mechanism to enable certain kinds of data exchanges and guarantee the integrity of those data exchanges? We've done a few experiments at Beth Israel Deaconess, and I am now part of an effort with The Gates Foundation in South Africa to use blockchain and biometrics to share HIV data across the country with providers and with patients. I think the jury is out, but you asked the speculative question: Is there a broader solution for an ecosystem? Blockchain may have potential to solve some of these risks.
RW: What does all this look like 10 years from now?
JH: Well, of course I'm 55 and here's what I tell my staff: If I ever start becoming a barrier to innovation, it is time for me to leave. Because my brain started its training in the fax machine era with Selectric typewriters. There are some solutions that maybe my brain isn't plastic enough to imagine. But here's what, for the moment, I think it looks like 10 years from now. Beth Israel Deaconess is building a new building in which we will have Bluetooth low-energy beacons in each room. Patients and doctors will have proximity cards or watches that they wear so we will know the physical location of every patient and every caregiver in the hospital at the room level. The workflow around getting orders done, closing the loop, responding to emergencies will be done with situational awareness based on who the patient is, where the patient is, what disease states they have, and the 10,000 patients like them who came before. We have a dozen machine learning projects that are helping us augment human capabilities so that the EHR becomes a valuable tool that helps you get to the right diagnosis and appropriate therapy. Time and time again, the innovations I'm making are not just because the technology is cool but because it's going to help us deliver safer, higher quality, and more efficient care by taking away that lost time that today's EHR has saddled on our doctors
.png)
No hay comentarios:
Publicar un comentario