Congratulations! Your organization has gained regulatory approval and launched its medical device product. The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past. However, several components of the DHF continue as a reference and evolve, including requirements and risk management. Here are 3 ways active management of requirements and risk continues after commercialization:
1: Post-market surveillance
Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised. That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions. As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.
As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered. A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk. Depending on the outcome, corrective action may be needed.
For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch. The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file. Given the low risk and lack of trend, further failure investigation and corrective action were not taken. However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk. This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.
As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.
2: New Products
Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.
The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products. A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another. Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.
3: Change Control Evaluation
Change control evaluations is another way management of requirements and risks continue after commercialization. Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.
Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact. Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.
For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient. The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns. There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs. The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time. A change owner is assigned to identify and evaluate a new sensor. This person is most likely not the same engineer who originally designed and selected the first sensor. And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected. This is where having accessible and well managed requirements and risk management becomes important. The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.
While change post-commercialization is inevitable, difficult change control management is not.
RELATED POST: Product Development Process: How Confident Are You That You Are Not at Risk?
Beyond Commercialization
Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market. Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.