Functional Safety

A medical device is a product specified for use in patients, in diagnosis, in therapy, or in surgery. These medical devices are usually very complex. This complexity makes it difficult, in practice, to determine every failure mode that may cause physical injury or damage (hazard) to the health of people. The challenge is to design the medical device to prevent or to control hazards when they arise.

The Medical Device Directive and FDA prescribe requirements for processes by which development of a medical device is to meet safety, effectiveness, and quality to protect public health. Every device manufacturer must meet the requirements of the Medical Device Directive to legally place a medical device in the European market and satisfy the FDA requirements for the device to be placed in the North American market.

This article introduces a systematic approach to develop a medical device that is functionally safe. Functional safety is defined as part of the overall safety that depends on a system or piece of equipment operating correctly in response to its inputs, including the safe management of likely operator errors, hardware failures, and environmental changes. Functional safety is analogous to Essential Performance, which is a key requirement in the third edition of the IEC 60601-1 standard. For example, an over temperature protection using a thermal sensor to de-energize the device before it overheats is an instance of functional safety. However, providing specialized insulation on the device to withstand high temperatures is not an instance of functional safety, although it is clearly an instance of safety.

The consequences of not meeting the functional safety requirements can be disastrous to device manufacturer as highlighted by the highly publicized case of the Therac-25 machine. The Therac-25 was a radiation therapy machine, which resulted in at least six accidents between 1985 and 1987. Due to loss of functional safety, patients received massive overdoses of radiation with fatal consequences. More recently, in 2010, the FDA ordered the recall and destruction of a specific volumetric infusion pump in use in the United States, with an estimated cost to the manufacturer of approximately $500 million.

Table 1: Self tests for single fault condition compliance


Standards
Medical device development is a highly regulated industry. The device manufacturer requires expertise on all the relevant regulations and standards pertinent to the particular device under development. A high level, but not exhaustive list, of the medical regulations and standards appear in Chart 1.

IEC 60601-1 is the harmonized standard for medical electrical equipment recognized by public health authorities in most countries. The latest edition of IEC 60601:2005, the so-called Third Edition of IEC 60601-1 will become the new Bible of all medical electrical equipment safety from the June 1, 2012 (mandatory adoption) in Europe and a year later in the United States. The IEC 60601-1 conformity standard consists of collateral standards designated IEC 60601-1-xx (where the xx represents a number). In addition, specific standards designated IEC 60601-2-xx (where the xx represents a number) exist to amend or clarify the basic standards as they relate to various types of electrical equipment used in the treatment of patients.

The Third edition is very different from the Second edition, in that in order to show product conformance it requires a risk management file and process conforming to ISO 14971, the international standard for Application of Risk Management to Medical Devices.

The FDA also recognizes the IEC 60601 with minor deviations. In order to more closely align the UL standard number with the IEC 60601, UL published the first edition of UL 60601-1 in April 2003 to replace UL 2601-1. For reference, the main differences between the IEC 60601-1 and the UL 60601-1 standard relate to: components, leakage currents, moving parts, oxygen, flammability, mains plug, power cords, and markings.

The IEC 61508 standard is specifically concerned with functional safety. The IEC 61508 standard is not a medical specific standard but rather a generic standard. It applies to electrical and/or electronic and/or programmable electronic technologies irrespective of their application to provide guidance for users and regulators to gain confidence when using these technologies.

As the world of standards can be complicated and a minefield, the recommendation is to engage early in the development process a notified body to determine the best certification option for the medical device because of the difference in the standards that apply to each individual medical device.

Chart 1: Medical regulations and standards


Development Lifecycle
Functional Safety covers all lifecycle activities from initial concept, through hazard analysis and risk assessment, development of the safety requirements, specification, design, and implementation.

Functional Safety has full system scope in that it has to treat the function of a component or subsystem as part of the function of the whole system, and functional safety methods have to extend to every part that the device actuates, controls, or monitors.

The challenge is to design the system in such a way as to prevent dangerous failures or to control them when they arise. Dangerous failures may arise from various sources such as incorrect specifications of the system, hardware, or software; and omissions in the safety requirements specification (e.g. failure to develop all relevant safety functions during different modes of operation). (Chart 2)

Achieving Functional Safety The approach to functional safety identified in this document complements other practices such as hazard analysis, fault tree analysis, and failure-mode-effect-analysis, which are typically used in risk management. The functional safety approach specifically uses the concept of the single fault condition and self-tests that must be in place to guarantee that the device remains single fault safe.

Chart 2: Development lifecycle and functional safety


The Single Fault Condition

IEC 60601-1 defines Single Fault Condition as a condition in which a single means for reducing a risk is defective, or a single abnormal condition is present. Single Fault Safe is defined as a characteristic of a medical electrical equipment, or its parts, whereby it remains free of unacceptable risk during its expected service life under single fault conditions.

In order for a device to remain single fault safe under the single fault condition, the following sequence of events must be considered:

  1. A first random Single Fault Condition can occur at any time.
  2. The medical device shall remain Single Fault Safe after the Single Fault condition.
  3. If the first Single Fault Condition cannot be detected, then after some time a second Single Fault Condition must be considered. Note that this second Single Fault Condition must be independent of the first Single Fault Condition.
  4. The medical device shall remain Single Fault Safe with the occurrence of the combination of the first and second Single Fault Condition.

It is important to note that the term Single Fault Safe is misleading because more than a Single Fault Condition may have to be considered as identified in point three above.
 

Self-tests
Self-tests are key for the medical device to remain single fault safe during its expected service life. The requirements for self-tests is dependent on the protection type available for a particular fault. The protection type can classified as:

  • CPP – One control system with two or more independent protective measures
  • CP – One control system with one independent protective measure
  • C – One control system with no independent protective measure
  • Mixed Independent control and protection tasks on the same microprocessor/microcontroller

If a control and a protective function are performed by the same software task (i.e. no independent protective function) then this will be classified as C.

Compliance with the single fault condition can be achieved using self-tests as follows:

For reference, an excellent standard for self-tests is Appendix H software requirements for Class B controllers, control functions intended to prevent unsafe operation of IEC 60730-1, "Automatic electrical controls for household and similar use." Although not a medical device standard, it contains tests that are equally applicable to medical devices.
 

Approach
The functional safety approach consists of three phases as illustrated in Chart 3.
 

Functional Safety Analysis
The objective of the functional safety analysis is to identify the hazards that may arise if the essential performance is not met, and which state the device shall be placed in if it is to occur. Essential Performance is defined as performance necessary to achieve freedom from unacceptable risk. Essential Performance is most easily understood by considering whether its absence or degradation would result in an unacceptable risk. The analysis is performed by considering the whole device. For each device function, the essential performance is identified and the consequences of not meeting it are captured. This allows the identification of the state the device shall be place in if this scenario is to occur.
 

Architecture Generation
Chart 3: Function safety approach Either in parallel or serially, with the analysis of the functional needs, a device architecture can be generated. During the functional safety analysis, the safe state of the device has been identified and it will fall into one of three categories.

  1. Fail-safe device — A fail-safe system has a safe state. In case of a device failure, it is acceptable to put the device into this fail-safe state.
  2. Fault tolerant device — The device must be fault tolerant if no fail safe state exists.
  3. Inherently safe — The device can cause no harm; no need to carry further functional safety analysis of the device.

The next decision is to decide the system architecture based on the previous device safety category. This has impact of the manufacturing and development costs, but the most important consideration must be the safety of the device. Three architectures are common:

  1. Redundant architecture – preferred architecture for fault tolerant devices. The device performs the same process on equivalent architectures (e.g. multiple processors with equal peers) and action is taken using a decision algorithm (e.g. voting system). For example, a heart-lung machine would require this type of architecture.
  2. Control and protective architecture – preferred architecture for fail-safe devices. The control architecture will control the behavior of the device. The protective system will monitor that the control system is behaving safely. If the protective system detects a problem, then it will place the medical device into the safe state. Often, the second processor is much smaller, leading to cost savings over the redundant architecture option. A large number of therapeutic medical devices (i.e. those that actively do something to a patient, rather than passively measure a value) make use of this architecture.
  3. Single architecture – preferred architecture for inherently safe devices or low-cost high volume medical devices. A single processor will control the device and perform any safety functions as required. The challenge is that considerably more effort needs to be invested in proving that the device remains safe in the presence of catastrophic failure of the processor. A large proportion of measurement medical devices are single architecture (e.g. blood oxygen monitors).

The identification of the architecture shall drive the architecture detailed design. Once in place, the device architecture can be tested against the single fault condition.
 

Single Fault Condition Test
Failure conditions shall be identified to test against the single fault condition. A reference list of potential failures follows, but is not limited to:

  • Random hardware failure mechanisms
  • Systematic hardware failure mechanisms
  • Software errors
  • Common cause failures
  • Human error
  • Environmental influences (e.g. electromagnetic, temperature, mechanical phenomena)
  • Supply system voltage disturbances (e.g. loss of supply, reduced voltages, re-connection of supply)

A safe architecture shall address those failures. Failure conditions shall have a counter measure if it can cause harm. Counter measures are other system components or functions that protect the user from the identified hazard or failure condition. These include those components required for normal functional performance as well as those that have a purely protective function. In addition, each failure condition shall have the protection type CPP, CP, C, or mixed identified.

Compliance with the single fault condition can be achieved using the self-tests identified in Table 1.

Check if self-tests are achievable with current architecture or if a more obvious architecture, will facilitate tests.

Review the architecture analysis internally to confirm that the self-tests are achievable with the current device architecture and update the device architecture accordingly. In addition, if the product requires submission to a regulatory body, then it is recommended reviewing this analysis with the regulatory body. If the device architecture does not fully satisfy the functional safety then update the device architecture and re-evaluate it until it does meet the functional safety requirements. Finally, always update the system architecture, subsystem requirements, and detailed design with the output of this analysis.
 

Conclusion
Functional safety covers all safety lifecycle activities, from initial concept, through hazard analysis and risk assessment; development of the safety requirements; specification, design, and implementation; operation and maintenance; modification; and to final decommissioning and/or disposal.

Failure to address functional safety early in the device lifecycle may result in irreparable delays in the launch of your device. More importantly, it may put human lives at risk.

This article presents a systematic approach to add to the repertoire of methodologies used in the risk management process of the medical device, which should help your submission to the relevant notified bodies. Notified bodies demand that proper risk management processes are in place.

September 2011
Explore the September 2011 Issue

Check out more from this issue and find your next story to read.