On Thu, 2003-02-06 at 01:24, Wayne Wilson wrote:
> Ignacio Valdes wrote:
> 
> > david derauf wrote:
> >
> >>  Kaiser Permanente to put patient records online
> >>  
> >> Kaiser has spent the last 10 years internally developing an 
> >> electronic records system, but following implementation problems, 
> >> finally opted for a commercial system. The insurer expects to save $1 
> >> billion by using the Epic system in place of developing its own 
> >> system, according to George Halvorson, chairman and CEO of Kaiser 
> >> Permanente (Rundle, 2/4).
> >
> >
> > 'save $1 billion' by spending $1.8 billion? If I were a Kaiser patient 
> > I'd be hanging onto my wallet.
> 
> 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.
> 

This entire analysis is spot-on. The tactic for OSS is to convince Big
IT management (or better, their bosses - the CEO, not just the CIO) that
funding a parallel OSS approach is the best possible risk management
they could undertake for these sort of hugely expensive but demonstrably
very risky projects - and that includes buying, configuring and
system-integrating a commercial package.

Let's see: if one per cent of the US$1.8 billion budget were allocated
to an independent risk management strategy involving a FOSS approach -
that's US$18 million. That's more than enough to complete the design,
build and testing of OpenEHR, construct all sorts of interfaces and
front-ends for it, and probably develop a large number of archetypes,
all on very acceptable timeframes. Doesn't matter that the people
working on OpenEHR aren't part of companies which have multi-million
dollars turnovers, or even that they live elsewhere - this is the risk
management strategy, remember, which won't be needed anyway because the
main projects not going to fail, is it? So relax about using all this
unorthodox FOSS stuff.

In my dreams...

Tim C


Reply via email to