STANDARD OPERATING PROCEDURE
Doc # / Rev / Title / Product Risk Management / Sheet / 1 / of / 2Proprietary Information. Property of
REVISION HISTORY
REVISION / DESCRIPTION / RELEASE BY / RELEASE DATE1 / Initial Release
APPROVAL HISTORY FOR CURRENT REVISION
DEPARTMENT / Name / Signatureon ECO / Date
Created by
Approved By
CONTROLLED DISTRIBUTION
QuantitY / Location /Format
1 / e-Document Control / Electronic1 / Document Control / Printed
1 / e-Technical File / Electronic
TRAINING REQUIREMENTS FOR CURRENT REVISION
If trained on the previous revision of this document: / Read Only TrainingIf NOT trained on the previous revision of this document: / Classroom Training
- SCOPE
1.1. The purpose of this document is to provide a guidance to be used for the identification, tracking and management of risk conditions or events observed in the design and operation of a product.
1.2. This procedure identifies general guidelines that can be applied to systems comprised of electro-mechanical devices, software and consumables.
- DEFINITIONS
2.1. Product Life Cycle – The period of time that begins when a product is conceived and ends when the product is no longer available for use or support is provided.
2.2. Failure Modes and Effects Analysis (FMEA) – A procedure by which each potential failure mode in a system is analyzed to determine the results or effects on the system and to classify failure modes according to severity. FMEA is a bottom-up system safety analysis method.
2.3. Fault Tree Analysis (FTA) – An analytical technique whereby an undesired system state is specified and the system is then analyzed to find all credible ways in which the undesired event can occur. FTA is a top-down system safety analysis method.
2.4. Risk - The combination of the probability of occurrence of harm and the severity of that harm
2.5. Residual Risk – The risk remaining after risk control measures have been taken
2.6. Harm - Physical injury or damage to the health of people, or damage to property or the environment
2.7. Hazard - the potential source of harm
2.8. Safety – Freedom from conditions that can cause death, serious injury, occupational illness or misdiagnosis. May also include damage to or loss of equipment or property.
2.9. Severity
2.9.1. A severity rating is defined to provide a measure of the worst credible outcome that should result should a safety mishap occur. The severity rating takes into consideration the safety requirements for the class of device. Severity is based on a qualitative measure of the potential consequence of a safety hazard.
2.10. Probability
2.10.1. Probability is defined as the likelihood of occurrence over the life of the system taking into consideration the defined safety requirements. In determining probability, the total user population, hours of operation, and system life should be taken into account.
2.11. Detection
2.11.1. Detection is a measurement of the ability of controls, sensors or other mechanisms to detect failures.
2.12. Risk Priority Number
2.12.1. The Risk Priority Number (RPN) is a mathematical product of the seriousness of a group of Effects (Severity), the likelihood that a Cause will create the failure associated with those effects (occurrence) and an ability to detect the failure before it gets to the customer (Detection). In equation form,
RPN = [S] X [O] X [D]
A risk priority number may be reported depending on the model used. The maximum RPN will depend on the individual scales used for each risk element
- ASSOCIATED MATERIALS/REFERENCED DOCUMENTS
3.1. ISO 13485 Medical devices - Quality management systems - Requirements for regulatory purposes
3.2. 21 CFR 820 Food and Drug Administration, Medical Devices, Quality System Regulation
3.3. ISO 14971:2012 Medical Devices - Application of Risk Management to Medical Devices.
3.4. IEC 62366:2007 Medical devices -- Application of usability engineering to medical devices
3.5. IEC61010-1 Safety Requirement for electrical equipment for measurement, control, and laboratory use, Part 1.
3.6. IEC61010-2-101 Safety Requirements for electrical equipment for measurement, control and laboratory use - Part 2-101: Particular Requirements for in vitro diagnostic (IVD) medical Equipment.
3.7. BS EN 61326 Electrical Equipment for Measurement, Control and Laboratory Use - EMC Requirements.
3.8. IEC 60601-1-4 Medical electrical equipment - Part 1-4: General requirements for safety - Collateral Standard: Programmable electrical medical systems
- RESPONSIBILITY
4.1. Responsibility for Risk Management will be assigned in the Design and Development Plan for the product. This may be the project manager or another appropriate employee or consultant with technical knowledge of the product. The person assigned to and responsible for risk assessment should be one that can remain objective in assessing the risks associated with the product.
- DEVELOPMENTAL PROCEDURES
5.1. A Risk Management Plan should be written and released through Document Control prior to initiating the risk management process. The plan shall include, but not be limited to the following:
5.1.1. The scope of the plan, identifying and describing the medical device and the life cycles phases that are applicable
5.1.2. A verification plan or specific callout to a separate verification plan that includes risk verification.
5.1.3. Allocation of responsibilities
5.1.4. Requirements for review of risk management activities
5.1.5. Criteria for risk acceptance
5.2. The first step in identifying hazards is to analyze the medical device for characteristics that could affect safety. One way of doing this is to ask a series of questions concerning the manufacture, intended use, qualification of the end user and ultimate disposition of the medical device. If one asks these questions from the point of view of all the individuals involved (e.g. users, service personnel, patients, etc.), a more complete picture may emerge of where the potential hazards can be found. The questions at the end of this procedure can aid the reader in identifying all the potential hazards of the medical device being analyzed. The list is not exhaustive, and the reader is cautioned to add questions that may have applicability to the particular medical device.
5.3. If it is determined that a Risk Analysis is not required, a written justification must be included as part of the Design History File and presented and approved at the appropriate Design Control Phase Review.
5.4. In cases where the device being analyzed is a component part of or accessory to a system, the individual components or accessories may undergo risk management analysis and a total risk management report shall be generated taking into account all system elements.
5.5. OBJECTIVES
5.5.1. The following are objectives of the risk management effort.
5.5.1.1. To ensure safety and effectiveness is designed into the system throughout the development life cycle. The design must address safety concerns from the earliest phases of the development process.
5.5.1.2. To ensure risks associated with the system are identified, analyzed, and eliminated or reduced to an acceptable level as early in the development process as possible. Recognizing that most systems have an inherent level of risk, the objective of risk management is to ensure these risks are managed and controlled prior to commercialization of the product.
5.5.2. Risk Analysis as a Design Input - During the requirements specification phase of the development process, the system requirements are to be analyzed for complete and correct definition of risk related requirements. Specific activities to support the requirements phase are as follows.
5.5.2.1. Risks are defined as a result of the conduct of analysis methods, such as; constructing a list of risk areas, performing a Failure Modes and Effects Analysis, performing a Fault Tree Analysis, or other analysis method.
5.5.2.2. Analyze the Functional Requirements Specification and Design Specifications to ensure that all potential unsafe states are defined, monitors are specified as appropriate to detect risk conditions, and controls are specified to ensure safe system operation.
5.5.2.3. Define risk related requirements to be addressed in hardware and software designs as well as labeling.
5.6. DESIGN ANALYSIS (DESIGN INPUT)
5.6.1. During the Design Phase of the development process, the design shall be analyzed for complete and correct definition of the design approach for reducing and/or eliminating risks. The following are specific activities to support the Design Phase risk analysis.
5.6.1.1. Perform fault tree and/or FMEA analysis to identify potential hazards to patient, operator and environment.
5.6.1.2. Inspect the design specification to ensure that the approach for elimination or mitigation of program risks is appropriate, comprehensive and reliable.
5.6.1.3. Provide recommendations for the operator interface to include alarms and on-line warnings or caution notes regarding safety conditions.
5.6.1.4. Develop test plans for related functions.
5.6.2. The test procedures should define tests that will appropriately stress the system and cause errors or potential malfunctions to occur. The objective of the test process should be to uncover as many errors as possible in the most expeditious manner. Testing is designed to address the events that the end user may encounter; however comprehensive testing of all possible event combinations is not possible. Therefore, analysis should be performed to define event combinations most likely to cause errors, based upon the probability and severity assessment for a given error condition.
5.7. PRODUCT RISK ANALYSIS (DESIGN OUTPUT)
5.7.1. Risk Analysis is an ongoing process and, therefore, the risk analysis is updated throughout the development process and the life cycle of the product.
5.7.2. A risk analysis is to be performed to document an assessment of the system identifying safety related areas, and specifying design criteria. If possible, a preliminary risk analysis is to be performed during the early design or concept phase. Since detailed design information is not typically available at this point, Fault Tree analysis is most suitable for this phase.
5.7.3. The list of safety risks is generated through consultation with research and development, management personnel as well as representatives from the user community. A candidate list of areas to be addressed includes the following:
Interfaces to other systems.
Environmental constraints such as EMI that may be experienced in the operational environment.
Operations, test and emergency procedures in case of system failures and shutdown.
Experience from previous department efforts and lessons learned regarding safety controls and potential safety risk conditions.
Risk related requirements for similar or related products as defined by domestic and international regulatory agencies.
Labeling and training requirements.
System redundancies, monitors, and fail-safe features to ensure safe operation.
5.7.4. Decisions regarding the adequacy of safety controls are to be analyzed in accordance with a risk model. The purpose of this model is to quantify the probability and severity and ensure that appropriate safety requirements have been defined. The model used shall be specified in the risk analysis.
5.7.5. Selection of the Cut-off RPN:
5.7.5.1. To manage the list of failures, it is appropriate to set a cut-off RPN, where any failure modes with an RPN above the designated maximum RPN receive immediate attention, and those below cut-off are left alone for the time being or possibly addressed through product labeling. For example, a cut-off of 100 of a 1000 scale (10%) would mean that any failure that has a low severity (5), once per year occurrence (4) and moderately high detectability (4) would fall below the RPN cut-off and could be reasonably assumed to be of acceptable risk. A failure that has a moderate or greater severity (6+), once per year (or more) occurrence (4) and moderately low detectability (4+) would fall above the RPN cut-off and would require further action.
5.7.5.2. An exception to the above would be if a very high severity event occurred with low probability, it would have a low RPN, yet still pose a probably hazard to either the patient or the user. To assure that this is not the case; any failure mode with a severity at 8 or above shall be reviewed regardless of its RPN number.
5.7.5.3. Example1: Maximum RPN = 1000; Report risk details with RPN > 100
5.7.5.4. Example2: Maximum RPN = 125; Report risk details with RPN > 12
5.7.6. Risk-Benefit Analysis
5.7.6.1. A Risk-Benefit Analysis will be included in the final risk report. There is no specific format for this. The main concern are risks with a high RPN, however, a risk with high severity and a low RPN must also be considered in this analysis.
5.7.6.2. Not all risks that have been identified can be removed. Residual risks need to be identified in the risk analysis and discussed in the context of a risk-benefit analysis
5.7.6.3. The risk-benefit analysis must cover all risks that have been identified, regardless of RPN number.
5.8. FAILURE MODES AND EFFECTS ANALYSIS
5.9. The Failure Modes and Effected Analysis (FMEA) consists of identifying the various modes of failure for a system and analyzing the effects of those failures. It is intended to isolate and identify areas where the system design can be strengthened to increase safety. A FMEA can be performed on subsystems of a larger system. This may be appropriate for a complex subsystem.
5.10. Several software tools are available to help construct an FMEA analysis; however, a spreadsheet is a typical format for documenting an FMEA.
5.10.1. The FMEA is a controlled process to be updated and maintained throughout the development phases and operational system lifespan using actual failure modes seen during development and test phases to enhance the analysis.
5.11. A FMEA is primarily used to evaluate failure modes for a defined system hardware and software functions. A Fault Tree Analysis (FTA) is better suited for analysis of potential misuse and abuse conditions. If FTA is not performed, the FMEA should include analysis of potential misuse and abuse conditions to ensure that these conditions are also addressed in the FMEA analysis.
5.11.1. The following is a summary of procedures to be used in the conduct of the FMEA.
5.11.1.1. Completely define the system to be analyzed including interface functions and hardware components. Block diagrams of system components are helpful to ensure all hardware components and interfaces are addressed. Be sure to include hardware alarms, sensors, and power sources. As appropriate, ensure that software safety related control and calculation functions are defined in addition to the hardware components.