Quality, safety and ethics in the use of computers to advise on patient care|
Quality and safety of decision support systems
Green Paper drafted by OpenClinical, 2002
Developers of Clinical Decision Support Systems (CDSSs) have to
date tended to be more concerned with the efficacy of their systems (e.g.
measurable improvements in healthcare outcomes) than with safety (e.g.
potential for hazardous side-effects). A review of quality, safety, ethical and
legal liability issues suggests that CDSSs developers will be expected to
comply with a “duty of care” covering all aspects of the design, development
and deployment life-cycle. Borrowing from experience in the transport, power
and other safety-critical industries, we identify a range of quality and safety
assurance methods whose adoption may be needed before CDSSs can safely
become an integral part of routine patient care, and before the trust of
healthcare professionals, patients and other stakeholders can be gained. No
single method will be sufficient for safe development and deployment; a range
of techniques will be needed and used selectively. This OpenClinical green
paper seeks to initiate a discussion of this topic...
There is now good evidence that clinical decision support systems (CDSSs) such as patient
monitoring and reminder systems, prescribing systems, treatment management and workflow
systems can make a significant contribution to quality and consistency of patient care. Interest in
the use of such technologies is now growing rapidly, particularly in light of the recognition that
human error in the delivery of patient care is a major source of avoidable mortality and morbidity
[IOM Report, 2001].
Despite the potential of CDSSs to help improve patient care we must also anticipate possible
risks in their introduction. Most new medical technologies entail new hazards (e.g. unanticipated
side-effects of drugs) and even with our best efforts it will not be possible to avoid entirely the
possibility that at some point in the future someone will suffer, or possibly die, in circumstances
where a CDSS is involved. Software developers clearly have a responsibility to ensure that
avoidable hazards are anticipated and prevented, and that unavoidable ones are properly
managed should they occur.
In the context of CDSSs, there is also a further longstanding and unanswered issue concerning
legal liability: if a decision support system gives bad advice, who will be held responsible? The
software designers? The providers of the medical knowledge used by the system? Or the endusers
- the healthcare professionals who are responsible for the final clinical decision? No-one
seems to know: so far as we can establish, there is no case law to establish the relevant
precedents, either in the USA, Europe or elsewhere. CDSS developers must anticipate possible
legal liabilities that might result from the use of their technologies.
In this paper, we review current practices in software engineering with a view to discussing
options for establishing quality methodologies that are appropriate for CDSS technology
development. Further, we consider circumstances in which liability issues might come up, and
propose an initial set of methods and procedures to help deal with the legal exposure that might
arise should patients come to harm in situations where CDSS technology is used.
Management of quality and safety of clinical decision support systems is an important but difficult
challenge requiring technical, professional and organisational commitment. A policy that is overly
lax could lead to patient harm and ethico-legal problems, while one that is overly stringent will be
a disincentive to developing such technologies and achieving the potential for improved patient
care that they offer. This green paper has set out a variety of options for defining quality and
safety procedures to help system designers and developers demonstrate that their duty of care
has been discharged. It is not intended that all such options should be used in all applications but
that the level of investment in managing quality and safety should match the potential level of
clinical risk associated with technical or operational failures. The table in section 3 (to be
completed) will offer a tentative proposal for structuring the options that might be recommended
for different risk levels.
Documented compliance with an explicit quality and safety process could provide the best
practical demonstration that a developer’s duty of care has been taken seriously, and that any
faults, accidents or other mishaps that subsequently occur are probably unavoidable given the
current state of clinical and scientific knowledge and do not represent negligence by the
|Entry on OpenClinical: 2003
Last main update: April 2003