On Wednesday, February 5, 2003, at 09:24 AM, Wayne Wilson wrote:
That's not the comparison. What they are implying is that if they were to continue in-house development, they are estimating it would cost 2.8 billion to finish while the Epic system is going to cost 1.8 billion.
The real question to ask is how could any internally developed system cost 2.8 billion dollars?
While it was stated in another post that Kaiser was using COBOL, that was certainly not true system wide for patient records. I don't really know Kaiser's systems, but as part of a group evaluation, I did see a in-house developed system in the Colorado region that was based on OS/2 client server systems running I believe a pure O-O language development, smalltalk I think, but I could be wrong about the language.
In any case, what was being developed was the typical path followed that we just talked about with the on-line OO system being shut down in another CA. health system. (and I have seen this pattern is several other large health systems).
That path is this:
Physicians don't like commerical systems, want to build their own.
Big IT thinks the only way to do that is to hire a Big IT consulting firm.
Big IT consulting firm does a formal design/build process using latest technology and spends Big bucks.
Do to conservatism all around, even with physician input or leadership, design converges on what's perceived as the norm, which suprise, resembles most commerical systems.
It should then come as no suprise that a custom, one-off design of what is basically just another commerical system, costs substantially more than a commerical system whose development was spread out in time and sites.....and, stands a very good chance of not being any better than the commerical systems.
Physicians are back to step 1, only now so much money has been spent the cycle can't restart for another 5-10 years.
To go back to my original question, I think I have answered why it would cost more to do in-house than buy.....
This is where open source comes in --- It changes the development paradigm:
There is no Big IT consultants to ramp up front end costs.
Development is spread out in time and sites, thus competing favorably with commerical systems.
Physician leadership can still be conservative, but the benchmark is no longer what exists, but what should exist!
Deployment can be done is phases, that is, expectations will not be that a complete system will drop into place overnight sometime ..., thus smoothing out user workflow disruptions (and for physicians this workflow is nothing less than patient care). This disruption is never counted on until after trouble starts in both commerical systems and the Big-IT syndrome in-house builds.
