Issue No.04 - April (2006 vol.39)
Published by the IEEE Computer Society
Richard A. Schrenker , Massachusetts General Hospital
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MC.2006.139
Systems and software engineering contribute not only to advancing and improving the delivery of healthcare but also to doing it more safely than has been the case in the past.
Turning "To err is human, but to really screw up, you need a computer" on its head, in 1999 the Institute of Medicine's To Err Is Human: Building a Safer Health Care System recommended 1 that healthcare professionals focusing on patient safety should increase their understanding of how information technology could be applied to deliver safer care. This recommendation was made as part of the approach to reducing errors in the delivery of care leading to the death of as many as 98,000 US citizens annually.
Much of the subsequent response to that challenge has focused on increasing the capabilities of enterprise hospital and clinical information systems—for example, implementing order-entry systems to check for drug allergies when writing prescriptions. But IT and patient care also come together at the bedside in the medical equipment and instrumentation systems used to deliver direct patient care—for example, smart infusion pumps that help ensure that the right dose of the right drug is administered to the right patient.
The articles in this special issue will touch on both types of systems, while focusing primarily on the application of software and systems engineering to software-based medical devices and device systems used at the bedside.
Revisiting the Past
There is no free lunch, of course. That software brings risks of its own to healthcare technology was not news in 1999. Six years before To Err Is Human, Computer published an evaluation of the Therac-25 accidents in which Nancy Leveson and Clark Turner provided what retrospectively may be seen as a "warning shot" regarding the impact of software on medical technology. 2 Under "Lessons Learned," they quoted a medical physicist:
We have assumed … manufacturers have all kinds of safety design experience since they've been in the business a long time. We know that there are many safety codes, guides, and regulations to guide them and we have been reassured by the hitherto excellent record of these machines … Perhaps, though, we have been spoiled by this success.
The authors go on to note:
If we assign software error as the cause of the Therac-25 accidents, we are forced to conclude that the only way to prevent such accidents in the future is to build perfect software that will never behave in an unexpected or undesired way under any circumstances (which is clearly impossible) or not to use software at all in these types of systems.
They also note that "Although using good software engineering practices will not prevent all software errors, it is certainly required as a minimum" and that "Safety is a quality of the system in which the software is used; it is not a quality of the software itself."
These warnings echo in the enterprise domain as well. In "Some Unintended Consequences of Information Technology in Health Care: The Nature of Patient Care Information System-Related Errors," Joan Ash and colleagues cite examples of PCIS failures that led to decreased safety, the opposite intent of its design. 3 They recommend that "developers and vendors should be clearer about the limitations of their technologies."
That said, today's limitations may have been yesterday's advanced features. Given the increasing rate of change of technological innovation and its introduction into healthcare delivery, it is not surprising to find different vintages of similar systems simultaneously available in clinical practice. This in turn can lead to originally unanticipated user expectations being applied to older systems, potentially resulting in unintended consequences not only in their application but also for developers, as described in the " Healthcare Professionals' Perceptions of Medical Software and What to Do About It" sidebar by Phillip A. Laplante and coauthors.
A similar problem is reflected at the point of delivery of care, where an increasing number of medical devices are embedded systems with complexity and capabilities that exceed products from just a few years ago.
Providing care to any one patient is likely to require multiple devices, particularly for the more acutely ill. The instrumentation at an intensive care bedside will minimally include a physiologic monitoring system to acquire, process, communicate, display, and generate appropriate alarms for ECG, one or more blood pressure devices, and devices for monitoring oxygen saturation, cardiac output, respiration, and other key parameters. Other devices likely to be in use will include infusion pumps (smart or otherwise) and a ventilator. Equipment that can be brought in as needed includes dialysis systems and laboratory equipment such as automated blood and chemistry analyzers.
Some patients will need all of the above and perhaps more; others will present different needs. Assuring the readiness and availability of this equipment requires having a robust and reliable medical technology management system.
Responding to the demands of the patient care environment requires (among other things) hospital medical equipment inventories that are not only well-stocked—we currently manage more than 18,000 devices for our approximately 1,000-bed hospital—but fairly dynamic as well. New equipment—and new makes, types, and models of equipment—is added continuously, often replacing outdated equipment, but sometimes providing new functionality. Consequent human factors as well as technical and user training issues require ongoing monitoring and attention. None of this is terribly new, but the addition of software-based medical devices adds more wrinkles. Henry Petroski's 4 admonition is worth remembering:
Any design change … can introduce new failure modes or bring into play latent failure modes. Thus it follows that any design change, no matter how seemingly benign or beneficial, must be analyzed with the objectives of the original design in mind.
Managing software versions, installing patches, or placing devices on shared network infrastructures are examples of activities that are already introducing new sets of problems to the clinical environment, including some that have yet to manifest themselves.
Manufacturers, regulators—for example, the FDA—and medical equipment users all have played roles in the evolution of medical technology management systems that have brought us to this point. Viewing the process from 30,000 feet, manufacturers develop a device; regulators approve it for sale; and users buy, use, and maintain it. But it is not clear whether this model will remain sustainable going forward, as clinical demands driving technological responses appear to point to the need for a less linear and more collaborative process among the involved parties. For example, currently there is little in the way of standards-based interoperability among medical devices, even in the presence of ongoing efforts like IEEE 11073, which date back to the early 1990s.
Why these efforts have yet to succeed is not fully clear even to those of us who have been involved. However, over the past few years, a movement has started to take shape that is characterized not only by increased collaboration, but also by users taking a more active role in establishing the vision for future systems and deriving the requirements to which manufacturers and regulators need to respond.
Active efforts following this model include the creation of the American College of Clinical Engineering-sponsored Domain for Patient Care Devices within the Integrating the Healthcare Enterprise Initiative (IHE PCD), 5 in which the collaborators include clinicians, engineers, and informaticists from healthcare providers as well as federal regulatory staff, manufacturers, and standards experts. Another derives from work started in the Massachusetts General Hospital's Operating Room of the Future 6 and is described by Julian Goldman and coauthors in their " The Medical Device 'Plug-and-Play' (MD PnP) Interoperability Program " sidebar.
Broad Vision, National Agenda
Much like the fable of the blind men describing an elephant, our perception of the scope of the application of information technology to healthcare is largely influenced by where we encounter the system. Virtually all of us can relate to issues associated with medical data records management, making it easier to appreciate the Institute of Medicine's recommendations for enterprise-level and larger information systems. Although less visible to the public, visions are beginning to take shape that are also national in scope but more focused on technologies used in the direct provision of care.
In "High-Confidence Medical Device Software and Systems," Insup Lee and colleagues describe a national collaborative effort involving academics and professionals working together to identify and address the critical issues presented by the emergence of intelligent clinical technologies.
Vision meets reality
Moving from vision to product requires not only attention to good software engineering practices and awareness of the regulatory environment, but also a grounding in fundamental risk management principles. Steven R. Rakitin explores all three in "Coping with Defective Software in Medical Devices."
Reality meets New Age: How can we not use agile methods?
In "IGSTK: An Open Source Software Toolkit for Image-Guided Surgery," Kevin Gary and colleagues start with a description of the critical requirements posed by the needs of image-guided surgery that, when coupled with the resources available to his team, result in daunting development constraints. The authors describe the development and application of a mixture of classical and agile tools and methods in support of their clinical application.
Wireless changes everything
In many institutions, it once was easy to partition medical and nonmedical networked devices by installing them on physically distinct wired networks. That degree of control effectively came to an end with the introduction of wireless medical device networks. In "Ensuring Patient Safety in Wireless Medical Device Networks," Vijay Gehlot and Elliot B. Sloane provide an insightful view into the risks, details, and nuances of placing such a system into service. They also examine the subtleties driving the need for hospital-based clinical engineering involvement in system verification and validation.
Everything Changes FDA
Cognizant of issues like the ones that challenged Gary's team, regulators are faced with determining how to respond to issues that emerge with the rapid evolution of software-based medical devices. In "A Formal Methods Approach to Medical Device Review," Raoul Jetley and colleagues describe a set of formal approaches for application test and validation during the premarket approval process or when doing a forensic analysis of problems that occur after a device has been delivered to the market.
Indeed, to err is human. But it does not follow that harm cannot be prevented. Systems and software engineering contribute not only to advancing and improving the delivery of care but also to doing it more safely than has been the case in the past. Doing so appears likely to require greater collaboration between manufacturers, regulators, and users in the future. And it is happening.
But more needs to be done, and soon. While the work that the IHE and MD PnP are doing makes many of us hopeful that interoperable medical device systems will soon begin to be realized, hard questions need to be asked, such as, Why did IEEE 11073 move so slowly? What more needs to happen for its vision to be realized in the market? What could we do differently to avoid similar inertia when tackling future systems and software engineering problems?
The involvement of experts from outside the medical technology domain could prove valuable. For example, researchers might be better positioned to help us more rigorously address emerging issues such as whether medical device networks should merge with hospital or other clinical information systems networks. And, jumping even further outside the box, consideration needs to be given to how healthcare-based engineers, caregivers, and technologists can become even more engaged in technology definition, development, and design decisions and activities, to, for example, address human factors issues that will likely increase with device and system complexity.
Medicine remains fundamentally reactive; we wonder how it can be otherwise. A person can do everything possible to remain healthy, but sooner or later, if an accident doesn't strike, illness will. When this occurs, clinicians attending to the patient remain driven by the basic principle, "First, do no harm," and they expect that the tools they use will not permit their violating that principle.
To address patient safety in the face of the perturbations that arise from human error as well as other sources, proactive systems and software engineering attention must increasingly focus on continuously creating robust, reliable, and dependable applications and an infrastructure focused on addressing needs at the point of delivery of care.
I thank Bob Colwell for encouraging me to serve as guest editor for this special issue and Scott Hamilton for patiently shepherding me through the process. I received appreciated feedback on this editorial from my colleagues Mike Cusack, Luis Melendez, and Jason Davis. The work and guidance of my colleague, patient-safety expert Jeff Cooper, has inspired my interest in relating software, systems, and clinical engineering around safety. Last and most, I want to jump outside the engineering box to thank my father, Dick Schrenker, for inspiring me to put first things first in whatever I do. Hence, the theme not just of this editorial but the application of technology wherever it touches medicine: When it comes to what engineering brings to healthcare, safety comes first.
Richard A. Schrenker manages the Systems Engineering Group in the Department of Biomedical Engineering at Massachusetts General Hospital. He received an MS in electrical engineering from Johns Hopkins University. Schrenker is a member of the IEEE EMBS and Computer Societies, the American College of Clinical Engineering, the ACM, and the Association for the Advancement of Medical Instrumentation, and is a cofounder and Life Member of the Baltimore Medical Engineers and Technicians Society. He is active in IEEE 11073, IHE PCD, and MD PnP development efforts. Contact him at firstname.lastname@example.org.