The road to compliance for medtech manufacturers begins with a robust quality system. This article details QSR milestones and includes a roadmap to help reach that destination.
Small and medium size enterprises (SMEs) in the medical device industry often have a spotty understanding of quality system regulations (QSRs), also known as quality management systems, with which they must comply if they want to bring their products to market in the European Union, the United States and elsewhere. Misinterpretations and misunderstandings involving QSRs are not uncommon. To dispel them, some concepts require clarification.
Technology and quality. Some companies think that good technology ensures product quality. This is not necessarily the case. Quality, as defined in regulations, is not the same as the quality of a product. Indeed, there is no direct relationship between technology and the QSR. Good or even advanced technology does not mean high quality in QSR terminology.
Product development and paperwork. Product development is often thought of as the real work and that what US FDA and other regulatory authorities want to see is merely paperwork. Actually, product development is a planned task—a highly regulated, documented process that must follow QSR guidelines. The product should not be developed without a proper, well-documented plan.
QSR and organisation. QSR is often seen as only being applicable to those aspects of a company that are concerned with product quality. Actually, QSR should be implemented throughout an entire organisation, regardless of its size.
An SME must consider how it is going to comply with the QSR during the product development process. Figure 1 shows a simple flow chart of the lifecycle of a medical device. Not all of the regulations or standards are listed; rather, the overarching QSR of design control is referred to twice, first during product development and then during manufacturing.
When to start design control
The product lifecycle flow chart in Figure 1 clearly shows that design control regulations do not begin with new portfolio planning and research and feasibility studies; they only come into play at the start of the design and development phase of a medical device. This answers one of the questions that many SMEs ask: When should we start design control? Regulatory authorities do not care how smart or technologically advanced a device may be during new/portfolio work or feasibility studies, as this stage only involves business decisions. Therefore, this part of the product lifecycle is not subject to regulatory requirements from US FDA, the European Agency for the Evaluation of Medicinal Products, the UK Medicine and Health Care Products Regulatory Agency or other worldwide bodies. That said, it is sound practice for an organisation to implement good business practices by documenting each stage. For example, setting up standard operating procedures (SOPs) that include planning, review and approval steps and documentation is recommended. This makes all outcomes traceable and backs up decisions with substantial evidence. Putting SOPs into place also ensures that all employees are immersed in a quality culture, which can only benefit a company as it seeks compliance.
Design control for product development
A design control flow chart is illustrated in Figure 2. It does not cover all of the elements of design control but is sufficient to explain the steps that are critical for QSR compliance.
So, what is design control? It is a systematic process with a range of activities, including the following key elements:
1. Design and development planning
2. Design input
3. Design output
4. Design review
5. Design verification
6. Design validation
7. Design transfer
8. Design changes
9. Design history file (DHF)
In general, design control is about planning, design execution, testing against specifications (inputs) and requirements (user needs), and uncovering and fixing problems at an early stage (risk reduction). It is important that a company gets used to planning and organising team action and documentation for the first eight activities listed above.
Team action and documentation are highlighted in the design control flow chart because of the critical part they play in achieving compliance with QSRs. For every project and subproject, it is good practice to have a planning, review and approval system with good documentation in place for the whole team.
Design and development planning
Many people think that a plan is a schedule. It is not: a schedule is merely one of the outputs of a plan. What should be in the plan? With regard to design control, a plan is a top-level document and a full description of processes involved during product design and development, including roles, responsibilities and measurable deliverables. It documents planned actions such as peer reviews, major reviews and decision points. In general, a development plan ensures that the design process is controlled and follows regulatory guidance. It should include at least three parts:
Project plan. The project leader is responsible for creating a project plan for each project and subproject undertaken with tasks approved and resources assigned.
Project schedule. This includes planned actions and major project milestones. As design and development progresses, the project plan will be reviewed, updated and approved, where applicable. These changes also need to be reviewed, approved and documented.
Project team. The project leader chooses a project team made up of members who are qualified to meet the needs of each assignment.
It is important to clarify the two concepts of user needs and design inputs that are highlighted in Figure 2. User needs are the required functions from the customer’s perspective (often the intended use and intended use environments are defined by the marketing department). Design input means the physical and performance requirements of a device that are used as the basis for device design including hardware, software and so forth. They make the required specifications suit design, development and manufacturing needs. From a design control perspective, user needs have to be validated while design inputs have to be verified. Validation and verification and fail or pass criteria should be detailed in the plan.
Design requirements are the key inputs to the design process. Design requirement specifications must document all of the characteristics that are essential to the proper functioning of the device; when needed and applicable, the specifications are updated and approved as the design evolves. The detailed inputs and associated and potential risk analysis should be reviewed and approved throughout the development process using approved design control procedures. Changes to the product requirements must be reviewed and approved in the same manner. Incomplete, ambiguous or conflicting requirements should also be identified and addressed via the design review process and then documented.
In the simplest terms, design output = device + packaging and labeling + device master record.
Design outputs should conform to design input requirements, and they should be structured in such a way that the outcome is traceable. Design output procedures should contain or make reference to acceptance criteria. These procedures are there to ensure that the outputs are adequate for evaluating the functions of a device, which may include product subsystems, outputs from risk analysis and final product specifications. It is necessary to specify and enumerate the design output as part of the roles and deliverables in the project plan, and then revise and update it whenever needed.
Output deliverables should include, at least, device specifications, risk analysis, packaging and labeling and the device master record (DMR).
In general, formal design reviews are intended to:
- assess design results, including designs for production and the support processes
- provide feedback to designers, such as problems and potential risks
- assess project progress
- provide confirmation that the project is ready to move on to the next stage of development.
Review meetings and records (meeting minutes) should be well documented.
Design verification and validation
In this section, verification and validation (V&V) are discussed together because they follow the same methodology despite having different goals.
Verification is confirmation by examination of objective evidence that the design output meets the functionality and performance specified by the design input. Verification activities should be focused on answering the question: Did we design the product correctly? Is it in accordance with the correct requirements and the right parts?
Validation is the process of evaluating a product at the end of the development process (or following a design change of an existing product) to confirm that the device conforms to defined user needs and intended uses under actual or simulated use conditions.
If good requirements and specifications have been written, the V&V processes are straightforward. V&V deliverables should include a verification or validation plan, protocol, report and risk analysis and trace matrix of risks and potential risks.
Another question people often ask is how many manufacturing batches should be run for V&V? Regulatory authorities have not defined this number. Manufacturing three batches for each planned verification and planned validation is probably the starting point. Here, planned means within design control, and three runs normally satisfy regulatory requirements. However, the manufacturer decides on the number of manufacturing runs for V&V purposes, choosing the amount of batches that he feels are adequate to meet design specifications and requirements. V&V should be treated seriously and variation, rather than simply confirmation of expected behavior, should be sought. As well as ensuring compliance, a manufacturer who performs V&V is also safeguarding his own long-term interests.
Design transfer is the correct translation of device design into production specifications and the transfer of responsibility to the manufacturing department to actually make the device. Transferring knowledge from the design team to the manufacturing and support functions should take place throughout the design process. Good industrial practice includes planned training to make sure that both responsibility and knowledge are transferred to manufacturing. Design transfer deliverables include a comprehensive design transfer plan that covers the initial and final operation plan and process validation and a device master record (DMR).
Two elements must be taken into consideration when it comes to design change: document control and change control. Document control pertains to establishing and maintaining procedures to control all design documents, including approval and distribution, status tracking and revision history. Change control means enumeration of deficiencies and corrective actions arising from verification and review of the design, and tracking their resolution prior to design transfer. The question is again about responsibility. Before design transfer, design changes are the responsibility of the design team. After that, product and process changes are the responsibility of manufacturing.
Design history file
The design history file (DHF) is a compilation of records that describes the design history of a finished device. The elements have been highlighted in the previous points and include:
- Design plan—project plan, schedule and design team
- Design inputs—design requirements documents and risk analysis
- Design outputs—device specifications, risk analysis, packaging and labeling, DMR, traceability files
- Design review—all review files
- Design verification—test plan, protocols and reports
- Design validation—test plan, protocols and reports
- Design transfer—DMR, process validation plans, protocols and reports
- Product release—authorisation to ship
- Design change—all change files.
Quality system roadmap
A quality system has seven key elements, as shown in Figure 3. Management control is the key aspect, since it is vital that managers with executive responsibility understand basic requirements and the entire interconnected systems. Almost all quality audits/inspections are based on a top-down inspection of a manufacturer’s quality system.
The question is, how to comply? The starting point is to write a Quality Management System Manual as a top-level document and to implement it throughout the entire organisation. The manual should cover all aspects of the basic requirements in Figure 3. The following is an example of the contents that a quality management system manual should have:
- Purpose, scope
- Quality management system:general requirements and documentation requirements
- Management responsibilities: management commitment, customer focus, quality policy, planning, responsibility, authority, communications and management review
- Resource management: provision of resources, human resources, infrastructure, work environment
- Product realisation: planning of product realisation, customer-related processes, design and development, purchasing, production and services, control of monitoring and measuring devices
- Measurement/analysis/improvement: monitoring and measurement control of nonconformance, data analysis and management; improvement.
Ensuring full compliance with QSRs is a critical process for medical device manufacturers. Achieving compliance must be an inherent and systematic approach across the whole company, with planning, review, approval, documentation and management control as the central factors in that approach.
Xiang C. Zhang, PhD
is Principal Consultant, Medical Devices,
at CERAM, Queens Road, Penkhull,
Stoke-on-Trent ST4 7LQ, UK
tel. +44 1782 764 428
Find more content on:
to post comments