Towards Ultra Reliable Medical Systems

With today's conventional system development techniques, as size and complexity increase so does the probability that a system, when introduced into operation, cannot be trusted. This is despite an inordinate amount of testing and evaluation. And when a system works, the cost of attaining such a state is often needlessly high. The predictable result is wasted dollars, lost time and missed deadlines. For many systems, coping with events that cannot be entirely predicted is vital to effective real-time system performance. The uncertainty of actual environmental conditions at the moment of truth can present challenges to operational reliability that border on the impossible. Such was the case with the Therac 25 radiation therapy environment [I , 21. As a result of hardware, software and humanware system defects and defects in integrating these systems during development and in real time, people unnecessarily lost their lives. These incidents are a cruel reminder that "One small break in the chain of care can have grave consequences" [3]. For a medical environment, whether it be one with direct or indirect human involvement, a technology which reverses these trends is needed to develop ultra-reliable systems. Ideally, a system that is ultra-reliable has zero defects. Zero-defect systems are theoretically possible, but difficult, to achieve. There are today, however, substantial numbers of errors which exist, or potentially exist, in developed systems or systems to be developed which can be eliminated. This can be accomplished by using a combination of common sense and advanced modeling, simulation and software development techniques. Properties of Zero-Defect Systems A system is an assemblage of objects united by some form of regular interaction or interdependence. It could consist of hardware, software or humanware objects; or, it could be a combination of any of these. Thus, a person, a computer, a software program or the integration of these objects is a system. A zero-defect system is defined in terms of properties about the system (e.g., its developmental states of existence such as a definition or an implementation, each of which is an evolving input object to the system which develops it) and in terms of properties of the system for its operational states of existence. A zero-defect system is one which is reliable in both a formal and practical sense. A formal system is consistent and logically complete; it has no interface errors (or ambiguities). Apractical system is developed on time and it is affordable to bdild and operate; it works. A system which works will handle the unpredictable, both as a system being developed and as a system being operated, it satisfies the developer's intent; it satisfies the user's intent; it always gets the right answer at the right time and in the right place; it is efficient to operate in time and in space. To handle the unpredictable, a system, during its own development, will handle changing development requirements without affecting unintended areas; it will handle change and the unexpected during its operation. This includes having the ability to reconfigure in real-time, detect errors and recover from them and the ability to be simulated in, operate in, respond to and interface with a distributed, asynchronous, real-time environment. An affordable system has properties which prevent errors from being created in the future. It is portable, flexible, understandable and repeatable; its development requires minimum people time and minimum calendar time. A porrubfe system can be implemented in or operational in different, changing and diverse parallel environments; it can exist in different, changing, diverse, secure and multi-layers of abstraction; it allows for the plug-in or reconfiguration of different modules, or parts of modules, for those objects which can vary in functionality from state to state; it has the ability to be used by various applications and execute on various operational environments (e.g., human, robot and computer environments). Aflexible system has the ability for its definition to be changed from many olbjects to one (providing for abstraction, integraticn and applicative operators) or from one object to many (providing for decomposition, modularity and computability), as necessary both during its developmental and operational states. For a system to be understandable, one is able to define the integration of all of its objects; trace it and any object in that system (including its behavior and its structure), throughout each phase of development (and from one phase to the next; define it to be as simple as possible, but not simpler; define it in such a way that it naturally corresponds to the real world of which it is a model; communicate it with a common semantics to all entities including all levels of users, all levels of developers, all levels of managers and all levels of computing facilities and their respective environments; and one k able to define it with "friendly" definitions (where "friendly" is a relative term with respect to each kind of user), using variable, user sebxted syntaxes, relating to and being derived from a common semantic base, and capitalizing on the ability to hide unnecessary detail. A repeatuble , or reusable, system is defined with mechanisms which inherently facilitiate the process of standardization ani1 the ability to define and use more abstract and common mechanisms, all of which by thleir very nature support functionally natural modularity (e.g., mechanisms are "dumb" in that they are not aware of nor do they need to be aware of their context of use or their implementations and an object always exists as an integrated entity with respect to structure, behavior and properties of control); to be repeatalile a system must inherently provide properties for mechanization (and thus the automation) of its own development processes. Philosophy A zero-defect system begins with a set of reliable thoughts which result in a reliable model. A model is a tentative definition of a system or theory that accounts for all of its known properties [4 1. A model could be defined for just about anything: an airplane, building an airplane, fl!ying an airplane, eating a sandwich, a missile sys tem, planning your day's activities, a patient, a doctor, the process of providing radiation treatment to a patient, a radiation machine 01' the process of building a radiation machine. A model can be simulated with software. A simulation is the "running", exercising, testing or execution of a imodel. A software simulation is the set of instruclions (software) which "runs" a simulation on a particular computer. Once a reliable model is defined (or an unreliable model is redefined to be reliable) a software implementation consistent witt, the model (i.e., a reliable simulation of the model) is developed. The next step is to build the real system (e.g., a machine if the system is a hardware system). If the real system to be developed is a software system, this step may not be necessary, since a software system already exists as a result of implementing the model. The responsibility for developing a rcliable system resides with the user and the developer. The user is responsible for knowing wha he wants; the developer is responsible for communicating the user wishes to the computing environment. The ideal modeling environment begins with reliable building blocks. To build a reliable system, only reliable systems are used as building blocks and only reliable mechanisms (systems, themselves) are used to integrate these building blocks. Each new syst:m, constructed from only reliable systems, is then used along with the more primitive systems to build new, larger and more comprehensive reliable systems. The philosophy that reliable systems are defined in terms of reliable systems; is applied in a more global sense in the managerr ent