chore: add 7 8 9
This commit is contained in:
parent
cbb5561fc6
commit
48e35621ed
GPG Key ID:
8B3B0604F164E04F
633
chapter07.raw
Normal file
633
chapter07.raw
Normal file
@ -0,0 +1,633 @@
|
||||
chapter 7. Fundamentals.
|
||||
All the parts of the process described in the following chapters start from the same
|
||||
fundamental system engineering activities. These include defining, for the system
|
||||
involved, accidents or losses, hazards, safety requirements and constraints, and the
|
||||
safety control structure.
|
||||
|
||||
section 7.1.
|
||||
Defining Accidents and Unacceptable Losses.
|
||||
The first step in any safety effort involves agreeing on the types of accidents or
|
||||
losses to be considered.
|
||||
In general, the definition of an accident comes from the customer and occasion-
|
||||
ally from the government for systems that are regulated by government agencies.
|
||||
Other sources might be user groups, insurance companies, professional societies,
|
||||
industry standards, and other stakeholders. If the company or group developing the
|
||||
system is free to build whatever they want, then considerations of liability and the
|
||||
cost of accidents will come into play.
|
||||
Definitions of basic terms differ greatly among industries and engineering disci-
|
||||
plines. A set of basic definitions is used in this book (see appendix A) that reflect
|
||||
common usage in System Safety. An accident is defined as:
|
||||
Accident: An undesired or unplanned event that results in a loss, including loss
|
||||
of human life or human injury, property damage, environmental pollution,
|
||||
mission loss, etc.
|
||||
An accident need not involve loss of life, but it does result in some loss that is unac-
|
||||
ceptable to the stakeholders. System Safety has always considered non-human
|
||||
losses, but for some reason, many other approaches to safety engineering have
|
||||
limited the definition of a loss to human death or injury. As an example of an
|
||||
inclusive definition, a spacecraft accident might include loss of the astronauts (if
|
||||
the spacecraft is manned), death or injury to support personnel or the public, non-
|
||||
accomplishment of the mission, major equipment damage (such as damage to launch
|
||||
|
||||
|
||||
facilities), environmental pollution of planets, and so on. An accident definition used
|
||||
in the design of an explorer spacecraft to characterize the icy moon of a planet in
|
||||
the Earth’s solar system, for example, was [151]:
|
||||
A1. Humans or human assets on earth are killed or damaged.
|
||||
A2. Humans or human assets off of the earth are killed or damaged.
|
||||
A3. Organisms on any of the moons of the outer planet (if they exist) are killed
|
||||
or mutated by biological agents of Earth origin.
|
||||
Rationale: Contamination of an icy outer planet moon with biological agents
|
||||
of Earth origin could have catastrophically adverse effects on any biological
|
||||
agents indigenous to the icy outer planet moon.
|
||||
A4. The scientific data corresponding to the mission goals is not collected.
|
||||
A5. The scientific data corresponding to the mission goals is rendered unusable
|
||||
(i.e., deleted or corrupted) before it can be fully investigated.
|
||||
A6. Organisms of Earth origin are mistaken for organisms indigenous to any of
|
||||
the moons of the outer planet in future missions to study the outer planet’s
|
||||
moon.
|
||||
Rationale: Contamination of a moon of an outer planet with biological
|
||||
agents of Earth origin could lead to a situation in which a future mission
|
||||
discovers the biological agents and falsely concludes that they are indige-
|
||||
nous to the moon of the outer planet.
|
||||
A7. An incident during this mission directly causes another mission to fail
|
||||
to collect, return, or use the scientific data corresponding to its mission
|
||||
goals.
|
||||
Rationale: It is possible for this mission to interfere with the completion of
|
||||
other missions through denying the other missions access to the space
|
||||
exploration infrastructure (for example, overuse of limited Deep Space
|
||||
Network1 (DSN) resources, causing another mission to miss its launch
|
||||
window because of damage to the launch pad during this mission, etc.)
|
||||
|
||||
footnote. The Deep Space Network is an international network of large antennas and communication facilities
|
||||
that supports interplanetary spacecraft missions and radio and radar astronomy observations for
|
||||
the exploration of the solar system and the universe. The network also supports some Earth-orbiting
|
||||
missions.
|
||||
|
||||
Prioritizing or assigning a level of severity to the identified losses may be useful
|
||||
when tradeoffs among goals are required in the design process. As an example,
|
||||
consider an industrial robot to service the thermal tiles on the Space Shuttle, which
|
||||
|
||||
|
||||
is used as an example in chapter 9. The goals for the robot are (1) to inspect the
|
||||
thermal tiles for damage caused during launch, reentry, and transport of a Space
|
||||
Shuttle and (2) to apply waterproofing chemicals to the thermal tiles.
|
||||
Level 1:
|
||||
A1.1: Loss of the orbiter and crew. (e.g., inadequate thermal protection)
|
||||
A1.2: Loss of life or serious injury in the processing facility.
|
||||
Level 2:
|
||||
A2.1: Damage to the orbiter or to objects in the processing facility that results.
|
||||
in the delay of a launch or in a loss of greater than x dollars.
|
||||
A2.2: Injury to humans requiring hospitalization or medical attention and
|
||||
leading to long-term or permanent physical effects.
|
||||
Level 3:
|
||||
A3.1: Minor human injury. (does not require medical attention or requires only
|
||||
minimal intervention and does not lead to long-term or permanent physical
|
||||
effects)
|
||||
A3.2: Damage to orbiter that does not delay launch and results in a loss of less
|
||||
than x dollars.
|
||||
A3.3: Damage to objects in the processing facility (both on the floor or sus-
|
||||
pended) that does not result in delay of a launch or a loss of greater than x
|
||||
dollars.
|
||||
A3.4: Damage to the mobile robot.
|
||||
Assumption: It is assumed that there is a backup plan in place for servicing
|
||||
the orbiter thermal tiles in case the tile processing robot has a mechanical
|
||||
failure and that the same backup measures can be used in the event the
|
||||
robot is out of commission due to other reasons.
|
||||
The customer may also have a safety policy that must be followed by the contractor
|
||||
or those designing the thermal tile servicing robot. As an example, the following is
|
||||
similar to a typical NASA safety policy:
|
||||
General Safety Policy: All hazards related to human injury or damage to the
|
||||
orbiter must be eliminated or mitigated by the system design. A reasonable
|
||||
effort must be made to eliminate or mitigate hazards resulting at most in
|
||||
damage to the robot or objects in the work area. For any hazards that cannot
|
||||
be eliminated, the hazard analysis as well as the design features and develop-
|
||||
ment procedures, including any tradeoff studies, must be documented and
|
||||
presented to the customer for acceptance.
|
||||
|
||||
|
||||
One (but only one) of the controls used to avoid this type of accident is an air-
|
||||
borne collision avoidance system like TCAS (Traffic alert and Collision Avoidance
|
||||
System), which is now required on most commercial aircraft. While the goal of TCAS
|
||||
is increased safety, TCAS itself introduces new hazards associated with its use. Some
|
||||
hazards that were considered during the design of TCAS are:
|
||||
H1. TCAS causes or contributes to a near midair collision (NMAC), defined as
|
||||
a pair of controlled aircraft violating minimum separation standards.
|
||||
H2. TCAS causes or contributes to a controlled maneuver into the ground.
|
||||
H3. TCAS causes or contributes to the pilot losing control over the aircraft.
|
||||
H4. TCAS interferes with other safety-related aircraft systems.
|
||||
H5. TCAS interferes with the ground-based Air Traffic Control system (e.g.,
|
||||
transponder transmissions to the ground or radar or radio services).
|
||||
H6. TCAS interferes with an ATC advisory that is safety-related (e.g., avoiding
|
||||
a restricted area or adverse weather conditions).
|
||||
Ground-based air traffic control also plays an important role in collision avoidance,
|
||||
although it has responsibility for a larger and different set of hazards:
|
||||
H1. Controlled aircraft violate minimum separation standards (NMAC).
|
||||
H2. An airborne controlled aircraft enters an unsafe atmospheric region.
|
||||
H3. A controlled airborne aircraft enters restricted airspace without author-
|
||||
ization.
|
||||
H4. A controlled airborne aircraft gets too close to a fixed obstacle other than a
|
||||
safe point of touchdown on assigned runway (known as controlled flight into
|
||||
terrain or CFIT).
|
||||
H5. A controlled airborne aircraft and an intruder in controlled airspace violate
|
||||
minimum separation.
|
||||
H6. Loss of controlled flight or loss of airframe integrity.
|
||||
H7. An aircraft on the ground comes too close to moving objects or collides with
|
||||
stationary objects or leaves the paved area.
|
||||
H8. An aircraft enters a runway for which it does not have a clearance (called
|
||||
runway incursion).
|
||||
Unsafe behavior (hazards) at the system level can be mapped into hazardous
|
||||
behaviors at the component or subsystem level. Note, however, that the reverse
|
||||
(bottom-up) process is not possible, that is, it is not possible to identify the system-
|
||||
level hazards by looking only at individual component behavior. Safety is a system
|
||||
property, not a component property. Consider an automated door system. One
|
||||
|
||||
|
||||
reasonable hazard when considering the door alone is the door closing on someone.
|
||||
The associated safety constraint is that the door must not close on anyone in the
|
||||
doorway. This hazard is relevant if the door system is used in any environment. If
|
||||
the door is in a building, another important hazard is not being able to get out of a
|
||||
dangerous environment, for example, if the building is on fire. Therefore, a reason-
|
||||
able design constraint would be that the door opens whenever a door open request
|
||||
is received. But if the door is used on a moving train, an additional hazard must
|
||||
be considered, namely, the door opening while the train is moving and between
|
||||
stations. In a moving train, different safety design constraints would apply compared
|
||||
to an automated door system in a building. Hazard identification is a top-down
|
||||
process that must consider the encompassing system and its hazards and potential
|
||||
accidents.
|
||||
Let’s assume that the automated door system is part of a train control system.
|
||||
The system-level train hazards related to train doors include a person being hit by
|
||||
closing doors, someone falling from a moving train or from a stationary train that
|
||||
is not properly aligned with a station platform, and passengers and staff being unable
|
||||
to escape from a dangerous environment in the train compartment. Tracing these
|
||||
system hazards into the related hazardous behavior of the automated door compo-
|
||||
nent of the train results in the following hazards:
|
||||
1. Door is open when the train starts.
|
||||
2. Door opens while train is in motion.
|
||||
3. Door opens while not properly aligned with station platform.
|
||||
4. Door closes while someone is in the doorway.
|
||||
5. Door that closes on an obstruction does not reopen or reopened door does
|
||||
not reclose.
|
||||
6. Doors cannot be opened for emergency evacuation between stations.
|
||||
The designers of the train door controller would design to control these hazards.
|
||||
Note that constraints 3 and 6 are conflicting, and the designers will have to reconcile
|
||||
such conflicts. In general, attempts should first be made to eliminate hazards at
|
||||
the system level. If they cannot be eliminated or adequately controlled at the
|
||||
system level, then they must be refined into hazards to be handled by the system
|
||||
components.
|
||||
Unfortunately, no tools exist for identifying hazards. It takes domain expertise
|
||||
and depends on subjective evaluation by those constructing the system. Chapter 13
|
||||
in Safeware provides some common heuristics that may be helpful in the process.
|
||||
The good news is that identifying hazards is usually not a difficult process. The later
|
||||
steps in the hazard analysis process are where most of the mistakes and effort occurs.
|
||||
|
||||
|
||||
There is also no right or wrong set of hazards, only a set that the system stake-
|
||||
holders agree is important to avoid. Some government agencies have mandated the
|
||||
hazards they want considered for the systems they regulate or certify. For example,
|
||||
the U.S. Department of Defense requires that producers of nuclear weapons
|
||||
consider four hazards:
|
||||
1. Weapons involved in accident or incidents, or jettisoned weapons, produce a
|
||||
nuclear yield.
|
||||
2. Nuclear weapons are deliberately prearmed, armed, launched, fired, or released
|
||||
without execution of emergency war orders or without being directed to do so
|
||||
by a competent authority.
|
||||
3. Nuclear weapons are inadvertently prearmed, armed, launched, fired, or
|
||||
released.
|
||||
4. Inadequate security is applied to nuclear weapons.
|
||||
Sometimes user or professional associations define the hazards for the systems they
|
||||
use and that they want developers to eliminate or control. In most systems, however,
|
||||
the hazards to be considered are up to the developer and their customer(s).
|
||||
section 7.3.
|
||||
System Safety Requirements and Constraints.
|
||||
After the system and component hazards have been identified, the next major goal
|
||||
is to specify the system-level safety requirements and design constraints necessary
|
||||
to prevent the hazards from occurring. These constraints will be used to guide the
|
||||
system design and tradeoff analyses.
|
||||
The system-level constraints are refined and allocated to each component during
|
||||
the system engineering decomposition process. The process then iterates over the
|
||||
individual components as they are refined (and perhaps further decomposed) and
|
||||
as design decisions are made.
|
||||
Figure 7.1 shows an example of the design constraints that might be generated
|
||||
from the automated train door hazards. Again, note that the third constraint poten-
|
||||
tially conflicts with the last one and the resolution of this conflict will be an impor-
|
||||
tant part of the system design process. Identifying these types of conflicts early in
|
||||
the design process will lead to better solutions. Choices may be more limited later
|
||||
on when it may not be possible or practical to change the early decisions.
|
||||
As the design process progresses and design decisions are made, the safety
|
||||
requirements and constraints are further refined and expanded. For example, a
|
||||
safety constraint on TCAS is that it must not interfere with the ground-based air
|
||||
traffic control system. Later in the process, this constraint will be refined into more
|
||||
detailed constraints on the ways this interference might occur. Examples include
|
||||
|
||||
|
||||
constraints on TCAS design to limit interference with ground-based surveillance
|
||||
radar, with distance-measuring equipment channels, and with radio services. Addi-
|
||||
tional constraints include how TCAS can process and transmit information (see
|
||||
chapter 10).
|
||||
Figure 7.2 shows the high-level requirements and constraints for some of the air
|
||||
traffic control hazards identified above. Comparing the ATC high-level constraints
|
||||
with the TCAS high-level constraints (figure 7.3) is instructive. Ground-based air
|
||||
traffic control has additional requirements and constraints related to aspects of the
|
||||
collision problem that TCAS cannot handle alone, as well as other hazards and
|
||||
potential aircraft accidents that it must control.
|
||||
Some constraints on the two system components (ATC and TCAS) are closely
|
||||
related, such as the requirement to provide advisories that maintain safe separation
|
||||
between aircraft. This example of overlapping control raises important concerns
|
||||
about potential conflicts and coordination problems that need to be resolved. As
|
||||
noted in section 4.5, accidents often occur in the boundary areas between controllers
|
||||
and when multiple controllers control the same process. The inadequate resolution
|
||||
of the conflict between multiple controller responsibilities for aircraft separation
|
||||
contributed to the collision of two aircraft over the town of Überlingen (Germany)
|
||||
|
||||
|
||||
in July 2002 when TCAS and the ground air traffic controller provided conflicting
|
||||
advisories to the pilots. Potentially conflicting responsibilities must be carefully
|
||||
handled in system design and operations and identifying such conflicts are part of
|
||||
the new hazard analysis technique described in chapter 8.
|
||||
Hazards related to the interaction among components, for example the inter-
|
||||
action between attempts by air traffic control and by TCAS to prevent collisions,
|
||||
need to be handled in the safety control structure design, perhaps by mandating
|
||||
how the pilot is to select between conflicting advisories. There may be considerations
|
||||
in handling these hazards in the subsystem design that will impact the behavior of
|
||||
multiple subsystems and therefore must be resolved at a higher level and passed to
|
||||
them as constraints on their behavior.
|
||||
|
||||
section 7.4.
|
||||
The Safety Control Structure.
|
||||
The safety requirements and constraints on the physical system design shown in
|
||||
section 7.3 act as input to the standard system engineering process and must be
|
||||
incorporated into the physical system design and safety control structure. An
|
||||
example of how they are used is provided in chapter 10.
|
||||
Additional system safety requirements and constraints, including those on opera-
|
||||
tions and maintenance or upgrades will be used in the design of the safety control
|
||||
structure at the organizational and social system levels above the physical system.
|
||||
There is no one correct safety control structure: what is practical and effective will
|
||||
depend greatly on cultural and other factors. Some general principles that apply to
|
||||
all safety control structures are described in chapter 13. These principles need to be
|
||||
combined with specific system safety requirements and constraints for the particular
|
||||
system involved to design the control structure.
|
||||
The process for engineering social systems is very similar to the regular system
|
||||
engineering process and starts, like any system engineering project, with identifying
|
||||
system requirements and constraints. The responsibility for implementing each
|
||||
requirement needs to be assigned to the components of the control structure, along
|
||||
with requisite authority and accountability, as in any management system; controls
|
||||
must be designed to ensure that the responsibilities can be carried out; and feedback
|
||||
loops created to assist the controller in maintaining accurate process models.
|
||||
|
||||
section 7.4.1. The Safety Control Structure for a Technical System.
|
||||
An example from the world of space exploration is used in this section, but many
|
||||
of the same requirements and constraints could easily be adapted for other types
|
||||
of technical system development and operations.
|
||||
The requirements in this example were generated to perform a programmatic
|
||||
risk assessment of a new NASA management structure called Independent
|
||||
|
||||
Technical Authority (ITA) recommended in the report of the Columbia Accident
|
||||
Investigation Board. The risk analysis itself is described in the chapter on the new
|
||||
hazard analysis technique called STPA (chapter 8). But the first step in the safety
|
||||
or risk analysis is the same as for technical systems: to identify the system hazards
|
||||
to be avoided, to generate a set of requirements for the new management structure,
|
||||
and to design the control structure.
|
||||
The new safety control structure for the NASA manned space program was
|
||||
introduced to improve the flawed engineering and management decision making
|
||||
leading to the Columbia loss. The hazard to be eliminated or mitigated was:
|
||||
|
||||
System Hazard:
|
||||
Poor engineering and management decision making leading to a loss.
|
||||
|
||||
Four high-level system safety requirements and constraints for preventing the
|
||||
hazard were identified and then refined into more specific requirements and
|
||||
constraints.
|
||||
1. Safety considerations must be first and foremost in technical decision
|
||||
making.
|
||||
a. State-of-the art safety standards and requirements for NASA missions must
|
||||
be established, implemented, enforced, and maintained that protect the
|
||||
astronauts, the workforce, and the public.
|
||||
b. Safety-related technical decision making must be independent from pro-
|
||||
grammatic considerations, including cost and schedule.
|
||||
c. Safety-related decision making must be based on correct, complete, and
|
||||
up-to-date information.
|
||||
d. Overall (final) decision making must include transparent and explicit con-
|
||||
sideration of both safety and programmatic concerns.
|
||||
e. The Agency must provide for effective assessment and improvement in
|
||||
safety-related decision making.
|
||||
2. Safety-related technical decision making must be done by eminently qualified
|
||||
experts, with broad participation of the full workforce.
|
||||
a. Technical decision making must be credible (executed using credible per-
|
||||
sonnel, technical requirements, and decision-making tools) .
|
||||
b. Technical decision making must be clear and unambiguous with respect to
|
||||
authority, responsibility, and accountability.
|
||||
c. All safety-related technical decisions, before being implemented by the
|
||||
Program, must have the approval of the technical decision maker assigned
|
||||
responsibility for that class of decisions.
|
||||
|
||||
d. Mechanisms and processes must be created that allow and encourage all
|
||||
employees and contractors to contribute to safety-related decision making.
|
||||
3. Safety analyses must be available and used starting in the early acquisition,
|
||||
requirements development, and design processes and continuing through the
|
||||
system life cycle.
|
||||
a. High-quality system hazard analyses must be created.
|
||||
b. Personnel must have the capability to produce high-quality safety
|
||||
analyses.
|
||||
c. Engineers and managers must be trained to use the results of hazard analy-
|
||||
ses in their decision making.
|
||||
d. Adequate resources must be applied to the hazard analysis process.
|
||||
e. Hazard analysis results must be communicated in a timely manner to those
|
||||
who need them. A communication structure must be established that
|
||||
includes contractors and allows communication downward, upward, and
|
||||
sideways (e.g., among those building subsystems).
|
||||
f. Hazard analyses must be elaborated (refined and extended) and updated
|
||||
as the design evolves and test experience is acquired.
|
||||
g. During operations, hazard logs must be maintained and used as experience
|
||||
is acquired. All in-flight anomalies must be evaluated for their potential to
|
||||
contribute to hazards.
|
||||
4. The Agency must provide avenues for the full expression of technical con-
|
||||
science (for safety-related technical concerns) and provide a process for full
|
||||
and adequate resolution of technical conflicts as well as conflicts between
|
||||
programmatic and technical concerns.
|
||||
a. Communication channels, resolution processes, adjudication procedures
|
||||
must be created to handle expressions of technical conscience.
|
||||
b. Appeals channels must be established to surface complaints and concerns
|
||||
about aspects of the safety-related decision making and technical conscience
|
||||
structures that are not functioning appropriately.
|
||||
Where do these requirements and constraints come from? Many of them are based
|
||||
on fundamental safety-related development, operations and management principles
|
||||
identified in various chapters of this book, particularly chapters 12 and 13. Others
|
||||
are based on experience, such as the causal factors identified in the Columbia and
|
||||
Challenger accident reports or other critiques of the NASA safety culture and of
|
||||
NASA safety management. The requirements listed obviously reflect the advanced
|
||||
technology and engineering domain of NASA and the space program that was the
|
||||
focus of the ITA program along with some of the unique aspects of the NASA
|
||||
|
||||
|
||||
culture. Other industries will have their own requirements. An example for the
|
||||
pharmaceutical industry is shown in the next section of this chapter.
|
||||
There is unlikely to be a universal set of requirements that holds for every safety
|
||||
control structure beyond a small set of requirements too general to be very useful
|
||||
in a risk analysis. Each organization needs to determine what its particular safety
|
||||
goals are and the system requirements and constraints that are likely to ensure that
|
||||
it reaches them.
|
||||
Clearly buy-in and approval of the safety goals and requirements by the stake-
|
||||
holders, such as management and the broader workforce as well as anyone oversee-
|
||||
ing the group being analyzed, such as a regulatory agency, is important when
|
||||
designing and analyzing a safety control structure.
|
||||
Independent Technical Authority is a safety control structure used in the nuclear
|
||||
Navy SUBSAFE program described in chapter 14. In this structure, safety-related
|
||||
decision making is taken out of the hands of the program manager and assigned to
|
||||
a Technical Authority. In the original NASA implementation, the technical authority
|
||||
rested in the NASA Chief Engineer, but changes have since been made. The overall
|
||||
safety control structure for the original NASA ITA is shown in figure 7.4.3
|
||||
For each component of the structure, information must be determined about its
|
||||
overall role, responsibilities, controls, process model requirements, coordination and
|
||||
communication requirements, contextual (environmental and behavior-shaping)
|
||||
factors that might bear on the component’s ability to fulfill its responsibilities, and
|
||||
inputs and outputs to other components in the control structure. The responsibilities
|
||||
are shown in figure 7.5. A risk analysis on ITA and the safety control structure is
|
||||
described in chapter 8.
|
||||
|
||||
footnote. The control structure was later changed to have ITA under the control of the NASA center directors
|
||||
rather than the NASA chief engineer; therefore, this control structure does not reflect the actual
|
||||
implementation of ITA at NASA, but it was the design at the time of the hazard analysis described in
|
||||
chapter 8.
|
||||
|
||||
|
||||
section 7.4.2. Safety Control Structures in Social Systems.
|
||||
Social system safety control structures often are not designed but evolve over time.
|
||||
They can, however, be analyzed for inherent risk and redesigned or “reengineered”
|
||||
to prevent accidents or to eliminate or control past causes of losses as determined
|
||||
in an accident analysis.
|
||||
The reengineering process starts with the definition of the hazards to be elimi-
|
||||
nated or mitigated, system requirements and constraints necessary to increase safety,
|
||||
and the design of the current safety-control structure. Analysis can then be used to
|
||||
drive the redesign of the safety controls. But once again, just like every system that
|
||||
has been described so far in this chapter, the process starts by identifying the hazards
|
||||
|
||||
|
||||
and safety requirements and constraints derived from them. The process is illus-
|
||||
trated using drug safety.
|
||||
Dozens of books have been written about the problems in the pharmaceutical
|
||||
industry. Everyone appears to have good intentions and are simply striving to opti-
|
||||
mize their performance within the existing incentive structure. The result is that the
|
||||
system has evolved to the point where each group’s individual best interests do not
|
||||
necessarily add up to or are not aligned with the best interests of society as a whole.
|
||||
A safety control structure exists, but does not necessarily provide adequate satisfac-
|
||||
tion of the system-level goals, as opposed to the individual component goals.
|
||||
This problem can be viewed as a classic system engineering problem: optimizing
|
||||
each component does not necessarily add up to a system optimum. Consider the air
|
||||
transportation system, as noted earlier. When each aircraft tries to optimize its path
|
||||
from its departure point to its destination, the overall system throughput may not
|
||||
be optimized when they all arrive in a popular hub at the same time. One goal of
|
||||
the air traffic control system is to control individual aircraft movement in order to
|
||||
|
||||
|
||||
optimize overall system throughput while trying to allow as much flexibility as pos-
|
||||
sible for the individual aircraft and airlines to achieve their goals. The air traffic
|
||||
control system and the rules of operation of the air transportation system resolve
|
||||
conflicting goals when public safety is at stake. Each airline might want its own
|
||||
aircraft to land as quickly as possible, but the air traffic controllers ensure adequate
|
||||
spacing between aircraft to preserve safety margins. These same principles can be
|
||||
applied to non-engineered systems.
|
||||
The ultimate goal is to determine how to reengineer or redesign the overall
|
||||
pharmaceutical safety control structure in a way that aligns incentives for the greater
|
||||
good of society. A well-designed system would make it easier for all stakeholders
|
||||
to do the right thing, both scientifically and ethically, while achieving their own goals
|
||||
as much as possible. By providing the decision makers with information about ways
|
||||
to achieve the overall system objectives and the tradeoffs involved, better decision
|
||||
making can result.
|
||||
While system engineering is applicable to pharmaceutical (and more generally
|
||||
medical) safety and risk management, there are important differences from the
|
||||
classic engineering problem that require changes to the traditional system safety
|
||||
approaches. In most technical systems, managing risk is simpler because not doing
|
||||
something (e.g., not inadvertently launching the missile) is usually safe and the
|
||||
problem revolves around preventing the hazardous event (inadvertent launch): a
|
||||
risk/no risk situation. The traditional engineering approach identifies and evaluates
|
||||
the costs and potential effectiveness of different ways to eliminate or control the
|
||||
hazards involved in the operational system. Tradeoffs require comparing the costs
|
||||
of various solutions, including costs that involve reduction in desirable system func-
|
||||
tions or system reliability.
|
||||
The problem in pharmaceutical safety is different: there is risk in prescribing a
|
||||
potentially unsafe drug, but there is also risk in not prescribing the drug (the patient
|
||||
dies from their medical condition): a risk/risk situation. The risks and benefits
|
||||
conflict in ways that greatly increase the complexity of decision making and the
|
||||
information needed to make decisions. New, more powerful system engineering
|
||||
techniques are required to deal with risk/risk decisions.
|
||||
Once again, the basic goals, hazards, and safety requirements must first be identi-
|
||||
fied [43].
|
||||
System Goal: To provide safe and effective pharmaceuticals to enhance the long-
|
||||
term health of the population.
|
||||
|
||||
Important loss events (accidents) we are trying to avoid are:
|
||||
1. Patients get a drug treatment that negatively impacts their health.
|
||||
2. Patients do not get the treatment they need.
|
||||
|
||||
|
||||
Three system hazards can be identified that are related to these loss events:
|
||||
H1: The public is exposed to an unsafe drug.
|
||||
1. The drug is released with a label that does not correctly specify the condi-
|
||||
tions for its safe use.
|
||||
2. An approved drug is found to be unsafe and appropriate responses are
|
||||
not taken (warnings, withdrawals from the market, etc.)
|
||||
3. Patients are subjected to unacceptable risk during clinical trials.
|
||||
H2: Drugs are taken unsafely.
|
||||
1. The wrong drug is prescribed for the indication.
|
||||
2. The pharmacist provides a different medication than was prescribed.
|
||||
3. Drugs are taken in an unsafe combination.
|
||||
4. Drugs are not taken according to directions (dosage, timing).
|
||||
H3: Patients do not get an effective treatment they require.
|
||||
1. Safe and effective drugs are not developed, are not approved for use, or
|
||||
are withdrawn from the market.
|
||||
2. Safe and effective drugs are not affordable by those who need them.
|
||||
3. Unnecessary delays are introduced into development and marketing.
|
||||
4. Physicians do not prescribe needed drugs or patients have no access to
|
||||
those who could provide the drugs to them.
|
||||
5. Patients stop taking a prescribed drug due to perceived ineffectiveness or
|
||||
intolerable side effects.
|
||||
From these hazards, a set of system requirements can be derived to prevent them:
|
||||
1. Pharmaceutical products are developed to enhance long-term health.
|
||||
a. Continuous appropriate incentives exist to develop and market needed
|
||||
drugs.
|
||||
b. The scientific knowledge and technology needed to develop new drugs and
|
||||
optimize their use is available.
|
||||
2. Drugs on the market are adequately safe and effective.
|
||||
a. Drugs are subjected to effective and timely safety testing.
|
||||
b. New drugs are approved by the FDA based upon a validated and reproduc-
|
||||
ible decision-making process.
|
||||
c. The labels attached to drugs provide correct information about safety and
|
||||
efficacy.
|
||||
|
||||
|
||||
d. Drugs are manufactured according to good manufacturing practices.
|
||||
e. Marketed drugs are monitored for adverse events, side effects, and potential
|
||||
negative interactions. Long-term studies after approval are conducted to
|
||||
detect long-term effects and effects on subpopulations not in the original
|
||||
study.
|
||||
f. New information about potential safety risk is reviewed by an independent
|
||||
advisory board. Marketed drugs found to be unsafe after they are approved
|
||||
are removed, recalled, restricted, or appropriate risk/benefit information is
|
||||
provided.
|
||||
3. Patients get and use the drugs they need for good health.
|
||||
a. Drug approval is not unnecessarily delayed.
|
||||
b. Drugs are obtainable by patients.
|
||||
c. Accurate information is available to support decision making about risks
|
||||
and benefits.
|
||||
d. Patients get the best intervention possible, practical, and reasonable for
|
||||
their health needs.
|
||||
e. Patients get drugs with the required dosage and purity.
|
||||
4. Patients take the drugs in a safe and effective manner.
|
||||
a. Patients get correct instructions about dosage and follow them.
|
||||
b. Patients do not take unsafe combinations of drugs.
|
||||
c. Patients are properly monitored by a physician while they are being treated.
|
||||
d. Patients are not subjected to unacceptable risk during clinical trials.
|
||||
In system engineering, the requirements may not be totally achievable in any practi-
|
||||
cal design. For one thing, they may be conflicting among themselves (as was dem-
|
||||
onstrated in the train door example) or with other system (non-safety) requirements
|
||||
or constraints. The goal is to design a system or to evaluate and improve an existing
|
||||
system that satisfies the requirements as much as possible today and to continually
|
||||
improve the design over time using feedback and new scientific and engineering
|
||||
advances. Tradeoffs that must be made in the design process are carefully evaluated
|
||||
and considered and revisited when necessary.
|
||||
Figure 7.6 shows the general pharmaceutical safety control structure in the
|
||||
United States. Each component’s assigned responsibilities are those assumed in the
|
||||
design of the structure. In fact, at any time, they may not be living up to these
|
||||
responsibilities.
|
||||
Congress provides guidance to the FDA by passing laws and providing directives,
|
||||
provides any necessary legislation to ensure drug safety, ensures that the FDA has
|
||||
|
||||
|
||||
enough funding to operate independently, provides legislative oversight on the
|
||||
effectiveness of FDA activities, and holds committee hearings and investigations of
|
||||
industry practices.
|
||||
The FDA CDER (Center for Drug Evaluation and Research) ensures that the
|
||||
prescription, generic, and over-the-counter drug products are adequately available
|
||||
to the public and are safe and effective; monitors marketed drug products for
|
||||
unexpected health risks; and monitors and enforces the quality of marketed drug
|
||||
products. CDER staff members are responsible for selecting competent FDA advi-
|
||||
sory committee members, establishing and enforcing conflict of interest rules, and
|
||||
providing researchers with access to accurate and useful adverse event reports.
|
||||
There are three major components within CDER. The Office of New Drugs
|
||||
(OND) is in charge of approving new drugs, setting drug labels and, when required,
|
||||
recalling drugs. More specifically, OND is responsible to:
|
||||
1.•Oversee all U.S. human trials and development programs for investigational
|
||||
medical products to ensure safety of participants in clinical trials and provide
|
||||
oversight of the Institutional Review Boards (IRBs) that actually perform these
|
||||
functions for the FDA.
|
||||
2.•Set the requirements and process for the approval of new drugs.
|
||||
3.•Critically examine a sponsor’s claim that a drug is safe for intended use (New
|
||||
Drug Application Safety Review). Impartially evaluate new drugs for safety
|
||||
and efficacy and approve them for sale if deemed appropriate.
|
||||
4.•Upon approval, set the label for the drug.
|
||||
5.•Not unnecessarily delay drugs that may have a beneficial effect.
|
||||
6.•Require Phase IV (after-market) safety testing if there is a potential for long-
|
||||
term safety risk.
|
||||
7.•Remove a drug from the market if new evidence shows that the risks outweigh
|
||||
the benefits.
|
||||
8.•Update the label information when new information about drug safety is
|
||||
discovered.
|
||||
The second office within the FDA CDER is the Division of Drug Marketing, Adver-
|
||||
tising, and Communications (DDMAC). This group provides oversight of the mar-
|
||||
keting and promotion of drugs. It reviews advertisements for accuracy and balance.
|
||||
The third component of the FDA CDER is the Office of Surveillance and Epi-
|
||||
demiology. This group is responsible for ongoing reviews of product safety, efficacy,
|
||||
and quality. It accomplishes this goal by performing statistical analysis of adverse
|
||||
event data it receives to determine whether there is a safety problem. This office
|
||||
reassesses risks based on new data learned after a drug is marketed and recommends
|
||||
|
||||
|
||||
ways to manage risk. Its staff members may also serve as consultants to OND with
|
||||
regard to drug safety issues. While they can recommend that a drug be removed
|
||||
from the market if new evidence shows significant risks, only OND can actually
|
||||
require that it be removed.
|
||||
The FDA performs its duties with input from FDA Advisory Boards. These
|
||||
boards are made up of academic researchers whose responsibility is to provide
|
||||
independent advice and recommendations that are in the best interest of the general
|
||||
public. They must disclose any conflicts of interest related to subjects on which
|
||||
advice is being given.
|
||||
Research scientists and centers are responsible for providing independent and
|
||||
objective research on a drug’s safety, efficacy, and new uses and give their unbiased
|
||||
expert opinion when it is requested by the FDA. They should disclose all their con-
|
||||
flicts of interest when publishing and take credit only for papers on which they have
|
||||
significantly contributed.
|
||||
Scientific journals are responsible for publishing articles of high scientific quality
|
||||
and provide accurate and balanced information to doctors.
|
||||
Payers and insurers pay the medical costs for the people insured as needed
|
||||
and only reimburse for drugs that are safe and effective. They control the use of
|
||||
drugs by providing formularies or lists of approved drugs for which they will reim-
|
||||
burse claims.
|
||||
Pharmaceutical developers and manufacturers also have responsibilities within
|
||||
the drug safety control structure. They must ensure that patients are protected from
|
||||
avoidable risks by providing safe and effective drugs, testing drugs for effectiveness,
|
||||
properly labeling their drugs, protecting patients during clinical trials by properly
|
||||
monitoring the trial, not promoting unsafe use of their drugs, removing a drug from
|
||||
the market if it is no longer considered safe, and manufacturing their drugs accord-
|
||||
ing to good manufacturing practice. They are also responsible for monitoring drugs
|
||||
for safety by running long-term, post-approval studies as required by the FDA;
|
||||
running new trials to test for potential hazards; and providing, maintaining, and
|
||||
incentivizing adverse-event reporting channels.
|
||||
Pharmaceutical companies must also give accurate and up-to-date information
|
||||
to doctors and the FDA about drug safety by educating doctors, providing all avail-
|
||||
able information about the safety of the drug to the FDA, and informing the FDA
|
||||
of potential new safety issues in a timely manner. Pharmaceutical companies also
|
||||
sponsor research for the development of new drugs and treatments.
|
||||
Last, but not least, are the physicians and patients. Physicians have the responsi-
|
||||
bility to:
|
||||
1.•
|
||||
Make treatment decisions based on the best interests of their clients.
|
||||
2.• Weigh the risks of treatment and non-treatment.
|
||||
|
||||
|
||||
3.•Prescribe drugs according to the limitations on the label
|
||||
4.•Maintain up-to-date knowledge of the risk/benefit profile of the drugs they are
|
||||
prescribing
|
||||
5.•Monitor the symptoms of their patients under treatment for adverse events
|
||||
and negative interactions
|
||||
6.•Report adverse events potentially linked to the use of the drugs they
|
||||
prescribe
|
||||
Patients are taking increasing responsibility for their own health in today’s world,
|
||||
limited by what is practical. Traditionally they have been responsible to follow their
|
||||
physician’s instructions and take drugs as prescribed, accede to the doctor’s superior
|
||||
knowledge when appropriate, and go through physicians or appropriate channels to
|
||||
get prescription drugs.
|
||||
As designed, this safety control structure looks strong and potentially effective.
|
||||
Unfortunately, it has not always worked the way it was supposed to work and the
|
||||
individual components have not always satisfied their responsibilities. Chapter 8
|
||||
describes the use of the new hazard analysis technique, STPA, as well as other basic
|
||||
STAMP concepts in analyzing the potential risks in this structure.
|
||||
586
chapter07.txt
Normal file
586
chapter07.txt
Normal file
@ -0,0 +1,586 @@
|
||||
chapter 7. Fundamentals.
|
||||
All the parts of the process described in the following chapters start from the same
|
||||
fundamental system engineering activities. These include defining, for the system
|
||||
involved, accidents or losses, hazards, safety requirements and constraints, and the
|
||||
safety control structure.
|
||||
|
||||
section 7.1.
|
||||
Defining Accidents and Unacceptable Losses.
|
||||
The first step in any safety effort involves agreeing on the types of accidents or
|
||||
losses to be considered.
|
||||
In general, the definition of an accident comes from the customer and occasionally from the government for systems that are regulated by government agencies.
|
||||
Other sources might be user groups, insurance companies, professional societies,
|
||||
industry standards, and other stakeholders. If the company or group developing the
|
||||
system is free to build whatever they want, then considerations of liability and the
|
||||
cost of accidents will come into play.
|
||||
Definitions of basic terms differ greatly among industries and engineering disciplines. A set of basic definitions is used in this book .(see appendix A). that reflect
|
||||
common usage in System Safety. An accident is defined as.
|
||||
Accident. An undesired or unplanned event that results in a loss, including loss
|
||||
of human life or human injury, property damage, environmental pollution,
|
||||
mission loss, etc.
|
||||
An accident need not involve loss of life, but it does result in some loss that is unacceptable to the stakeholders. System Safety has always considered non-human
|
||||
losses, but for some reason, many other approaches to safety engineering have
|
||||
limited the definition of a loss to human death or injury. As an example of an
|
||||
inclusive definition, a spacecraft accident might include loss of the astronauts .(if
|
||||
the spacecraft is manned), death or injury to support personnel or the public, nonaccomplishment of the mission, major equipment damage .(such as damage to launch
|
||||
|
||||
|
||||
facilities), environmental pollution of planets, and so on. An accident definition used
|
||||
in the design of an explorer spacecraft to characterize the icy moon of a planet in
|
||||
the Earth’s solar system, for example, was .
|
||||
A1. Humans or human assets on earth are killed or damaged.
|
||||
A2. Humans or human assets off of the earth are killed or damaged.
|
||||
A3. Organisms on any of the moons of the outer planet .(if they exist). are killed
|
||||
or mutated by biological agents of Earth origin.
|
||||
Rationale. Contamination of an icy outer planet moon with biological agents
|
||||
of Earth origin could have catastrophically adverse effects on any biological
|
||||
agents indigenous to the icy outer planet moon.
|
||||
A4. The scientific data corresponding to the mission goals is not collected.
|
||||
A5. The scientific data corresponding to the mission goals is rendered unusable
|
||||
(i.e., deleted or corrupted). before it can be fully investigated.
|
||||
A6. Organisms of Earth origin are mistaken for organisms indigenous to any of
|
||||
the moons of the outer planet in future missions to study the outer planet’s
|
||||
moon.
|
||||
Rationale. Contamination of a moon of an outer planet with biological
|
||||
agents of Earth origin could lead to a situation in which a future mission
|
||||
discovers the biological agents and falsely concludes that they are indigenous to the moon of the outer planet.
|
||||
A7. An incident during this mission directly causes another mission to fail
|
||||
to collect, return, or use the scientific data corresponding to its mission
|
||||
goals.
|
||||
Rationale. It is possible for this mission to interfere with the completion of
|
||||
other missions through denying the other missions access to the space
|
||||
exploration infrastructure .(for example, overuse of limited Deep Space
|
||||
Network1 .(DSN). resources, causing another mission to miss its launch
|
||||
window because of damage to the launch pad during this mission, etc.)
|
||||
|
||||
footnote. The Deep Space Network is an international network of large antennas and communication facilities
|
||||
that supports interplanetary spacecraft missions and radio and radar astronomy observations for
|
||||
the exploration of the solar system and the universe. The network also supports some Earth-orbiting
|
||||
missions.
|
||||
|
||||
Prioritizing or assigning a level of severity to the identified losses may be useful
|
||||
when tradeoffs among goals are required in the design process. As an example,
|
||||
consider an industrial robot to service the thermal tiles on the Space Shuttle, which
|
||||
|
||||
|
||||
is used as an example in chapter 9. The goals for the robot are .(1). to inspect the
|
||||
thermal tiles for damage caused during launch, reentry, and transport of a Space
|
||||
Shuttle and .(2). to apply waterproofing chemicals to the thermal tiles.
|
||||
Level 1.
|
||||
A1.1. Loss of the orbiter and crew. .(e.g., inadequate thermal protection)
|
||||
A1.2. Loss of life or serious injury in the processing facility.
|
||||
Level 2.
|
||||
A2.1. Damage to the orbiter or to objects in the processing facility that results.
|
||||
in the delay of a launch or in a loss of greater than x dollars.
|
||||
A2.2. Injury to humans requiring hospitalization or medical attention and
|
||||
leading to long-term or permanent physical effects.
|
||||
Level 3.
|
||||
A3.1. Minor human injury. .(does not require medical attention or requires only
|
||||
minimal intervention and does not lead to long-term or permanent physical
|
||||
effects)
|
||||
A3.2. Damage to orbiter that does not delay launch and results in a loss of less
|
||||
than x dollars.
|
||||
A3.3. Damage to objects in the processing facility .(both on the floor or suspended). that does not result in delay of a launch or a loss of greater than x
|
||||
dollars.
|
||||
A3.4. Damage to the mobile robot.
|
||||
Assumption. It is assumed that there is a backup plan in place for servicing
|
||||
the orbiter thermal tiles in case the tile processing robot has a mechanical
|
||||
failure and that the same backup measures can be used in the event the
|
||||
robot is out of commission due to other reasons.
|
||||
The customer may also have a safety policy that must be followed by the contractor
|
||||
or those designing the thermal tile servicing robot. As an example, the following is
|
||||
similar to a typical NASA safety policy.
|
||||
General Safety Policy. All hazards related to human injury or damage to the
|
||||
orbiter must be eliminated or mitigated by the system design. A reasonable
|
||||
effort must be made to eliminate or mitigate hazards resulting at most in
|
||||
damage to the robot or objects in the work area. For any hazards that cannot
|
||||
be eliminated, the hazard analysis as well as the design features and development procedures, including any tradeoff studies, must be documented and
|
||||
presented to the customer for acceptance.
|
||||
|
||||
|
||||
One .(but only one). of the controls used to avoid this type of accident is an airborne collision avoidance system like T Cass .(Traffic alert and Collision Avoidance
|
||||
System), which is now required on most commercial aircraft. While the goal of T Cass
|
||||
is increased safety, T Cass itself introduces new hazards associated with its use. Some
|
||||
hazards that were considered during the design of T Cass are.
|
||||
H1. T Cass causes or contributes to a near midair collision .(N Mack), defined as
|
||||
a pair of controlled aircraft violating minimum separation standards.
|
||||
H2. T Cass causes or contributes to a controlled maneuver into the ground.
|
||||
H3. T Cass causes or contributes to the pilot losing control over the aircraft.
|
||||
H4. T Cass interferes with other safety-related aircraft systems.
|
||||
H5. T Cass interferes with the ground-based Air Traffic Control system .(e.g.,
|
||||
transponder transmissions to the ground or radar or radio services).
|
||||
H6. T Cass interferes with an A T C advisory that is safety-related .(e.g., avoiding
|
||||
a restricted area or adverse weather conditions).
|
||||
Ground-based air traffic control also plays an important role in collision avoidance,
|
||||
although it has responsibility for a larger and different set of hazards.
|
||||
H1. Controlled aircraft violate minimum separation standards .(N Mack).
|
||||
H2. An airborne controlled aircraft enters an unsafe atmospheric region.
|
||||
H3. A controlled airborne aircraft enters restricted airspace without authorization.
|
||||
H4. A controlled airborne aircraft gets too close to a fixed obstacle other than a
|
||||
safe point of touchdown on assigned runway .(known as controlled flight into
|
||||
terrain or C Fit).
|
||||
H5. A controlled airborne aircraft and an intruder in controlled airspace violate
|
||||
minimum separation.
|
||||
H6. Loss of controlled flight or loss of airframe integrity.
|
||||
H7. An aircraft on the ground comes too close to moving objects or collides with
|
||||
stationary objects or leaves the paved area.
|
||||
H8. An aircraft enters a runway for which it does not have a clearance .(called
|
||||
runway incursion).
|
||||
Unsafe behavior .(hazards). at the system level can be mapped into hazardous
|
||||
behaviors at the component or subsystem level. Note, however, that the reverse
|
||||
(bottom-up). process is not possible, that is, it is not possible to identify the systemlevel hazards by looking only at individual component behavior. Safety is a system
|
||||
property, not a component property. Consider an automated door system. One
|
||||
|
||||
|
||||
reasonable hazard when considering the door alone is the door closing on someone.
|
||||
The associated safety constraint is that the door must not close on anyone in the
|
||||
doorway. This hazard is relevant if the door system is used in any environment. If
|
||||
the door is in a building, another important hazard is not being able to get out of a
|
||||
dangerous environment, for example, if the building is on fire. Therefore, a reasonable design constraint would be that the door opens whenever a door open request
|
||||
is received. But if the door is used on a moving train, an additional hazard must
|
||||
be considered, namely, the door opening while the train is moving and between
|
||||
stations. In a moving train, different safety design constraints would apply compared
|
||||
to an automated door system in a building. Hazard identification is a top-down
|
||||
process that must consider the encompassing system and its hazards and potential
|
||||
accidents.
|
||||
Let’s assume that the automated door system is part of a train control system.
|
||||
The system-level train hazards related to train doors include a person being hit by
|
||||
closing doors, someone falling from a moving train or from a stationary train that
|
||||
is not properly aligned with a station platform, and passengers and staff being unable
|
||||
to escape from a dangerous environment in the train compartment. Tracing these
|
||||
system hazards into the related hazardous behavior of the automated door component of the train results in the following hazards.
|
||||
1. Door is open when the train starts.
|
||||
2. Door opens while train is in motion.
|
||||
3. Door opens while not properly aligned with station platform.
|
||||
4. Door closes while someone is in the doorway.
|
||||
5. Door that closes on an obstruction does not reopen or reopened door does
|
||||
not reclose.
|
||||
6. Doors cannot be opened for emergency evacuation between stations.
|
||||
The designers of the train door controller would design to control these hazards.
|
||||
Note that constraints 3 and 6 are conflicting, and the designers will have to reconcile
|
||||
such conflicts. In general, attempts should first be made to eliminate hazards at
|
||||
the system level. If they cannot be eliminated or adequately controlled at the
|
||||
system level, then they must be refined into hazards to be handled by the system
|
||||
components.
|
||||
Unfortunately, no tools exist for identifying hazards. It takes domain expertise
|
||||
and depends on subjective evaluation by those constructing the system. Chapter 13
|
||||
in Safeware provides some common heuristics that may be helpful in the process.
|
||||
The good news is that identifying hazards is usually not a difficult process. The later
|
||||
steps in the hazard analysis process are where most of the mistakes and effort occurs.
|
||||
|
||||
|
||||
There is also no right or wrong set of hazards, only a set that the system stakeholders agree is important to avoid. Some government agencies have mandated the
|
||||
hazards they want considered for the systems they regulate or certify. For example,
|
||||
the U.S. Department of Defense requires that producers of nuclear weapons
|
||||
consider four hazards.
|
||||
1. Weapons involved in accident or incidents, or jettisoned weapons, produce a
|
||||
nuclear yield.
|
||||
2. Nuclear weapons are deliberately prearmed, armed, launched, fired, or released
|
||||
without execution of emergency war orders or without being directed to do so
|
||||
by a competent authority.
|
||||
3. Nuclear weapons are inadvertently prearmed, armed, launched, fired, or
|
||||
released.
|
||||
4. Inadequate security is applied to nuclear weapons.
|
||||
Sometimes user or professional associations define the hazards for the systems they
|
||||
use and that they want developers to eliminate or control. In most systems, however,
|
||||
the hazards to be considered are up to the developer and their customer(s).
|
||||
section 7.3.
|
||||
System Safety Requirements and Constraints.
|
||||
After the system and component hazards have been identified, the next major goal
|
||||
is to specify the system-level safety requirements and design constraints necessary
|
||||
to prevent the hazards from occurring. These constraints will be used to guide the
|
||||
system design and tradeoff analyses.
|
||||
The system-level constraints are refined and allocated to each component during
|
||||
the system engineering decomposition process. The process then iterates over the
|
||||
individual components as they are refined .(and perhaps further decomposed). and
|
||||
as design decisions are made.
|
||||
Figure 7.1 shows an example of the design constraints that might be generated
|
||||
from the automated train door hazards. Again, note that the third constraint potentially conflicts with the last one and the resolution of this conflict will be an important part of the system design process. Identifying these types of conflicts early in
|
||||
the design process will lead to better solutions. Choices may be more limited later
|
||||
on when it may not be possible or practical to change the early decisions.
|
||||
As the design process progresses and design decisions are made, the safety
|
||||
requirements and constraints are further refined and expanded. For example, a
|
||||
safety constraint on T Cass is that it must not interfere with the ground-based air
|
||||
traffic control system. Later in the process, this constraint will be refined into more
|
||||
detailed constraints on the ways this interference might occur. Examples include
|
||||
|
||||
|
||||
constraints on T Cass design to limit interference with ground-based surveillance
|
||||
radar, with distance-measuring equipment channels, and with radio services. Additional constraints include how T Cass can process and transmit information .(see
|
||||
chapter 10).
|
||||
Figure 7.2 shows the high-level requirements and constraints for some of the air
|
||||
traffic control hazards identified above. Comparing the A T C high-level constraints
|
||||
with the T Cass high-level constraints .(figure 7.3). is instructive. Ground-based air
|
||||
traffic control has additional requirements and constraints related to aspects of the
|
||||
collision problem that T Cass cannot handle alone, as well as other hazards and
|
||||
potential aircraft accidents that it must control.
|
||||
Some constraints on the two system components .(A T C and T Cass). are closely
|
||||
related, such as the requirement to provide advisories that maintain safe separation
|
||||
between aircraft. This example of overlapping control raises important concerns
|
||||
about potential conflicts and coordination problems that need to be resolved. As
|
||||
noted in section 4.5, accidents often occur in the boundary areas between controllers
|
||||
and when multiple controllers control the same process. The inadequate resolution
|
||||
of the conflict between multiple controller responsibilities for aircraft separation
|
||||
contributed to the collision of two aircraft over the town of Überlingen .(Germany)
|
||||
|
||||
|
||||
in July 2 thousand 2 when T Cass and the ground air traffic controller provided conflicting
|
||||
advisories to the pilots. Potentially conflicting responsibilities must be carefully
|
||||
handled in system design and operations and identifying such conflicts are part of
|
||||
the new hazard analysis technique described in chapter 8.
|
||||
Hazards related to the interaction among components, for example the interaction between attempts by air traffic control and by T Cass to prevent collisions,
|
||||
need to be handled in the safety control structure design, perhaps by mandating
|
||||
how the pilot is to select between conflicting advisories. There may be considerations
|
||||
in handling these hazards in the subsystem design that will impact the behavior of
|
||||
multiple subsystems and therefore must be resolved at a higher level and passed to
|
||||
them as constraints on their behavior.
|
||||
|
||||
section 7.4.
|
||||
The Safety Control Structure.
|
||||
The safety requirements and constraints on the physical system design shown in
|
||||
section 7.3 act as input to the standard system engineering process and must be
|
||||
incorporated into the physical system design and safety control structure. An
|
||||
example of how they are used is provided in chapter 10.
|
||||
Additional system safety requirements and constraints, including those on operations and maintenance or upgrades will be used in the design of the safety control
|
||||
structure at the organizational and social system levels above the physical system.
|
||||
There is no one correct safety control structure. what is practical and effective will
|
||||
depend greatly on cultural and other factors. Some general principles that apply to
|
||||
all safety control structures are described in chapter 13. These principles need to be
|
||||
combined with specific system safety requirements and constraints for the particular
|
||||
system involved to design the control structure.
|
||||
The process for engineering social systems is very similar to the regular system
|
||||
engineering process and starts, like any system engineering project, with identifying
|
||||
system requirements and constraints. The responsibility for implementing each
|
||||
requirement needs to be assigned to the components of the control structure, along
|
||||
with requisite authority and accountability, as in any management system; controls
|
||||
must be designed to ensure that the responsibilities can be carried out; and feedback
|
||||
loops created to assist the controller in maintaining accurate process models.
|
||||
|
||||
section 7.4.1. The Safety Control Structure for a Technical System.
|
||||
An example from the world of space exploration is used in this section, but many
|
||||
of the same requirements and constraints could easily be adapted for other types
|
||||
of technical system development and operations.
|
||||
The requirements in this example were generated to perform a programmatic
|
||||
risk assessment of a new NASA management structure called Independent
|
||||
|
||||
Technical Authority .(I T A). recommended in the report of the Columbia Accident
|
||||
Investigation Board. The risk analysis itself is described in the chapter on the new
|
||||
hazard analysis technique called STPA .(chapter 8). But the first step in the safety
|
||||
or risk analysis is the same as for technical systems. to identify the system hazards
|
||||
to be avoided, to generate a set of requirements for the new management structure,
|
||||
and to design the control structure.
|
||||
The new safety control structure for the NASA manned space program was
|
||||
introduced to improve the flawed engineering and management decision making
|
||||
leading to the Columbia loss. The hazard to be eliminated or mitigated was.
|
||||
|
||||
System Hazard.
|
||||
Poor engineering and management decision making leading to a loss.
|
||||
|
||||
Four high-level system safety requirements and constraints for preventing the
|
||||
hazard were identified and then refined into more specific requirements and
|
||||
constraints.
|
||||
1. Safety considerations must be first and foremost in technical decision
|
||||
making.
|
||||
a. State-of-the art safety standards and requirements for NASA missions must
|
||||
be established, implemented, enforced, and maintained that protect the
|
||||
astronauts, the workforce, and the public.
|
||||
b. Safety-related technical decision making must be independent from programmatic considerations, including cost and schedule.
|
||||
c. Safety-related decision making must be based on correct, complete, and
|
||||
up-to-date information.
|
||||
d. Overall .(final). decision making must include transparent and explicit consideration of both safety and programmatic concerns.
|
||||
e. The Agency must provide for effective assessment and improvement in
|
||||
safety-related decision making.
|
||||
2. Safety-related technical decision making must be done by eminently qualified
|
||||
experts, with broad participation of the full workforce.
|
||||
a. Technical decision making must be credible .(executed using credible personnel, technical requirements, and decision-making tools). .
|
||||
b. Technical decision making must be clear and unambiguous with respect to
|
||||
authority, responsibility, and accountability.
|
||||
c. All safety-related technical decisions, before being implemented by the
|
||||
Program, must have the approval of the technical decision maker assigned
|
||||
responsibility for that class of decisions.
|
||||
|
||||
d. Mechanisms and processes must be created that allow and encourage all
|
||||
employees and contractors to contribute to safety-related decision making.
|
||||
3. Safety analyses must be available and used starting in the early acquisition,
|
||||
requirements development, and design processes and continuing through the
|
||||
system life cycle.
|
||||
a. High-quality system hazard analyses must be created.
|
||||
b. Personnel must have the capability to produce high-quality safety
|
||||
analyses.
|
||||
c. Engineers and managers must be trained to use the results of hazard analyses in their decision making.
|
||||
d. Adequate resources must be applied to the hazard analysis process.
|
||||
e. Hazard analysis results must be communicated in a timely manner to those
|
||||
who need them. A communication structure must be established that
|
||||
includes contractors and allows communication downward, upward, and
|
||||
sideways .(e.g., among those building subsystems).
|
||||
f. Hazard analyses must be elaborated .(refined and extended). and updated
|
||||
as the design evolves and test experience is acquired.
|
||||
g. During operations, hazard logs must be maintained and used as experience
|
||||
is acquired. All in-flight anomalies must be evaluated for their potential to
|
||||
contribute to hazards.
|
||||
4. The Agency must provide avenues for the full expression of technical conscience .(for safety-related technical concerns). and provide a process for full
|
||||
and adequate resolution of technical conflicts as well as conflicts between
|
||||
programmatic and technical concerns.
|
||||
a. Communication channels, resolution processes, adjudication procedures
|
||||
must be created to handle expressions of technical conscience.
|
||||
b. Appeals channels must be established to surface complaints and concerns
|
||||
about aspects of the safety-related decision making and technical conscience
|
||||
structures that are not functioning appropriately.
|
||||
Where do these requirements and constraints come from? Many of them are based
|
||||
on fundamental safety-related development, operations and management principles
|
||||
identified in various chapters of this book, particularly chapters 12 and 13. Others
|
||||
are based on experience, such as the causal factors identified in the Columbia and
|
||||
Challenger accident reports or other critiques of the NASA safety culture and of
|
||||
NASA safety management. The requirements listed obviously reflect the advanced
|
||||
technology and engineering domain of NASA and the space program that was the
|
||||
focus of the I T A program along with some of the unique aspects of the NASA
|
||||
|
||||
|
||||
culture. Other industries will have their own requirements. An example for the
|
||||
pharmaceutical industry is shown in the next section of this chapter.
|
||||
There is unlikely to be a universal set of requirements that holds for every safety
|
||||
control structure beyond a small set of requirements too general to be very useful
|
||||
in a risk analysis. Each organization needs to determine what its particular safety
|
||||
goals are and the system requirements and constraints that are likely to ensure that
|
||||
it reaches them.
|
||||
Clearly buy-in and approval of the safety goals and requirements by the stakeholders, such as management and the broader workforce as well as anyone overseeing the group being analyzed, such as a regulatory agency, is important when
|
||||
designing and analyzing a safety control structure.
|
||||
Independent Technical Authority is a safety control structure used in the nuclear
|
||||
Navy SUBSAFE program described in chapter 14. In this structure, safety-related
|
||||
decision making is taken out of the hands of the program manager and assigned to
|
||||
a Technical Authority. In the original NASA implementation, the technical authority
|
||||
rested in the NASA Chief Engineer, but changes have since been made. The overall
|
||||
safety control structure for the original NASA I T A is shown in figure 7.4.3
|
||||
For each component of the structure, information must be determined about its
|
||||
overall role, responsibilities, controls, process model requirements, coordination and
|
||||
communication requirements, contextual .(environmental and behavior-shaping)
|
||||
factors that might bear on the component’s ability to fulfill its responsibilities, and
|
||||
inputs and outputs to other components in the control structure. The responsibilities
|
||||
are shown in figure 7.5. A risk analysis on I T A and the safety control structure is
|
||||
described in chapter 8.
|
||||
|
||||
footnote. The control structure was later changed to have I T A under the control of the NASA center directors
|
||||
rather than the NASA chief engineer; therefore, this control structure does not reflect the actual
|
||||
implementation of I T A at NASA, but it was the design at the time of the hazard analysis described in
|
||||
chapter 8.
|
||||
|
||||
|
||||
section 7.4.2. Safety Control Structures in Social Systems.
|
||||
Social system safety control structures often are not designed but evolve over time.
|
||||
They can, however, be analyzed for inherent risk and redesigned or “reengineered”
|
||||
to prevent accidents or to eliminate or control past causes of losses as determined
|
||||
in an accident analysis.
|
||||
The reengineering process starts with the definition of the hazards to be eliminated or mitigated, system requirements and constraints necessary to increase safety,
|
||||
and the design of the current safety-control structure. Analysis can then be used to
|
||||
drive the redesign of the safety controls. But once again, just like every system that
|
||||
has been described so far in this chapter, the process starts by identifying the hazards
|
||||
|
||||
|
||||
and safety requirements and constraints derived from them. The process is illustrated using drug safety.
|
||||
Dozens of books have been written about the problems in the pharmaceutical
|
||||
industry. Everyone appears to have good intentions and are simply striving to optimize their performance within the existing incentive structure. The result is that the
|
||||
system has evolved to the point where each group’s individual best interests do not
|
||||
necessarily add up to or are not aligned with the best interests of society as a whole.
|
||||
A safety control structure exists, but does not necessarily provide adequate satisfaction of the system-level goals, as opposed to the individual component goals.
|
||||
This problem can be viewed as a classic system engineering problem. optimizing
|
||||
each component does not necessarily add up to a system optimum. Consider the air
|
||||
transportation system, as noted earlier. When each aircraft tries to optimize its path
|
||||
from its departure point to its destination, the overall system throughput may not
|
||||
be optimized when they all arrive in a popular hub at the same time. One goal of
|
||||
the air traffic control system is to control individual aircraft movement in order to
|
||||
|
||||
|
||||
optimize overall system throughput while trying to allow as much flexibility as possible for the individual aircraft and airlines to achieve their goals. The air traffic
|
||||
control system and the rules of operation of the air transportation system resolve
|
||||
conflicting goals when public safety is at stake. Each airline might want its own
|
||||
aircraft to land as quickly as possible, but the air traffic controllers ensure adequate
|
||||
spacing between aircraft to preserve safety margins. These same principles can be
|
||||
applied to non-engineered systems.
|
||||
The ultimate goal is to determine how to reengineer or redesign the overall
|
||||
pharmaceutical safety control structure in a way that aligns incentives for the greater
|
||||
good of society. A well-designed system would make it easier for all stakeholders
|
||||
to do the right thing, both scientifically and ethically, while achieving their own goals
|
||||
as much as possible. By providing the decision makers with information about ways
|
||||
to achieve the overall system objectives and the tradeoffs involved, better decision
|
||||
making can result.
|
||||
While system engineering is applicable to pharmaceutical .(and more generally
|
||||
medical). safety and risk management, there are important differences from the
|
||||
classic engineering problem that require changes to the traditional system safety
|
||||
approaches. In most technical systems, managing risk is simpler because not doing
|
||||
something .(e.g., not inadvertently launching the missile). is usually safe and the
|
||||
problem revolves around preventing the hazardous event .(inadvertent launch). a
|
||||
risk/no risk situation. The traditional engineering approach identifies and evaluates
|
||||
the costs and potential effectiveness of different ways to eliminate or control the
|
||||
hazards involved in the operational system. Tradeoffs require comparing the costs
|
||||
of various solutions, including costs that involve reduction in desirable system functions or system reliability.
|
||||
The problem in pharmaceutical safety is different. there is risk in prescribing a
|
||||
potentially unsafe drug, but there is also risk in not prescribing the drug .(the patient
|
||||
dies from their medical condition). a risk/risk situation. The risks and benefits
|
||||
conflict in ways that greatly increase the complexity of decision making and the
|
||||
information needed to make decisions. New, more powerful system engineering
|
||||
techniques are required to deal with risk/risk decisions.
|
||||
Once again, the basic goals, hazards, and safety requirements must first be identified .
|
||||
System Goal. To provide safe and effective pharmaceuticals to enhance the longterm health of the population.
|
||||
|
||||
Important loss events .(accidents). we are trying to avoid are.
|
||||
1. Patients get a drug treatment that negatively impacts their health.
|
||||
2. Patients do not get the treatment they need.
|
||||
|
||||
|
||||
Three system hazards can be identified that are related to these loss events.
|
||||
H1. The public is exposed to an unsafe drug.
|
||||
1. The drug is released with a label that does not correctly specify the conditions for its safe use.
|
||||
2. An approved drug is found to be unsafe and appropriate responses are
|
||||
not taken .(warnings, withdrawals from the market, etc.)
|
||||
3. Patients are subjected to unacceptable risk during clinical trials.
|
||||
H2. Drugs are taken unsafely.
|
||||
1. The wrong drug is prescribed for the indication.
|
||||
2. The pharmacist provides a different medication than was prescribed.
|
||||
3. Drugs are taken in an unsafe combination.
|
||||
4. Drugs are not taken according to directions .(dosage, timing).
|
||||
H3. Patients do not get an effective treatment they require.
|
||||
1. Safe and effective drugs are not developed, are not approved for use, or
|
||||
are withdrawn from the market.
|
||||
2. Safe and effective drugs are not affordable by those who need them.
|
||||
3. Unnecessary delays are introduced into development and marketing.
|
||||
4. Physicians do not prescribe needed drugs or patients have no access to
|
||||
those who could provide the drugs to them.
|
||||
5. Patients stop taking a prescribed drug due to perceived ineffectiveness or
|
||||
intolerable side effects.
|
||||
From these hazards, a set of system requirements can be derived to prevent them.
|
||||
1. Pharmaceutical products are developed to enhance long-term health.
|
||||
a. Continuous appropriate incentives exist to develop and market needed
|
||||
drugs.
|
||||
b. The scientific knowledge and technology needed to develop new drugs and
|
||||
optimize their use is available.
|
||||
2. Drugs on the market are adequately safe and effective.
|
||||
a. Drugs are subjected to effective and timely safety testing.
|
||||
b. New drugs are approved by the F D A based upon a validated and reproducible decision-making process.
|
||||
c. The labels attached to drugs provide correct information about safety and
|
||||
efficacy.
|
||||
|
||||
|
||||
d. Drugs are manufactured according to good manufacturing practices.
|
||||
e. Marketed drugs are monitored for adverse events, side effects, and potential
|
||||
negative interactions. Long-term studies after approval are conducted to
|
||||
detect long-term effects and effects on subpopulations not in the original
|
||||
study.
|
||||
f. New information about potential safety risk is reviewed by an independent
|
||||
advisory board. Marketed drugs found to be unsafe after they are approved
|
||||
are removed, recalled, restricted, or appropriate risk/benefit information is
|
||||
provided.
|
||||
3. Patients get and use the drugs they need for good health.
|
||||
a. Drug approval is not unnecessarily delayed.
|
||||
b. Drugs are obtainable by patients.
|
||||
c. Accurate information is available to support decision making about risks
|
||||
and benefits.
|
||||
d. Patients get the best intervention possible, practical, and reasonable for
|
||||
their health needs.
|
||||
e. Patients get drugs with the required dosage and purity.
|
||||
4. Patients take the drugs in a safe and effective manner.
|
||||
a. Patients get correct instructions about dosage and follow them.
|
||||
b. Patients do not take unsafe combinations of drugs.
|
||||
c. Patients are properly monitored by a physician while they are being treated.
|
||||
d. Patients are not subjected to unacceptable risk during clinical trials.
|
||||
In system engineering, the requirements may not be totally achievable in any practical design. For one thing, they may be conflicting among themselves .(as was demonstrated in the train door example). or with other system .(non-safety). requirements
|
||||
or constraints. The goal is to design a system or to evaluate and improve an existing
|
||||
system that satisfies the requirements as much as possible today and to continually
|
||||
improve the design over time using feedback and new scientific and engineering
|
||||
advances. Tradeoffs that must be made in the design process are carefully evaluated
|
||||
and considered and revisited when necessary.
|
||||
Figure 7.6 shows the general pharmaceutical safety control structure in the
|
||||
United States. Each component’s assigned responsibilities are those assumed in the
|
||||
design of the structure. In fact, at any time, they may not be living up to these
|
||||
responsibilities.
|
||||
Congress provides guidance to the F D A by passing laws and providing directives,
|
||||
provides any necessary legislation to ensure drug safety, ensures that the F D A has
|
||||
|
||||
|
||||
enough funding to operate independently, provides legislative oversight on the
|
||||
effectiveness of F D A activities, and holds committee hearings and investigations of
|
||||
industry practices.
|
||||
The F D A CDER .(Center for Drug Evaluation and Research). ensures that the
|
||||
prescription, generic, and over-the-counter drug products are adequately available
|
||||
to the public and are safe and effective; monitors marketed drug products for
|
||||
unexpected health risks; and monitors and enforces the quality of marketed drug
|
||||
products. CDER staff members are responsible for selecting competent F D A advisory committee members, establishing and enforcing conflict of interest rules, and
|
||||
providing researchers with access to accurate and useful adverse event reports.
|
||||
There are three major components within CDER. The Office of New Drugs
|
||||
(O N D). is in charge of approving new drugs, setting drug labels and, when required,
|
||||
recalling drugs. More specifically, O N D is responsible to.
|
||||
1.•Oversee all U.S. human trials and development programs for investigational
|
||||
medical products to ensure safety of participants in clinical trials and provide
|
||||
oversight of the Institutional Review Boards .(I R Bs). that actually perform these
|
||||
functions for the F D A.
|
||||
2.•Set the requirements and process for the approval of new drugs.
|
||||
3.•Critically examine a sponsor’s claim that a drug is safe for intended use .(New
|
||||
Drug Application Safety Review). Impartially evaluate new drugs for safety
|
||||
and efficacy and approve them for sale if deemed appropriate.
|
||||
4.•Upon approval, set the label for the drug.
|
||||
5.•Not unnecessarily delay drugs that may have a beneficial effect.
|
||||
6.•Require Phase 4 .(after-market). safety testing if there is a potential for longterm safety risk.
|
||||
7.•Remove a drug from the market if new evidence shows that the risks outweigh
|
||||
the benefits.
|
||||
8.•Update the label information when new information about drug safety is
|
||||
discovered.
|
||||
The second office within the F D A CDER is the Division of Drug Marketing, Advertising, and Communications .(DDMAC). This group provides oversight of the marketing and promotion of drugs. It reviews advertisements for accuracy and balance.
|
||||
The third component of the F D A CDER is the Office of Surveillance and Epidemiology. This group is responsible for ongoing reviews of product safety, efficacy,
|
||||
and quality. It accomplishes this goal by performing statistical analysis of adverse
|
||||
event data it receives to determine whether there is a safety problem. This office
|
||||
reassesses risks based on new data learned after a drug is marketed and recommends
|
||||
|
||||
|
||||
ways to manage risk. Its staff members may also serve as consultants to O N D with
|
||||
regard to drug safety issues. While they can recommend that a drug be removed
|
||||
from the market if new evidence shows significant risks, only O N D can actually
|
||||
require that it be removed.
|
||||
The F D A performs its duties with input from F D A Advisory Boards. These
|
||||
boards are made up of academic researchers whose responsibility is to provide
|
||||
independent advice and recommendations that are in the best interest of the general
|
||||
public. They must disclose any conflicts of interest related to subjects on which
|
||||
advice is being given.
|
||||
Research scientists and centers are responsible for providing independent and
|
||||
objective research on a drug’s safety, efficacy, and new uses and give their unbiased
|
||||
expert opinion when it is requested by the F D A. They should disclose all their conflicts of interest when publishing and take credit only for papers on which they have
|
||||
significantly contributed.
|
||||
Scientific journals are responsible for publishing articles of high scientific quality
|
||||
and provide accurate and balanced information to doctors.
|
||||
Payers and insurers pay the medical costs for the people insured as needed
|
||||
and only reimburse for drugs that are safe and effective. They control the use of
|
||||
drugs by providing formularies or lists of approved drugs for which they will reimburse claims.
|
||||
Pharmaceutical developers and manufacturers also have responsibilities within
|
||||
the drug safety control structure. They must ensure that patients are protected from
|
||||
avoidable risks by providing safe and effective drugs, testing drugs for effectiveness,
|
||||
properly labeling their drugs, protecting patients during clinical trials by properly
|
||||
monitoring the trial, not promoting unsafe use of their drugs, removing a drug from
|
||||
the market if it is no longer considered safe, and manufacturing their drugs according to good manufacturing practice. They are also responsible for monitoring drugs
|
||||
for safety by running long-term, post-approval studies as required by the F D A;
|
||||
running new trials to test for potential hazards; and providing, maintaining, and
|
||||
incentivizing adverse-event reporting channels.
|
||||
Pharmaceutical companies must also give accurate and up-to-date information
|
||||
to doctors and the F D A about drug safety by educating doctors, providing all available information about the safety of the drug to the F D A, and informing the F D A
|
||||
of potential new safety issues in a timely manner. Pharmaceutical companies also
|
||||
sponsor research for the development of new drugs and treatments.
|
||||
Last, but not least, are the physicians and patients. Physicians have the responsibility to.
|
||||
1.•
|
||||
Make treatment decisions based on the best interests of their clients.
|
||||
2.• Weigh the risks of treatment and non-treatment.
|
||||
|
||||
|
||||
3.•Prescribe drugs according to the limitations on the label
|
||||
4.•Maintain up-to-date knowledge of the risk/benefit profile of the drugs they are
|
||||
prescribing
|
||||
5.•Monitor the symptoms of their patients under treatment for adverse events
|
||||
and negative interactions
|
||||
6.•Report adverse events potentially linked to the use of the drugs they
|
||||
prescribe
|
||||
Patients are taking increasing responsibility for their own health in today’s world,
|
||||
limited by what is practical. Traditionally they have been responsible to follow their
|
||||
physician’s instructions and take drugs as prescribed, accede to the doctor’s superior
|
||||
knowledge when appropriate, and go through physicians or appropriate channels to
|
||||
get prescription drugs.
|
||||
As designed, this safety control structure looks strong and potentially effective.
|
||||
Unfortunately, it has not always worked the way it was supposed to work and the
|
||||
individual components have not always satisfied their responsibilities. Chapter 8
|
||||
describes the use of the new hazard analysis technique, STPA, as well as other basic
|
||||
STAMP concepts in analyzing the potential risks in this structure.
|
||||
1276
chapter08.raw
Normal file
1276
chapter08.raw
Normal file
File diff suppressed because it is too large
Load Diff
1175
chapter08.txt
Normal file
1175
chapter08.txt
Normal file
File diff suppressed because it is too large
Load Diff
1864
chapter09.raw
Normal file
1864
chapter09.raw
Normal file
File diff suppressed because it is too large
Load Diff
1703
chapter09.txt
Normal file
1703
chapter09.txt
Normal file
File diff suppressed because it is too large
Load Diff
102
replacements
102
replacements
@ -1,48 +1,70 @@
|
||||
: .
|
||||
— .
|
||||
\[.\\+\]
|
||||
( .(
|
||||
19\\([[:digit:]][[:digit:]]\\) 19 \\1
|
||||
20\\([[:digit:]][[:digit:]]\\) 20 \1
|
||||
200\\([[:digit:]]\\) 2 thousand \1
|
||||
— .
|
||||
: .
|
||||
) ).
|
||||
\[.\\+\]
|
||||
AAI A A I
|
||||
ACO A C O
|
||||
AFB A F B
|
||||
AI A I
|
||||
ASO A S O
|
||||
ATC A T C
|
||||
ATO A T O
|
||||
AWACS A Wacks
|
||||
B757 B 7 57
|
||||
BH B H
|
||||
BMDS B M D S
|
||||
BSD B S D
|
||||
CFAC C FACK
|
||||
CFIT C Fit
|
||||
CTF C T F
|
||||
DC-10 D C 10
|
||||
DMES D Mez
|
||||
DO D O
|
||||
FDAAA F D A A A
|
||||
FDA F D A
|
||||
FMEA F M E A
|
||||
FMIS F Miss
|
||||
GAO GAOW
|
||||
HAZOP Haz Op
|
||||
HMO H M O
|
||||
HQ-II H Q-2
|
||||
HTV H T V
|
||||
IFF I F F
|
||||
III 3
|
||||
II 2
|
||||
IOM I O M
|
||||
IRB I R B
|
||||
ITA I T A
|
||||
IV 4
|
||||
AWACS A Wacks
|
||||
ASO A S O
|
||||
PRA P R A
|
||||
HMO H M O
|
||||
MIC M I C
|
||||
DC-10 D C 10
|
||||
OPC O P C
|
||||
TAOR T A O R
|
||||
AAI A A I
|
||||
ACO A C O
|
||||
AFB A F B
|
||||
AI A I
|
||||
ATO A T O
|
||||
BH B H
|
||||
BSD B S D
|
||||
CTF C T F
|
||||
CFAC C FACK
|
||||
DO D O
|
||||
GAO GAOW
|
||||
IFF I F F
|
||||
JOIC J O I C
|
||||
JSOC J SOCK
|
||||
JTIDS J tides
|
||||
MCC M C C
|
||||
MD M D
|
||||
NCA N C A
|
||||
NFZ N F Z
|
||||
OPC O P C
|
||||
ROE R O E
|
||||
SD S D
|
||||
JAXA Jax ah
|
||||
JOIC J O I C
|
||||
JSOC J SOCK
|
||||
JTIDS J tides
|
||||
MCC M C C
|
||||
MD M D
|
||||
MIC M I C
|
||||
NCA N C A
|
||||
NFZ N F Z
|
||||
NMAC N Mack
|
||||
OND O N D
|
||||
OPC O P C
|
||||
OPF O P F
|
||||
OSMA O S M A
|
||||
PDUFA P D U F A
|
||||
PRA P R A
|
||||
ROE R O E
|
||||
SD S D
|
||||
SITREP SIT Rep
|
||||
STPA S T P A
|
||||
TACSAT Tack sat
|
||||
TAOR T A O R
|
||||
USCINCEUR U S C in E U R
|
||||
WD W D
|
||||
19\\([[:digit:]][[:digit:]]\\) 19 \\1
|
||||
200\\([[:digit:]]\\) 2 thousand \1
|
||||
20\\([[:digit:]][[:digit:]]\\) 20 \1
|
||||
B757 B 7 57
|
||||
TAOR T A O R
|
||||
TAOR T A O R
|
||||
TCAS T Cass
|
||||
TMI T M I
|
||||
TTPS T T P S
|
||||
USCINCEUR U S C in E U R
|
||||
WD W D
|
||||
Loading…
x
Reference in New Issue
Block a user