Скачать презентацию Root Cause Analysis and Failure Mode and Effects Скачать презентацию Root Cause Analysis and Failure Mode and Effects

8278eb9c232cd35be6abf1a00acc0e88.ppt

  • Количество слайдов: 56

Root Cause Analysis and Failure Mode and Effects Analysis Root Cause Analysis and Failure Mode and Effects Analysis

Learning Objectives • Discuss the utility of the root cause analysis (RCA) process in Learning Objectives • Discuss the utility of the root cause analysis (RCA) process in health care • Describe the steps of performing a failure mode and effects analysis (FMEA) in a health care setting • Explain the benefits of drawing from a multidisciplinary team to complete these evaluations

RCA of Medication Errors • Analytically identifies critical underlying reasons for the occurrence of RCA of Medication Errors • Analytically identifies critical underlying reasons for the occurrence of an adverse event or close call (near miss) • Answers these questions: – What happened? – Why did it happen? – What usually happens? – What should have happened according to policies and procedures? – What will prevent it from happening again? – What actions need to be taken? – How will outcomes be measured? • Any event has multiple root causes – Evaluating root causes can lead to changes that will break the chain of events and avoid the final breakdown

RCA of Medication Errors • Can be applied to one event or a series RCA of Medication Errors • Can be applied to one event or a series of events • Involves: – Presenting data clearly – Generating practical recommendations – Implementing appropriate corrective action – Establishing systemic controls to avoid recurrence

Consider the Environment • The reporting environment or culture in the workplace determines the Consider the Environment • The reporting environment or culture in the workplace determines the RCA • “The medical imperative is clear: To make health care safe we need to redesign our systems to make errors difficult to commit, and create a culture in which the existence of risk is acknowledged and injury prevention is recognized as everyone’s responsibility. ”* • People will not speak up if: – They fear punishment – They are accustomed to unsafe situations • A nonthreatening environment that fosters an open culture of reporting errors facilitates RCA *Leape LL, et al. JAMA. 1998; 280: 1444– 7.

Steps in RCA 1. 2. 3. 4. 5. Charter the team Document and research Steps in RCA 1. 2. 3. 4. 5. Charter the team Document and research Identify root causes Develop actions Establish outcome measures

Charter the Team • People – Multidisciplinary – Include those versed in the process Charter the Team • People – Multidisciplinary – Include those versed in the process but not directly involved with the incident • Places, tools, and time – Provide adequate meeting space, computer access, and time • Management support – Brief management – Obtain written consent for the allocation of assets necessary to complete the RCA

Document and Research • Use the preliminary report to write a description of the Document and Research • Use the preliminary report to write a description of the event • Collect data relevant to the event – Policies, photographs, equipment involved, etc. • Interview key participants in the event • Gather credible references that may assist in understanding the event • Rewrite the event description, adding the new information

Identify Root Causes • Create a diagram of the flow of events – Trace Identify Root Causes • Create a diagram of the flow of events – Trace the chronology of events that led to the adverse event or close call (see Figures 5 -1 and 5 -2 in the textbook for examples) – Examine the process to find weaknesses: • Include what really happened, not what was supposed to happen • At each step of the event flow ask “Why? ” • Provide the RCA teams with easy-to-use tools to increase the probability that all teams will be equally rigorous over time • Table 5 -1 illustrates questions for an “initial understanding” that a team must consider to discover what happened and how to prevent a recurrence – Figure 5 -3 shows a sample cause-and-effect fishbone diagram for analyzing events – Write a concise cause-and-effect statement based on the findings in the diagram

Event Flow Diagram of “Initial Understanding” • A hospitalized patient was treated with heparin Event Flow Diagram of “Initial Understanding” • A hospitalized patient was treated with heparin and warfarin • The patient’s therapy was changed and restarted, and eventually he experienced fatal bleeding

Event Flow Diagram of “Final Understanding” • RCA team conducted interviews and uncovered several Event Flow Diagram of “Final Understanding” • RCA team conducted interviews and uncovered several processes that contributed to the high level of anticoagulation • The final understanding diagram contains information that was discovered through investigation of system-level causes

Fishbone Diagram of Anticoagulation Events • The Ishikawa fishbone diagram is used in aggregated Fishbone Diagram of Anticoagulation Events • The Ishikawa fishbone diagram is used in aggregated RCA of anticoagulation-related events • Notations on branches indicate the portions of the process associated with an adverse event

Develop Actions • Team should state the actions members took to address the root Develop Actions • Team should state the actions members took to address the root cause(s) of the errors – Action statement should be readily understood (specific and concrete) – Conduct a trial of the actions to address the problems, if possible – Action statement should have buy-in from process owners • Goal is to prevent a recurrence of the same close call or adverse event or at least to minimize it – Actions should be permanent and physical, not temporary and procedural – Actions should not be asking providers to “pay more attention next time” – Avoid unnecessary training or new policies – Table 5 -2 in textbook lists examples of actions proposed in RCA

Establish Outcome Measures • Include measures for evaluating whether the actions prevent future events Establish Outcome Measures • Include measures for evaluating whether the actions prevent future events • Outcome measures should: – Not only measure whether the action was completed but whether the action was effective – Be quantifiable and, when appropriate, include clear numerators and denominators – Clearly define the strategies and include the frequency and time frame for monitoring – Include a threshold or goal, and ensure it is realistic

Aggregated RCA • Some types of events occur fairly often but do not always Aggregated RCA • Some types of events occur fairly often but do not always result in serious harm • A facility may not have the resources for individual analysis of every event, and batch analysis of these events may be advantageous • The process for aggregated review is similar to the individual RCA except a subset of events is chosen for more review and action planning • RCA team members often serve for 1 year to provide efficient use of resources and consistency among analyses • Aggregated review teams can be more creative in their approach to the analysis because there is no single event • Teams should ensure that RCA does not become routine; employ a variety of tools (e. g. , floor plans, diagrams, bar charts)

Aggregated RCA at VHA Facilities • Aggregated review required for potentially serious events (e. Aggregated RCA at VHA Facilities • Aggregated review required for potentially serious events (e. g. , patient falls, missing patients, parasuicidal events, adverse drug events) • VHA determines severity using the matrix shown in Table 5 -3 • Key factors in determining severity of events – Extent of injury – Length of stay – Level of care required for remediation • Actual events with a score of 3 require RCA • For potential adverse events, severity is assigned on most likely worst -case systems scenario • Potential medication events with a score of 3 can be analyzed individually or in quarterly aggregate RCA • Visit the Department of Veterans Affairs (VA) Web site for details of the process: www. patientsafety. gov

System-Level Vulnerabilities • Primary tasks of RCA team – Identify the system-level features and System-Level Vulnerabilities • Primary tasks of RCA team – Identify the system-level features and processes • Ask the correct questions to uncover the causes • See Table 5 -1 of textbook for questions to assess system-level vulnerabilities – Shore up systems and processes that contribute to safety – Eliminate or control those that make things more dangerous • RCA team can utilize tools efficiently and comprehensively determine the flow of events – Revisit the “initial understanding” event flow diagram (Figure 5 -1) • RCA team should state the findings clearly and with sufficient detail for easy identification of the system-level vulnerabilities (root causes or contributing factors) that need to be fixed

System-Level Vulnerabilities • Helpful guidelines in writing statements about root causes and contributing factors System-Level Vulnerabilities • Helpful guidelines in writing statements about root causes and contributing factors – Show cause and effect (e. g. , nearly identical packaging) – Phrase findings to avoid negative statements about people or things – Focus on system-level problems, not individual performance – Get to the norms behind procedural violations – Remember that failure to act is causal only when there is a preexisting duty to act

Human-Factors Engineering • Human-factors engineering: the study of how people interact and work successfully Human-Factors Engineering • Human-factors engineering: the study of how people interact and work successfully with other people and things in their world, and how to increase success or improve human performance by “designing-in” physical or environmental cues or processes • Examples of the actions proposed in RCA using design-in safety – Physically separate look-alike and sound-alike products – Build in redundancy, double checks, and fail-safe features – Test usability • Institute for Safe Medication Practices (ISMP) maintains that the failure of device manufacturers to consider principles of humanfactors engineering can contribute to user error – See textbook pages 75– 7 for detailed description of need for focus on human factors in device design Gosbee L, et al. In Manasse H, et al. , eds. Medication Safety: A Guide for Health Care Facilities. Bethesda, MD: American Society of Health-System Pharmacists; 2005.

Human Factors in Device Design: Medtronic Synchro. Med Infusion Pumps • Reports to the Human Factors in Device Design: Medtronic Synchro. Med Infusion Pumps • Reports to the Food and Drug Administration (FDA) describe accidental intrathecal injections of concentrated morphine during attempts to refill Medtronic Synchro. Med infusion pump, resulting in fatal overdosages • The pump is titanium and described as the size of a hockey puck • The pump is surgically implanted under the skin of the abdomen or flank and has a catheter that resides in the intrathecal space • The small injection port on the front allows the drug supply to be replenished via passage of a thin needle through the skin into the port and thus into the drug reservoir • A template to help locate this reservoir is included in the kit • The problem arises because there is also a catheter access kit for the device and its template is similar looking • Identical-looking kits are the problem

Human Factors in Device Design: Synchro. Med Implantable Infusion Pump Implantable infusion pump Refill Human Factors in Device Design: Synchro. Med Implantable Infusion Pump Implantable infusion pump Refill kit template (above left) and catheter access kit template (above right)

Human Factors Recommendations • Use patient-controlled analgesia (PCA) pumps that read bar codes to Human Factors Recommendations • Use patient-controlled analgesia (PCA) pumps that read bar codes to automatically set the concentration – Strive to use a single concentration of analgesics – Avoid stocking and using multiple concentrations of the same drug that differ by a factor of 10 (e. g. , 0. 5 mg/m. L and 5 mg/m. L of morphine) • Carefully position syringe labels so important drug information can be seen readily during pump setup and infusion • Monitor patients frequently and have antidotes readily available • Consider using oximetry and capnography for PCA patients and those on continuous narcotic infusions

Human Factors Recommendations • When new devices are purchased, use failure mode and effects Human Factors Recommendations • When new devices are purchased, use failure mode and effects analysis (FMEA) to proactively identify design flaws and all points at which user error might occur • Establish a system of independent double checks when highalert medications are administered • Avoid using pumps with a priming function that can deliver a bolus during infusions • If patients or family members will be using medication delivery devices, provide them with clear spoken and written instructions; alert them to potential user error with the devices; require return demonstrations with sufficient practice to ensure competency • Report drug-related device failure and user error to the USPISMP Medication Errors Reporting Program and to FDA so timely action can be taken to alert others to problems

Actions and Outcomes • Obstacles can derail the RCA team’s work – Lack of Actions and Outcomes • Obstacles can derail the RCA team’s work – Lack of information about exactly why things happened – Too broad or too narrow a focus – Frequently recurring events • Events happen again before corrective action implemented • Ways to work through obstacles – Collecting additional information through interviews with a broad range of staff, patients, and families – Simulating the event – Focusing on the situation at hand – Focusing on what can be done to prevent a similar situation rather than becoming “hypnotized” by the event – Researching what has been done in similar situations by using research tools such as the Web and professional colleagues

Utility of RCA in the Medication-Use Process • Example Case: patient received a large Utility of RCA in the Medication-Use Process • Example Case: patient received a large dose of phenytoin suspension, resulting in mild toxicity – Immediate reaction, blame the nurse – The RCA team, instead, found that system-level issues existed – The resident who ordered the drug was confused about how to express the dose in the order entry software – The pharmacist finishing the electronic order was distracted – The medication was supplied to the nurse in bulk bottles instead of unit-dose packaging • Fixing these system-level issues yields larger benefits because more than one patient and more than one nurse could be affected

Utility of RCA in the Medication-Use Process • Example Case: an RCA team looked Utility of RCA in the Medication-Use Process • Example Case: an RCA team looked at an event related to the use of floor-stock IV solutions – Blaming the nurse for selecting the wrong IV solution would have been easy – The RCA team, instead, looked into how the products were replenished and the process for oversight of the items in automated dispensing machines – Systems-level improvements were implemented: • Dispensing IV solutions with additives through the pharmacy – Patients benefited from this action and nurses were freed from some materials management activity

Tracing System-Level Vulnerabilities: Case Report by the ISMP • Partial patient identifier – A Tracing System-Level Vulnerabilities: Case Report by the ISMP • Partial patient identifier – A handwritten order for carbamazepine 400 mg twice daily for an adult patient was received by the pharmacist – The patient profile was retrieved by typing the last name only – The pharmacist inadvertently entered the medication into the profile of a 4 -year-old child with the same last name • Computer system weaknesses – The pharmacist did not recognize that the dosage would be an overdose for a small child – The patient’s age was not in a prominent location on the order entry screen – The pharmacist could not match the prescribed medication to the patient’s medical condition because the patient’s diagnoses and comorbid conditions were not listed on the pharmacy profile – Computer system did not require entry of a weight for pediatric patients – No functional dose alerts in the system

Tracing System-Level Vulnerabilities: Case Report by the ISMP (continued) • Nonstandard medication administration record Tracing System-Level Vulnerabilities: Case Report by the ISMP (continued) • Nonstandard medication administration record (MAR) checks – The MAR was delivered to the patient care unit that night, but the nurse did notice the error – MAR verification was not standardized in the hospital; different nurses doing it different ways, if done at all – No official policy requiring MAR verification, no written procedures, and process not addressed during nursing orientation • Adult dose and dosage form for a child – The next morning, the nurse crushed the pills and gave the 4 -year-old patient the erroneous dose, failing to recognize it as too high for a child – Nurse did not question why tablets were sent for a 4 -year-old child – Nurse did not inquire about a more suitable dosage form; the drug is available in chewable tablets and as a liquid suspension • Unverified patient history – Nurse who administered the first dose assumed the child was receiving carbamazepine because he had a history of seizures

Tracing System-Level Vulnerabilities: Case Report by the ISMP (continued) • Unverified patient history (continued) Tracing System-Level Vulnerabilities: Case Report by the ISMP (continued) • Unverified patient history (continued) – The child did not have history of seizures, but the nurse verbally passed that erroneous information to the nurses on the next shift, and so on the information was passed – The child received three more doses in error, from three different nurses • Language barrier – The child’s parents were present when one dose was given – The nurse tried to tell the parents the medication was used to control seizures – The parents and the child had a limited understanding of English and could not intervene to correct the erroneous seizure history • Poor physician access to MAR – The physician did not detect the error during routine rounds – The nursing MAR was not readily accessible for review – No electronic or pharmacy computer-generated summary of prescribed therapy on the chart

Tracing System-Level Vulnerabilities Case Report by the ISMP (continued) • Poor physician access to Tracing System-Level Vulnerabilities Case Report by the ISMP (continued) • Poor physician access to MAR (continued) – The physician did notice that the child was not receiving the medication he prescribed – The error was detected when the child became lethargic, developed nausea and vomiting – At this point the nurse suspected a problem with the dose and contacted the physician – The physician stated he had not prescribed carbamazepine for the patient – The child’s carbamazepine level was 18 mcg/m. L (normal therapeutic range is 4– 12 mcg/m. L) – This error delayed the child’s discharge, although he recovered without further problems • Errors are almost never caused by the failure of a single element in the system • Underlying system failures lead to errors that often can be identified through RCA

Ambiguous drug order Communication No maximum dose warnings Poor physician access to MAR Drug Ambiguous drug order Communication No maximum dose warnings Poor physician access to MAR Drug information Verbal reporting Environmental Staff factors education Language barrier Patient education Latent Failure Model of Complex System Failure Modified from James Reason, 1991.

ISMP Case Report Discussion • Use two patient identifiers (e. g. , full name, ISMP Case Report Discussion • Use two patient identifiers (e. g. , full name, identification number, date of birth) to verify patient identity when entering orders • Ask the pharmacy system vendor to build “look-alike patient name” alerts into the order entry system for activation when more than one patient has the same last name • Use a computerized prescriber order entry (CPOE) system that is interfaced with the pharmacy computer system to eliminate the need for pharmacy order entry • Post a daily electronic or computer-generated summary of prescribed medications on each patient’s chart

ISMP Case Report Discussion • Standardize, document, and require the use of an MAR ISMP Case Report Discussion • Standardize, document, and require the use of an MAR verification process whenever new MARs are distributed (or rewritten) • Teach nurses to compare the pharmacy label (on dispensed medications) with the initial MAR entry before the first dose is administered to ensure that the pharmacist’s and nurse’s interpretation and transcription of a medication order is correct • Require documentation of medical history (including comorbid conditions) on order entry screens, MARs, and other records used during change-of-shift reports • Require recalculation of all doses of pediatric medications before the drug is dispensed (pharmacists) and during initial order transcription/verification onto the MAR (nurses) to ensure the dose is appropriate

ISMP Case Report Discussion • Require the entry of weight in computer systems before ISMP Case Report Discussion • Require the entry of weight in computer systems before orders for pediatric patients can be processed • Build and test maximum and subtherapeutic dose alerts in the order entry system (based on patient age and weight when applicable) • Encourage nurses to investigate the possibility of an error if drugs for pediatric patients are dispensed in adult dosage forms • Provide translators or written information for teaching patients and families about diagnoses, treatment plans, and newly prescribed medications • Establish a process for thoroughly investigating all “missing” medications before asking nurses to resend an order or before dispensing the medication again

Health Care Failure Mode and Effects Analysis Health Care Failure Mode and Effects Analysis

Introduction to Failure Mode and Effects Analysis • Failure mode analysis (FMA) – Used Introduction to Failure Mode and Effects Analysis • Failure mode analysis (FMA) – Used to find potential risks in a system or product by identifying all the ways it could possibly fail – Analyzes why failures occur – May refer to specific types of failure or to degrees of failure – Outgrowth of quality control concerns • Failure mode and effects analysis (FMEA) – A risk assessment method – Based on simultaneously analyzing failure modes, their consequences, and associated risk factors – Useful in the design stage as well as in the post hoc analysis – Used most extensively in high-risk areas or by high-cost industries • FMA and FMEA have been used to reduce the frequency and consequences of failures

Failure Analysis • Historically – Failures were retraced in a sequential, linear narrative until Failure Analysis • Historically – Failures were retraced in a sequential, linear narrative until the fault was found • Today – Many subsystems at play, thus a linear perspective is not always effective in finding the failure – More complex systems require systemic analyses of both production and product failures – Both FMA and FMEA use systemic analyses • Systemic analysis does not require that events follow a single story, but simultaneous examination of all stories • FMA asks, “What has failed, what could fail, and how? ” • FMEA asks, “Given the various possibilities for failure, what are the potential consequences of each? ”

Human Error and FMEA • An estimated 70% to 90% of all accidents are Human Error and FMEA • An estimated 70% to 90% of all accidents are a result of human error • Human failures are often equated with blame, which is more suited to the linear narrative • The assumption – Human error is unpredictable, therefore the systemic analysis approach is often not utilized to find the source of the problem • The reality – Human errors are drawn from the limited set of meaningful things that an individual can do in any defined situation • Theoretically, human errors are capable of a priori discovery and analysis because the spectrum of errors is limited Denning PJ. Human error and the search for blame. RIACS Technical Report TR-89. 46; 1989.

Applying FMEA to Medication Error Prevention • FMEA asks what will happen if a Applying FMEA to Medication Error Prevention • FMEA asks what will happen if a health care provider: – – – – Mistakes one medication for another because of the packaging Administers the wrong drug or dose Gives a drug to the wrong patient Administers a drug by the wrong route or at the wrong rate Omits a dose Gives a drug at the wrong time Takes any action that may produce a medication error • FMEA may reveal in some cases that: – The patient can tolerate the error – The error will be intercepted by the checks and balances built into the health system’s quality improvement processes – Specific steps must be put in place to address potential errors that are intolerable

Designing Error Traps Can Prevent Errors From Becoming Accidents Knowledge Performance Error Safety System Designing Error Traps Can Prevent Errors From Becoming Accidents Knowledge Performance Error Safety System (Error Trap) Accident Prevention

Learning About Potential Failure Modes From Reported Errors • Essential to develop a database Learning About Potential Failure Modes From Reported Errors • Essential to develop a database of error modes by creating a uniform and rational system of reporting errors and including those that have not resulted in patient injury and near misses – Locally (within a facility) or through larger databases • ISMP is collecting this information in the United States, Canada, and Spain • A standard approach to reducing failures in mechanical and electronic systems is the introduction of redundancy in critical subsystems • Multisensory channels could be used to prevent errors – Example: changing the feel of packaging by making the syringe rough or square

Application of FMEA • FMEA utilizes before-the-fact evaluation rather than RCA performed after an Application of FMEA • FMEA utilizes before-the-fact evaluation rather than RCA performed after an error • RCA is essential, but analyzing processes and products before problems occur is equally important to an organization’s comprehensive medication error reduction strategy • FMEA proactively identifies ways in which products or processes can fail, why they might fail, how they can be made safer • FMEA must employ an interdisciplinary team approach • The Joint Commission requires a proactive risk assessment tool and many organizations have chosen FMEA Joint Commission on Accreditation of Healthcare Organizations. Failure Mode and Effects Analysis in Health Care: Proactive Risk Reduction; 2002. Institute for Healthcare Improvement. Failure mode and effects analysis tools. Available at www. ihi. org

An Application of FMEA • Quantitative steps for FMEA approach – Choose a high-risk An Application of FMEA • Quantitative steps for FMEA approach – Choose a high-risk process or product vulnerable to error – Assemble an interdisciplinary team including those who prescribe, dispense, administer, and monitor – Describe and document the process – Determine potential areas where errors may occur by looking at why errors might happen considering areas such as the patient’s age, tolerance to certain drugs, physician knowledge about the medication – Decide if the potential errors are unacceptable by looking at consequences for the patient and domino effect on the process – Prioritize and take action to eliminate or reduce unacceptable errors – Make sure the actions have been successful • Table 21 -1 illustrates the use of FMEA for analyzing PCA • Table 21 -2 illustrates the quantitative measure for the FMEA

VA Approach to FMEA • Healthcare FMEA (HFMEA) was developed by the VA National VA Approach to FMEA • Healthcare FMEA (HFMEA) was developed by the VA National Center for Patient Safety (NCPS) • HFMEA combines FMEA and the FDA’s hazard analysis and critical control point (HACCP) concepts and decision tree with definitions and tools from the VA’s RCA process • NCPS found FMEA systems used successfully in industry needed modification for use in evaluating health care processes – Table 21 -3 in textbook outlines the sources of concepts used in HFMEA – Table 21 -4 in textbook compares HFMEA and RCA – Specific terms used in HFMEA are defined on pages 577– 8 in the textbook

HFMEA Steps 1. 2. 3. 4. 5. Select a topic Assemble the team Graphically HFMEA Steps 1. 2. 3. 4. 5. Select a topic Assemble the team Graphically describe the process Conduct a hazard analysis Develop actions and outcome measures

HFMEA Steps: Selecting a Topic • Topic should not be too broad or too HFMEA Steps: Selecting a Topic • Topic should not be too broad or too narrow • Patient safety officer (PSO) or medication safety officer along with the quality or risk manager should select the topic • The Joint Commission advises the use of available information about sentinel events known to occur in health care institutions that provide similar care and services • Topic should have value to the institution and be justifiable to auditors • PSO should complete a rough flow diagram, using topic selected, to outline the primary process steps as used in that hospital • PSO should then select five or six steps that will be the narrow focus of the HFMEA • Sample flow diagram of HFMEA is shown in Figure 21 -2 of textbook

HFMEA Steps: Forming a Team • The HFMEA team should be multidisciplinary – Ensures HFMEA Steps: Forming a Team • The HFMEA team should be multidisciplinary – Ensures multiple viewpoints are considered • Including people who do not know the process ensures critical review of the accepted standards and practices and identification of potential vulnerabilities that others might miss – Reduces disciplinary bias • Having at least two subject matter experts on the team improves chances that the analysis has technical merit • Designate a team leader and a team recorder • PSO usually serves as an advisor and consultant

HFMEA Steps: Graphically Describing the Process • Develop the process flow diagram and verify HFMEA Steps: Graphically Describing the Process • Develop the process flow diagram and verify it • Number the process and subprocess steps on the flow diagram – A sample of subprocess steps is illustrated in Figure 21 -3 in the textbook

HFMEA Steps: Conducting a Hazard Analysis • Select a part of the process and HFMEA Steps: Conducting a Hazard Analysis • Select a part of the process and conduct a hazard analysis, listing and numbering all potential failure modes for each part • Teams should employ different methods for identifying potential failure modes – NCPS triage cards for RCA – Brainstorming – Cause-and-effect diagramming • Determine severity and probability and resulting hazard score – Table 21 -2 provides the hazard score matrix – Table 21 -5 presents the HFMEA definitions of severity • Use a decision tree to determine course of action – Figure 21 -4 shows a hazard analysis decision tree • Complete a separate worksheet for each failure mode – Table 21 -6 provides a sample failure mode worksheet

HFMEA Steps: Conducting a Hazard Analysis • The team completes the scoring for each HFMEA Steps: Conducting a Hazard Analysis • The team completes the scoring for each failure mode before moving on to failure mode causes • Assess the failure mode if the hazard score is 8 or higher • Team does not need to determine causes for low hazard failure modes – Low hazard failure modes are prioritized for action if the hazard is a single-point weakness • High hazard scores are de-emphasized if the failure mode has an existing control measure or if it is detectable before the event would occur – Example of detectable hazard: a missing patient wristband

HFMEA Steps: Developing Action and Outcome Measures • Team develops a description of actions HFMEA Steps: Developing Action and Outcome Measures • Team develops a description of actions for each failure mode selected for remediation – Identifies outcome measures – Designates a single person responsible for completing each action • Outcome measures for these actions could include setting a date for checking to ensure that the module has been activated and setting a date for testing the system • A critical step is ensuring the system functions effectively and new vulnerabilities have not been introduced elsewhere • Leadership of the organization needs to be committed to each recommended action – If management does not concur, the team should revise the action

The VA Experience • VA used HFMEA with the topic: assessment of hospitals’ contingency The VA Experience • VA used HFMEA with the topic: assessment of hospitals’ contingency processes for failure of the electronic bar code medication administration (BCMA) system – All VA facilities are required to have up-to-date and well-tested contingency plans for medication administration – NCPS staff prepared supporting documents and guidelines – All VA facilities submitted HFMEA reports to NCPS in the fall of 2002 – An HFMEA project reviewed the best ideas from around the country – Software to help facilities nationwide be in constant readiness during BCMA downtimes was released – Disasters, such as hurricanes and power failure, tested this but no facility reported any major problems • VA has found that staff now using HFMEA on more projects

Tips for Performing HFMEA • Think of failure modes as “what could go wrong” Tips for Performing HFMEA • Think of failure modes as “what could go wrong” • Think of the failure mode cause as “why” the failure would occur • Present failure modes as a problem statement that needs to be corrected • Ensure that the team diagrams the flow diagram steps that actually occur, not the ideal process • Once the team has diagrammed a process, post the flow charts in the work area because staff not serving on the team may have ideas for additional steps that have been forgotten or failure modes that no one has suggested • After the team develops the process diagram, have team members visit the work area to observe staff performing the process and verify that their assumptions are correct • Follow the numbering and lettering format for the process and subprocess diagrams

Tips for Performing HFMEA • Chronological event flow diagrams used in RCAs are different Tips for Performing HFMEA • Chronological event flow diagrams used in RCAs are different from process flow diagrams used in HFMEA – RCA event diagrams show what actually happened on the day of the event – HFMEA process diagrams depict the usual activities • For a failure mode or failure mode cause to be classified as “detectable” on the HFMEA decision tree, it must be so visible and obvious that it will be discovered before it interferes with completion of the task or activity • A single individual should be identified for follow-up on the corrective actions identified on the HFMEA worksheet • Use the most recent HFMEA worksheet; for the current version visit to the VA Web site: www. patientsafety. gov

Tips for Performing HFMEA • Conduct a hazard analysis on the failure mode before Tips for Performing HFMEA • Conduct a hazard analysis on the failure mode before identifying failure mode causes, so time is not spent identifying causes when it is not necessary • Pick projects of manageable size • Failure modes can be tough to brainstorm – Teams can use the literature, the facility’s own events, ISMP medication safety reports, similar failures from other industries, and the experience of team members – If teams get stuck, they should take a break or use creativitybuilding exercises to improve the flow of information – Cause-and-effect diagrams can help by constantly raising the question “Why? ”

References Denning PJ. Human error and the search for blame. Research Institute for Advanced References Denning PJ. Human error and the search for blame. Research Institute for Advanced Computer Science. Technical Report TR-89. 46; 1989. Gosbee L, Burkhardt M. Application of human factors engineering in process and equipment design. In: Manasse H, Thompson K, eds. Medication Safety: A Guide for Health Care Facilities. Bethesda, MD: American Society of Health-System Pharmacists; 2005. Institute for Healthcare Improvement. Failure mode and effects analysis tools. Available at: www. ihi. org Joint Commission on Accreditation of Healthcare Organizations. Failure Mode and Effects Analysis in Health Care: Proactive Risk Reduction. Oakbrook Terrace, IL: Joint Commission Resources; 2002. Leape, LL, Woods DD, Hatlie MJ, et al. Promoting patient safety by preventing medical error [editorial]. JAMA. 1998; 280: 1444– 7.