JF,
My original post was in response to an article of the type "OSS for the
medical arena won't work because...." It seems important to respond to
such notions before they become the conventional wisdom for senior
decision-makers in health care organizations.
In this case, the argument boiled down to "...because individual
programmers won't be able to assume the liability for their software or
obtain FDA certification." I suggested another approach to these
problems; businesses will arise to provide support and services around
any viable OSS effort. Protection against liability and FDA
certification could be among those services. I pitched that as a
first-level response to the article, to help senior managers rest
easier.
You answered with details I didn't know about FDA certification, and
pointed out that it's likely to be a very burdensome process for an open
source-based company. That sounds right to me, but I'm not sure there's
any way around it. I agree with you that eventually the FDA will come
around. I envision an awkward initial time when the first OSS medical
software companies are building their market and credibility, where they
will still have to deal with the old FDA constraints. Eventually the
broader health care community will prevail on the FDA to expand their
perspective--"life will find a way"--but it may take a while. Gunther
Schadow's distinction between open and closed loops of control helped me
think about this. The original article focused on what was apparently a
closed loop anesthesia system (for deliberate dramatic effect, I
suppose). I think OSS efforts will gain much faster acceptance
initially if they focus on open loop systems. Once the OSS methodology
is proven in that arena, then presumably the FDA will be more receptive
to OSS efforts for closed loop systems.
Steve Doubleday
JF Lancelot wrote:
>
> Gunther,
>
> I don't want to monopolize the list on this issue, but I can't hold back a
> few comments:
>
> You quote one paragraph of mine which makes it sound as if I'm against
> OSS, or believe it is doomed, which is most certainly not the case.
>
> My point was that since there are no clear or simple provisions in the FDA
> regs for OSS, the approach suggested by Steve Doubleday would be overly
> vendor-burdening and party-pooping.
>
> Like it or not, some aspects of an EMR system are likely to fall under
> these regs today or in the not-so-distant future (for example "advanced"
> EMR decision support features, drug dose calculations...), particularly as
> EMR systems become more common. FDA reg issues will come into play sooner
> or later.
>
> I think all the players (FDA, the health care facility, the software
> vendors and the OSS developers themselves) will eventuall recognize the
> top-quality potential of OSS schemes and adapt. They'll have no choice.
> Just like the dinosaurs escaped from Jurassic Park: life will find a way...
>
> JF
>
> At 02:35 PM 8/6/99 -0500, Gunther Schadow wrote:
> >JF Lancelot <[EMAIL PROTECTED]> wrote:
> >
> >> I think the OSS paradigm puts a very large burden on the vendor, and
> >> this may result in a very conservative attitude by the vendor
> >> towards incorporating enhancements into their distribution and/or
> >> otherwise letting it evolve.
> >
> >FDA certification of software is an interesting thread that could
> >quickly turn out pretty sad. I don't know pretty much anything about
> >the regulations here in the U.S., but from what I hear here about
> >certified, "proven" quality I am very worried whether anyone but DoD
> >or NASA can comply with it. May be IBM can too, but from what I know
> >about MS quality standards :-) I doubt that even MS could comply. It
> >seems like this kind of "risk awareness" puts any kind of innovative
> >software design (and software development paradigm) into the straight
> >jacket of "righteous" software engineering dogma, i.e. waterfall
> >model, with proofs of design at every step, etc., in short, the kind
> >of thinking that comes largely out of DoD and NASA.
> >
> >While I see that an extremely high level of prudence is necessary
> >before you shoot a man into space to depend on software systems, or
> >before you control nuclear weapons with it, this kind of prudence
> >comes with an extremely high cost. If only heavily subsidized
> >government agencies can comply, it's not good for the innovation and
> >deployment of low cost EMR systems. On the other hand, if it becomes a
> >matter of how much you can afford "faking" the "righteous" software
> >engineering process (and paying the astronomical fees for FDA
> >certification and auditing) then it's even worse. Sure, Microsoft can
> >afford to pay whatever money it costs to get certifications, but does
> >this make their software any better? We all know that if you know the
> >rules really well, you can play around their intent.
> >
> >So what would I suggest? First off, to revise liability assumptions,
> >and put a considerable liability on the end user (i.e. the Healthcare
> >Organization.) That is, those organizations who have staff working in
> >EMR systems implementation and maintenance, should be free to choose
> >and should be liable for what happens. Second, certification is a
> >dubious prejudice, and should not preempt a careful investigation of
> >the facts of every particular liability cases, by the courts, lawyers
> >and testifying experts.
> >
> >Third, and most important, to keep a sane spirit in software
> >development, analysis and deployment. The real risks of software use
> >occur when we install closed loops of dependence on a software
> >component. When I control the ventilator, norepinephrine pump, or
> >anaesthetics application of my ICU patient by closed regulation loops,
> >then I am better sure that the software I am using will not crash or
> >fail in subtle ways. This kind of software deployment is like
> >shooting a crew into space and does require a lot of prudence. But
> >luckily this is not the normal use case!
> >
> >For an EMR system with nice data management features and some decision
> >support I can relax much of the NASA level prudence, because there is
> >no closed loop of control. Every data put into the system has a
> >source that is under human control. Data that comes out of the system
> >is read and interpreted by humans before the data controls any
> >actions. Further, there are lots of parallel data channels, e.g.,
> >vital signs are fed into the EMR system, but will still be shown on
> >the conventional monitor and supervised by the doctor and nurse from
> >there. I.V. pumps will still show their settings at the bedside, and
> >even if programmed from a computer system, will (should!) require the
> >check and manual activation by the trained nurse or doctor. Lab
> >systems are automated since many years now, and still, common policy
> >is that no value leaves the lab that has not been seen by a human who
> >knows his stuff.
> >
> >We should first concentrate on computer systems that assist and
> >support the work of human professionals. A certification model built
> >on the NASA level of prudence will bog down pretty much all creativity
> >and will lead to monopolies and high prices of medical software.
> >
> >Finally, finally, there is at least one case, I believe, (with
> >Dr. Reed Gardener's system at Salt Lake City) where some partially
> >closed control loops have been installed in ICU ventilator
> >control. But this has been a long term effort of in-house development,
> >and more importantly, it has been done stepwise. Lots of human control
> >in between, and only under careful controlled trials, have control
> >functions been taken over by the computer. And most importantly this
> >has been done only to the extent where it could be scientifically
> >proven that patients were weaned off the ventilator faster through
> >automatic control than through human control. So, automation has been
> >driven by *medical* considerations (not cost issues!!!!) That is, the
> >patient's risk (of prolongued ventilation) could be reduced through
> >the computer control.
> >
> >I'd be far more concerned however, if we tried to use decision support
> >systems and closed loop control to save paying wages to health care
> >professionals.
> >
> >so let's keep doing good work :-)
> >regards
> >-Gunther
> >
> >Gunther Schadow -----------------------------------
> http://aurora.rg.iupui.edu
> >Regenstrief Institute for Health Care
> >1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
> >[EMAIL PROTECTED] ---------------------- #include
> <usual/disclaimer>
> >
> >
> --
> JF Lancelot, CliniComp, Intl. - mailto:[EMAIL PROTECTED]
> _______________________________________________________
> USA Tel: +1 (858)546-8202 Fax: +1 (858)546 0154
> France Tel: +33 (1) 5543 0216 Fax: +33 (1) 4217 0260
