Assembling a

Design History File

for your medical device

© Qualio — QMS for Life Sciences

Table of Contents

What is a Design History File? 4

The essential components of a DHF 5
Design History File vs. Device Master Record vs.
Device History Record 8
DHFs for software in medical devices 9
How to prepare your DHF for an FDA or ISO audit 12
Keep your DHF organized with an eQMS 13

2
Facing an ISO 13485 or FDA 21 CFR 820 audit? Your Design
History File (DHF) is an invaluable piece of the puzzle.

A good DHF is a logical, structured and ordered compilation

of your medical device design control activities.

This guide breaks down everything you need to know about

assembling a Design History File, from key ingredients and
audit prep to where your device master records and history
records fit in.

We hope you find it useful and welcome any questions you

may have.

Kelly Stanton
Director of Quality, Qualio

3
What is a Design History File?

A Design History File is a record of all the actions and steps involved in designing
a medical device. The documentation that comes out of design control
procedures is collectively called the “Design History File” or DHF.

Prior to starting development, manufacturers must develop a design control

process. Design control refers to actions taken by a manufacturer to control the
design and development of a new medical device. Under a robust design control
process, the initial device that was intended to be designed should match the
final design without any variation unless documented. Design control processes
must be completed according to the requirements outlined in the FDA’s 21 CFR
Part 820.30 and ISO 13485:2016 about design controls. Most manufacturers
develop a set of procedures on how to follow design controls and how to
document decision making throughout the development process.

During an FDA audit, the auditor will examine each medical device’s DHF.
The auditor reviews these documents to ensure the device was developed
through a design control process. Additionally, the auditor will review internal
procedures to ensure that the procedures meet FDA regulations. A fully
documented DHF and procedures provides FDA with the confidence that the
device was developed properly and the device is safe for market.

Note: every device will need its own DHF and each DHF will be to be revised
during any changes to the design. A DHF can either be an actual file that
contains each needed component or with an electronic quality management
system (QMS), it can be a document that has a link to each part. Electronic QMS
allow manufacturers to quickly log any changes.

4
The essential
components of a DHF

For a DHF to be comprehensive, there broad and the specifics feed into the
are certain components that must be design inputs. For example, a user
included. These are: need could be “designed for use in
pediatrics.” To meet that user need, the
Design plan manufacturer will develop a series of
design inputs that will make the user need
A Design Plan is an overall plan for the “pediatric use” possible.
medical device design and product
development that outlines all the activities
necessary to conceptualize and create the
proposed product. The Design Plan will
specify details like who is responsible for
implementing each step and the order of
implementation. Additionally, the design
plan will describe how the responsible
parties will interact throughout the design
process and when they will meet.

User needs

User needs refers to all of the parameters

a user needs for a device to be successful
in the market. User needs can come from
end users, regulators and manufacturers’
desires. Typically user needs are more

5
 Design inputs Design review

Design inputs are specific physical Throughout the design process, a group
requirements for the device. The DHF of cross-functional stakeholders will
must include documentation that lists need to meet to review the DHF. These
all of the design inputs. Design inputs meetings are called “design review.” They
are developed from user needs and the must be documented and minutes must be
intended use of the device. In the pediatric captured. In this meeting the stakeholders
example, design inputs to meet the user will review the design and make a
need for pediatric use could include decision about moving forward with the
specifications for a smaller patient, color development of the product. The decision
choices to make the device more appealing must be documented as part of the DHF.
to children, or weigh less than 3 pounds to
be easily held by children. Design verification

Design outputs Design verification refers to all testing

done to ensure that the design inputs
The outcome of a design input is the meet the design outputs. All parameters
design output. In the pediatric example, identified in the design inputs must be
a design output from the design input to tested to ensure they are met by the
make a lighter design could be to utilize design outputs. In the pediatric example,
plastic components. The design output the design verification might be a test
would be all the components that are that weighs the pediatric device. The
plastic to help ensure the device remains acceptance criteria could be “the product
lightweight. The design outputs tell must weigh less than 3 pounds.” The
the story of how to make the device. design is verified if all design inputs are
Eventually the design outputs become the met by the design outputs. The technician
basis for the Device Master Record (DMR). who performs the testing must document
The DMR is used to transition the device to when the testing was performed, what
a manufacturing floor. methods were used, and the results.

6
 Design validation

Design validation refers to all testing done

to ensure the user needs are met by the
final finished medical device. This type of
testing will prove that the intended use is
appropriate and there is a clinical use for
the device. In the pediatric example, the
design validation would test whether the
device can be used for pediatric patients.
Design validation is often animal testing or
human clinical trials.

Design transfer

Design transfer outlines how the design

device is translated into production
specifications. Some manufacturers use a
design transfer checklist to ensure they’re
capturing all steps for design transfer to
production.

Design changes

Medical devices iterate and change

throughout their lifecycle. The FDA and
other regulators are aware and recognize
that medical devices will go through
changes. All design changes must be
documented using a design change
process and documented the rationale for
the change.

7
Design History File vs. Device
Master Record vs. Device
History Record

Design History Files, Device Master Records, and Device History Records
sound similar, but are separate forms of documentation that represent
different stages of the medical device development process.

The Design History File (DHF) and Device Master Record (DMR) are like
a medical device recipe and contain all of the information that’s needed
to actually make the device. The DHF contains all of the specifications,
materials, and data of the finished medical device. During development, all
documentation about design is stored within the DHF. The DMR identifies the
manufacturing steps and processes used to make the device. Once design
outputs are being evaluated, documentation is stored within the DMR.

The device history record (DHR) keeps the records of production. The DHR
contains documentation of every batch, lot, and unit made, as well as the
date and time of manufacturing. The DHR includest each device was made
according to the DMR. If a customer complaint comes in, manufacturers use
the DHR to determine what batch was affected and will alert other customers
if it affects the batch.

8
DHFs for software in
medical devices

The FDA recognizes that software in Software-related

medical devices and as a medical device, documentation
such as firmware controlling a device,
standalone software applications, and Software-related documentation includes
software that’s installed on a computer, the design of the device, how to implement
cannot always follow the traditional that design, how the device was tested,
medical device regulatory pathways and how any potential hazards were identified,
DHF structure. risk management practices, and provides
traceability.
For software in medical devices and as a
medical device, DHF documentation will Device hazard analysis
need to include the following:
Device Hazard Analysis refers to a
Level of concern software-related risk documentation,
This document includes all software or
Level of concern is an FDA term that
hardware hazards, including how severe
defines the risk associated with the
those hazards are and any mitigations that
software. There are three levels of
were taken.
concern: major, minor, and moderate.
Manufacturers must determine the Software requirements
device’s level and document the
specification
justification for level of concern. The FDA
provides guides and definitions to guide This document is very similar to the design
manufacturers through this exercise. inputs document but for the software.

9
The software requirements specifications Software development
define the requirements for installing environment description
the software properly and using the
software. This could include hardware This is a requirement only for devices with
requirements, programming language, moderate or major concern. Software
software performance, and others. The development environment is a “summary
level of detail required in this document is of the software development life cycle
dependent on the level of concern. plan.” With major-concern devices, an
annotated list of control documents
Architecture design chart created during the development process
and a list of coding standards will be
If your device is a minor concern, no included in this document.
documentation is needed here. For
moderate- and major-concern devices, Verification and validation
you’ll need detailed diagrams and/or flow (V&V) documentation
charts of the functional units and software
modules. All software related devices will need to
have documented protocols with identified
Software design specification pass/fail criteria and corresponding
reports. For devices with moderate
Again, for minor-concern devices, there
and major levels, it’s recommended to
are no requirements needed. Moderate-
list all V&V activities, results, and pass/
and major-concern devices will need to
fail criteria. In addition, the traceability
submit how the software requirements’
analysis must identify how these are linked
specifications are implemented.
to the design requirements.

Traceability analysis Revision level history

Because every input requirement and
You can show this as a line item sheet that
specification of a medical device requires
outlines each revision to the software
an output, the FDA requires documented
during development and include the date,
traceability between the requirements and
version number, and description of the
outputs. The FDA recommends showing
changes.
this through a matrix with line items.

10
 Unresolved anomalies

Manufacturers must document all

unresolved software anomalies only for
devices with moderate and major levels
of concern. Indicate each activity, the
impact to device performance, and the
timeframe for correcting the problem. The
FDA recommends an explanation for how
each anomaly could impact the device’s
effectiveness and safety.

Of note, the FDA points out that “software

not covered by this guidance includes
software designed for manufacturing or
other process-control functions, but not
intended for use as a device.”

11
How to prepare your DHF
for an FDA or ISO audit

Manufacturers who don’t maintain their documentation properly are

unprepared for an audit. Poor documentation practices typically result in
longer audits, with more findings, and a poor relationship with FDA. All of
these things can be costly and resource intensive.

To be audit-ready when the FDA comes to visit, start the documentation

process early. Begin preparing the Design History File early in the design
process to ensure it is accurate and captures all design discussions.

Create procedures that identify how to document design and development

activities. Utilize forms or templates to ensure DHF harmony between other
devices in the portfolio. Procedures, work instructions, forms, and templates
are all good ways to standardize documentation activities and ensure they
are part of the company’s culture.

Finally, consider a digital quality management approach for your design

controls and your DHF, DMR and DHR. Manual paper-based quality systems
clutter and complicate your regulatory compliance and make a single,
controlled source of truth for your design activities difficult.

Digital design control management eliminates the manual headache of

sourcing design data from disparate systems and helps you generate an
automated DHF in real time.

12
Keep your DHF organized
with an eQMS

By using a quality management system designed for life sciences

companies, manufacturers can store and maintain DHFs in software
designed with regulatory compliance top of mind. Qualio’s quality
management platform is made to scale with medical device start-ups
and has built-in features and templates to help manage and accelerate
your product development process.

Need regulatory help? Our Qualio+ team of seasoned quality experts

are standing by.

We got set up very quickly. I was alone as quality manager, so I really appreciated the
support by Qualio and especially Sumatha. Sometimes I didn’t have time to create
an ISO 13485 process from scratch, so I asked if she could produce a template. And
that’s what she did. The support was great.
— Mohamad El Zein
Quality Manager, Ender Diagnostics

13
See our medical
device quality
management
software in action
Schedule a demo with us

Call us today
1.855.203.2010 • +353 1 697 1522