2019年 4月 4日
EMERGO BY UL SUMMARY OF KEY POINTS:
Medical device design and development processes in the context of risk management require careful consideration and planning by manufacturers. Following our webinar in early 2019, we explore five key issues companies face when linking design and development with risk management and, ultimately, patient safety.
Risk/Benefit analysis is required in clause 6.5 of ISO 14971, but there is very little guidance on what is expected. How do risk/benefit analyses impact design controls?
Risk/benefit analyses are very much device-specific and context-dependent. Generally it is expected that the clinical data on benefits and risks demonstrates acceptability for all medical conditions and target populations covered by the intended purpose as compared to the current state of the art.
Therefore, the current knowledge/state of the art needs to be identified; that is, manufacturers should identify relevant (similar) benchmark devices and medical alternatives available to the target population. Information should then be gathered on the risks and the benefits of the devices and treatment alternatives.
With this information, a comparison can be made between the “new” device and relevant benchmark devices and/or medical alternatives, assessing both risks and benefits. Because such comparisons can be subjective in nature, and require specialists knowledge to accurately assess, clinical input is critical. During the comparison, it may be found that limitations to the intended use of the device or to the medical indications for some populations, and/or medical conditions may be necessary to achieve an acceptable risk/benefit balance. Further, individual risks associated with some specific device feature or performance element may warrant limitations or restrictions (design controls) to achieve an acceptable risk/benefit balance.
Product risk management is owned by the manufacturers, but how can service providers (e.g. software developers) contribute to safe design?
First and foremost, it must be understood that any element outsourced by an end-equipment manufacturer nonetheless remains their responsibility. That is, in accordance with the FDA QSR 820.50, and ISO 13485 Clause 7.4, end-equipment manufacturers are ultimately responsible for their product, including where product elements, such as software, are outsourced.
That said, suppliers may demonstrate their commitment to providing a high level of integrity through compliance with ISO 13485. Note that one of the changes introduced in ISO 13485:2016 was the provision that suppliers or other external parties providing product to organizations can also choose to comply with the standard.
Beyond compliance with ISO 13485 (and IEC 62304), software developers can and should collaborate closely with their end-equipment manufacturers to ensure design requirements are understood and implemented correctly, and that appropriate feedback loops are in place as design options are considered. This is due to the fact that there are situations where software risk controls may unintentionally subvert safety risk controls or features, and vice-versa.
For example, consider a reasonable cybersecurity risk management design selection to include a password for system access; such a design control may have serious consequences in devices such as a defibrillator. Consider that ready user access to and application of a defibrillator is essential to achieving the intended performance of the device (delivery of life-saving therapy); any delay in a user’s access to use of the device, such as attempting to enter a password (which they may not know) would be unacceptable.
Accordingly, software developers can contribute in very meaningful ways to the safe design of products. Careful consideration should be made as to appropriate mechanisms for collaboration between end-equipment manufacturers and their service providers.
Do questions (and the answers) from Annex C have to be included in risk analyses?
Please note that Annex C is identified in the text of ISO 14971 as "informative." In ISO standards, Annexes are used to provide additional information. They can be normative (e.g. a test method that the user is required to follow) or informative (additional information that complements the user’s understanding). As such, it is not necessary to include the questions and answers from Annex C in your risk analysis.
However as a practice, review and documentation of this assessment are encouraged, even if not subject to regulatory and audit review. Consider treating the Annex C question and answer information as the start of a brainstorming session to identify, as comprehensively as possible, all risks associated with your device. It is also worth noting that we have seen organizations that have reviewed and documented their responses to the Annex C questions, yet they have treated the activity as a “checkbox exercise.” Meaning, they completed the activity but then did nothing with the information captured.
The Annex C questions comprise a rich set of data points to aid in establishing an understanding of the hazards and hazardous situations to be considered in the risk analysis, and provide a strong foundation upon which to build design input requirements.
How does one identify risks for a new device not on the market, and not similar to other devices?
It is rare for a device to be totally new to the market where there are no similarities to other devices, whether or not those devices have been previously used for a medical purpose. Consider that an existing device may incorporate a feature or technology similar to a new device for a medical indication that is entirely different from the current medical indication being contemplated.
As a starting point, review other devices having a similar intended use, similar principles of operation or a similar technology used in non-medical fields, or, for medical indications other than that currently contemplated.
Consider workflows, and information flows; recognizing that failures to perform tasks correctly, or corruption or breakdown of information flows, can lead to significant hazards and hazardous situations.
Also, generate a list of hazards and hazardous situations by responding to the questions of ISO 14971, Annex C. From there, look to other products facing similar hazards and hazardous situations. Again, these other devices may or may not be medical devices, or may be for use in other medical indications. Such a review will frequently help to identify risks that are evident from use of the feature or technology in other applications.
Scaling risk seems somewhat subjective, so how can this be reliable?
Establishing risk acceptability criteria, and the necessary task of creating scales for severity of harm and probability of occurrence, are frequently misunderstood and do indeed affect the overall risk management process. To improve the reliability of the risk scales, and therefore the overall risk management process, it must first be understood that the criteria and their scales can and should be tailored to the device in question.
Of course, the criteria and scales may be appropriate for a class of products or a family of devices; nevertheless, research should be performed to understand the type and severity of harm and the frequency of occurrence that has been experienced with the device in question. Scaling risk is then accomplished by considering the severity and probability elements separately.
From a severity point of view, seek the input of clinicians experienced in treating the medical condition that your device is intended to address, and who are familiar with the harms associated with such devices. A search of the US FDA MAUDE database, internal proprietary information and other sources will also reveal the types of events that have occurred. Such efforts will frequently suggest appropriate severity classifications for the device in question.
Next to be considered is the probability of a particular event. From the same sources used for identifying severity scales, information is also typically available to derive probability scales. Note that a one-size-fits-all approach is not realistic or recommended. We have seen, for example, instances where probability scales are defined as “0.01≥ Occurrence > 0.001”, “0.001≥ Occurrence > 0.0001” and so on, without any reference to whether the scale is based on probability of harm per use, per device, per hour of use, or within a population. Obviously this must be defined, and will depend entirely on whether the device is a sterile dressing, a therapeutic x-ray machine, a patient monitor, etc. Capturing the information described will assist in establishing risk scales aligned with actual device use, considering both the observed degree of harm and the frequency.
Mark Leimbeck is Chair of the UL Health Sciences Council.