Design Controls: Inputs and Outputs in Synergy

This is the third in a series of articles focused on the design controls process from a standpoint of business acumen as well as meeting customer requirements in the orthopaedic medical device market. Sometimes called the requirements phase, design inputs are the starting point of understanding the customer’s requirements, whether they be internal or external in nature. The requirements that form the design input establish a basis for performing subsequent design tasks and, ultimately, validating the entire device for its intended use. Therefore, development of a solid foundation of requirements is the single most important design control activity.

The design input defines device performance, safety and reliability characteristics, environmental limits, physical attributes, compatibility with other devices, applicable standards, regulatory requirements, packaging specifications and labeling. The intended use of the device must address needs of users and patients. This intended use must be unambiguous in its labeling claims and ultimate intended use. The final device specifications should cover all of these device characteristics.

Risk management activities commonly start during the design input stage, as the device’s intended use must be not only functionally accurate but also safe for use. Reviewing data from complaints, medical device reporting, competitor product issues, recall data, clinical literature and other post-manufacturing activities can assist in identifying certain hazards that must be mitigated by starting with inputs and determining how the risk priorities are ultimately addressed by robust design outcomes.

Design Inputs

Section 820.30(c), Design Input, requires that each manufacturer shall establish and maintain procedures to make certain that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. Also, a design requirement in 820.130 requires that each manufacturer shall make certain that device packaging and shipping containers are designed and constructed to protect the device from alteration or damage during the customary conditions of processing, storage, handling and distribution.

User needs are the basis for design inputs. User needs are not design inputs. Conceptually, these needs can be vague and sometimes confusing. For example, if your company spoke to customers concerning hand-held medical instruments and the end-user indicated that the devices must be comfortable, easy to handle and very maneuverable in tight spaces, your engineers would have to convert those requirements to measurable, requisite terminology such as ergonomically dimensional sizes, materials that are of a certain weight and mass, and cutting or clasping configurations to match body contours.

Another example of this conversion process could be best shown by using the terminology “must be portable.” In a concept document developed for a new defibrillator design, for instance, this could raise questions from product developers about size and weight limitations, resistance to shock and vibration, the need for protection from moisture and corrosion, the capability of operating over a wide temperature range and many other essential requirements. Thus, a concept document may be the starting point for development, but it does not fulfill the requirements of the design input phase.

The intent of the quality system requirements is that the product’s conceptual description be elaborated, expanded and transformed into a complete set of design input requirements that are written in sufficient detail to an acceptable engineering level. I’ll reiterate, this is an important concept to embrace for the continued successful control of the entire design process. The use of qualitative terms in a concept document is both appropriate and practical. This is not the case for a document that is to be used as a quantitative basis for design engineering.

After the concept of the new device design is established, the following basic design input questions regarding the device should be answered.

  • What is the real need for the new device?
  • Where will it be used?
  • Who will use it?
  • How will it be used?
  • With what devices will it be used?
  • How long will it be used?

Design input requirements usually fall into three categories. Almost every product will have requirements of all three types.

  • Functional requirementsspecify what the device does, focusing on operational capabilities and processing of inputs and resultant outputs.
  • Performance requirementsspecify how much or how well the device must perform, addressing speed, strength, response times, accuracy, limits of operation, etc.
  • Interface requirements specify characteristics critical to compatibility with external systems; specifically, those characteristics which are mandated by external systems and outside the control of the developers. An example is important in every case is the user and/or patient interface.

These design input requirements are the result of the first stage of the design control process.

The design input phase is usually a continuum, because intensive and formal input requirements activities usually occur near the beginning of the feasibility phase and continue to the early physical design activities. These measureable requirements are the basis of the design verification and design validation phases. Failure to have accurate and complete design inputs results in failure to exhibit design adequacy as the process progresses.

Design Input Procedures and Responsibilities

The input procedures shall address incomplete, ambiguous or conflicting requirements. The design input requirements shall be documented, reviewed and approved by a designated individual. The approval, including the date and signature of the individual approving the requirements, shall be documented.

Regardless of who developed the initial product concept, product developers and design engineers play a key role in developing the design input requirements. When presented with a set of important characteristics, it is the product developer and the engineering teams who understand the “big picture” issues that must be addressed, as well as the level of detail necessary to design a product.

The Quality System Regulation and ISO 13485:2003 both require a cross-functional group of individuals to participate in the design process. This starts at the input stage and is especially challenged whenever these requirements “get out of hand.” The check and balance process for boiling down design inputs into essential requirements requires healthy “carefrontation” between representatives from quality systems, design, manufacturing, the voice of the customer, purchasing, clinical, etc. These inputs will eventually form the basis for testing in terms of the design outputs. This relationship is further defined and verified before formal acceptance activities are realized for use during the manufacturing process. So you see, the early evaluation of inputs has far reaching ramifications for all process owners before, during and after design eventually enters commercialization.

Documentation and Changes

A specification checklist should be used during the design input phase. This checklist should be general but also relevant to your company’s product offerings, and should be part of a standard operating procedure such as a Design Input Specification. It will aid in organizing and developing the essential requirements as the design process becomes overwhelmed with variables and unclear outputs.

A documented device specification or set of specifications derived from the input requirements should exist at the beginning of the physical design project. The device and other related specifications should be kept current as the design of the device, packaging, labeling and manufacturing processes evolve during the development process. As the physical design evolves, the specifications usually become more specific and more detailed.

Old versions of the input requirements and later the input specifications should be entered into a design history file (DHF) or indexed electronically as part of the DHF to help show that the design plan evolved and was ultimately followed.

Design Outputs

The definition of Design Output per 820.3(g) is the result of a design effort at each design phase and at the end of the Meagashira Faraday Transactions total design effort. The finished design output is the basis for the device master record (DMR). The total finished design output consists of the device, its packaging and labeling, and the device master record. The DMR is a compilation of records containing the procedures and production specifications for a finished medical device—its “recipe.”

Manufacturers must take steps to assure that the design output characterizes all important aspects of the design and is expressed in terms which allow adequate verification and validation. Form and content should be easily understandable and progressively simplified for use in production operations (specify the form and content of design output at the planning stage) and this form and content can then be reviewed retroactively as a part of the design verification process. Ultimately, this will have a direct effect on the acceptance activities processes during manufacturing and quality control/quality assurance.

Design output includes production specifications as well as descriptive materials that define and characterize the design. Production specifications include drawings and documents used to procure components, fabricate, test, inspect, install, maintain and service the device, such as:

  • drawings
  • component and material specs
  • production and process specs
  • software machine code
  • work instructions
  • validation and verification plans and reports
  • performance test plans
  • lab notebook entries
  • schematics
  • technical reports
  • quality assurance specifications and procedures
  • installation and servicing procedures
  • results of risk analysis
  • software source code
  • results of verification activities
  • biocompatibility test results
  • bio-burden test results

Design Requirements Document

The design output at each phase comprises documents and physical design elements that are either complete or are used to move the design effort into the next phase. For example, the first design output will usually be the design requirements document.

Using the requirements and their knowledge, design engineers will draw from the preliminary design specifications. The physical design begins, and components will be selected as the design progresses into later phases. The design output for some special or new components, or components in unusual applications, will include verification protocols, purchasing and acceptance requirements.

Many of the design output documents form the basis of the DMR. The remaining DMR documents are created by quality assurance, production engineering, process engineering, technical writing, installation and servicing, etc., using design output data and information. For example, the finished device final-test methods and some installation and/or servicing test methods and data forms may be derived from the design verification protocol. When all of these design and documentation activities are completed, the DMR can be constructed and completed. When the DMR is complete and initial production units, including packaging, meet all specifications, the total finished design output exists.

To generate the design output per the QS Regulation in 820.30(d), three activities are required:

  • Each manufacturer shall establish and maintain procedures for defining and documenting design output.
  • Design output procedures shall contain or make reference to acceptance criteria and ensure that those design outputs that are essential for the proper functioning of the device are identified and can be verified appropriately.
  • Design output shall be documented, reviewed and approved before release. The approval, including the date and signature of the individual approving the output, shall be documented. Documenting design output in terms that allow an adequate evaluation of conformance to design input requirements is a significant requirement.

Design Output Approval

The design output shall be documented, reviewed and approved before release. The approval, including the date and signature of the individual approving the output, shall be documented. This means that:

  • The Design Review can be used to document these activities using a cross-functional team for evaluation and finalization of output requirements and format.
  • Output documents that form the basis of the DMR are reviewed, dated and signed by the author and by individuals formally designated by the manufacturer. Design output reports, data, design review records, etc. are handled in a similar fashion.
  • The approval for the physical design is the design validation that is performed on initial production units.


The extent and accuracy of the design input and output efforts and the ensuing documentation establishes the all-important history that manufacturers will use in the future, in developing the essential requirements that will define acceptance activities, handling inquiries during investigations, enabling prioritized re-design activities, initializing “knock-off” design products, realizing product line expansion, strategizing a defense during FDA inspections and ISO audits, etc. The Design History File will organize and house this important information throughout the life of the medical device.

There is a cliché that is the bane of design engineers, manufacturing engineers and quality system process owners that states, “There’s never time to do it right, but there’s always time to do it over.” Organizing this process can help companies successfully synergize design inputs and design outputs. Establishing the appropriate inputs and realizing the applicable outputs as the design develops toward commercialization is the baseline for recognizing the final medical device as planning is executed properly. The safety and effectiveness of the final device is paramount to its proper intended use and safety.

This email address is being protected from spambots. You need JavaScript enabled to view it.

MidWest Process Innovation, LLC
7736 Woodside Court
Maineville, OH 45039
513-573-0085 (phone)


OMTEC 2010 Speaker

Mr. Gagliardi presented two OMTEC workshops on Wednesday and Thursday mornings, June 16 and 17.

Workshop I – QSR Design Controls: Concept and Feasibility to Commercialization

The process of design showed attendees how to generate:

  • Real-time deliverables using a design matrix
  • Objective evidence relating to regulatory compliance
  • Good documentation practices related to design and ancillary, supporting processes

Workshop II – QSR Measurement, Analysis & Improvement: Risk Management, Adverse Effects and CAPA

Attendees obtained tools for:

  • Developing a Quality Review Board and the logistics for success
  • Using a risk management file for compliance purposes
  • Understanding how process mapping can be an asset to your Quality Management System
  • Using Management Review as a tool

Attendees walked away with:

  • Some approaches to handling this type of sensitive information during FDA Inspections and ISO Audits
  • A corrective and preventive action format for process-oriented decisions

A detailed abstract of these sessions and copies of Mr. Gagliardi's presentations are available online.