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>
