OpenClinical logo

Quality, Safety & Ethics

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

Abstract

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...

Context

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.

Conclusions

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 developer.

spacer

Read the
OpenClinical
Green Paper

OpenClinical Green Paper

Quality and safety of decision support systems

Entry on OpenClinical: 2003
Last main update: April 2003
Search this site
 

 bullet  OpenClinical briefing paper: Ethical considerations for the development of Decision Support Systems by Alan J. Green  bullet  Public reports on quality and safety in healthcare

Privacy policy User agreement Copyright Feedback

Last modified:
© Copyright OpenClinical 2002-2011