Regional Extension Centers & Ripple Effects | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Regional Extension Centers & Ripple Effects

May 30, 2009
by aguerra
| Reprints

On Thursday, HHS/ONC published a

proposal for the HITECH-mandated Health Information Technology Extension Program. While a news writeup with highlights can be found

here, the proposal brought a number of questions to mind that I’d like to work through.

The document states:

“Providers that seek to adopt and effectively use health information technology (health IT) face a complex variety of tasks. Those tasks include assessing needs, selecting and negotiating with a system vendor or reseller, and implementing workflow changes to improve clinical performance and, ultimately, outcomes.”

It would seem there will be tremendous temptation here for RCs to play favorites. Vendors will soon understand that the key to moving software will be not convincing practices and small hospitals of their worth, but making friends with decision makers at the RCs. Will there be rules to prevent vendors from taking RC decision makers out to dinner, from buying them lunch? Today, pharmacy reps use such tactics to influence physician prescribing behavior, and government is having a hell of a time trying to stamp out the practice. Will there be reviews to see if particular RCs are predominantly recommending a particular vendor?

“The major focus for the Centers' work with most of the providers that they serve will be to help to select and successfully implement certified electronic health records (EHRs.”

Will such selection assistance put a damper on some private consulting business, particularly work done for large practices and small hospitals? If you can get it for free (or much less, due to government subsidies), why pay full price? Well, often you get what you pay for, and it’s possible the RCs provide such poor service that the private consultants survive. We’ll see.

Now on to the question of implementation services. These services often made up the bulk of vendor revenue. Usually, the idea is to sell the software fairly cheap (get in the door) and sock ’em on the implementation, maintenance and upgrade fees. Well, what happens when these vendors find providers buying the software from them, but going to the RC for implementation services? Vendors have a responsibility to shareholders (or themselves, if private) to not just maintain, but increase, revenues. So when you cut off one revenue stream they either have to grow a totally new one (hard) or increase an existing one (easy). Thus, software prices will go up as vendors look to make the bulk of their money on the front end, now that the back end is gone.

But just how good will the implementation services that an RC provides be? These centers will have to implement software from all vendors, which is very, very hard. This is another reason to fear they will keep recommending the same vendors, as they develop proficiency in the implementation of particular favorites. “Oh, you don’t really want that one? It’s very hard to put in.”

Will vendors have a chance to brief the RC decision makers on the “benefits” of their products? How can one RC have enough knowledge/talent to have equal depth in 10 inpatient vendors products and dozens upon dozens of ambulatory solutions? On paper, it doesn’t quite make sense. How could RCs afford such talent? Wouldn’t qualified individuals make much more on the open market?

“All regional centers will assist adopters to effectively meet or exceed the requirements to be determined a "meaningful user" for purposes of earning the incentives authorized under Title IV of Division B.”

Fast forward to a point when, after RC assistance, a small practice is deemed not to have achieved meaningful use, and is denied its application for incentives? What happens next? A call to the RC might go as follows:

“I got denied”

“That’s terrible.”

“You said I would qualify.”

“You must not have done what we told you.”

“But now I’m stuck with this system you recommended and all the bills, and I’ve got no money coming in.”

“Good luck with that. We did our part.”

Will there be an appeals process for those denied meaningful user status? How accountable will the RCs be for making sure a provider reaches that status? Will they be dragged into appeals? What is required of the provider in that relationship? Must they prove a good-faith effort? Who decides? Who reviews? We’ll see.




Anthony this is some really scary stuff you just published. Thank you for bringing this out in the light. My concern with the proposal is the following:
"In developing and implementing this and other programs pursuant to the HITECH Act, ONC is consulting with other Federal agencies with demonstrated experience and expertise in information technology services, such as the National Institute of Standards and Technology."
This is doomed for failure from the start. Federal agencies have a history of failed healthcare IT projects. Efforts take twice as long and they use a "one size fits all" approach. They have no experience in preforming solid workflow gap analysis, or working with vendors to have the solution fit the client (instead of the client fitting the solution).
The sad part is that tax dollars will be spent using another government layer, instead of providing solid patient care solutions.

Government thinks it can just license or sanction these "private" ventures and write checks (of taxpayer money), but one of the main problems is oversight. A massive administrative structure will be needed just to put into place and monitor these RCs. As with many other things HITECH, I don't see it working well at all.

Hi Jordan,

Thanks for your comment. I can give you a general answer here, and look for a blog or edit memo from me with more thoughts as this situation evolves.

I can tell you that I think this project is ridiculous. I have no idea how the government thinks it will build these centers so quickly in order to help people qualify for the first round of incentive payments. I have no idea where they think the talent to staff them will come from, and I have no idea which providers will avail themselves of the REC services.

Here's another thing to think about, these organizations will both help with the selection of software AND do the implementation, which I've been told by savvy consultants is a clear conflict of interests.

Also, there is a vision for the RECs to be self-sustaining, but I have no idea how this is going to happen. When they start having to charge real fees, will they be able to complete with existing consultancies on price and quality? I doubt it.

Anyone waiting for the RECs to help with their IT plans is delusional.

Anthony, Great blog.
A few comments
"It would seem there will be tremendous temptation here for RCs to play favorites. "
If you look at the funding announcement released last week Appendix D - Conflict of Interest Certification Template... This is a very interesting and vague document - Your thoughts?

"How could RCs afford such talent? Wouldn't qualified individuals make much more on the open market?"
It would seem that the magnitude of this funding opportunity could draw the talent out of the woodwork... I wonder what the short term impact will be to seasoned Hospital IT execs and Consultants.

"It is expected that each regional center will provide technical assistance within a defined geographic area, and that each defined geographic area will be served by only one center."
Page 8 of the announcement states that the regions are now defined as the HHS/CMS regions for the first cycle of awards, and then for the second and third it would seem that the regions may be redefined. It does not say that there will be only one RC in each center... it says "at least one successful applicant within each of the 10 HHS/CMS regions" This means that some of the originally funded RC's will have funding in the first cycle and be evaluated again and possibly expanded or dismantled. So far there estimation is 70 (or more) RC's

I would be interested to read your comments to the actual program announcement.