Thursday, January 21, 2010

COMPLEXITY 6

This is the sixth in a series of new posts on the subject of complexity in scientific research. The theme of this collection is that scientific progress, particularly in the realm of healthcare, has declined as a consequence of the high complexity in software and other technologies.

-- POST BEGINS HERE --

"Any informatics problem can be solved by adding an extra layer of abstraction."
- Anonymous source, sometimes referred as the golden rule of computer science

Much can be learned about the consequences of complexity by reviewing technology disasters. A 2003 article in the British Medical Journal described a project to install a computerized integrated hospital information system in Limpopo (Northern) Province of South Africa Rlita. This poor province 42 hospitals and invested heavily to acquire the system. This fascinating article describes what went wrong and provides a list of factors that led to the failure of the system. this included a failure to take into account the social and cultural milieu in which the system would be used. There was an underestimation of the complexity the undertaking and insufficient appreciation of the length of training required by the hospital staff.

One of the most challenging features of many Hospital Information Systems is computerized physician order entry (CPOE). The intent of CPOE is to eliminate the wasteful hand-written (often illegible) doctor's orders that may need to be transcribed by nurses, pharmacists, and laboratory personnel before finally entered into the HIS. Having the physicians directly enter their orders into the HIS has been a long-awaited dream for many hospital administrators. In a fascinating report, patient mortality was shown to increase after implementation of CPOE. In this study, having CPOE was a strong, independent predictor of patient death. Somehow, a computerized service intended to enhance patient care had put patients at increased risk (1).

High-tech medical solutions seldom achieve the desired effect when implemented by low-tech medical staff. Introducing complex informatics services, such as CPOE, requires staff training. There needs to be effective communication between the clinical staff and the hospital IT staff and between the hospital IT staff and the HIS vendor staff. Everyone involved must cooperate until the implemented system is working smoothly. This is virtually impossible. Hospital personnel know that a wide range of standard practices (such as complex tests, tests using specialized imaging equipment, procedures that require patient preparation or transportation, timed-interval dosage administration, expert consultations, interventions that require close attending staff supervision) become very iffy on weekends, holidays, and after about 4:00 PM on weekdays. It is difficult to get shift workers to interface seamlessly with a computer system that never sleeps.

When it comes to hiding in the safe shadow of complexity, nobody does it better than software designers. They will take a problem, such as computer-aided diagnosis, or computer-aided medical decision-making, and produce a software application that purports to provide an answer. Your input is an x-ray or a series of lab tests and clinical finding, and out comes a diagnosis. We fool ourselves into thinking that the designers of complex software systems must understand how the system works. Not so. Computers allow us to design complex, interdependent, systems that are unpredictable and inherently chaotic.

Software failure is probably the most sensitive indicator of the limits of complexity. It is very easy to create software that works at a level of complexity beyond anything found in physical systems. The weakest programmers tend to fix bugs with layers of subroutines. Stronger programmers will simplify the problem and re-write their code, eliminating unnecessary subroutines. A 1995 report by the Standish group showed that most software projects sponsored by large companies are failures. Only 9% of such project are finished on time and within budget, and many of the finished projects do not meet the required performance specifications (2). Complexity is a plague on almost every area of science.

Probably the most famous medical software disaster involved the Therac-25 (3). Between 1985 and 1987, at least 6 patients received massive overdoses of radiation due to a software error in a radiation therapy device. A review of the incidents uncovered numerous errors in the engineering and in procedures for detecting and correcting softare problems.

Medical software errors are not rare. The FDA analyzed 3140 medical device recalls conducted between 1992 and 1998 reveals that 242 of them (7.7%) are attributable to software failures. Of those, 192 (or 79%) were caused by software changes made after the software's initial production and distribution (4).

[1] Han YY, Carcillo JA, Venkataraman ST, Clark RS, Watson RS, Nguyen TC, Bayir H, Orr RA. Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics 116:1506-1512, 2005.

[2] The Standish Group Report: Chaos. http://www.projectsmart.co.uk/docs/chaos-report.pdf, 1995.

[3] Leveson N. Medical Devices: The Therac-25. Appendix A in: Leveson N. Safeware: system safety and computers, Addison-Wesley, Reading, 1995.

[4] General Principles of Software Validation; Final Guidance for Industry and FDA Staff. January 11, 2002.

-- TO BE CONTINUED --

© 2010 Jules Berman

key words:informatics, complexity, jules j berman, medical history
My book, Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information was published in 2013 by Morgan Kaufmann.



I urge you to explore my book. Google books has prepared a generous preview of the book contents.