Design Review

This blog talks about design review, another important part of design control. Design Project Plan shall schedule when to have the design reviews. Design review is an important milestone in the design process of medical device.

Should there be a minor upgrade to an existing device, may be a single review is warranted.

For a whole project or a substantial changes to an existing device, several design reviews are warranted. Design review must be done logically, in detail and be recorded.

The first review portion should start early in the project, to evaluate and finalize design input requirements, to review risk management, and to review early conceptual design.

The second portion shall review design verification phase and the review purpose is to ensure design input meets design output requirements and perhaps to finish continuing risk management and to review the design output.

The last portion of the review should deal with the completion of production trial runs and design validation. The purpose of this portion of design review is to ensure the device meets user and production requirements. An evaluation of the final risk management report is also be reviewed.Of course, the above sequence of design review is just a suggestion.

The project manager can decide what portion of design review can be started based on priority or need. For example, for more complex design, the project manager can schedule additional design reviews to ensure the design review was done in focus, thorough and in compliance.

How about Label and Document Review? A review of the label and document should also be part of the design review. A review of the labeling include manuals, instruction for use, chart, package insert and labels and they should all be reviewed methodologically and ensure to be compliant to all pertinent guideline like 21 CFR 820 and ISO 13485, for example.

The portion of this review may be part of the Final Design Review. This can be a separate review because it may involve a wider range of participants like regulatory affairs, finance and marketing.

After all the documents are reviewed, they will be released in the Device Master Record.Project manager should have a Design Review Checklist (DRC) to identify the project and the phase being reviewed, the date, time, place, the participants, the review topic, any documents reviewed and outstanding action items. DRC should be distributed prior to the meeting to ensure participants prepare for the review.

Depending on the review topic, participants should involve project manager, process engineering, quality assurance, regulatory affairs, marketing and consultants etc.

Results of design reviews are recorded in minutes of the meetings prepared. Examples of the record includes:

·       Copy of the agenda for the meeting.

·       Place, date, time and list of participants with their name and signatures.

·       Disposition of outstanding action items and the actions necessary to resolve them. Detail of disposition is warranted.

·       Notes, results and conclusions for each reviewed item,

·       Requested corrections and changes, and actions necessary to implement them,

·       Approvals and consents with signatures and date.

·       Risk Analysis Report.

·       Engineering Drawings and Specifications.

·       Clinical Trial Report.

·       Instruction For Use.

Finally, all records pertain to design reviews are placed into the Design History File both hardcopy and softcopy.

Reference	Criteria
21 CFR 820.30(e)	Does the company establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device's design development?
21 CFR 820.30(e)	Do the procedures ensure that participants at each design review include representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed?
21 CFR 820.30(e)	Are the results of a design review, including identification of the design, the date, and the individual(s) performing the review, documented in the design history file (DHF)?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.

Design Output

The blog is about design output, another important part of design control. Another concept that should be remembered is

Design Inputs = Design Outputs

There should be a procedure to handle how to deal with design output. Product design output consists of documents, samples, models, math data, software, testing results, specifications etc., that specify the device and its manufacturing, packaging, labeling, installation, and servicing; as well as product acceptance criteria. The following categories of specifications are typically, but not limited to be included in design output:

·       Product specifications,

·       Assembly Drawings,

·       Specifications for purchased products,

·       Manufacturing process specifications,

·       Packaging specifications,

·       Labeling specifications,

·       Installation specifications,

·       Work Instructions,

·       Software Code,

·       Quality Assurance Specifications and Procedures,

·       Maintenance and servicing specifications,

·       Bioburden test results,

·       Biocompatibility test results,

·       Result of Risk Analysis,

·       Product acceptance criteria (purchased, in-process and final)

Design output documents are included in the Device Master Record (DMR). DMR is a compilation of all records that contains procedures and specifications of a FINISHED product.

Per FDA Section 21 CFR 820.181 which states that “Each manufacturer shall maintain device master records”, therefore DMR is part of a requirement.

Design output is expressed in terms that can be verified against design input requirements. Design verification will be blogged later.

Design output documents are reviewed and approved before release during intermediate and final design reviews.

Verification that design output meets the design input requirements is important. When such verification involves calculations or other engineering methods, it is carried out as a design verification activity. When it is a more qualitative evaluation and can be conducted by a design review meeting. 

Ensure that individual design output documents are complete, correct, and are not in conflict with each other. A designated associate shall carry out this checking activities.

Results of reviews carried out by the design review meetings are documented in minutes of the meetings. Results of other reviews and verifications are documented by signoffs on the reviewed documents, memos and reports.

There should be a project manager to oversee all the design control activities. He or she must approve and release design output documents.

Before approving the documents, the project manager verifies that all required reviews have been carried out with satisfactory results, and completes the reviews.

Design output documents are controlled. Their establishment, review, authorization, issue, distribution, and revisions are carried out in accordance with  procedures which handle Control of Documents and Device Master Record.

Approvals of design outputs are evidenced by the project manager dating and signing the Document Change Order releasing the design output documents. Then the manufacturer has a finished product until there are changes which warrant another update of the DMR and slightly change the medical device. The whole or partial process is repeated.

Reference	Criteria
21 CFR 820.30 (d)	Has the company established and maintained procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements?
21 CFR 820.30 (d)	Do design output procedures 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?
21 CFR 820.30 (d)	Is design output documented, reviewed, and approved before release?
21 CFR 820.30 (d)	Is the approval, including the date and signature of the individual(s) approving the output, documented?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.

Design Input

 

This blog talks about design input, 21 CFR 820.30(c), an important requirement of design control. A procedure to handle design input is warranted.

Normally, Research & Development and Engineering should bear the responsibility to initiate this design input requirements. The input requirement includes product concepts such as product engineering sketches, models and rough prototypes of the device.

Basically the general product descriptions at this stage are translated into more specific engineering term such as actual product specifications like product sizes, weight, electrical power, and perhaps Interphasing with computer software. More often, the product specifications shall be specific enough to provide acceptance criteria for design verification later on. Design Verification and Validation will be blogged later.

Of course, all design input requirements are documented systematically, chronologically and logically. Examples of design input documents are engineering data sheets, drawings, photographs, samples, intended use of the device, performance characteristics, prototypes, product’s computer software, electrical specification, IFU etc.   

All the design input requirement needed to be captured systematically into Product Requirement Document (PRD). Examples of design input are shown below:

·       Intended use and indications for use. This is very critical of the factor of design input, many of the testing, verification, validation and device classification will be predicated on the intended use.

·       User / patient / clinical characteristics. What can the device do in a clinical settings like disease diagnosis or treat a disease.

·       Physical / chemical characteristics. Length, weight, size, what materials.

·       Limits and tolerances.

·       Performance characteristics. What can this device do to the patients and diseases?

·       Risk analysis: What method deployed? Top Down and Bottom Up. FMEA, FTA etc.

·       Product safety. A detail description of the safety. Safety should be mentioned in the IFU and labeled on the product.

·       Toxicity and biocompatibility. Materials may have some biocompatibility issue if have contact with human tissue. Sponsor should choose a material as biocompatibility with human tissue if possible.

·       Electromagnetic compatibility. When the product is used in a hospital setting, what effect of the device with the environment.

·       Compatibility with accessories and auxiliary devices

·       Compatibility with the environment of intended use. Here the working environment shall be established like relative humidity, temperature etc.

·       Human factors. How well any user use the device.

·       Labeling / packaging. Sample of labeling like IFU.

·       Voluntary industry standards like IEC 60601 etc.

·       Manufacturing processes: How to make this device?

·       Sterility: How this product is sterilized? Gamma or E-beam.

Another key concept is Traceability Matrix, all design inputs or in fact any things change or happen to the development of the device will be traced in the matrix. There are a lot of changes in the life-cycle of the medical device, therefore, the traceability matrix must be updated diligently. 

Of course, all the design requirements must be documented, reviewed and approved by designated personnel. It is prudent to involve all R&D, engineering, regulatory, chemist and even marketers so they are on board early on to give design input. Needless to say, these design input documents requirement must be approval with date and signatures.

Reference	Criteria
21 CFR 820.30(c)	Has the company established and maintained procedures to ensure 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?
21 CFR 820.30(c)	Do the procedures include a mechanism for addressing incomplete, ambiguous, or conflicting requirements?
21 CFR 820.30(c)	Are the design requirements documented, reviewed, and approved by a designated individual?
21 CFR 820.30(c)	Is the approval, including the date and signature of the individual(s) approving the requirements documented?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.

Design History File

Blog 22 will talk about Design History File (DHF) and subsequent several blogs will talk about several elements of design control of medical device. For example, Design Planning, Design Input, Design Verification and Validation, Design Changes and Design Transfer.

In a layman language, DHF is the collection and compilation of all product development from product idea, inception, design input, design output, risk management, design verification and validation and design changes. Each medical device is different and therefore the DHF may be different.

 It is also important to realize that DHF should also be updated if there are new changes occurred to the device. For example, after the launch of a medical device and tested in a real situation, there might be customers complaints and injuries that prompt the device manufacturer to change the medical device feature so to reduce the customer complaints and injuries. This new change must also be updated into the DHF.

 The following are some examples of documents that should be included in the DHF.

 ·       Design Plan and Record of plan revision, meeting minutes etc.

·       Design Product Requirement like product description, drawing etc.

·       Customer Input and requirement.

·       Design Input Requirements and all records of reviews and approvals.

·       Research, Studies, Calculations, drawings and Analysis supporting the design.

·       Protocols and reports of all design verification and validation.

·       Clinical Protocols and Reports if this is clinical research done on the device.

·       Risk Management Plan, Analysis and Reports.

·       Records of review and approval of design output documents.

·       Agenda and meeting minutes of design reviews.

·       Records of any design changes.

DHF must be updated and preserved until the medical device is no longer in the market. Even tough, the sponsor is not making the device, as long as the product is in the market, a DHF must be preserved.

Reference	Criteria
21 CFR 820.30 (j)	Has the company established and maintained a design history file (DHF) for each type of device?
21 CFR 820.30 (j)	Does the design history file (DHF) contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.

Training

Training is another important part of medical device’s quality system. Ideally all personnel must be trained well to perform their daily works. Therefore, a procedure to handle training is warranted.

The purpose of this training procedure is to provide a system, assign responsibilities, identify training needs, provide the required training and  maintain training record.

The objective of a robust training program is to ensure all employees acquire the knowledge and skills when performing their jobs. They should be conversant with the relevant requirements of the quality system pertaining to their job functions.

The training blog is subdivided into 1) Company-wide Training and Awareness Programs 2) Departmental Training and 3) Training Effectiveness and Evaluation and 4) Training Record and Documentation.

1)    Company-wide Training and Awareness Programs

Company-wide training and awareness programs are discussed sub-categorically into the following sections.

1.1  General Orientation and Quality System Training

Normally, the human resource department provides for the general orientation while training department provides the quality system training. This training make the employees familiar with administrative rules, employee program and benefits, 401K plan, vacation policy, sexual harassment etc. The training also explains the medical device products, product requirements and the quality system. The product and quality system should comprises of the following:

 ·       Discussion of the Quality Policy. Normally, even the employee badge has the quality policy printed.

·       Overview of the company’s company system. For example, 21 CFR 820 quality system for medical device plus perhaps ISO 13485.

·       Training on each product the company make. Each employee shall be trained on each product on critical quality characteristics and ramification of a failure or malfunction of the device. How the product is made etc?

·       An explanation of how individual employee contributes to the well-being of the company quality system.

1.2  Safety Training

Safety training is also important in the organization. Many of the medical devices manufacturing processes and tool, for examples can cause serious harm to the employees during production. You do not want to start a fire to burn down the facility.

Therefore, all employees are trained in safe work practices, first aid, use of personal protective equipment, emergency procedures, fire extinguisher handling, as applicable. Safety training is provided by the individual responsible for Human Resources or directly by departments. Human Resources maintain these records.

1.3  Company-Wide System

Examples of company-wide system are Trackwise system. Trackwise system is used to record CAPA, Laboratory Investigation and Deviations. Other systems are Windchill, SAP, material-coding and bar-code system.

1.4  External Training

Many medical device sponsors have educational reimbursement policy for employees to participate in seminars, conferences or even getting another advance degree or certification pertaining to the industry. For example, project manager might take the Professional Management Professional (PMP) certification to efficiently handle a project. Or an employee who is getting a M.Sc in Regulatory Affairs to know more of the regulatory affairs.

1.5  Quality and Regulatory Certification

Company encourages personnel to be certified as Regulatory Affairs Certification (RAC) especially if you are in or planning to move to the Regulatory Affairs department. Certified Quality Auditor (CQA) and Certified Quality Engineer (CQE) are also useful as a quality professional like in auditing. There are also other certification like Clinical Research Associate and the list go on and on.

2)    Departmental Training

Each department is responsible to provide the necessary training to ensure employees are skilled, capable, and competent to perform their functions in the department in question. For example, if you are in the manufacturing, may be, more training on production process validation, process capability, out of specification training, verification and validation related activities training.

On-the-job training (OJT) is another important and efficient way to train less experienced employees. There are simply not easy to learn from a procedure and protocol. OJT must be used more often. Experience in the industry tells me that OJT is important, there may be things which are difficult to be captured in the procedure.

3)    Training Effectiveness and Evaluation

Training effectiveness is often not being paid more attention. After each employee is trained and it does not mean he or she is effectively trained. Often times, employees do not think it is important. They attend the training and sign the document and considered trained. Therefore, to gauge the effectiveness of the training regiment, the approaches are shown below.

This evaluation assesses whether a particular training has achieved its objectives and if the employee is competent and skilled to perform the new job function. The evaluation is taking test and performing several productions to gauge how many products have defects. Results of all the evaluation are recorded and is kept with the original training record.

4)    Training Record and Documentation

All training records can be kept virtually and in a cabinet. In this day and age, there are many training software to be deployed so that to keep all training records like Master Control. This is particularly important for sponsor which employs thousands of employees.

21 CFR QSR (Subpart B), 60	Does the training procedures includes the identification of the training need?
21 CFR 820.20 (b)(2)	Has the company provided adequate resources, including the assignment of trained personnel, for management, performance of work, and assessment activities, including internal quality audits, to meet the requirements of this part?
21 CFR 820.25 (a)	Does the company have sufficient personnel with the necessary education, background, training, and experience to assure that all activities required for the quality system are correctly performed?
21 CFR 820.25 (b)	Have procedures been established for identifying training needs, and ensure that all personnel are trained to adequately perform their assigned responsibilities?
21 CFR 820.25 (b)(1)	As part of their training, are personnel made aware of device defects that may occur from the improper performance of their specific jobs?
21 CFR 820.25 (b)(2)	Are the personnel who perform verification and validation activities made aware of defects and errors that may be encountered as part of their job functions?
21 CFR 820.25 (b)	Does the quality system ensure that all personnel are trained to adequately perform their assigned responsibilities?
21 CFR 820.70 (d)	Has the company established and maintained requirements for the health, cleanliness, personal practices, and clothing of personnel for situations where contact could be reasonably expected to have an adverse effect on product quality?
21 CFR 820.70 (d)	Has the company ensured that temporary personnel are appropriately trained or supervised by a trained individual?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.