Under Control

Medical device safety starts during the design stage

by Les Schnoll

Online-only content

For those of us in the medical device industry who deal with the U.S. Food and Drug Administration (FDA), receiving a letter that begins with the words "You have failed to …" is not the way you want to start your day. And it’s certainly not the best way to get on your CEO’s radar.

But it is important to remember that if a medical device fails, people can be severely injured or die. We don’t want this to happen to anyone, so our highest priority as medical device manufacturers is the safety of our customers, and their patients and caregivers. Therefore, we must—with absolute certainty—ensure the design and process are reliable, and we must produce it exactly the same way every time. Any change must be revalidated.

To ensure good quality assurance practices are used for the design of medical devices and that they are consistent with quality system requirements worldwide, the FDA revised the current good manufacturing practice (cGMP) requirements in 1996 by incorporating them into the quality system regulation, 21 CFR 820. An important component of the revision was the addition of design controls. These changes were made to reflect the FDA’s belief that the intrinsic quality, safety and effectiveness of a device are established during the design phase.

The Safe Medical Devices Act of 1990 (SMDA) amended the Food, Drug and Cosmetic Act, providing the FDA with the authority to add preproduction design controls to the cGMP regulation. This change was based on findings that a significant proportion of device recalls were attributed to the faulty design of product.

Specifically, in January 1990, the FDA published the results of an evaluation of device recalls that occurred between October 1983 and September 1989 in a report titled "Device Recalls: A Study of Quality Problems."

The FDA found that approximately 44% of the quality problems that led to voluntary recall actions during this six-year period were attributed to errors or deficiencies that were designed into devices and may have been prevented by adequate design controls. These design-related defects involved non-critical devices (for example, patient chair lifts, in-vitro diagnostics and administration sets) and critical devices (for example, pacemakers and ventilators).

With respect to software used to operate medical devices, the data were even more striking. A study of software-related recalls for the period of fiscal years 1983 through 1991 indicated that more than 90% of all software-related device failures were due to design errors—generally, the failure to validate software prior to routine production.

The FDA revised the cGMP regulation to add the design controls authorized by the Safe Medical Devices Act of 1990 (SMDA) because the agency believed it was beneficial to the public and the medical device industry for the regulation to be consistent, to the extent possible, with the requirements for quality systems contained in applicable international standards. Primarily, this meant syncing with ISO 9001:1994 Quality systems—Model for quality assurance in design, development, production, installation and servicing.

It’s elementary

Despite these steps, the FDA continues to cite manufacturers for serious design control violations found during inspections that lead to warning letters. So it’s crucial for medical device manufacturers to know the 10 formal elements (risk management could be considered an 11th element) that comprise design controls and how they relate to the regulatory requirements:

  1. Design controls overview: This requires that when manufacturers or suppliers develop a product subject to design controls, they must establish and maintain the proper documentation to ensure the specified design requirements are met. In addition, design practices for software incorporated into products must meet the intent of applicable standards.
  2. Design and development planning: This describes the overall development plan and defines design activities and responsibilities. Plans must be established and maintained that describe or reference the design and development activities, and define responsibility for implementation. The plan must identify and describe the interactions between different groups or activities that provide or result in input to the design and development process. The plans should be reviewed, updated and approved as design and development evolves.
  3. Design input: Procedures are established and maintained to ensure the design requirements relating to a product are accurate and appropriate, and address the intended uses and intended use environments of the product, including user needs. These needs-and-uses requirements serve as the basis for design validation.

    Once established, the needs-and-uses requirements are transformed into verifiable engineering specifications for the product that include, at a minimum, the performance requirements, the functional requirements, physical requirements, interface requirements, safety and reliability requirements, environmental requirements, applicable standards and regulatory requirements, and labeling and packaging requirements.

    The completed design input consists of intended uses and needs, as well as the product engineering specifications. The procedures include a system for addressing incomplete, ambiguous, inaccurate or conflicting requirements. Functional requirements, design requirements, intended use, intended purpose and the intended operating environment of the product are formally documented, reviewed and approved by designated individuals. The approval, including date and signature, is documented in the design history file.

  4. Design output: This includes the final technical documents that constitute the device master record (DMR). This information shows the device was developed according to the design plan and design inputs. Procedures must be maintained for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements.

    Design output procedures contain or make reference to acceptance criteria and ensure those design outputs essential to the proper safe functioning of the product are identified. Design outputs include design architectures or block diagrams, software code, subsystem specifications, module or software specifications, interface specifications, component specifications and part drawings. Design output is documented, reviewed and approved prior to release. The approval, including date and signature, is documented in the design history file.

  5. Design reviews: Ongoing meetings occur throughout the design process and verify the development of the design meets the requirements outlined in the design input stage.

    Procedures must be established and maintained to ensure one or more formal documented reviews of the design results are planned and conducted at appropriate points throughout the product development process. Reviews are triggered once the project design team has completed, reviewed and internally accepted the required design outputs.

    The procedures ensure the design outputs are reviewed by an independent, cross-functional group of reviewers, as well as any specialists needed. The results of the design review, including identification of the design review, the design, the date and the individuals performing the review, are documented in the design history file.

  6. Design verification: Procedures are established and maintained to verify the product and associated accessories design. Design verification confirms that the design outputs meet the design input requirements specifications. It also verifies labeling, user manuals and risk mitigations. The results of the design verification, including identification of the design, methods, acceptance criteria, the dates and the individuals performing the verification, are documented in the design history file.

    Design verification activities include testing, inspections, analyses, measurements and demonstrations to confirm associated design inputs and specifications for proper functioning of the device are met. It also ensures hazards and risk mitigations identified within design input documents are verified.

  7. Design validation: Procedures are established and maintained to ensure the product and associated accessories conform to clinical claims, intended uses, intended purposes and the intended use environments stipulated in the design inputs. Successful completion of design validation always depends on successful completion of design verification.

    Design validation is performed under defined operating conditions on initial production units, lots or batches. Design validation includes risk analysis and software validation, where appropriate. This includes testing of production equivalent units under actual or simulated use conditions to provide objective evidence that the particular intended uses can be consistently fulfilled.

    The results of the design validation, including identification of the design, methods, acceptance criteria, the dates and the individuals performing the validation, are documented in the design history file.

  8. Design transfer: Procedures are established and maintained to ensure the product design has been adequately and correctly translated into production specifications. Design transfer includes determination that manufactured products are repeatedly and reliably produced to specification. The results of design transfer activities are documented in the product’s DMR.

    A portion of the design transfer process is completed when the design history file is finished. Corresponding information is then transferred to the DMR. The translation of design outputs into production specifications completes the remaining portion of design transfer.

    Online Table 1 lists activities typically performed to translate design outputs into production specifications and provides examples of each activity. Other activities or methods may be used to complete DMR creation.

  9. Design change control: This shows that all modifications to the design after the design review were identified, reviewed and approved. Procedures must be established and maintained to identify, document, review and approve design changes before they are implemented.

    Preproduction design change establishes the design change procedure, beginning when any design output is finalized and prior to release for production. At a minimum, design configuration and change control must be established before formal verification or validation of the design.

    Production design change establishes the design change procedure, beginning when the completed product drawings and the bill of material are released for production. Post-production design changes must follow design controls based on the scope, scale and risks associated with the changes. At a minimum, design changes must be technically reviewed, and the impact on the product risk assessment must be determined and validated, including the impact on prior verification and validation.

  10. Design history file: These are the documents that show the device complies with the approved design plan and design control procedures. This file is the basis for the DMR, which includes all specifications, drawings, outputs and actions relating to the development of the device. A design history file is established and maintained for each new design or modification of existing design. The file contains or references the records necessary to demonstrate that the design was developed in accordance with the approved design plan.
  11. Risk management: These activities are required during most phases of development. The extent of this testing is proportional to the risks associated with the product. If risks are unacceptable, the device may need to be redesigned or warning labels attached. It is important that any changes do not introduce new risks or hazards.

    Procedures for risk management must be established and maintained throughout the design control process and the production design change process. The depth of the design practices (design rigor) is based on the level of risk established for the particular portion of the design during risk assessment.

Keep this in mind

There are some practical points to consider when implementing and maintaining a compliant and value-added design control process:

  • A simple and attainable design control process should be defined so it can be updated and improved as the company grows and matures.
  • Rely on risk management activities to determine the level of detail required for design controls. Low-risk devices typically do not require as much documentation of design and development steps or design output compared with higher-risk products.
  • The product development process generates useful documentation that should be included in the design history file. But don’t muddle the file with unnecessary documents, such as records of every phone call, memo and e-mail.
  • Some design information is sensitive and confidential, so treat it that way and be aware of potential issues that may arise under the Freedom of Information Act.
  • Product clearance or approval of a medical device submission does not guarantee or imply compliance with design control regulatory requirements.
  • All medical devices with a software component, including class one devices, require implementation of design controls. Implement software validation as part of design validation for all software components. The level of detail of software validation is a function of the level of risk resulting from the use of software components in the device.

Using common sense, paying attention to detail and following the regulatory requirements identified above will decrease the possibility of your chief executive waking up to a warning letter that questions the design of the company’s products.

Online-only content

Online Table 1

Les Schnoll is vice president of quality assurance and regulatory affairs at J.T. Posey and Co. in Los Angeles and has 30 years of experience in industries regulated by the FDA. He earned a doctorate in health law from Kaplan University. A member of the U.S. technical advisory group to International Organization for Standardization technical committee 176, Schnoll wrote The Regulatory Compliance Almanac (Paton Press, 2001, 2008). He is a senior member of ASQ and an ASQ-certified quality engineer, auditor and manager.

--Phillip LaCroix, 03-13-2018

--Phillip LaCroix, 03-13-2018

Average Rating


Out of 2 Ratings
Rate this article

Add Comments

View comments
Comments FAQ

Featured advertisers