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.