Medical Device Design Control (Part 3 of 3)

By laurencesampson

Medical device product development work is a highly integrated, and regulated process. Implementation of a requirements tracking solution requires attention to a variety of nuanced topics. In this 3-part series, we present a practical approach derived from real-world experience developing medical devices using Polarion solutions. In this third and final installment, we look into Document Definition.

(Continued from Part 2)

Document Definition

The next step is document definition. In this phase, it is determined which documents will be used to contain each of the relevant work items, and how the documents will be approved. Some of the documents expected by regulators are included below:

Regulatory Requirements Analysis

There are typically two documents used in the development process that are generated by the regulatory department.

Regulatory Analysis – In this analysis the regulatory department analyzes the new product to determine regulatory requirements including:

Device markets and areas of legal jurisdiction

Device classification(s)

Accessory needs

Other regulatory requirements related specifically to the device in development

Clinical Evaluation Report (CER) – This report has a variety of names, but is a summary of the performance of the device or similar device in the field. It pulls from public and company records to determine the type of user harms/severity found in the general use population, and the frequency of occurrence. This data forms the basis of the initial risk analysis and provides a solid foundation to the design requirements. Regulatory evaluation is a good example of company generated requirement sources. Other examples include design best practice, legal liability, and SOPs used to reprocess international standards.

Risk Management

Risk management is broken down into three documents. The content for the Risk Analysis is originated in several more:

The Risk Management Plan

Risk Analysis
- DFMEA
- PFMEA
- Harms
- Hazardous Situations
- Harms based Fault Tree Analysis (FTA) – Database traceability table

Risk Management Report

Some of the structure of the document artifacts are mandated. For example, ISO requires that the Risk Analysis take a Harms-based approach. Consideration should also be given to assure that the documents contain all of the information required by law. Examples include:

Risk Management Plan ( EN ISO 14971:2009, The plan shall include the following: Scope of activities… assignment of responsibilities… criteria for acceptability… verification activities… activities related to collection and review )

Risk Management Report ( EN ISO 14971:2009, The review shall at least ensure the risk management plan has been appropriately implemented… the overall residual risk is acceptable… methods are in place to obtain relevant production and post-production information )

One way to accomplish this would be to pull federal registers into the Polarion tool as requirement documents. These legal requirements would be satisfied by the company SOP requirements, or an ISO Standard, which would in turn be satisfied by compliance of the design documents to the company SOP. What better way to establish the audit traceability from the requirement source to the design document evidence? When asked in an audit, the company compliance with a particular paragraph of the FDA CFRs or European MDDs could be directly traced from the legal requirement to the SOP, making identification of the records proving compliance easy.

The proof progression is as follows:

Legal Requirement > Company SOP Requirement/ISO Standard > All project Document records

Harms – Harms should be at the top of the comprehensive product risk analysis. Aside from the regulatory desire for this to be the case, it provides a convenient post-market audit trail. When adverse events occur in the field, they are most often associated with harm to the user. In such cases, as the risk management file is sorted by harms, it is a rapid process to determine which hazardous situations were predicted to be contributors to the harm at hand, and to see all of the mitigations used for control. This provides a concise way to identify whether the root cause of the issue was considered, and what is needed to correct the problem in the field. It also can quickly identify the Design V&V testing associated with the design feature and what testing would need to be repeated in the event that design changes are necessary.

Hazardous Situations – Hazards and hazardous situations should be analyzed in every way possible to determine the potential problems in the design, manufacture and use of the device. All of these methods (DFMEA, PFMEA, Fault Tree, evaluation of field clinical use, clinical trials, etc…) should identify hazardous situations and become visible in the Harms-based analysis as potential causes of the user harm.

Mitigations – Every mitigation of a hazard at the disposal of the company should be listed in the Harms based fault tree analysis. User needs, product requirements, and manufacturing requirements should all be considered legitimate mitigations to a hazardous situation. This is in part due to the ISO 14971:2012 Annex Z requirement that labeling should not be used to decrease the occurrence of a hazard. We need as comprehensive a strategy as possible to control product use when it is not possible to control use with device design. When mitigating a hazardous situation, we need every tool available to the company to reduce the risk, in the words of ISO 14971:2012, “as much as is possible”.

The risk mitigation strategy is also the best source of data for product labeling. Instead of using a similar device currently sold in the market or a board of physicians to define risks in need of precaution, warning or contraindication, what better place to develop a comprehensive list of potential issues than from the risk analysis? When the high/medium risk is identified, one of the mitigations should be the use of product labeling. While the label cannot be used to decrease the occurrence of the hazard, from a product liability standpoint it’s a terrific way to justify when and where user notifications should be used.

Design

Design Inputs (PRD) – The document set should include at least one document, and more likely many, that define the User Needs, and Product Requirements. These documents are often developed to mirror the actual development process and the suppliers used in the development process. Thought should be given to how the documents will be organized in the project contractual environment.

Design Outputs (Specifications) – Specifications come in a variety of forms, including prints, code, and manufacturing work instructions, for example. A plan to track satisfaction of all design requirements should be devised. It is often not necessary to pull every specification into the design control, because depending upon the testing strategy there may not be a need to touch on all of the files.

On the other hand, if all specifications are in the system, testing could be tracked for all data required by the product quality plan (first articles, in-process testing, receiving inspection) providing a more complete picture of the entire device lifecycle. This strategy could nicely set up the manufacturing group for integration of post-market test data into the product history.

Design Verification and Validation Plan (Design V&V) – As mentioned above, the ability to search the project file for User Needs, Product Requirements and their test case is a very powerful functionality.

Manufacturing

Product Realization Plan – This plan is used to define how to construct the product. Often a company will break up this list into more than one document.

Product Construction Flow Chart – The flowchart provides context for the later discussion of processes and the requirements for each step of the product fabrication. This list is then checked for duplication and becomes the basis for the Master Validation Plan. When a process validation is required, the test case is defined. When it is not, the file contains the justification for non-inclusion.

Master (Process) Validation Plan – This part of the document is a convenient location for a discussion of all of the processes used to construct the product, an identification of all processes which require process validation, and the container for the process validation test work items. The Process validation work is a mitigation to potential product hazards and should be linked as such to the hazard for display in the harms based fault tree analysis.

Quality Management Plan – Once the construction progression is established, the quality management plan is used to provide the assurance of product quality with points of product performance verification within the construction plan. These points of verification are also mitigations to potential product hazards, and should be listed in the harms based fault tree analysis.

Design Transfer Plan – Once product development and testing are complete and approved, the design must be transferred to manufacturing as a product approved to be built for outside use.

This plan also gives important consideration as to how the company intends to monitor and collect device manufacturing and field performance. The company Quality Policy Objectives must be evaluated at each Quality Management Review Meeting. These objectives include performance of the quality auditing, CAPA, Complaint, and Manufacturing systems. Ideally, the design mitigation strategy would set up the framework to determine the areas of greatest risk, and provide checkpoints for control. Examples include:

Internal Audits

3rd Party Audits

Receiving Inspection

First Article Inspection

In-process Inspection

Product Complaints

Field Failures

If these tests are included in the design control framework, the data from the tests would naturally propagate into the management review process. Occurrence of hazards would be tabulated, making a review of the field harm/hazard risk simple and intuitive.

Customization

Wiki reporting tools give the program manager ultimate flexibility in determining the format and data needed for every reporting need. With this flexibility comes the powerful ability to change reporting and data structures with unexpected or complicated results. Report output, and background data manipulation should be carefully analyzed and changes tested before implementation of the tool on a broad data set. Opportunities for customization include:

RPL Calculation – Unique methods for calculating the product Risk Priority Level (RPL). I have seen a great variety of methods used. Severity * Occurrence, Severity 2 * Occurrence, Severity * Detection * Occurrence, with a great multiplicity of ranking scales. 1-10, 1-5, 1-20, pick lists, equations, and additional variables. In fact there are so many ways to accomplish this function, that I would expect the need to customize it to your company needs.

Link Relationships – Some people build the system from the product needs up to the harm, some from the harm down to the mitigations. If your internals system is fixed, you may need to rebuild the relationships in a way that is compatible with your company SOPs. The good news is that Polarion is flexible and supports either approach.

Work Item Terminology – There are many different terms used for the same logical concept. It is common to require the system to conform with Company policy.

DFMEA, PFMEA Terminology – The FMEA has been around for quite some time, but use of the tool varies widely in different industries, and sometimes the use of different methodologies bleeds into the Medical Device industry. Some consideration should be given to how the FMEA is presented and disseminated into the design control file.

Design Traceability Report – The design traceability report is a depiction of the design proof. The format of the report, and the linkages represented would need to be changed if any of the building components (work items, linking relationships, background data) are changed. Work item approval workflows are a good example.

Conclusion

It is no wonder that a program manager can quickly become overwhelmed by the system architecture required to successfully complete a medical device development project. Initially, it may be tempting to say, “How hard could this be? I will just make a list.”, and start the process using a Microsoft Excel® spreadsheet for design inputs, and Microsoft Word® for the first pass at the product requirements document. However, with only a cursory investigation into the complexity of the development process one can see that this will lead to an ever expanding workload with a geometric increase in the probability of error.

Polarion is a tool purpose built to help you manage complex design artifacts and linking relationships. With this tool, established relationships remain without costly maintenance, while program updates can occur in a structured, searchable environment. Please give us a call and start the process of accelerating productivity and innovation, while avoiding errors in your next development project.

FREE PDF DOWNLOAD
Download the full content of this article series as a sharable PDF file