Design History File (DHF): An Overview

Design History File (DHF) for Medical Devices: Introduction

This posts wants to provide an overview of the process of preparation of the design history file (DHF) for medical devices according to ISO 13485:2016 and other applicable regulations (such as 21 CFR 820). The design process is by far the most important one for a medical device company. It is often a very complex process, which requires knowledge of many medical device standards and regulation.

Specifically, this post takes in consideration different ISO standard and regulations to provide a comprehensive overview of the design control process for medical devices. The most significant regulations are:

• ISO 13485:2016 – Medical devices — Quality management systems — Requirements for regulatory purposes.
• IEC 62304:2006 / AMD 1:2015 – Medical device software — Software life cycle processes — Amendment 1
• ISO 14971:2019 – Medical devices — Application of risk management to medical devices. You can find here a post about the update of ISO 14971.
• IEC 62366-1:2015/AMD 1:2020 – Medical devices — Part 1: Application of usability engineering to medical devices — Amendment 1
• ISO 15223-1:2021 – Medical devices — Symbols to be used with medical device labels, labelling and information to be supplied — Part 1: General requirements
• Other regulatory requirements, as applicable.

Design History File (DHF): Organization of the Documentation.

This posts provides an example of organization of the design documentation for a medical device that includes hardware and software. We will divide the design control process in different phases and, for each phase, we provide explanation of the related documentation.

Design History File (DHF): General Process

Firstly, the design process can be considered as a “V” where starting from the user needs of the device, we arrive to the design transfer and design validation. These are the last steps necessary to bring a medical device in the market.

There are 6 different phases, which are th following:

• Project Launch : definition of the process.
• Design Inputs : the physical and performance characteristics of a device as the basis for device design. 
• Design Outputs: the results of a design effort. This consists in the phase where the development of the device is frozen.
• Verification activities. Verification is confirmation by examination and provision of objective evidence that output meets input requirements
• Design Transfer: transfer of the device specifications to the manufacturing process.
• Validation Activities: evidences of the ability to meet user needs and intended use.

Design History File (DHF) Part I: Project Launch

In this initial phase, the user needs need to be documented. Furthermore, a preliminary risk analysis can also be prepared.

Usually, in this phase there is the necessity to prepare the list of all the standard and regulations related to the medical device object of the design process.

Specifically, this phase shall contain the intended use, intended user and user populations

Moreover, in this phase, the design and development phase needs to be prepared.

Design History File (DHF) Part II: Design Input

Furthermore, in this phase there is the necessity to document the high level requirements related to the device.

From risk management point of view, there is the necessity to prepare the first version of risk analysis and the risk management plan according to ISO 14971:2019.

If the medical device contains software, in this phase the following documentation needs to be prepared, according to IEC 62304:2006 / AMD 1:2015 :

• Software development plan 
• Software Architecture Design
• SOUP or COTS Management (Off the shelf software)

This is not an exhaustive list, because the level of documentation depends from the class of risk of the software.

Furthermore, in this phase requirement specifications for hardware and software need to be documented.

Design History File (DHF) Part III: Design Output

Moreover, this phase regards the freezing of the device specification and definition of the outputs of the device.

Form risk management point of view, an initial version of the risk management report is necessary.

In this phase it is necessary to prepare the test protocol for testing HW and SW device specifications. From the HW point of view, it is important to document the BOM of the device in this phase.

From usability point of view, this phase needs to have documentation on the usability plan for both formative and summative evaluation. For this reason, an initial version of the labelling, IFU and other accompanying documents need to prepared and included in this phase.

Design History File (DHF) Part IV: Design Verification

This phase consists in performing and documenting all the verification activities for HW and SW. It includes all the verification reports for all the product requirements. Furthermore, this phase contains documentation on the formative usability evaluation of the device.

Design History File (DHF) Part V: Design Transfer

This phase corresponds to the transfer of the specification from the prototypes to the manufacturing process, so to have scalable process for production of the specific device. It includes documentation on the design transfer, the DHR (Design History Record) for the design transfer. Other documentation includes the manufacturing SOP and the device master record.

Design History File (DHF) Part VI: Design Validation

Moreover, the last phase is the validation phase. It includes all the documentation related to electrical safety and electromagnetic compatibility (if the device is a active medical device), biocompatibility, summative usability evaluation, risk management report (and traceability matrix).

This approach provides a framework for the process of design for any medical device.

Design Review

To conclude, at specific intervals, which in our case it can be at the end of each phase, it is necessary to perform design reviews. According to 21 CFR 820, design Review is a documented, comprehensive, systematic examination to:

1)Evaluate adequacy of the design requirements.

2) Evaluate capability of the design to meet requirements.

3) Identify any problems.

Attendee of the design review are: 1) Representatives of all functions concerned and specialists and 2) Individual(s) without direct responsibility for the stage being reviewed.

Document results of design review in Design History File (DHF), including identification of design, date, and individuals performing review.

Design review, along with management review, are two very important process for the QMS.

Design Control Procedure

QualityMedDev has prepared a Design Control Procedure ready to be downloaded that is fully compliant with the section 7.3 of ISO 13485:2016 and 21 CFR 820.30. The procedure provides a detailed list of documentation that is necessary to prepare to build the whole Design History File of a medical device, based on the different phases of the design process. Moreover,  the procedure provides as well guidelines for specific  documentation which are of fundamental importance for the design process, for example the design review, design and development plan or the list of applicable regulatory requirements associated to the device.

Subscribe to 4EasyReg Newsletter

4EasyReg is an online platform dedicated to Quality & Regulatory matters within the medical device industry. Have a look to all the services that we provide: we are very transparent in the pricing associated to these consulting services.

Within our WebShop, a wide range of procedures, templates, checklists are available, all of them focused on regulatory topics for medical device compliance to applicable regulations. Within the webshop, a dedicated section related to cybersecurity and compliance to ISO 27001 for medical device organizations is also present.

As one of the leading online platforms in the medical device sector, 4EasyReg offers extensive support for regulatory compliance. Our services cover a wide range of topics, from EU MDR & IVDR to ISO 13485, encompassing risk management, biocompatibility, usability, software verification and validation, and assistance in preparing technical documentation for MDR compliance.

Do not hesitate to subscribe to our Newsletter!