Why The Wait For Electronic Medical Records
I spoke this week to the articulate and knowledgeable Dr. Lynn Harold Vogel, CIO of the University of Texas' MD Anderson Cancer Center, about all the reasons why Americans don't have electronic medical records today, what the best e-health record initiatives out there today are, and how his hospital is building its own electronic records system and working to improve the way it treats cancer.
I spoke this week to the articulate and knowledgeable Dr. Lynn Harold Vogel, CIO of the University of Texas' MD Anderson Cancer Center, about all the reasons why Americans don't have electronic medical records today, what the best e-health record initiatives out there today are, and how his hospital is building its own electronic records system and working to improve the way it treats cancer.Intelligent Enterprise: What do you think are the most notable efforts toward an electronic medical record and how close is it to reality?
Vogel: There's a lot of hype and political mileage around having an accessible health record for every American. The first question is, what kind of electronic medical record do you want? There are two basic models. One is based on the Veterans Administration, in which no matter where you go in the country, any physician in any veterans hospital can call up your complete medical record. After Katrina went through New Orleans, the question was, what happened to the medical records of all the New Orleans evacuees? If you were a veteran and you ended up in a veterans' hospital, your medical record was already there because they have a national system that's consistent across the country, that's based on standards.
IE: What is the Veterans Administrations' electronic medical record like?
Vogel: It's built on the old MUMPS language. Some would argue that it doesn't have all the functionality of some of the current product offerings, but it works and if you need to go to a veterans hospital and have your blood pressure taken and then you go 200 miles away to another veterans hospital and someone wants to know what your blood pressure was at the last place, it will be there. It's not the slickest or the most graphically enhanced environment but it works. The second model contains a smaller subset of data. If I end up in a Kansas City emergency room with a broken leg, what specific things should the doctor know about me that would be helpful in his diagnosis or treatment plan? It might be basic demographic and insurance information, so if you show up but you're unconscious, they can figure out who you are and get some additional information electronically. It might include access to your last hospital stay or information about your last physician visit, maybe it's the last set of clinical labs, or the last set of X-rays, but it's not the full, complete medical history. The veterans' e-record is very complete, it is in many ways the gold standard for completeness. They've been working on it for about 40 years and they were quite free to focus on the clinical system and build an electronic medical record that had no implications for billing. That's changed; now veterans have to pay a copay for each visit. But the system has not been driven by billing requirements, which is the real challenge that every other hospital in the country faces in terms of building an electronic medical record. At some point somebody's got to send out a bill in the right format, in the right place, to the right insurance company or consistent with the right contractual agreements about how bills should be sent. So that adds a level of complexity, and since it's the clinical experience that drives the bill, that's a very close relationship between clinical activity and billing.
IE: So most healthcare providers have a much more complicated patient record scenario.
Vogel: Exactly. When Katrina went through and everybody started to complain about who had access to medical records and how miserable the health industry was that it didn't have electronic records, one idea was, let's create a bunch of regional groups that will share medical information within a region.
IE: Because it was too hard to do it nationally?
Vogel: Yes. So the government set up regional health information organizations, or RHIOs. There are several hundred around the country. The problem is, many of these RHIOS were set up in the hope that at some point the government would come in and pay for maintaining them, because that's always been the long-term question. You can start something, but who's going to pay for the second month of operation, or the tenth month of the second year?
IE: Are the RHIOS like clearinghouses for medical information?
Vogel: It depends. Some of them are clearinghouses, some of them are efforts to give physicians in one hospital access to data in another hospital. There are two RHIOs that have been so far relatively successful. One is in Santa Barbara, CA, which is where the concepts got started and Dr. Brailer [the National Health Information Technology Coordinator] got some of his experience before he went to Washington; the second one is in Indianapolis. Both of these have long histories of institutional cooperation, so they hit the deck running, as opposed to a lot of other places where hospitals are in such intense competition with one another that they don't want to share much data.
IE: If you had electronic records that were transferable, accessible and readable anywhere, would you really need a third party?
Vogel: No. The federal government's role has increasingly been in establishing standards. The buzzword is, "standards of interoperability." If systems all write to the same standard, they should be relatively compatible. HL7 is one example of that. That's an application-level standard of data that you're then able to transfer data from one system to another, even though the hardware, operating system, etc. may not be compatible. The problem, even with something like HL7, is that it's a lot like Unix. One would like to say that Unix is Unix is Unix, but in fact my version of Unix may be slightly different than your version, so it's always a problem to get everybody to do exactly the same thing.
IE: Are the proponents of HL7 trying to make it more universal?
Vogel: They're trying to get there, it's a very active group, part of ISO I believe now, so it's made a huge difference in the cost of moving data from one system to another. It's been an important part of what we've done.
The basic dilemma in all of this has been, who pays for this? There needs to be a financial incentive. Left to their own devices, hospitals will want to keep their patients in their hospital, keep their data on their own, and software vendors don't have strong incentives to write software that will be compatible with their competitors. The financing has always been problematic, because the vast majority of healthcare financing comes either from the federal government or from third-party payors like Aetna and Prudential. These private sector organizations are generally publicly traded companies who have an allegiance to their stockholders. If they're going to spend millions of dollars on interoperable medical records, they need to explain that to their stockholders and how that will impact their earnings in future years. By far the biggest payors for healthcare in this country are Medicare and Medicaid, which are the federally funded programs. But those programs are so large that there's incredible pressure to keep costs down, so it's not clear that they should bear the brunt of the millions of dollars that it would take to make medical records interoperable.
IE: I think they just had some big cutbacks.
Vogel: Yes. The other group that's come out strongly in favor of all this has been employers. Employers are interested in two things: One, they want to save money, two, they want high quality care for their employees. The problem is that healthcare is very costly in this country. The two examples that have come out recently are that GM spends more on healthcare for its employees and retirees than it does on steel in its cars. Starbucks spends more on healthcare than it does on coffee beans. Somehow, things have gotten out of balance such that in many corporations, cost for healthcare is the single fastest rising cost of doing business.
IE: Theoretically electronic records would make healthcare cheaper in the long run.
Vogel: Absolutely.
IE: But it would take a long time?
Vogel: Somebody has got to make the investment up front in order to make it happen.
IE: Who should it be?
Vogel: Since I'm with a provider organization, my bias is clearly that those who pay for healthcare in the long run will get the benefits, so they should pay.
IE: The insurance companies?
Vogel: Yes and the federal government should step up to facilitate funding. The problem is the costs are so dramatic that it's fairly daunting.
IE: Why would something like HL7 be so costly?
Vogel: Assume for the sake of argument that you could get all the vendors around the table and they'd all agree on how they should write software and what standards they should adhere to. Now the problem is, who's going to pay for all these vendors to rewrite their software from where it is today in order to meet the standards? Epic, which is a huge player in this game, is all in MUMPS, with a Cache database behind it. Others are all over the map. If they're going to adhere to standards, they'd have to rewrite much. The other option is to put a front end on everything that looks about the same and is able to access data. That's probably a less expensive alternative in the long run, but getting actual access to the data and being able to use it through a shared front end would be hard.
IE: Don't the vendors rewrite their software over time anyway?
Vogel: Cerner, which is another big player, last did a major rewrite of its software in the early 1990s. I'm not aware that they're planning to do another rewrite. Epic has never rewritten from the basic core they started with 20 years ago. Healthcare is probably the most complex industry we have in our economy. When you have an organization where the people that pay the bills are not the people that receive the products, it's very disjointed. Imagine going to your car dealer, taking your car in for repairs and when it's done, telling the mechanic, here's $25 toward the $800 bill, go get the rest from somebody else and figure out how that's going to work. Doctors at most hospitals in this country, with the exception of academic medical centers and even some of those, don't work for the hospitals. They work for themselves, they're independent entrepreneurs and they suffer all the problems and challenges of small businessmen. They're typically undercapitalized, it's hard to make long-term investments, particularly at high dollars, so when we sit back and criticize them for not jumping whole-hog into the electronic medical record environment, you have to factor in that these are small businessmen, they often don't have access to capital at attractive rates that will allow them to make these investments. If we had an e medical record, who would benefit? The patient obviously would benefit, but the patient doesn't pay for her care. Most of us only pay a marginal amount of our health bill. You could say the doctors should pay for it, they benefit because they can give better care. That would be interesting if we had doctors that had the capital and backing to do it. Down the line, let's go to the insurance companies. Many of them are beholden to stockholders as well as patients. Their challenge is to keep their costs down, not to make huge investments. Often it rolls back to the hospitals, they have sufficient size that they can go to the capital markets, borrow money in order to make these kinds of investments. A 300-400 bed hospital that wants to do a full-fledged clinical system can probably expect to spend $10-$15 million to do it. For a small organization, that's a big chunk of change.
IE: Is that what you've done?
Vogel: We've done a couple of things. The other revolution going on in medicine has to do with personalized medicine. Imagine going into a doctor's office and the doctor does a DNA test, gets a pattern of your DNA around a tumor you have, a susceptibility to a chronic illness, or whatever else. Now the challenge is, this data which comes out of genomic analysis is available for him to not only aid in his diagnosis but to plan a therapy, to put a drug package or medication process together that will target and be sensitive to your genomic expression. This genes stuff used to be in the realm of research and nobody worried about it. But the fundamental way we diagnose and treat patients in the future will be impacted by what used to be research methods. So the research enterprise and clinical enterprise, which used to be separate, are coming together closely. There's probably no other disease category where that's more evident than cancer.
IE: Is that what everybody's doing or are you in the vanguard?
Vogel: We're on the leading edge of it. Cancer facilities in general are doing a lot of this work. Cancer is a very visible disease, it impacts significant numbers of people, there's funding available for it, and we've already established relationships between particular kinds of genetic expressions and kinds of cancer. So there's a lot of promise and hope that what used to be the research business is now increasingly becoming part of the clinical business. The problem is that most hospitals and healthcare software vendors they focus only on the clinical part of the business. They're in for a rude awakening in the next three to five years, because the whole world of research, in terms of data and information technology, is fundamentally different from the world of clinical care. We knew we had to write our own stuff. We had a product we'd been working on for several years called Clinic Station that's used by all our physicians, it lets the physicians look at all the clinical data and images on any patient.
IE: Including MRIs, CAT scans, and PET scans?
Vogel: Everything is in that package. The challenge now is to rearchitect that environment, which was started about five years ago, into Microsoft's .net environment which we think is one of the most robust and well-supported. That's when we got involved with Avenade. We recognized that hospitals are not at their best as developers of software, it's not our core business. So we were looking for a partner that had a strong development background, a commercial orientation to software development, documentations, and cost estimates. Academic medical centers in particular like to play with software, every physician likes to pick up his Java for Dummies book and become an expert. We realized early on that we were not experts. As smart as we thought we were, we picked a partner we felt was smarter than we were in this business. So we are now on a path to rearchitect our entire clinical environment and to continue along the path of development of our own electronic medical record in-house. We're probably one of a half dozen or less healthcare institutions in the country that are taking this risk. But we think we're one of two top-rated cancer centers in the country, Memorial Sloan Kettering being the other, and one way we can maintain our leadership and our vision is by making a serious commitment to developing our software.
We're fully embracing SOA as our approach. The reason we're is that we have a number of disparate systems throughout the organization -- some support research, some support clinical practice -- and in each case they're the best of breed at what they do. Rather than try to move data from one system to another or put it into a huge data repository, we've wrapped services around legacy applications.
Rearchitecture is an important concept because the original Clinic Station was built in Visual Basic. Microsoft no longer officially supports Visual Basic. So we knew we were headed for a change. We spent about six months trying to sort out whether we should go to a .net world or an open source world. We discovered that a lot of the criticism of .net came from people who had taken old code and gone through a conversion process, the old black box model, where you put your VB in the left side and the .net comes out the right side. The problem is that in taking that approach you lose a lot of the potential gain you get from starting over again -- rethinking what you do. We were particularly concerned about scalability and performance. Ironically, some of the testing we've done on the initial modules demonstrates that in a .net environment, performance and scalability can be better.
IE: What's your final vision for this whole project? Is your primary goal to have that universal electronic record?
Vogel: We will have at MD Anderson a fully electronic medical record environment, starting when the patient shows up at the front door until death. The medical record they have at MD Anderson will be a critical part of their care. But they're not always going to come to MD Anderson for their care. We want to make our electronic medical record data available to other physicians, so if you go to a hospital with pneumonia and the physician needs to know what has gone on with your cancer treatment and how it's working, that physician will be able to get the proper authorization to access your electronic data at MD Anderson. We also think that because we're focused on web front-ends and things like that, this can serve as a model for what an EMR might look like across the country. One clear difference in our approach is that most electronic medical record systems put all kinds of patient data into one big database. That turns out to be very proprietary and how you get the data in and how you get the data out, how you present it is the value that a proprietary vendor would offer. We have a virtual clinical repository because by and large we leave the data in the original legacy systems and access it through a services component. In some cases we've consolidated data into a repository but it's generally a repository of a focused design. For example, all our pathology data is in a single data repository. Every patient's laboratory and pathology data from 1980 is in that one place, we don't move it around elsewhere because that repository has a services component, so if you want to get access to that data, you can access it and look at it and incorporate it by looking at it into reports or presentations or screens. But we're very reticent to take data from one system, such as a laboratory system, and physically move it to a huge repository or another system. As soon as you move it, you've lost a connection, and it's entirely likely that the recipient system will not get updated and if the host system changes, now you've got an inconsistency that's inappropriate for patient care. So we're developing a research repository for certain kinds of research data, a demographic repository, and we have data bases for nursing services, for some disease-specific things, and those will be exposed as services within the SOA.
IE: How would a doctor at a different hospital access this?
Vogel: We don't have all the details worked out. For example, we have a number of referring physicians who refer their patients to us for cancer treatment. Those physicians today can come through a portal called MyMDAnderson for Referring Physicians. They look at the data on their patients, they can track the care of their patients through this portal. We have a patient portal. It's through that portal that I think that data will be available to appropriate people in the outside world. Because we don't require a huge physical database and because with a services approach you can access data where it sits, that's what gives it the vision of being able to be extended across other hospitals. We're part of the University of Texas system, there are several large health institutions within that system. One of our first tasks will be to test this model of accessing data because we're primarily a referral site, you come to us if you have a presumed diagnosis of cancer, not for primary care.
IE: What if you want to pull in the patient's history from a referring hospital?
Vogel: That's the other side of it. The model we're building with Clinic Station can be extensible so that if one of our sister hospitals has a similar portal, that would enable us to bring in data from whatever systems they have. If you give a physician access to a portal, then he or she can look at the data and use it and make decisions in caring for the patient.
IE: Do you think that outside data could be merged with what you have to create a complete record?
Vogel: That's the tricky part. Because once you start talking about physically merging data, now you're talking about a complicated data model. The question is, who curates that data? Who decides that what's already in there is duplicative with what you're trying to put in there? One of the challenges we have in healthcare is that we have many names for the same thing. So what is hypertension in your hospital may be borderline high blood pressure in mine, may be some other diagnosis in another place. That's the challenge of ontologies, which is, what do terms mean anyway?
IE: That's true in any industry.
Vogel: It's true in any industry, although in industries that are driven by financial environments, profit, loss, cost, etc., the CFOs have figured out to talk to each other. So a profit, absent all the discussion about what the appropriate accounting guidelines are, means basically the same thing to CFOs in different industries. Having a physicians agree on common terms could be a huge culture change.
IE: There's the MESH [Medical Subject Headings] ontology.
Vogel: Yes. There are different ontologies out there and things that are called ontologies. We have ICD9 codes for diagnosis, we have LOINC for lab values, we have SNOMED for additional pathology value, there's CAB, the cancer biomedical informatics grid that has spent a lot of time on ontologies and meanings. It turns out, for example, that cancer covers about 200 distinct diseases. At MD Anderson, we treat all of them. Part of the challenge when we get a diagnostic workup from another organization is understanding exactly what it is. The problem is, and we found this out during Katrina, a patient walks in the door and you say, what medications are you on? A typical response was, I take two yellow ones in the morning, three blue ones at lunch, and a pink one with dinner. We had physicians sitting down with patients going through the Physician's Desk Reference manual, which has pictures of pills, pointing out which pills they took.
As people get older, they get things other than cancer. We're talking a lot about co-morbidities. That is, what other things do you have wrong with you that may impact how we treat your cancer? It could be cardiac conditions, pulmonary conditions, diabetes, a whole host of things. So we're a microcosm not just for cancer.
The other problem, which is really a blessing, is that we have substantially increased survivor rates. There's a whole focus now on what happens to people after they've survived cancer. A lot of treatments for cancer, such as chemotherapy, are very toxic. We worry about adverse events and things that happen that we didn't predict, how did we manage it, and I think those kinds of things come to broaden our perspective on how we treat people. It turns out that if you take a pill for arthritis it may affect your heart. Chemotherapy is somewhat similar, if you put toxic stuff in your body, other stuff can happen.
IE: In the beginning of this conversation, you described the two basic types of electronic medical record: the VA's lifetime medical history versus a shorter, more recent record. Which do you think will end up being the universal e-record?
Vogel: I think the idea of having a universal medical record for all patients along the VA model is not attainable in the near future.
IE: Because…
Vogel: Because of cost, because the conditions that allow the VA to do that don't exist anywhere else in healthcare. Every veterans hospital reports up to the same place. It's a fairly militaristic approach to things -- if you come to our hospital, this is what you use. You don't have a choice. If the VA decides to do labs a particular way, that's the way they're done across the board. In most hospitals, not only does everybody have a vote, but everybody generally has a different vote. Physicians tend to be independent minded. Which on the one hand is what we want, we want their creativity and intelligence. On the other hand, it's a challenge to actually reach a decision. We're a very difficult market to sell into for third party vendors because we'll torture them. There's always questions, always someone who says let's think about this again.
IE: What do you think must be included in the electronic medical record?
Vogel: Current demographic and insurance information is critical because that helps the hospital figure out what to do. Secondly, to the extent you can view clinical data from another site, that would be fine, particularly recent data. The truth is, with images, after 18 months there's little viewing of images. It may be different in mammography where you're looking at changes over time. Once you get past 24 months, most radiologists will tell you they're not relevant. Any recent X-rays you've had might be useful, any recent clinical values, but the blood test of 20 years ago is not that relevant.
IE: What's the best way to package the universal e-record -- in a barcode, in an embedded chip?
Vogel: A Massachusetts CIO achieved some notoriety last year by having a chip implanted in his elbow. He's now going to have his DNA sequenced and published on the web so anybody can look at it. The question here is how to protect privacy. It's true that people guard their ATM cards as they walk around the streets. But will they guard a barcode or a health card as much? I don't see people by and large getting implants with their medical records in them. Many people are averse to that sort of thing. If we can give you access to relevant data in some relatively straightforward way, which we do with our Clinic Station, then we've got a fighting chance for having a universal health record. But it's not all going to be in one place or in one format, it just has to be accessible.
IE: So you're envisioning hospitals communicating with each other, so that if a stunned or unconscious patient walks into the ER, you could search for the last hospital visit that person had?
Vogel: You might have a hospital-level identifier, we do that today with driver's licenses. If I'm doing a legal investigation and want to check whether you have a driver's license in any states, I can get that information. This might function in a similar way. You don't need health information very often, but when you need it, it's pretty important to have access to it. It's a matter of making that access as easy as possible, plus keeping all the bad people out.
IE: Do you see the federal government providing that network or layer that hospitals would link into?
Vogel: I think the federal government's role is focused largely on standards.
IE: It seems like somebody would have to be the host.
Vogel: The government most likely, reluctantly will be the one that ends up managing this, but amidst all the concerns about privacy and security it's a real challenge.
IE: Do you think the government will make its 2014 deadline for having national electronic medical records?
Vogel: No. With all the competing priorities in the private sector, in the government and in hospitals, our first objective is to serve our patients when they're here. We're happy to participate in other initiatives, but hospitals have a long way to go to get their own internal acts together in terms of electronic medical records. The interesting thing is that giving physicians access to electronic data is not so much a technical problem as it is a policy problem. How do you decide who are the right people, who gets access, who's authorized, who's appropriate, how do you control it, how do you keep people from cruising all the records?
IE: Is record-cruising a real problem?
Vogel: At Columbia University, when a famous ball player was in the hospital, they tracked 1,500 unauthorized attempts to look at his data. When President Clinton was in Columbia he went under an assumed name in order to protect his privacy.
IE: So it's an identity management/authorization challenge?
Vogel: It's huge.
IE: Are there any particular technologies, data formats or file formats that are critical to making electronic records happen? I think at one point they were talking about simply using PDFs?
Vogel: In some ways that's the lowest level because it's a document but it has no interactivity, it's just a picture. The thing that would make this happen is having an architecture that allows data of various types and stripes to be exposed, that's what SOA is intended to do. That's a crucial technology to embrace. Beyond that, it probably doesn't make a lot of difference -- people use technologies for a variety of reasons. As we've discovered, it quickly becomes a religious discussion, the open source people or the Microsoft people and Cache people all believe strongly that they have seen the light and it is good. Mediating those discussions is not fun.
IE: Did everybody stay when you went to .net?
Vogel: Yes. All our production clinical systems will be done in a .net environment, including research systems that interface with clinical. But all our pure research work and genetic expressions and such will be done on open source, because the science community thrives on open source. So we are Java people as well as .net people.I spoke this week to the articulate and knowledgeable Dr. Lynn Harold Vogel, CIO of the University of Texas' MD Anderson Cancer Center, about all the reasons why Americans don't have electronic medical records today, what the best e-health record initiatives out there today are, and how his hospital is building its own electronic records system and working to improve the way it treats cancer.
About the Author
You May Also Like