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
