Our consortium's primary objective was to provide a general overview of the potential hazards posed by clinical software systems and to suggest responsible approaches [1]. Our proposed monitoring strategy, based on categories of risk, goes far beyond the ability of an individual competent practitioner to detect software problems. Local software oversight committees and the careful testing of software during and after development are integral parts of our recommendations. In 1988, U.S. Food and Drug Administration Commissioner Frank Young recognized the safeguards provided by competent human users of clinical software systems [2]. Dr. Berner questions whether clinicians can detect and override faulty advice generated by clinical software systems. We note that similar concern could equally be applied to faulty advice from traditional human consultants. Our recommendations included local reporting of significant problems to national centers so that adverse national trends can be detected and corrected in a timely manner.

Our categorization of risk attempted to differentiate between systems in which competent intervention was easily accomplished (risk categories 0 through 2) and situations in which it was not (category 3). Dr. Berner implies that additional, national-level regulation and testing of clinical software programs before and after marketing might decrease the necessity for "user overrides." The consortium, in constructing its recommendations, concluded that no amount of prior testing can prevent or abrogate the responsibility of competent clinical users to override faulty output from clinical systems. Marketplace forces, ethical responsibilities, and the legal system already place substantial obligations for product reliability on system developers and vendors. An important point is that system output depends on system input. Incorrect entry of case findings into a decision support system can cause a system to give faulty advice, no matter how much prospective testing has been done. The behavior of an improperly trained clinician-user can also lead to adverse outcomes that are system-independent, just as poorly trained surgeons might produce worse outcomes than well-trained surgeons using similar techniques and equipment. Thus, national-level precertification of software cannot cover situations involving faulty input or improper training. Local review by software oversight committees is best suited to detecting and remedying situations when faulty input or poor training is at fault.

Smarter, better-tested systems cannot reduce the responsibility of clinician-users to have sound medical knowledge and good judgment. Our consortium's recommendations for responsible use and monitoring of clinical software systems are increasingly relevant, as shown by a growing body of literature documenting the benefits that software programs can provide during clinical practice [3, 4].