"We serve the sickest of the sick," says Doug Bach, CIO of Colorado access, a Medicaid and Medicare HMO based in Denver. And of its 120,000 members, a mere 3 percent account for nearly half of Colorado Access's costs. This means that the sooner the HMO identifies its neediest patients, and steers them into its intensive care management programs, the more it cuts treatment costs down the road.
Thus the partnership Colorado Access forged last year with Thomson Medstat, which provides custom medical-decision-support applications to help integrate pharmacy and lab dataresults from patient cholesterol screenings, blood tests, etc.into the Medstat data warehouse of claims and treatment information.
Now Colorado Access is successfully using that clinical data to find early indicators of diabetes among its members, and it's getting those patients into early-treatment programs.
There's plenty of evidence that its intensive-care management programs are working: Tracking a specific group of high-risk members receiving the services last year, Colorado Access found they are saving more than $400 per member per month.
The best part is that Colorado Access paid nothing for the custom-developed software.
Aside from participating in weekly meetings with Medstat developers, the HMO's primary contribution was working with its third-party labs to get the data into consistent and usable formats, something it would have had to do anyway.
This was the second project the nonprofit has worked on with Ann Arbor, Mich.-based Medstat to help develop a custom application, making Bach a two-time member of a quietly growing club: CIOs forging partnerships with their software vendors to help cut the cost of, or speed access to, custom software.
Though such partnerships may not show up in IT industry research, analysts and anecdotal observations suggest they are on the rise.
They are particularly prevalent in certain vertical marketsfinancial services, healthcare and lawwhere CIOs can parlay their company's industry expertise and reputation into big savings, more influence and support and, in some cases, royalty revenue when the vendor resells the application.
The vendor, in turn, gets to go to school on the customer, developing experience and a marketing portfolio for use in future sales efforts.
|Customer Name||Colorado Access|
|Software Vendor||Thomson Medstat|
|Deal||Joint development of an application that integrates lab dataresults from blood tests, etc.into the Medstat data warehouse to help identify health plan members who are candidates for diabetes treatment.|
|Vendor Benefit||Access to live clinical data, gathered and rationalized by Colorado Access, gives Medstat a powerful new feature that is a selling point for other customers including healthcare providers, insurance plans, large employers and government agencies.|
But the driving force behind these vendor partnerships goes beyond mutual benefits. It is also born of necessity.
"One of the reasons we've seen this become more popular than it has been in the past is that companies are more and more dependent on the big enterprise application vendors," said Jim Shepherd, vice president of research at AMR Research, in Boston.
The more a company's operations rely on prepackaged software from firms such as Oracle Corp., SAP AG or Siebel Systems Inc., the more CIOs are turning to those vendors for custom development, rather than to potentially cheaper alternatives offered by third-party integrators or in-house development, added Shepard.
"If I have SAP as my application backbone, I may be using SAP's applications for 70 percent to 80 percent of all of my application functionality," said Shepherd.
"And if I'm going to build to extend that, it's more important than ever that whatever gets written is completely compatible with that SAP environment."
But like any deal, partnering with a vendor can be a tricky bit of business. Some of these deals can be the ruin of either customer or vendor. Understanding the contracts and who owns the intellectual property, and anticipating hidden costs, is imperative.
This article was originally published on 10-10-2005