This page contains a Flash digital edition of a book.
Commentary: Electronic Health Records

(where only a browser is required), there is no need for any SaaS EHR developer to have a large, local installed base.

When you ask some REC representatives about this, they divert the question by saying something like, “We will look at this in a year or so and let any previously ex- cluded EHR vendors, whose share has become signifi cant in our state or region, into our program.” That makes no sense either. If RECs picked EHR companies that already have local penetration and then promoted them for a year, to 1,000 to 4,000 physicians that they are helping to adopt EMRs, how likely is it that other non- promoted EHR companies

Arthur Gasch

( is founder and Bill Andrew ( is executive vice president of Medical Strategic Planning. Follow MSP on LinkedIn and via MSPehrSelector on Twitter.

will improve market share in that year? It seems to us that this approach discriminates against a large group of EHR developers whose products don’t have penetration in specifi c market areas.

A better question might be, “Does a company offering a SaaS EHR solution have enough well-trained help-desk personnel for its total installed EHR base?” With a SaaS EHR model, many group practices’ eggs are all in one big basket. If the server fails, the disruption could be hundreds or even thousands of group practices all over the U.S. at the same time. What a fruitful hacker and cyber terrorist target! Is the help desk located in the U.S.? Do help-desk personnel speak fl uent English? What privacy laws actually apply to sites hosted outside of the U.S. or with non-U.S. help desks? Do foreign privacy laws confl ict with state or federal HIPAA privacy laws? If so, how is HIPAA compliance and a secure chain of custody of patient records maintained and substantiated? The current EHR prequalifi cation process is fl awed by its lack of transparency and its cumbersome nature. Given that this is the largest giveaway of U.S. taxpayer dollars in history conducted by non-government surrogates, where are the checks and balances? Readers who are VCs or EHR developer board mem- bers, take note: Unless you can fi nd a way to succeed in this convoluted process, your company will be crippled in competing for the next 100,000 physicians who become EHR users, which may put your company in jeopardy – even if you don’t focus on primary-care specialties. If less than 10 EHR suppliers gain 100,000 new users, do you doubt they can customize future versions of their primary care-oriented EHR software to address your specifi c clinical market specialties as well? Companies that want a stake in this $34 billion pie certainly need to get their products ONC certifi ed, but is that is all they need to do? To date, CCHIT and the Drummond Group have

32 December 2010

certifi ed 40 complete or modular EHRs, but far fewer have had success with any signifi cant group of RECs – and not one has been selected by all of them. Since certifi ca- tion is a requirement for MU, and no certifi cations were issued until October 2010, on what basis could any REC consider certifi cation when picking prequalifi ed EHR developers?

It would be helpful for the ONC to publish a table of the scored criteria response from every EHR vendor that responded to every REC RFQ so far, as it would reveal the core functionality they share, if any. Since this is paid for by taxpayer dollars, with RECs acting in proxy for the federal government, it is a reasonable expectation.

Given that this is the largest giveaway of U.S. taxpayer dollars in history conducted by non-government surrogates, where are the checks and balances?

Medical Strategic Planning (MSP) has a tool that can demonstrate which common functionalities EHR products share; it’s called the EHR Selector, and the specifi c function is known as the REC-Check. It allows any consultant, REC, physician user or EHR vendor to determine shared functionality of any set of EHR products, including those shared by EHR vendors pre- qualifi ed by any RECs. Visit the MSP EHR Selector (, subscribe and run your own “REC-Check” today. It will allow you to fi nd additional vendors that provide equivalent functionality. At the recent American Health Information Manage- ment Association (AHIMA) Convention and Exhibit in Orlando, one presentation addressed many of the issues described above: According to Deborah Kohn, Dak Systems Consulting, and Elaine Lips, ELIPSe, the “perfect storm” is brewing with the ARRA/HITECH, HIPAA-5010, ICD-10, Patient Privacy Protection Act, ACO legislation and healthcare initiatives – portions of which are already in effect and the convergence of which will occur in 2012-2014. In fact, Kohn stated that the costs of HIPAA-5010 and ICD-10 implementation alone will eat up most or all of the incentive payments anticipated by physician practices.

1. A functionally equivalent EHR is an EHR that shares the collective functionality of the EHR picked by RECs, but was not chosen or even considered. These are determined by extracting shared EHR features from prequalifi ed EHRs and then using those features to search for other EHRs that match them on the MSP EHR Se- lector (


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36