Healthcare is not the only industry that's worked to prevent kickbacks from defining where business flows. In financial services, such frowned-on arrangements are termed "payment for order flow," and involve broker/dealers giving money managers "soft dollar" incentives for their trades. In healthcare, the concern involves physicians funneling their patients to whichever hospitals or imaging centers are offering them the best "incentives."
For a number of years, healthcare's answer to these concerns has been the Stark Law and the Federal Anti-Kickback statute. But last October, officials determined they could accept some relaxations in those rules in order to promote the donation of healthcare IT by hospitals to physicians.
But I suspect we're going to find there are many, many reasons other than cash that hospitals have been taking an exceedingly cautious approach here. As with most large-scale projects, the devil's in the details, and there are dozens of questions that come up when structuring any hospital/physician IT collaboration—especially one that requires such a fundamental change in a practice's workflow.
Hospital CEOs and CIOs taking a first stab at this would do well to take a methodical approach, first figuring out which practices/physicians to bring into the IT-donation family. But that's not easy, as the relaxation states the decision of where to donate cannot be tied to the amount of business funneled to a hospital.
In a subsequent step, hospitals might want to take a hard look at inpatient system providers and decide if offering the outpatient version of that software might be a good way to go (if such a version exists). CIOs tend to like this choice as they are already familiar with the vendor's software and service quality. But things can get sticky here too, as one version of the vendor's software might be significantly weaker than the other, leaving the recipient of the largess less than grateful.
Even if the hospital's inpatient systems vendor has a solid ambulatory offering, the practices approached will most likely want at least a little choice, so it's probably a good idea to have at least two offerings that have been vetted and that the hospital is willing to advise on/support on a long-term basis.
Once the hospital has a few offerings in its basket, CEOs/CIOs should be prepared with specific ideas about their organization's role in the practice's selection, implementation and adoption of the software. Remember—no one wins if the practice fails in moving its workflow to an electronic format. And speaking of failure, what happens if the implementation goes south? Does the hospital still foot the bill?
Physician practices also have many valid concerns about getting involved with these arrangements. Among other worries, they fear a loss of freedom, mobility and autonomy should they be tied too closely and tightly to one hospital through an IT arrangement. They also fear sharing their financial information (which may go along with the clinical information at the heart of the exchange).
I do believe these arrangements can work and benefit the practices, hospitals and patients involved. However, as with any long-term and complex relationship, it's much better to think everything through and get all the issues on the table before signing on the dotted line. In the same vein as the expression "good fences make good neighbors," laying out exactly what the expectations and responsibilities are for each party to the deal—including the vendor—may create an extreme air of formality on the front end, but will more than likely make for good neighbors down the road.