MPMN_Medical Product Manufacturing News

Medical Product Manufacturing News, November/December 2015

Issue link:

Contents of this Issue


Page 10 of 27

Q M E D . C O M / M P M N M E D I C A L P R O D U C T M A N U F A C T U R I N G N E W S N O V E M B E R / D E C E M B E R 2 0 1 5 1 1 to avoid. According to the Association for the Advancement of Medical Instrumentation (AAMI), a medical software risk management plan must: • Describe how the software will be used in the device, i.e., its intended use. • Describe how the software will be developed. • Identify any development aspects unique to risk management. • Identify the risk acceptance criteria, if different from the risk acceptance criteria of other components. Once intended use has been established, per IEC 62304, manufacturers must classify their system in one of three safety classes. Class A is for systems that pose no threat of injury or damage to health. Class B is for software systems that may cause non-serious injury. Class C is reserved for systems that have the potential to cause death or serious injury. The standard, stipulates that "Class shall be set with the knowledge of physicians and the intended use" of the device. Risk planning also includes the creation of a risk management file for every software item undergoing risk management. The risk management file should include all records and documents generated during the risk management process, including all risk control measures and the methods used to verify those measures. Risk Assessment The purpose of risk assessment is to determine the product's potential to cause harm, with harm being defined as physical damage to people, property or the environment. Every medical device has the potential to present a hazard. The hazard can lead to a hazardous situation. The hazardous situation can cause harm. Hazards can occur during normal use (intended use), but more so if the device is misused. Hazards and hazardous situations feed into your product development process to improve user needs and design inputs. Hazards that cannot be eliminated by design are called residual risks. They must be assessed and accepted or mitigated by the product developer. In terms of software, potential causes of hazardous situations include: • Incorrect or incomplete specification of functionality. • Software defects in the identified software item functionality. • Failure our unexpected results for software of unknown pedigree, or SOUP, which by definition is deemed a risk. • Hardware failures of other software defects that could result in unpredictable software operation. • Reasonably foreseeable misuse. 4 Risk assessment is made up of three interconnected processes: risk identification, risk analysis, and risk evaluation. The terms risk analysis and risk assessment are often used interchangeably, but they are not synonymous. • Risk identification focuses on uncovering and describing as many of the potential risks associated with the application of your software as possible. • Risk analysis focuses on estimating the level of risk associated with each independent risk uncovered during risk identification. Failure modes and effects analysis (FMEA) and fault tree analysis are popular risk analysis tools. Risk management software is also available to help you assess and track risk (see Figure 1). • Risk evaluation focuses on comparing your risk analysis results with your organization's predetermined risk threshold. Best (and Worst) Ways to Assess Risk Best: Assemble a cross-functional team, not one comprised solely of development engineers, to brainstorm possible hazard or misuse scenarios. Different perspectives will increase your chances of uncovering more risks. The team should form early; remain active throughout design and manufacture; and understand the foundation standards listed above. Best: Consider the risks posed by the medical device as a whole before the software and hardware risks. Hardware risk analysis should then run alongside software risk analysis. Best: Integrate risk management into the design process from the get-go. It is easier and cheaper to address risks during design than it is during production or worse, once the product is in use. Of course, you'll want to revisit your risk assessment any time a change is made, such as in a bug fix. Worst: Skipping risk analysis or performing it casually. Every identified risk requires its own risk analysis. Worst: Addressing (mitigating) risk during the assessment phase; that's risk control. Risk Control Once you've assessed your risk, it's time to brainstorm mitigation methods you can implement to reduce it to an acceptable level. ISO 14971 provides three design options to consider in order of priority: change the design to eliminate risk; incorporate protective measures in the device or manufacturing process; or provide information in an operator's manual that explains what steps to take when conditions that could lead to a risk occur. You must verify each risk control measure you implement, and document the verification in the risk management file. Verification activities should be appropriate to the classification and risk of the device, and may include testing, simulations and code and document inspections. The software must also be validated in accordance with regulatory expectations, often with reference to the broader medical device. Your goal is to produce documentation that is suitable for inclusion with (or referenced from) the device master file. Before you proceed to the next phase, it's important to review the software output to see if your risk control measures generated any potentially hazardous situations that might interfere with existing mitigation measures or require additional measures. Review and Monitor Risk Once you have documented all outstanding software anomalies in the risk management file, review the file to determine whether or not it complies with your risk management plan and all applicable regulatory standards. Make sure you have included appropriate methods for collecting production and post-production information (such as incident reports, customer complaints) throughout the product lifecycle. Make sure this information is included in your risk management file. If it isn't, you will need to update it and start the risk analysis process over again. Remember, risk management never ends! It is—and should be—an inherent component of your software design process. Sources 1. US FDA Center for Devices and Radiological Health, Medical Device Recall Report FY 2003 to FY2012, downloads/AboutFDA/CentersOffices/ OfficeofMedicalProductsandTobacco/CDRH/ CDRHTransparency/UCM388442.pdf (accessed October 8, 2015). 2. Ravages of Miscalculations, http://www. We-Did-Nothing-Wrong/2 (accessed October 7, 2015). 3. CareFusion Runs into More 'Deadly' Trouble with Infusion Pump, http://www. more-deadly-trouble-infusion-pump/2014-05-21 (accessed October 16, 2015). 4. Risk Management in Medical Device Software Device Software Development, http://www. Life-and-Limb-Medical-Device-Software- Development-Risk-Management (accessed October 9, 2015). Lisa Weeks, a marketing communications specialist at MasterControl, writes extensively about technology, the life sciences, and other regulated environments. Before her tenure at MasterControl, she worked with McNeil Pharmaceuticals, SAP AG, SCA Mölnlycke Health Care, Crozer-Keystone Health Systems, and NovaCare Rehabilitation/Select Med. Connect with her on LinkedIn or GxP Lifeline. Figure 1: Risk management software is available to help you assess and track risk.

Articles in this issue

Links on this page

Archives of this issue

view archives of MPMN_Medical Product Manufacturing News - Medical Product Manufacturing News, November/December 2015