Design and Development

When to start with the Design and Development process?

The answer is soon after you decide to develop a medical device.

This article guides you through the first steps of D&D. Let me know your comments, and you can always re-read the article on our webpage.

The D&D process is often depicted as shown below.

The first time I saw this, did I immediately know where to start with the D&D process? Well….. no. These pictures are only helpful when you understand the process, not to start understanding it.

In this article, I’ll discuss all steps and words used in this process flow diagram. At the end of the article, please look at this picture again and see if it makes sense now.

All steps and phases below should be documented, reviewed and signed like any other QMS document. The D&D plan (= input) defines if certain stages or reviews need to be finished and approved before continuing to the next step. An obvious one is that the D&D verification should be completed and reviewed before moving on to D&D validation.

User Needs

The first term we need to discuss is User Needs. Users can be (but are not limited to) the patient, surgeon, nurse, therapist or combinations thereof. The user needs to describe what they would want from the product. The information can be collected by interviewing, for instance, several users. Do record these interviews in meeting minutes, including the date of the interview.

From all these interviews, the user needs are defined and formalized in the user requirements. Consider the following topics to discuss with the users.

1. Purpose, goal, and effectiveness of the device.
2. Safety (electrical, biocompatibility, breaking, sharp edges, irradiation, etc. ).
3. Material (stainless steel, plastic, soft-touch, resorbable and degradation time. cleaning requirements ).
4. Shelf life, active life, sterility.
5. Packaging (single or double packaging, carton boxes, number of products per box etc.) and labelling (which information, QR or bar-codes).
6. Maintenance contracts, maintenance by the user, repairing service, and how to dispose of the product.

Be aware that you must write down the user requirements from the user’s point of view. User requirements are not the same as technical requirements, so use the words the users understand. The user requirements are translated into technical requirements as INPUT.

Also, be aware that user requirements may shift during the development project (especially when it takes a few years). Check the user needs periodically.

Design and Development Inputs

Defining the D&D inputs is an essential and strenuous task. Make sure your D&D inputs are clearly defined, objective and stated in a way that allows you to prove them. Keep verification of the D&D inputs in mind when describing them.

 

The following list are examples of D&D input

1. Design and Development Plan
2. Technical Requirements (e.g. max temperature, minimum pressure, etc. )
3. Statutory and regulatory requirements
4. Relevant information from previous designs
5. Regulatory approval plan, including (or separate) clinical trial plan
6. The output of risk analysis

In the D&D plan, the following topics must be discussed.

• purpose, goal, scope
• description of the final product, all components, consumables etc.
• roles and responsibilities
• stages of development
• When D&D reviews are mandatory (usually after each development stage, but sometimes more frequently)
• methods to perform verification between the D&D outputs and D&D inputs.

A larger team should collect D&D inputs with a broad range of experience and specialism (design, electrical, process, material engineering, marketing/sales, clinical trial experts etc.). Sources to define your inputs are the user needs, experience with prototypes, competitors’ products, previous (older) products, industry standards, etc.

Design and Development Process

The actual design and development process can commence when the user needs and D&D inputs are defined (at least the first draft). Standard project management rules apply to ensure that the D&D process is effective, efficient, controlled and on time. The project manager must organize regular team meetings and D&D review meetings to ensure the project is on the right track and no design creep occurs.

Design and Development Outputs

Outputs are verifiable results related to the input characteristics of the product that are essential for its safe and proper use. The output of the D&D process results in the specifications for purchasing, production, and service and reference to the acceptance criteria. Outputs can be

1. Design drawing with all its dimensions of the semi-finished parts and the final product,
2. Product specification of semi-finished products, assemblies, sub-assemblies, and finished products,
3. production procedures of all (intermediate) steps, assembly, packaging, sterilization etc.

Outputs will be the basis for the Device Master Record.

All the (in-vivo and in-vitro) tests are NOT part of the outputs.

Design and Development Verification

In short, the D&D verification proves that the D&D Outputs meet the D&D Inputs. This verification is done in the form of testing. The following types of testing are possible.

1. Prototype testing on devices that resemble the final product. Development testing on materials, models, etc., is vital to determine the design, but not verification testing.

1. Proof testing is also done on prototypes, but instead of testing to specifications (as done in prototype testing), the tests are to test the product to failure. For example, how far can you bend, load, and pull the device before it breaks—necessary testing for warnings and warranties and input for risk analysis.
2. Acceptance testing is done to determine if your products’ production is good. These can be tests on all products or a selection of the products produced. Preferably these tests are non-destructive but not always possible. Validation of the production and the acceptance criteria and testing are also part of the acceptance testing. More information on validation can be found in a previously published article.

Within all three of the above-described testing groups, different tests can take place: visual inspection, in-vitro testing (e.g. analysis, mechanical, electrical, software, ageing, degradation testing), in-vivo testing (biocompatibility, implantation studies) and all other studies required to establish that the D&D outputs meet the D&D inputs.

Use a design traceability matrix (DTM) to keep an overview of all D&D inputs, outputs and verifications. The DTM is a table with the following columns

1. User needs
2. The inputs (short description or, if possible, target value with tolerances)
3. References to input documentation, standards (e.g. ISO norms), regulatory documentation, SOPs etc.).
4. Output, short description or average values and standard deviations
5. References to output documentation
6. The verification is a tick-box, confirming that the input meets the output.
7. Reference of the verification documentation.

Design and Development Validation

The D&D validation relates the final product (the medical device) to the user’s needs.

There are different ways to perform the D&D validations, for example, clinical evaluations, user tests or reviews of topics like packing, (re-) sterilization, repair, maintenance, disposal, etc. Or in short, all studies confirm that the medical device meets all its user needs.

As said, the clinical study is one of the essential D&D validation studies. Medical device regulation (MDR) requires sufficient clinical evidence to prove the efficacy and safety of a medical device. What is sufficient clinical evidence? Not easy to define, but it should be verified with the notified body or FDA and aligned with sales, lifetime device, target population, benefit, residual risk from the risk assessment, foreseeable misuse, and state of the art.

Design and Development Review

An excellent D&D review has several positive effects. It ensures all team members, management and customers are up to date on all aspects of the design. Further, the team reviews that all contributory factors and design aspects are considered to ensure that the design fulfils the D&D Input.

A D&D review team consisting of the design team and non-team members (subject matter experts, customers, management, partners etc.) should regularly review the design. At least at all stages of the design and development process, as the figure above suggests. In the D&D review, one should review all changes of a previous development stage (updates in D&D inputs, for example).

Design and Development Transfer

Not part of the overview figure from the beginning of this document, but the D&D transfer is part of the Design and Development process. this is the action of transferring knowledge from the design or development department to production. Usually, this starts when producing devices for the clinical trial. These devices should be produced under ISO13485 / GMP; therefore, operations must be trained and information (specifications, instructions etc.) must be. The D&D transfer is concluded after D&D verification, and commercial standard production starts with an approved and validated product, as changes in design can happen due to the clinical study.

The Design History File (DHF) is the collection of documents and records from the D&D process. In the DHF, at least the specifications, inputs, test results, analysis, and observations are found. Not just the last version but all versions of the documents and records should be stored in the DHF.

The DHF is the basis for the design file or technical file, which needs to be reviewed by notified bodies or authorities for market approval.