An Open Letter to the New National Coordinator for Health IT - Untying HITECH’s Gordian Knot: Part 1

Congratulations to David Blumenthal on being named National Coordinator for Health Information Technology (ONCHIT). Dr. Blumenthal will be the person most responsible for the rules and distribution of the American Recovery and Reinvestment Act’s (ARRA) nearly $20 billion allocation, referred to as HITECH, designated to support physician and hospital adoption of health information technologies that can improve care.

The job is fraught with difficulties, which Dr. Blumenthal has readily acknowledged. His recent New England Journal of Medicine (NEJM) Perspective, “Stimulating the Adoption of Health Information Technology,” is a concise, clear and honest appraisal of two of these challenges, namely how to interpret and act upon the key terms used in the legislation, “meaningful use” and “certified EHR technology.” Dr. Blumenthal gets to the heart of the matter by identifying the tasks on which the National Coordinator’s success will most depend, and which will foster the greatest controversy.

The country needs Dr. Blumenthal to succeed. The issues are complex and, with huge ideological and financial stakes involved, politically charged.

Even so, we believe there are straightforward ways to help physicians and hospitals take advantage of this opportunity to use health IT to improve care. This article is the first of a series in which we’ll try to disentangle the Gordian knot of inter-related issues embedded in HITECH. Below we identify six issues. Then we address the first.

A defining paragraph in Dr. Blumenthal’s NEJM article offers his vision of the problem:

….[M]uch will depend on the federal government’s skill in defining two critical terms: “certified EHR” and “meaningful use.” ONCHIT currently contracts with a private organization, the Certification Commission for Health Information Technology [CCHIT], to certify EHRs as having the basic capabilities the federal government believes they need. But many certified EHRs are neither user-friendly nor designed to meet HITECH’s ambitious goal of improving quality and efficiency in the health care system. Tightening the certification process is a critical early challenge for ONCHIT. Similarly, if EHRs are to catalyze quality improvement and cost control, physicians and hospitals will have to use them effectively. That means taking advantage of embedded clinical decision supports that help physicians take better care of their patients. By tying Medicare and Medicaid financial incentives to “meaningful use,” Congress has given the administration an important tool for motivating providers to take full advantage of EHRs, but if the requirements are set too high, many physicians and hospitals may rebel — petitioning Congress to change the law or just resigning themselves to forgoing incentives and accepting penalties. Finally, realizing the full potential of HIT depends in no small measure on changing the health care system’s overall payment incentives so that providers benefit from improving the quality and efficiency of the services they provide. Only then will they be motivated to take full advantage of the power of EHRs.

Here are issues that, to develop rules that can make the most of emerging Health IT trends, deserve clarification:

1. The term “electronic health record” (EHR) is unclear and imprecise, especially given the wide-ranging tools that can be used to manage health information in electronic format. Before developing rules that will guide our use of these tools, a clearer definition is essential.
2. In thinking about health IT, it is useful to separate health data from the applications used to manage health data. Separating them is critical to better understanding the role of standards, certification and the criteria used to validate physicians’ and hospitals’ claims on HITECH’s incentive funds.
3. In a certification process, the appropriate scope of “basic [EHR] capabilities” should be limited to the critical few. Given constraints on time and resources and the “meaningful uses” that Congress wishes to promote, does it make sense to require a large package of features or a more limited set of basic capabilities?
4. How should the certification process be structured to ensure fairness, flexibility and openness to innovation? Does the current certification process meet these criteria?
5. The roles patients and consumers might play in any determination of “meaningful use” are important, but are left on HITECH’s sidelines. How can health IT policy enhance the patient’s health care experience and participation?
6. Will the incentive payments envisioned by HITECH actually encourage implementation of EHR technologies, and result in improvements in patient care quality? Or are better mechanisms available that can systemically improve care?

1. Definitions

First, let’s admit that there is no precise, universally-accepted meaning for “EHR.”

The term sometimes refers to medical records themselves, digital files containing a person’s health data and information. We believe this is what both Presidents Bush and Obama intended for the meaning when they have stated that all Americans should have their own electronic medical records. Individuals should be able to access their health information in electronic formats (of which there are many), and not just in paper records. Patients with their own EHRs can access them, give viewing permission to others, download them to computers or cell phones, and use software applications to manage and transfer the records in digital formats.

However, EHR may also mean a software application - like Intuit’s Quicken for financial management or Microsoft Office for business productivity - used by doctors, nurses, and staff in a medical practice, hospital or other clinical setting. (EMR, for “electronic medical record,” was an earlier term for this same class of software, now less used.) EHR software is typically utilized for creating, storing and managing a patient’s care-related and billing data. Dr. Blumenthal uses this meaning in the passage above; EHRs are certifiable software programs that have “capabilities.” We might also point out that EHR software for ambulatory care is very different from EHR software used in hospitals.

Unfortunately, many people have come to believe that a specific class of EHR software is required to consume and utilize the EHRs that are digital health records. But this is completely inaccurate. Many types of technologies can be used to manage digital records. If, for example, your electronic health record is a discharge summary written by a physician in Microsoft Word or PDF - two very common digital file format standards for text documents - you could use any number of word processing software programs to view that EHR, including some that are open source and/or free. Google Health, Microsoft HealthVault and WorldDoc store health records electronically for retrieval or updating by patients and the professionals or institutions that care for them. Even data that are digitally formatted in less publicly familiar standards, such as DICOM for radiological images and XML for structured medication or lab data, do not require an EHR application. Many types of software - personal health record applications (PHRs), image viewing programs, e-Prescribing applications, and even web browsers - can be used to create, consume, store, manage, and then transmit these data successfully. Each of these software programs, alone or in combination, deserves to be considered an EHR technology, by virtue of the fact that its main purpose is to handle electronic health records.

Further, the Certification Commission for Health Information Technology (CCHIT), initiated by the Health Information Management Systems Society (HIMSS), later re-organized as a non-profit and contracted by ONC while David Brailer was the the National Coordinator, insists that EHR software products must: a) include hundreds of features and functions, based on a model of such software that many would term “comprehensive,” and; b) be supplied by a single vendor. This EHR definition prohibits CCHIT certification for many simpler, less feature-rich, and less expensive EHR applications. It also prevents end-users from assembling EHR software from components from separate vendors and submitting this for CCHIT certification.

The upshot is that the term “EHR” is no longer very useful. It creates more confusion than it resolves. This is more than a quibble. One can never be certain what EHR refers to: health data in electronic format; a technology that is designed to handle electronic health records in some fashion; an EHR software program that has fewer or different features and functions than those required by CCHIT, or one that has been assembled from compatible modules; or a CCHIT-certified, comprehensive software application from a single vendor whose product has been accepted by CCHIT.

It is not necessary to accept this confusion. Ever-expanding technological options, more than anything else, have made the term EHR obsolete. However, we think clarity is especially important now, as we face the challenge of setting rules to determine who will and will not qualify for ARRA/HITECH funding. If the language we use to define key terms is arbitrary, capricious, biased or simply out-of-date, the guidance we follow will fail to be fair or, more importantly, in our national best interest.

So, in an effort to reach the appropriate level of clarity, we suggest that “EHR technology” replace the terms EMR or EHR in ONCHIT’s lexicon. The term would be defined as:

“An information technology tool, such as a software program or application, that is used to create, consume, manage or transport health data in electronic or digital form.“

This definition is very broad, allowing many different kinds of technologies to qualify as meaningfully useful — required by HHS and ONC — and without requiring features and functions that are not useful. For the market to work and to encourage optimal innovation that can benefit all Americans, it is important to allow recognition and certification of single function applications that can mix-and-match with others, as well as more comprehensive packages, according to the needs, the budget, and customers’ capacity to adopt. A first step is to create clarity in the language used to describe these tools.