faliur of automation, interaction, complexity, and failure

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.



This easy presents an example of failed information systems. The software failure is described, explored and analyzed in case form. The experienced and lesson learnt from this failure is used to make future decision and to avoid pitfalls by programmers and developers. Organizational poor needs assessment before and after system implementation and deficiencies in information technology infrastructure is highlighted. This easy essay will also describe the breakdown of the system, cause of the failures and some conclusion as to how the system could have best be managed. Professional information technology practitioners and project managers are the beneficiary because they will avoid such pitfalls and share experience from this case study.

Information systems professionals and students can learn best from the real-life experiences of others. An effective means for conveying these experiences and lessons learned is through case studies. Although proponents of advanced information technology argue that automation can improve the reliability of health care delivery, the results of introducing new technology into complex systems are mixed. We present a case study of such an emergent, unforeseen failure and use it to illustrate some of the problems facing designers of applications in health care. The title of the case study is “Automation, Interaction, Complexity, and Failure” by Robert L Wears and Richard I Cook.


With the advent of information technology (IT) and the world being a global village there is a high demand for digital and mobile technology in the world today where as, software advancement is the core to this development. <- a tricky sentence The wide of spread of computer networks and advancement in IT is continually making radical changes to our organizations and institutions. Institutions and Organisation spend a lot of money and resources to set up systems. The complexity of these systems and lack of customer support leads to frequent failures especially in instances where the system is outsourced and internally there is lack of skilled manpower towards that field. Some of the system failures are also caused by hardware failures. Continuous demand for more advance hardware and operating system has a direct effect in software upgrade. In such scenarios, in case system platform is not improved then, there is bound to failures. Application systems are complex and expensive to programme, and many skilled programmers are involved with the design both within the organisation or outsourced. Majority of organisation world over often outsource software built precisely as per requirements of the organisation. Therefore, the client organisation must do feasibility and needs assessment, in order to be very clear as to what system needs are, and the in-house software analysts needs to carryout viability, impact, risks and failure assessment resulting on implementation of such software.

The failure of a software system in an organization remains a major concern because of the cost involved. In a competitive world where organization are limited in budgetary allocation and funding are even withdrawn or reviewed IT system no longer deliver automatic benefits into the organization. According to report of five different surveys concluded that; an IT system is more likely to be unsuccessful than successful, about 1 out of 5 IT system is likely to bring full satisfaction, the larger the system the more likely the failure and 40 % of the system failed to achieve their business case within one year of going live (Nauman et al.). Heeks conducted an investigation of e-government projects in developing countries. The results of his survey show an extremely disappointing position: 35% projects are total failures, 50% projects are partial failures and 15% projects are successes. Good stats. 1.5 line spacing good.


A critically ill patient presented to a busy emergency department (ED) serving a large urban, indigent population. Intravenous access was obtained and a variety of pharmacologic agents were ordered. The resuscitation nurse went to obtain medications from an automated dispensing unit (ADU), part of a computer-based dispensing system in use throughout the hospital. He found an uninformative error message on the computer screen (“Printer not available”) and an unresponsive keyboard. The system did not respond to any commands and would not dispense the required medications. The ED nurse abandoned efforts to get the ADU to work and asked the unit clerk to notify the main pharmacy that the ADU was “down” and emergency medications were needed. He asked another nurse to try other ADUs in the ED. Other ED staff became aware of the problem and joined in the search for the sought after drugs. Some were discovered on top of another ADU in the ED, waiting to be returned to stock. Anticipating the patient's clinical deterioration, the ED physicians opened the resuscitation cart (“crash cart”) and prepared to intubate the patient, using the medications and equipment stored there. A pharmacist came to the ED and examined the unresponsive ADU. He decided not to use the bypass facility for downtime access because neither the drawers nor the bins were labelled with the names of the medications they contained, and this information could not be obtained from a non-functioning unit. Instead, he arranged for the pharmacy staff to use runners to bring medications from the main pharmacy, one floor below, to the ED in response to telephone requests. The patient eventually received the requested medications; her condition improved; she survived and was later discharged from the hospital.

A series of interviews with the ED staff, pharmacists, computer specialists and the ADU manufacturer's representative enabled a reconstruction of the complex sequence of events leading to this incident. The hospital had installed a popular computer-controlled automated dispensing system for drugs and supplies in 1994 to improve inventory tracking and reduce errors and pilferage, especially of controlled substances. The system was regarded as mature and reliable, and had been regularly upgraded. Other than a limited number of resuscitation drugs stored in “crash carts”, all hospital medications were dispensed via this system. At the time of this incident, there were 40 ADUs linked to two centrally located computers by a general-purpose computer network that provided connectivity to the hospital information system (HIS).

To enhance safety within the hospital, the ADUs were programmed to deny access to a drug unless there was a current, valid, pharmacist-approved order for it in the HIS pharmacy subsystem. This safety feature was implemented by a software interlock mechanism between the HIS, the pharmacy computer, and the ADUs. When a user attempted to retrieve a drug for a patient from the dispensing unit, the ADU would query the HIS via the pharmacy computers and provide the medication only if a validated order could be found in the HIS. This feature was not activated in the ED because of the time constraints associated with ED drug orders and delivery.

About two weeks prior to the incident, the hospital began a major HIS software upgrade that was complicated by a sudden, unexpected hardware failure resulting in the complete loss of all HIS functions. In response, operators in the pharmacy disabled the safety interlock feature that required order checking before dispensing medications so that nursing staff on the wards could obtain drugs. As the HIS came back online, the pharmacy operators enabled this feature in order to restore normal operations. However, the HIS crashed repeatedly during this process, prompting the pharmacy operators to disable the safety interlock feature again.

The procedure for enabling and disabling the safety interlock feature entailed dialog between the pharmacy central computer and the ADU computers, which was conducted for each item in the inventory of each dispensing unit. When this procedure was started on the day of this incident, it unexpectedly created a storm of messages to and from the dispensing units. This message storm slowed the system response such that the individual units appeared to be unresponsive to keyboard commands from users. The pharmacy operators monitoring the system initially thought that network communication problems were causing the outage, but gradually came to realize that the network was functioning normally but that the ADUs were overwhelmed with messages. This phenomenon was essentially similar to denial-of-service attacks that have occurred on the internet (CERT Coordination Center 2001); the ADUs were unavailable to the users because they were busy with a large number of messages. Eventually most of the ADUs appeared to resume normal operation. The operators had assumed that ED units would not be affected by this procedure because they did not use the order checking feature. The specific reasons for the message storm, and for why the ED unit did not resume normal operation could not be determined, leaving a residual and unremovable mystery about the system.


There are a number of issues which could have contributed this mess at the ED. The technical aspect of the ADU system was not well documented and staffs were not well trained on the technical aspect incase eventuality like the one in question. Alternative means of dispensing drugs incase there is such breakdowns was also not put in place. Given the number of modules and complexity of the system i.e. ADU and HIS interlock, contributed to the system breakdown. In such a system with short-lived failures there is need to put in place alternative means of dispensing drugs. Other option is to work out modality through which the interlink failures does affect ADU or HIS.

Since this system was outsourced this meant that computer specialist was not trained on the upgraded system. Adding ADU onto the already exist system i.e. HIS meant that there was a lot of changes warranting change in operational procedures. The organization might have ignored the following that is why there was a system failure:

Risk assessment: The organization should have carried out risk assessment in order to identify the risk involved in setting up such a system. Incase of system outages there should be an option like a backup in dispensing drugs. Apart from resuscitation cases which required emergency attention others which also deserved emergencies didn't have any. The crash cart system should have carted for all cases irrespective of whether it is time critical or not. So that incase of system breakdown then dispensing can be done out rightly and timely. Planners should have come up scenario which could have given them the idea of different drug administration which would require critical time management.

Inadequate analysis: Upgraded system which had interlink between ADU and HIS was not understood in early stages. The constraints and queries arising between the modules were not explained to the user. That is why pharmacy users disabled interlock feature that required order checking before dispensing medication. Otherwise if they were trained on the implication of such interlock feature they wouldn't have disabled it. The HIS - ADU system was intentionally limited to certain parts of the hospital, but “spilled over” to involve ADUs in the ED, which never were part of the HIS - ADU axis. This, and the co-residence of all these systems on a common Ethernet backbone, was a source on inapparent ? coupling. By virtue of increased “coupling” between components of the system, automation generates opportunities for a complex systems failure, a “normal accident” (Cook and Woods 1994; Perrow 1999).

Lack of internal staff involved in programming: Even though the internal staff were interviewed and probed on the manual procedure of administration and dispensing drugs this doesn't directly translate into automation procedure. The computer specialist should have been involved in the design and technical aspect of the ADU system. wrong expectations of a new system / no-one understands the system. Previous sentence not clear There is lack of awareness and knowledge in design and engineering that might be applied to health care problems. Thus, health institutions managers rely on existing internal staff without expertise in the new technology and risk assessment. From the context of the case study the managers knew what they want from the system but they didn't understand the technology.

Lack of teamwork: Computer specialist must be able to co-ordinate all the system involve in the patient care system i.e. HIS-ADU axis and help everyone understand the benefit of the system. Since the pharmacist and the nurses were not given proper guidance on handling techniques and operational procedures, at the initial stage this led to failure of the system.

Lack of professional standards: In this case study there is no mention of a user and technical manual which can be used as a reference by the hospital staff incase there is a breakdown. All systems need clear documentation that all users can understand not just one that can be understood by IT literate person.


Hospital health automation has its advantages which outweigh disadvantages; in the long run the implementation increases the efficiency of the operation and safety of the patient. The risks and failures experienced during implementation of this system demonstrate vulnerabilities of patient care systems. Emerging failures arising from independent system which are interlinked through live online queries seem almost impossible to foresee at the initial stage. Health care based systems are characterized by these risk and uncertainty because: a) High level of user satisfaction not being met. The user might not accept the system yet the management insists on the use of the system. b) Objective of the system specified at the analysis stage has not been met. Monitoring and evaluation of the system not implemented. c) There is no appropriate nature of use i.e. Lack of training of end users. d) Lack of proper institutionalization of the system. e) Inadequate hardware resources required by the HIS and ADU. The information about the system failures and causes of these provides valuable lessons and affirmation of quality practices. These concern development procedures, assurance practices during programming & implementation practices, and testing and piloting strategies. Methods to prevent and detect faults should be determined in earnest. Attention must be given to the details of logical operations, such as verifying that the correct algorithm has been specified in the first place. A good concluding section. 4%


The system should have allowed for after entry queries between ADU and HIS instead of online. This will allow for running of ADU even when HIS interlink is disabled. Alternatively, all drugs should be available in the crash cart to carter for period when the systems are down. Expedite on the technical and user operational manual and make them available to the hospital staff.