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:
- 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.
- 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.
- 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?
- How should the certification process be structured to ensure fairness, flexibility and openness to innovation? Does the current certification process meet these criteria?
- 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?
- 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.
David C. Kibbe MD MBA is a Family Physician and Senior Advisor to the American Academy of Family Physicians who consults on healthcare professional and consumer technologies. Brian Klepper PhD is a health care market analyst and a Founding Principal of Health 2.0 Advisors, Inc.
Categories: Uncategorized
I quote from the results section of an article in the New England Journal(Jha, A.K. et al; “Use of Electronic Health Records in U.S. Hospitals” NEJM 2009; 360:1628-38):
“….only 1.5% of U.S. hospitals have a comprehensive electronic-records system (i.e. present in all clinical units), and an additional 7.6% have a basic system (i.e. present in at least one clinical unit.) Respondents cited capital requirements and high maintenance costs as the primary barriers to implementation….”
Where are you going to get all this data to use in your applications if the hospitals (not to mention the dr’s offices) do not even have it available electronically at this moment? Sounds like the 20 billion would be best used, and easily soaked up, just by assisting hospitals and physician offices to actually install these systems at all. There will be little money for anything else…..
I’m with Stephen! I’d even settle for a hotel in San Francisco. DCK
In general I am on board with David and Margalit’s commentary. To reiterate the basic premise in my own words:
I think that the tiered ‘data/interoperability’-first, interface-second formula is mandatory to ‘untie’ the knot of the EHR problem. Banking, shipping, trading markets etc. have for years been able to conform to their own certification standards and then move on to the value-added services that such efficiency provides. What’s the big problem with healthcare? Are we missing the forest for the trees? Lets back-off for a second from clinical decision making, outcomes analysis, payment efficiency…we need to solidify the base promptly before building the walls…but if planned and acted upon, this can be accomplished quickly.
EHR stimulus needs to initiate with a directive to hammer-out “BASIC” interoperability standards for the main pillars of digital healthcare data, THEN this can be certified/monitored by CCHIT or whomever. There has to be enough of a potential marketshare or financial benefit to motivate the individual players to do so, and right or wrong it will likely have to start with government-directed mandate “play now or get out of the sandbox”.
Its time for lab, pharmacy, EMR, PHR, imaging and payor sources to pony-up ‘together’ and establish the basic fundamentals for interoperability ie demographics, patient health diagnoses/treatments, drug rx and dosing…at an entry level to allow for seamless exchange of health information.
This can then be passed to a certifying ‘body’ CCHIT etc., to then build upon moving forward. If ‘we’ don’t do this, someone ‘ie Uncle Sam’, might….and then we will bemoan inefficiency, poor care, high cost and lack of control.
I say we reserve the St.Regis Monarch Beach (it was good enough for AIG), invite major players and close the doors to the conference room for as long as it takes to establish cumulative cross-talk standards and present it in a nice package to Blumenthal so we can move along to the fun part.
SJM
All: Darwin famously said:
“Great is the power of steady misrepresentation; but the history of science shows that fortunately this power does not long endure.”
Cheers, DCK
Matthew, if indeed David and Brian are late to the party, then I submit that the party will be a very small and “exclusive” party and the salmon pate is made from canned salmon.
I agree that CCHIT seems to think that this is a done deal, but if we are really and truly interested in improving outcomes. we must walk before we run and we must have a critical mass of providers walk with us.
It’s not too late to come up with meaningful standards that can be adopted by the masses. Here is a suggestion:
1) The system shall be capable of bi-directional electronic communications with pharmacies using the NCPDP standard.
2) The system shall be capable of displaying tiered formularies and alternative drugs at the point of care.
3) The system shall display comprehensive prescription histories as maintained by the PBM.
4) The system shall be capable of transmitting laboratory orders and receiving laboratory results electronically using the HL7 standard.
5) The system shall produce reports following the existing PQRI standard requirements, or a subset thereof, as decided by the Secretary.
Requirements 1 through 3 shall be certified by Surescripts (as they already are).
Requirement 4 shall be certified by a nationally recognized reference laboratory, such as Quest or LabCorp (as it already is).
Requirement 5 shall be validated by actual submission to CMS.
Providers using a system, or a combination of systems, that fulfill all five requirements should be eligible for the incentive upon attestation, or through claim data, that validates ongoing use of such systems.
If we do that for 2011 and add more standards and requirements for 2012 and so forth, we will be engaging the vast majority of providers.
The main idea here is to stay away from trying to dictate to doctors how to register a patient and how to do their job. Focus should be on moving data and as time goes on, moving to/from more meaningful targets/sources.
Jonathan Bush was right in principle. At this point it doesn’t matter much how the data moves, as long as it moves. There will plenty of time to rearrange it in neatly marching rows and columns later.
My sense is that David and Brian are unfortunately late to the party, and are not winning any friends by telling the hostess that her salmon pate is made from mackerel.
Two important pieces from my interviews last week with the Cats Mark Leavitt and Glen Tullman (CCHIT Chair and Trustee respectively), and Jonathan Bush (AthenaHealth CEO and leading dog)
1) According to Leavitt & Tullman, CCHIT is in the catbird seat and the secretary HAS to decide on certification standards in such a short time period that it’s impractical to have another body establish itself in time to replace it. My guess is that they’re correct here.
2) Bush said, (essentially) screw “meaningful use”, just pay doctors for the data, and if they’re delivering CMS appropriate data, don’t worry about how they’re getting it into CMS’ system.
I have some concerns about Bush’s view but if we pay for the delivery of data sets (and we investigate to ensure accuracy) and then we pay on outcomes achieved (or at least processes followed) then we are most of the way there to what patients, consumers and payers want. We can then leave it up to doctors and providers to figure out the how.
No that’s all nice in theory, but it would require that the $19 billion is all reserved for P4P programs and not for EHR tools per se. And that’s clearly not the intent of the law now signed & money ready to be spent.
So I suggest that the dogs now leapfrog the cats. Igore $19 billion and start talking about the other half of what Blumenthal correctly posited as the problem
“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.”
If we can make even 5% of the $400 billion that Medicare pays physician alone on an annual basis be contingent on showing better outcomes for patients, that exceeds what’s in HITECH by far, and will have a bigger longer lasting impact.
Karl, I agree with you that HL7 is widely accepted and in spite of its complexity it is used everywhere in healthcare. However, this is HL7 2.X, the one with pipe delimiters and segments and all that.
CCD is NOT based on this standard. CCD is based on HL7 3.0 which is the XML version and bears almost no resemblance to its predecessor. This one is not widely used and the complexity of the underlying CDA and RIM is mind boggling to say the least. Compared to this beast, CCR is a very simple and efficient standard and I’d much prefer that we standardize on the CCR.
In any case, my point was that maybe we should relax the upfront requirements a bit and concentrate on involving as many providers as possible in the process of moving data instead of quibbling about standards that nobody uses.
Margalit,
Interoperability would suggest a standard that is widely accepted.
HL7 is already accepted as a standard for transport of healthcare data. As an organization they have worked hard at creating a standard that is acceptable across the spectrum of healthcare stakeholders.
Their CCD data format is already in use and would serve the needs of EHR consumers.
There are however some who are invested in ASTM’s CCR, but surely one of these two formats would more reasonably be the standard format for transmission of EHR data.
Excellent discussion David!
The definition of EHR technology as you define it could cove any web browser or email program. If we want to move healthcare forward then I suggest one word be added to the capabilities in this definition. That word is: transform
Adding that requirement implies that an application be able to perform analysis or conversionhealth data. This is the real promise that is dangled by google and Microsoft in building an ecosystem around their PHR platforms.
Without a transformation requirement we may stymie evolution of health it and encourage the adoption of technology that perpetuates the paper oriented systems that exist today.
All: I’d like to address Glenn Laffel’s thoughtful comment about where clinical decision support fits into the picture. To my mind, it’s got to be one of the “meaningful uses” along with ePrescribing, data sharing for care coordination, and quality and performance reporting. These last three are in the ARRA, but decision support is not.
Glenn is absolutely right on target to suggest that EHR technology’s highest and best use is to improve quality, and that one important way of doing that is to apply evidence-based analysis and guidance at the point of care, at the point of making decisions. I’m sure that David Blumenthal sees it this way, too.
But I have to admit I don’t know the best way to introduce clinical decision support systems into ambulatory care practices. I’m pretty sure it doesn’t require a comprehensive CCHIT-certified EHR software application. I’m pretty certain, on the other hand, that it does require minimal data about each patient to be collected, accessed, integrated — in a word, to be available — when and where decisions are likely to be made. There are probably dozens of clinical decision support EHR technologies out there, some of them web based and open source, some of them able to reside on an iPhone, some on mainframes — but none of them will work without accurate and up-to-date data that are relevant to the health and care treatments that are being decided upon or, in some cases, against.
This is why I’m such a advocate for taking a data liquidity step first. Let’s make it possible for every patient at every encounter to have accessible a minimal data set in standardized format, including but not necessarily limited to problem list, medications, allergies, recent labs, immunizations, and procedures. Let’s provide incentives to both doctors and patients to keep these data elements up-to-date and accurate, and add to them, and organize them, as appropriate for making the next decisions.
This isn’t information technology, it’s information engineering that enables information managment, which we’ll undoubtedly need IT to help us with.
Kind regards, dCK
Thanks for all the great comments. I want to address Karl’s point about “EHR” having been defined by ONCHIT. I think you help make our point that the term “electronic health record” now refers primarily to the individual’s health information in digital format. And so EHR technology ought to become the way we refer to tools that help create and manage that information. I’d include “repositories” as one of those EHR technologies, and a very, very important one. Most repositories of health data are relation database management systems, although there are newer database technologies, e.g. Amalga and dBMotion, that are hybrid.
But, in any case, it’s very important to point out that health data about an individual should come in standardized formats, and that EHR technologies then should be able to use these standards to share the data. Thanks for bringing this up. As a matter of fact, in our next installment in this series we’re going to address this issue of separating the data from the applications, as a means of getting to the heart of this horrible term “interoperability.” In our view, it’s not the applications/systems/device that contribute the essential capability of data exchange, but the data themselves.
Kind regards, DCK
I think the truth is somewhere in between. It depends on the institution and how recent the test was done.
It also is painful to extract from patients who have a lot of tests (and these are the ones likely to have potential duplications) when and where they had what tests. Some patients apparently want duplication – make sure evrything is still write. Of course this is unreasonable.
So, in summary, reduplicating noninvasive tests: rarely hurts the doc (i.e. rarely requires additional authorization any longer), makes most patients happy and is much less work/hassle then requesting and reviewing some test, poss. the same, that was done somewhere 4 mos. ago. And of course is the more defensive practice.
But there is the financial aspect, too. I think the self referring, for instances for MRIs, has to be stopped by law.
Just to present a different point of view:
As a PCP in private practice, I can almost always obtain clinical data I need in a timely manner, using phone, fax, mail, and a well-trained office staff.
When I see tests and procedures being unnecessarily duplicated, it’s almost always because the physician and/or institution has a financial interest in doing so, not that the old data was not obtainable. How will “EHRs” address this problem?
Karl, if we take these definitions literally, then Microsoft Office paired with secure e-mail should qualify as an EHR.
One can definitely create, manage and consult health related information stored in Excel and Word and all that information can be transported via secure e-mail. Millions of people and businesses base their interoperability on these tools, so I think they qualify as a standard. This is nothing more and nothing less than electronic paper charts.
Personally, I see no reason why this sort of system should not be eligible for the EHR definition above.
Although there may be misuse of the term EHR as both an application as well as a collection of data, the ONCHIT has defined EHR as the following.
“…An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one health care organization.”
Source : http://www.hhs.gov/healthit/documents/m20080603/10_2_hit_terms.pdf
This definition lists elements of an EHR.
• Electronic Record
• Standardized to Nationally Interoperable guidelines
• Able to be shared externally
Although there are many interoperability issues that have to be addressed (data format, codesets), to me the definition of an EHR is clearly a data repository and not an application.
EHRs are created maintained, managed, and possibly transported via EHR certified applications.
Excellent,very clarifying,post. Also Dr. Blumenthal needs all the help talented people with skills and values can give him.
Dr. Rick Lippin
Southampton,Pa
http://medicalcrises.blogspot.com
In Blumenthal’s NEJM perspective, he mentions from time to time that EHRs need to support provider-based improvement efforts, which to me suggests he’s thinking about a broader definition of an EHR than the one you’ve proposed that Bush and Obama have in mind.
David has had a longstanding interest in, and has made important contributions to the continuous improvement of quality in health care. He was one of the first to propose for example, that CQI tools first developed for use in industrial settings could be used by health care organizations.
I think David’s after a functional tool that overlays best practice guidelines, includes reminder systems about screening tests, and cuts prescribing errors…in short the EHR is a de facto quality improvement tool.
I would support this approach. If EHRs are going to become a wise investment of taxpayers’ $20 billion, they’ve got to be more than passive data repositories.
David’s well aware that there’s plenty of medical evidence on which to base such systems, and that the best EHRs are already helping physicians report on their performance in this regard and actually improve that performance.
Bravi, David and Brian! A very valuable discussion! It is essential that the certification process not merely “grandfather” established systems but, rather, be open to innovative systems as well.
To Margalit’s point about defining “meaningful use,” I’m not sure we can create a precise definition. This may be a case where, to quote I believe it was Justice Ginsburg, “I may not be able to define it but I know it when I see it.”
It seems to me that our objective is to make sure that a patient’s records are available quickly and easily to the patient and any care provider who needs them to treat the patient, in manageable, usable form. Accordingly, any system that does so would meet the “meaningful use” test.
I specifically include the patient as well as care providers in this statement of objective because I believe both are required to improve care quality, reduce care costs, and improve patient behavior. At the risk of provoking great wrath from health plans and payers, I specifically exclude payers because their involvement is tangential to the delivery of care and how the patient attends to his/her health.
David and Brian, great overview and very good definition for the term EHR.
I would like to pause for a moment and explore another term: meaningful use. The word meaningful is a subjective term. Meaningful to whom? What is meaningful to one healthcare constituency maybe completely meaningless to another. For example transporting data from a provider to a payer may be meaningful to the payer, irrelevant to the patient and a hindrance to a physician. Creating a nice digital, concise health record for the patient may be meaningful to the patient and equally inconsequential to both the payer and the provider.
So are we talking about meaningful to ARRA, e.g. providing better care and containing healthcare costs? In that case we need to define “meaningful use” as follows:
Measurable use that a physician makes of the EHR technology that directly correlates with measurable reductions in cost of care and measurable increases in quality of the same.
The assumption that we are all making, including ARRA and the President, is that transporting data from providers (to where?) will directly reduce costs and improve quality of care.
I can definitely see how the ability to transport some clinical data from one provider to another can create better efficiencies and contribute to cost reduction and quality of care by providing better personalized information at the point of care.
I am not so clear of the “meaningfulness” of transporting data to payers and even to patient maintained PHRs. I would much rather that the PCP be responsible (and properly reimbursed) for maintaining patient records correctly. I assume that he/she is much better qualified than most people to make meaningful use of such records.
So maybe we should further constrict this data transport to be first and foremost between providers. This makes the question of certification pretty simple, I would think. Can you or can you not export/consume a predefined set of data from/to your system? If that system happens to be an Excel sheet, or a piece of paper shouldn’t make any difference. We should certify only inputs and outputs and consider the provider a “black box”. I don’t think CCHIT or ONCHIT or any other official body should be in the business of certifying physicians’ workflows and practices.