Big Talk About Health IT

The American Recovery and Reinvestment Act (ARRA) included a substantial amount of money for investment into health information technology in the United States to help reduce medical errors and increase efficiency. The ARRA provided incentives through the Medicare program to health care professionals that adopt an EHR that they “meaningfully use,” and this has stirred up some controversy as the governmental agencies charged with laying out the specifics have gotten down to work. This newsletter examines some of the details of the incentive program and the debate over open source versus proprietary health IT systems in the market.

The ARRA and Health IT Investment
The ARRA has a number of provisions to encourage the expansion and further implementation of electronic health records for the purpose of increasing efficiency in the health care system while hopefully lowering costs. The Office of the National Coordinator for Health Information Technology (see website) has established a two-part strategic plan for expanding the installation of health records systems throughout the U.S.

Section 4101 of ARRA descibes the incentive payment process through the Medicare program for eligible professionals that are a “meaningful EHR user,” as that term is defined in subsection (o)(2) of the amended section 1848 of the Social Security Act (cited as 42 U.S.C. 1395w-4). The tortured definition provided within the statute has three basic requirements: (a) the certified EHR is being used in a “meaningful” manner to the satisfaction of the Secretary, (b) the EHR is connected to some “electronic exchange of health information to improve the quality of health care”, and (c) data is submitted to the Secretary on clinical quality measures on a regular basis. The data to be submitted to the Secretary is to be governed by contract between Medicare and the provider, and such proposed measures must go through the public notice and comment period in the Federal Register – similar to other proposed regulations under federal law.

The incentives payable to eligible providers are spread out over five years, with a maximum amount of 18,000 (if starting in 2011 or 2012), otherwise 15,000 that first year. That is, unless the first year of adoption of the EHR by the provider is after 2014, which in that case the provider is not eligible for any incentive at all through this section. So, a provider that adopted a certified EHR in 2011, demonstrated that: (a) he was using it in a meaningful manner, (b) connected to a data exchange, and (c) produced data to the Secretary as required, would be eligible for payments in total of 44,000 over a five year period starting in 2011 (18,000 in 2011, 12,000 in 2012, 8,000 in 2013, 4,000 in 2014, and 2,000 in 2015).

If instead the provider did all the above, but did not start until 2013, the first payment in 2013 would instead be 15,000, for a total of 41,000 over the five years 2013-2017. Sadly, if the provider did all of the above for the first time in 2015, they would get bupkis. That fact that there is an incentive to invest in health information technology, however, has begun a larger debate about what kind of system to acquire. Some have set the categories as either “open source” or “proprietary” (see a recent Wired blog post - click here for the article, and Phillip Longman in the Washington Monthly – click here for that article), with the latter option being the enemy to innovation, improved health outcomes, and usability.

Open Source v. Proprietary
First off, an open source program is merely governed by some version of the GPL, which means that other developers can reverse engineer, make derivate works, or otherwise include the original open source code in their subsequent open source code. Developers that freely work together to write something cool are developers writing code, but they aren’t necessarily health experts, physicians, efficiency gurus; in fact, they may not even have health insurance if they live in the U.S. (1 in 6 of us are uninsured). The fact that code is open source does have a big impact on how U.S. copyright law protects the work, but it doesn’t mean that somehow an open source developer is more in tune with health IT requirements, how to best integrate the system into a physician’s practice, or even necessarily what the actual requirements are for a physician to see a patient and document the visit to avoid liability for fraud or malpractice. That’s because for developers generally, requirements come from outside of the development community - from users.

And guess what – proprietary developers of software listen to their user community to understand their requirements. It’s part of the job of developers, regardless of whether the code is open source or proprietary. And, for everyone participating in the global economy, the people that pay for your product generally drive the features and functionality in it. If you can’t deliver, then your user base will go find someone else who can. So functionality is driven not by the method of developing the software or its licensing, but by the customers that are willing to pay for the privilege of using the end result. What tends to lock in developers to a particular platform is the inherent conservatism of larger software purchasers who want certain fixed features to work reliably (even if not optimally). This may be bad for innovation, but not every software user wants to be on the bleeding edge while seeing patients.

I’m generally a fan of the open source community, and there is a place for open source software in the electronic health records market. The shareware people were developing useful applications and offering them to the public ever since I started using a PC as a kid back in the 80’s. There is a lot to be said for application development that is done in a larger community where sharing is ok. For example, my blog is a Wordpress blog, which is an open source blogging software which provides a platform not just for writers like me, but also for developers to create cool plugins for Wordpress blogs that do all sorts of nice things like integrate with Google Analytics, backup your blog, or modify your blog’s theme, just to name a few that I happen to use regularly (thanks all of you that are linked to). VistA (a health record system in use at the nation’s VA hospitals) is getting a lot of mileage these days as an open source, publicly funded, and successful example of EHR in action. And this system can likely be meaningfully used by its users. The base licensing to operate it is free. But in fairness, VistA is not a new piece of software recently written by three college kids in a garage somewhere in between World of Warcraft online gaming sessions. This program has been in development for years. And “free” is relative.

For example, if you want support, you need to pay for it. If you want to run it in a production environment, you will need to buy equipment and probably get expert help. If you want to implement it, you will need to form a committee, develop a project plan, implement the project intelligently with input from your users, and be prepared to make a lot of changes to fit this system (or any system) into your health facility’s workflows. And if you find yourself writing anything approaching software, that will cost you something, too, as most health care providers do not have a team of developers available to them to modify any computer system. So, “free” in this context is relative, and genuinely understates the scope and effort required to get any piece of software to work in your facility. “Less” may be a more appropriate adjective. But then, that’s only true if you can avoid costly modifications to the software, and so far, there is no single EHR system that works in every setting, so expect to need to make some modifications to any system you implement, whether it is open source or proprietary.

Standards for Health IT
Repeatedly, I hear the refrain that this stimulus money is going to go to systems that can be put to a “meaningful use,” and that is going to exclude rogue open source Health IT developers from being funded, squelching innovation in the market place. I imagine that complying with the security regulations under HIPAA probably hinder innovation, too, but they increase the reliability of the system vendors that remain in the market place and reduce the risk to the data of patients that might be in their computer systems. Setting minimum standards for health records systems may favor incumbent systems, but honestly – is that so wrong? Isn’t the trade off here that when someone buys a system that is certified, they can have the satisfaction of knowing that someone else without a vested interest in the product, thought it had certain features or a proven record of delivering certain outcomes? Perhaps the certifiers aren’t neutral because they come from the industry of EHRs, but if I recall correctly, the people that run the internet have committees with representatives from the internet industry, yet I rarely hear that the standards for the POP3 protocol unfairly burden new or open source developers.

That someone set standards for EHRs like a government agency is a lot like the government setting the requirements for you to receive a driver’s license. Everyone who drives needs to understand what the red, octogonal sign with the capital letters “S T O P” means. On the other hand, you may never parallel park again, but you better learn how to do it if you want your license to drive in Maryland. Standards are always a mixed bag of useful and not-so-useful rules, but I don’t think there are too many people out there arguing that the government should not set minimum standards for drivers. A certification requirement for EHRs to establish minimum standards is no different. Ask the JCAHO people about it. Ask the HIPAA police. Ask the IT people you know. If you are going to develop an EHR, you better secure it, make sure the entries in the database are non-repudiatable, and have a disaster recovery approach. Don’t know what these things are? Do your homework before you write a computer system.

Proprietary Systems Have “Failed”
Now, another refrain has been that look at how all of these proprietary systems have failed the world of health services. For example, look at how more kids died at the Children’s Hospital ER in Pittsburg after the hospital implemented an EHR (I can feel a class action lawsuit in federal court). Who implements EHR’s in ER’s? So the doctor is standing there and a patient is having a heart attack. What should the doctor’s first act be? To register the patient into the EHR and record his vitals? I would think the doctor should be getting out the paddles and worrying about the patient’s heart beat, but then, I am an attorney and systems guy, not a physician. Look – dumb decisions to implement a computer system should not lead to subsequent critics blaming the computer system for not meeting the requirements of the installation. EHR is not appropriate every place patients are seen or for every workflow in a health care provider’s facility. No knock on the open source people, but I don’t want my ER physician clicking on their software when I am dying in the ER, either. I don’t want my doctor clicking anything at all – I want her to be saving me. That’s why I have been delivered to the ER.

In 2003, I led a health care center’s search for a health records systems. After reviewing our options, our user community made the final choice between two systems, both of which were proprietary. We ended up going with a product called Logician, which at the time was owned by MedicaLogic (now a subsidiary of the folks at GEMS IT, a division of General Electric).

Logician (now called Centricity EMR) is a closed source system that runs in Windows, but allows for end users to develop clinical content (the electronic equivalent to the paper forms that providers use to document care delivery) and to share that clinical content with other EMR users through a GE-hosted web site for existing clients of the system. In addition, Logician has a substantial following to support a national user group, CHUG, and has been around long enough for a small cottage industry of developers to create software to integrate with Logician (such as the folks at Kryptiq, Biscom, and Clinical Content Consultants who subsequently sold their content to GEMS IT for support).

After six years of supporting this system, I can assure you that this technology has its issues. That’s true, of course, of all information systems, and I would not suggest that the software developed by the eclectic collection of open source developers is necessarily any less buggy or any easier to support. In fact, I don’t have any opinion at all as to whether health records would be better off in an open source or proprietary health record system. Health professionals are very capable of independently evaluating the variety of information systems and choosing a system that will help them do their jobs. How the software gets developed does not predict that it will succeed. One of the big reasons that these projects tend to fail is a lack of planning and investment in the implementation of the system before the thing gets installed. This process, which, when done right, engages the user community in the project to guide it to a successful go live, is probably more important and actually takes more effort than the information system itself.

Mr. Longman criticizes the development model of “software engineers using locked, proprietary code” because this model lacks sufficient input from the medical users that ultimately must use the system in their practices. I suppose there must be some health records systems out there that were developed without health provider input, but I seriously doubt they are used by all that many practices. I do agree with Mr. Longman that there are plenty of instances where practices tried to implement a health records system and ended up going back to paper. We met several of these failed projects in our evaluation process. But I would not conflate proprietary systems with the failure to implement; proprietary systems that actually include health providers in their development process can be successfully implemented. Open source can work, too. As Mr. Longman points out, the VA Hospital system has been using an open source system now called VistA which works for the VA hospital system’s closed delivery system (patients at the VA generally get all of their care at a VA institution and rarely go outside for health care).

My point is that the labels “open source” and “proprietary” alone are not enough to predict the success or failure of a health records system project. Even a relatively inexpensive, proprietary, and functionally-focused system that is well implemented can improve the health of the patients served by it. There is a very real danger that the Obama administration’s push for health IT will be a boondoggle given the scope and breadth of the vision of health IT in our country. But the health industry itself is an enormous place with a wide variety of professionals, and the health IT market place reflects this in the varied information systems (both open source and proprietary) available today. I would not expect there to be any one computer system that will work for every health care provider, regardless of who actually writes the code.

Conclusion
ARRA has incentives for health care professionals to invest in health IT, and the studies of health IT show that it can reduce errors and increase efficiency when well-implemented. How a software program is written, or the contract under which it is licensed is not a predictor of whether the system will work properly or be used in a meaningful way. There do need to be standards for systems developed and used by the nation’s health care system, and a government agency (at least to start) may be the right entity to establish those guidelines today.